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"/>
FreeSWITCH to Sonus testing paths
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:
分享到:
相关推荐
.NET 解析rtp数据包,c#解析rtp包
该工具可以用于媒体服务器开发,模拟信令服务发送RTP码流,调试RTP媒体功能。实现信令和媒体分离同步开发. 使用方式 如: rtpplay.exe -T -f RTP文件名 -s 发送端口号 目的IP地址/目的端口号,如 rtpplay.exe -T -f ...
最小RTP数据传输测试程序,包括发送、接收
RTP中文版 实时流协议(RTSP) RTP:实时应用程序传输协议
C语言头文件 RTPC语言头文件 RTPC语言头文件 RTPC语言头文件 RTPC语言头文件 RTPC...RTPC语言头文件 RTPC语言头文件 RTPC语言头文件 RTPC语言头文件 RTPC语言头文件 RTPC语言头文件 RTPC语言头文件 RTPC语言头文件 RTP
使用Wireshark导出符合http://www.cs.columbia.edu/irt/software/rtptools/所指定的rtp流的步骤
RTP协议详细规格,内置RTP协议基本实现原理和参数指标
通过tcpdump或者wireshark抓到的包通常是rtp流,保存为.pcap格式文件后中,可通过wireshark进行解析,得出h264裸流,并保存为文件。 我这里有一段rtp流文件,作为演示使用(这个文件有点不标准,一般一个nal打一个...
RTP使用的demo,包含客户端和服务端
1,rtpplay:Play back RTP sessions recorded by rtpdump 2,rtpsend: Generate RTP packets from textual description, generated by hand or rtpdump 3,rtpdump: Parse and print RTP packets, generating ...
这是一篇论文,描述了如何从rtp协议往rtmp协议转换的实现细节和意义。
基于C语言编写的H264打包成RTP的源码!txt文本形式
wireshark检测RTP丢包
java rtp 接受发送声音
C# RTP.NET SDk demo
1、解析rtpdump文件获取rtp包。 2、将rtp包解为hevc/h265裸流并存为265文件。 资源是一个完整的vs2012工程。 对应的CSDN博文http://blog.csdn.net/andyshengjl/article/details/79330610
RTP PayloadType类型整理 RTP PayloadType类型整理
android studio 通过 rtp 发送和接收demo 主要是将官网中的jlibrtp 0.2.2协议包含的例子引用到工程中 demo中采用局域网广播的形式来发送数据 指定的ip需要自己去尝试
描述RTP协议以及如何编写RTP程序,帮助深入理解RTP协议和相关编程方法
g711音频文件封装rtp格式传输,vlc接收可以播放。