Contents [ hide ] 1 Overview 2 Devices with Issues 2.1 Sonus 2.1.1 Carrier Info 2.1.2 Dropped Audio 2.1.3 DTMF Problems 2.1.4 Other Options 2.1.5 See also

Overview

RTP issues can be difficult to diagnose without a healthy amount of packet captures, etc.

Devices with Issues

Sonus

Carrier Info

Carriers known to be using this device: L3, WilTel, Bandwidth.com, Broadvox, Global Crossing, XO, and Qwest.

• 19:40, 9 December 2008 (PST)
• Known to support exactly 729 with rfc2833 OR 711u with DTMF inband .
  • If you're using FreeSWITCH then you'll be stuck using 711u (PCMU) with DTMF inband. ( also rfc2833 look below how )
• Dropped audio infrequently. Anthony discovered that they have a +500ms response time if you STOP streaming RTP data to the carrier.

Whatever hardware they use has a list of reasons to reset.

• Causes:
  • If your installation of FreeSWITCH want to change timestamp base and send them mark bit, they reset with 2 seconds of silence.
  • If you send 2833 on it's own timestamp base it resets.

Dropped Audio

If you are suffering from dropped audio, specifically regarding the first 2-3 seconds of a single audio stream then try the following: In conf/vars.xml

    <!-- This will continue a steady stream of RTP to the Sonus device and your dropped audio will nearly diminish -->
<X-PRE-PROCESS cmd="set" data="send_silence_when_idle=400"/>

  

In sip_profiles/internal.xml Make sure you are running a FreeSWITCH version newer than Dec. 9th, 2008

    <!--This will rewrite all new timestamps instead of passing them from the other leg.-->
<param name="rtp-rewrite-timestamps" value="true"/>

  

DTMF Problems

If you are having DTMF problems and Sonus is in your media path , you should make sure you are using the latest version of FreeSWITCH. As of FreeSWITCH revision 10744, FreeSWITCH auto-detects Sonus end-points and applies a hack to "fix" the issue. The hack is described as follows (from switch_types.h):

    Sonus wrongly expects that, when sending a multi-packet 2833 DTMF event, the sender should
increment the RTP timestamp in each packet when, in reality, the sender should send the
same exact timestamp and increment the duration field in the 2833 payload. This allows a
reconstruction of the duration if any of the packets are lost.

final_duration - initial_timestamp = total_samples

However, if the duration value exceeds the space allocated (16 bits), the sender should
increment the timestamp one unit and reset the duration to 0.

Always sending a duration of 0 with a new timestamp should be tolerated but is rarely
intentional and is mistakenly done by many devices. The issue is that the Sonus expects
everyone to do it this way instead of tolerating either way. Sonus will actually ignore
every packet with the same timestamp before concluding if it's DTMF.

  

Note that the version of FreeSWITCH which has this patch auto-detects Sonus, so you don't need to configure anything.

If you are going through a provider who uses Sonus only as an SBC and not in your media path FreeSWITCH may incorrectly identify your call as going through Sonus and actually corrupt your media stream's DTMF. You can override FreeSWITCH's auto-detection ofend-user agents with a flag in your sip_profiles/ profiles. Just add:

    <param name="auto-rtp-bugs" value="clear"/>

  

In some cases, you may have the reverse situation where Sonus or Cisco equipment sits in your media path, but FreeSWITCH can't auto-identify it. In that case, try these settings:

    <param name="auto-rtp-bugs" value="CISCO_SKIP_MARK_BIT_2833"/>

  

if you are having trouble with Cisco equipment. For Sonus, try:

    <param name="auto-rtp-bugs" value="SONUS_SEND_INVALID_TIMESTAMP_2833"/>

  

If your Call to a Sonus still won't work

For those of you who have tried the auto-rtp-bugs and still cannot get DTMF to work for G711 negotiated calls, there appears to be an issue with the Sonus using Fax treatment which drops the out of band DTMF packets that come from FreeSWITCH (among other platform). Some more in depth information for Sonus users (at least for 5.0 and 5.1 users, I can't speak for those who may have the latest and greatest code revisions which may fix this) is below.

In the GSX Navigator (Sonus Insight), go to Sonus→Profiles→Packet Service Profiles→default. You may have some changes made to the Fax Treatment/Failure section. To resolve the DTMF you will have to change that to match the below examples.

An example of a base profile that will not work:

    Audio Encodings:          G.711      DTMF      Modem        Fax             
                Pkt Size/ Law/       Relay/    Treatment/   Treatment/      
Priority Codec  Code Rate Send SID   Remove    Failure      Failure         
3        G711SS 20        LAWFROMCIR NONE      G711FALLBACK 
    
      G711FALLBACK
    
        
                0BPS      DISABLED   DISABLED  CONTINUE     CONTINUE        
4        G711   20        LAWFROMCIR NONE      G711FALLBACK 
    
      G711FALLBACK
    
        
                0BPS      DISABLED   DISABLED  CONTINUE     CONTINUE    

  

What you would need to change it to, to fix the DTMF:

    Audio Encodings:          G.711      DTMF      Modem        Fax             
                Pkt Size/ Law/       Relay/    Treatment/   Treatment/      
Priority Codec  Code Rate Send SID   Remove    Failure      Failure         
3       G711SS  20        LAWFROMCIR NONE      G711FALLBACK 
    
      
        FAXRELAYORG711FA
      
    
    
                0BPS      DISABLED   DISABLED  CONTINUE     CONTINUE        
4       G711    20        LAWFROMCIR NONE      G711FALLBACK 
    
      
        FAXRELAYORG711FA
      
    
    
                0BPS      DISABLED   DISABLED  CONTINUE     CONTINUE        

  

The above profile will work if you are sending direct to the GSX using the dtg=TRUNKGROUP protocol. If you are routing your calls to the PSX, then you would make the appropriate changes to the Preferred Packet Service Profile that is attached to the trunk group that you are a) sending from or b) sending to.

It's a crazy world out there.

Other Options

    <!-- This will use the async timer (this one you can also set to none if you don't want asynchronous RTP traffic) --> 
<param name="rtp-timer-name" value="soft"/>

<!--
        RTP_BUG_SEND_LINEAR_TIMESTAMPS = (1 << 3),
    
          Our friends at Sonus get real mad when the timestamps are not in perfect sequence even during periods of silence.
          With this flag, we will only increment the timestamp when write packets even if they are eons apart.
    
        RTP_BUG_START_SEQ_AT_ZERO = (1 << 4),
    
          Our friends at Sonus also get real mad if the sequence number does not start at 0.
          Typically, we set this to a random starting value for your saftey.
          This is a security risk you take upon yourself when you enable this flag.
    
        RTP_BUG_NEVER_SEND_MARKER = (1 << 5),
    
          Our friends at Sonus are on a roll, They also get easily dumbfounded by marker bits.
          This flag will never send any. Sheesh....
-->
<param name="manual-rtp-bugs" value="SEND_LINEAR_TIMESTAMPS|START_SEQ_AT_ZERO|NEVER_SEND_MARKER"/>


    

      
        See also 
      
    
    

      For more information on these and other Sonus issues: 
    
  

• http://www.submityoursip.com/wiki/Sonus_NBS
• http://blog.krisk.org/2009/02/update-youve-been-waiting-for.html
• http://www.freeswitch.org/node/160

RTP Issues