1) Sonus requires all RTP packets (events or voice) to have unique timestamps. The RFCs specifically state that not only is it valid to use the same timestamp for various RTP packets, it is ideal in some cases (like events, for example).
2) The RFC 2833 events generated by Sonus equipment are goofy, to put it lightly. The event duration increments do not match the packetization of the voice stream as stated in RFC 2833 and elaborated on in RFC 4733. Specifically, Sonus equipment increments RFC 2833 duration 80 samples at a time as if the voice stream is 10ms (regardless of what it actually is). I don't know of any other implementations that do this. Even when the audio stream is *clearly* 20 ms (in the SDP, too) Sonus will continue to increment 80 samples at a time.
3) The most recent (and biggest problem) has been caused by the Sonus (seemingly arbitrary) requirement that there never be greater than 100ms gaps in RTP. This is inherently broken behavior for robustness in IP networks.
4) Sonus has yet another issue with RTP timing and sequencing... If a call is brought up with an endpoint that clocks it's own RTP stream (IVR server, for example) everything will be fine. Until the IVR server (or whatever) bridges that channel to another device that also clocks its own RTP. Sonus (probably related to #3 above) will lose sync and drop audio for up to several seconds while it catches up to the new RTP stream. This requires those of us that work with Sonus equipment to rewrite all timestamps and sequence numbers on our equipment; which has the adverse effect of less than optimal jitter buffering (which should ideally be done at each far endpoint).
(above taken from [1])
5) Various issues with packetization. According to bkw from Freeswitch Sonus does not respect ptime in the SDP (even if they set it).
Freeswitch will auto detect Sonus_uac and implement various workarounds. Some issues (such as 4 + 5) still need to be dealt with.
Asterisk has changed its default behavior for timestamps as of 1.4, 1.6, and trunk (SVN mid-December). However, if DTMF needs to traverse Asterisk core (as noted above) you may still have issues.
Known issues with SDP
- Missing mandatory 'connection information', and invalid order of lines:
SDP Offer sent to Sonus
v=0
o=userX 196 1 IN IP4 10.0.0.1
s=-
c=IN IP4 10.0.0.1
t=0 0
m=image 50328 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:4000
a=T38FaxMaxDatagram:1008
a=T38FaxUdpEC:t38UDPFEC
a=T38FaxUdpEC:t38UDPRedundancy
m=audio 50328 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20
a=silenceSupp:off - - - -
Invalid SDP Answer received from Sonus (lines starting with ## are editor's comments):
v=0
o=Sonus_UAC 19813 20746 IN IP4 192.168.0.1
s=SIP Media Capabilities
t=0 0
m=image 0 udptl t38
## 'c=' is expected here because it was not provided in the 'session' section above
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:4000
a=T38FaxMaxDatagram:1008
## If T.38 is disabled, why 'sendrecv' attribute is provided?
## (Moreover the attribute does not make sense for T.38.)
a=sendrecv
m=audio 6042 RTP/AVP 0
a=rtpmap:0 PCMU/8000
## 'c=' must precede any 'a=' lines.
c=IN IP4 192.168.0.2
a=sendrecv
a=maxptime:20
Not all Sonus end-points reply with invalid SDP. Hopefully, the ones that construct correct answers use newer firmware, and eventually (when all VoIP providers using Sonus equipment will have performed the firmware upgrade) the issue will disappear. So far, your SDP parser must be very permissive if you want to communicate with all versions of Sonus equipment successfully.
See SDP RFC and An Offer/Answer Model with the SDP for more information.
分享到:
相关推荐
.NET 解析rtp数据包,c#解析rtp包
Similation of networks with RTP
该工具可以用于媒体服务器开发,模拟信令服务发送RTP码流,调试RTP媒体功能。实现信令和媒体分离同步开发. 使用方式 如: rtpplay.exe -T -f RTP文件名 -s 发送端口号 目的IP地址/目的端口号,如 rtpplay.exe -T -f ...
最小RTP数据传输测试程序,包括发送、接收
RTP中文版 实时流协议(RTSP) RTP:实时应用程序传输协议
This document species an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the ...
C语言头文件 RTPC语言头文件 RTPC语言头文件 RTPC语言头文件 RTPC语言头文件 RTPC...RTPC语言头文件 RTPC语言头文件 RTPC语言头文件 RTPC语言头文件 RTPC语言头文件 RTPC语言头文件 RTPC语言头文件 RTPC语言头文件 RTP
RTP协议详细规格,内置RTP协议基本实现原理和参数指标
RTP使用的demo,包含客户端和服务端
使用Wireshark导出符合http://www.cs.columbia.edu/irt/software/rtptools/所指定的rtp流的步骤
基于C语言编写的H264打包成RTP的源码!txt文本形式
通过tcpdump或者wireshark抓到的包通常是rtp流,保存为.pcap格式文件后中,可通过wireshark进行解析,得出h264裸流,并保存为文件。 我这里有一段rtp流文件,作为演示使用(这个文件有点不标准,一般一个nal打一个...
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# RTP.NET SDk demo
描述RTP协议以及如何编写RTP程序,帮助深入理解RTP协议和相关编程方法
rtp rtcp 资料
java rtp 接受发送声音
RTP开发包,可以用它轻松实现媒体数据的RTP格式分发.
RTP PayloadType类型整理 RTP PayloadType类型整理