Known issues with RTP

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.

[ edit]

Known issues with SDP

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