I have got a very strange issue. Recently fax passthrough uing G.711a to a local fax server stopped working. It has been used in our environment in this way for several years and I am not aware of any change to the gateway configuration that would explain this behaviour.
It appears that the reason for failure is that after negotiating G.711a, the gateway (Cisco 2901 ISR, IOS 15.7(3)M5, DSP version is 46.2.12) starts sending G.729 packets. I suspect it is marking them with an incorrect payload type (18), rather than actually sending G.729 data as this makes no sense at all, and G.729 is not enabled or used anywhere within the entire environment, and this is even more illogical when fax is involved as G.729 is obviously totally incompatible.
Please refer to below, last SIP message from the gateway (192.168.100.1) and first RTP packet from the gateway which follows. In this test scenario, 182 is a fax machine (sender), plugged into an FXS port for testing, and 180 (192.168.100.5) is the fax server.
A couple of questions for those who may understand this a little better:
* Is it possible that Wireshark is misunderstanding the data and has just completely got it wrong - i.e. it's not payload type 18 (G.729)?
* Has anyone seen this strange issue before?
INVITE sip:180@192.168.100.5:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.100.1:5060;branch=z9hG4bK222388
From: "FXS 2" <sip:182@xxx.com>;tag=8CD00-79B
To: <sip:180@192.168.100.5>
Date: Thu, 06 Feb 2020 14:21:03 GMT
Call-ID: BDB56258-482211EA-804B87DF-ADD16460@xxx.com
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 3165861361-1210192362-2152105951-2916181088
User-Agent: Cisco-SIPGateway/IOS-15.7.3.M5
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1580998863
Contact: <sip:182@192.168.100.1:5060>
Expires: 180
Allow-Events: telephone-event
Call-Info: <sip:192.168.100.1:5060>;purpose=X-cisco-forkingcapable
Cisco-Gcid: BCB335F1-4822-11EA-8046-87DFADD16460
Session-ID: c76ea68986fe517093d47f1f5b045d49;remote=00000000000000000000000000000000
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 250
v=0
o=CiscoSystemsSIP-GW-UserAgent 8299 9209 IN IP4 192.168.100.1
s=SIP Call
c=IN IP4 192.168.100.1
t=0 0
m=audio 16386 RTP/AVP 8 101
c=IN IP4 192.168.100.1
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
Real-Time Transport Protocol
[Stream setup by SDP (frame 3125)]
10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False
...0 .... = Extension: False
.... 0000 = Contributing source identifiers count: 0
1... .... = Marker: True
Payload type: ITU-T G.729 (18)
Sequence number: 3216
[Extended sequence number: 68752]
Timestamp: 3675360086
Synchronization Source identifier: 0x07676401 (124216321)
Payload: f98d8ca000fadd758094e01000a733f2f13117d650c2c0a0…
By the way the "show call act voice compact" command on the gateway shows the codec as "None", not G711a which I could swear is what it used to show for these sort of calls.
