I am trying to configure a voice user to always use G.711u, that way, when sending a fax, there's no re-invite.
Currently, a re-invite isn't possible as our SBC doesn't correctly handle the SDP. (ruling out the use of t.38 as well)
Below is the relative config; attached is an example sip capture with the re-invite.
!
voice codec-list G711u
codec g711ulaw
!
voice trunk T00 type sip
description "SBC1 - SIP to PRI/POTS"
sip-server primary xx.xx.xx.xx
registrar primary xx.xx.xx.xx
codec-list G711u both
!
voice user 5415550000
connect fxs 0/3
password encrypted "3a3e1cc71c0f808a7a5ca64d5ad31b5a2cc9"
did "5415550000"
sip-identity 5415550000 T00 register auth-name "5415550000" password encrypted "2e2409467xj74896fa151f71ad8ddb4dbeae"
sip-authentication password encrypted "2622b51652bff45f7jx6fucace18e9162d35"
modem-passthrough
codec-list G711u
!
no voice fax-tone t38 v21-preamble
!
Thanks David!
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!
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 |
[snip]
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
a=rtpmap:0 PCMU/8000
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
and out-of-band.
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).
Ftwrobert,
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
no echo-cancellation
no modem-passthrough
Thanks!
David
Thanks David!
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!