Forcing a specific codec to prevent a SIP re-invite

[ftwrobert]

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

!

[jayh]

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. 

[ftwrobert]

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).

[Anonymous]

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

[ftwrobert · Accepted solution]

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!