4 Replies Latest reply on Mar 28, 2014 10:12 AM by ftwrobert

    Forcing a specific codec to prevent a SIP re-invite

    ftwrobert New Member

      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"


        codec-list G711u


      no voice fax-tone t38 v21-preamble


        • Re: Forcing a specific codec to prevent a SIP re-invite
          jayh Hall_of_Fame

          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

                                                                 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. 

            • Re: Forcing a specific codec to prevent a SIP re-invite
              ftwrobert New Member

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

            • Re: Forcing a specific codec to prevent a SIP re-invite
              david Employee



              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



              1 of 1 people found this helpful