It looks like the SBC doesn't support G.711u or is misconfigured. You specify PCMU/8000 and the SBC responds with no codec.
Look at the 200OK coming back from the SBC.
11:53:29.880 SIP.STACK MSG Rx: UDP src="pub_ip_of_sbc":5060 dst="pub_ip_of_TA900":5060 11:53:29.880 SIP.STACK MSG SIP/2.0 200 OK
11:53:29.882 SIP.STACK MSG Content-Type: application/sdp 11:53:29.883 SIP.STACK MSG 11:53:29.883 SIP.STACK MSG v=0 11:53:29.883 SIP.STACK MSG o=- 1517670118 1517670118 IN IP4 "pub_ip_of_sbc" 11:53:29.883 SIP.STACK MSG s=- 11:53:29.883 SIP.STACK MSG c=IN IP4 "pub_ip_of_sbc" 11:53:29.883 SIP.STACK MSG t=0 0 11:53:29.883 SIP.STACK MSG m=audio 53204 RTP/AVP 0 101 11:53:29.884 SIP.STACK MSG a=rtpmap:101 telephone-event/8000 11:53:29.884 SIP.STACK MSG a=ptime:20 11:53:29.884 SIP.STACK MSG a=nortpproxy:yes
Note that the SDP of the OK has no codec specified. I would expect to see
within the SDP. Because the codec wasn't negotiated the TA900 sends a reinvite. SBC again responds with no codec and we give up.
P.S. Excuse the looks of this reply! I hate the automatic formatting where copy/paste turns into some horrid form of a table that's impossible to edit.
I was under the impression the m= (Media Descriptions) is what was used to set up the codec. Where 0 is PCMU. RTP audio video profile - Wikipedia, the free encyclopedia
According to RFC 2833:
The RTP payload format is designated as "telephone-event", the MIME
type as "audio/telephone-event". The default timestamp rate is 8000
Hz, but other rates may be defined. In accordance with current
practice, this payload format does not have a static payload type
number, but uses a RTP payload type number established dynamically
I don't think this is a problem with negotiating the codec; On the second INVITE/OK, there's a 20 second gap where audio is being sent from the TA908 before it gives up and sends the BYE. (I presume it gives up because it's not receiving any fax tones back, as it's sending it's media to a non-routable IP).
1 of 1 people found this helpful
Thanks for posting! I just wanted to add a few more details regarding your scenario. Part of the standard operation of "modem-passthrough" is to re-INVITE when fax/modem tones are detected. This setting is what we recommend in your case, so it might be best to attempt to fix the reason for the re-INVITE not being allowed on the SBC. However, you could turn off "modem-passthrough" and attempt the Static Provisioning described in Configuring and Troubleshooting Fax and Modem Calls in AOS. Keep in mind that static provisioning should only be used if the port is used exclusively for faxing. To attempt this configuration, you could add the following to your existing configuration.
voice user 5415550000
We've fixed the reINVITE issue at this point and I will commence testing, I do have the config working by by-passing the SBC all together and communicating directly with our Metaswitch, so it should be just a few minor changes from here.
I appreciate your help!