[asterisk-dev] RTP interop with Sonus: hack

[John Todd]

On Jan 5, 2009, at 12:46 PM, Kristian Kielhofner wrote:

> Hello everyone,
>
>  I'm dealing with some Sonus equipment and I've run into the infamous
> Sonus RTP timestamp problem.
>
>  A brief overview for those who might not be familiar:
>
>  Sonus gateways will discard ANY RTP packets that have the same
> timestamp, even if they are completely different and have the sequence
> number properly incremented.  This is in violation of various RFCs.
> Try to get Sonus to do anything about it...
>
>  This usually manifests itself as an RFC2833 DTMF problem.  Currently
> if a Sonus gateway receives an RFC2833 event with the same timestamp
> as a voice packet the event (quite possibly the voice packet too) is
> dropped even though technically, per the RFCs, this is legitimate and
> in some cases preferred behavior (sending two packets with the same
> timestamp).  Even if the sequence numbers are different and the
> duration changes (as is proper with RFC2833 events of variable length)
> Sonus will drop at least the non-voice packet on the floor.
>
>  I don't know how they expect variable length RFC2833 events to work
> with their implementation; by spec these events have the same
> timestamp and sequence number (only increasing the duration).  I
> suppose their RFC2833 handler could process subsequent duration
> updates for RFC2833 events only AFTER an RFC2833 event is handled with
> a unique timestamp.  Yeah, or something like that.
>
>  Either way, what a mess.
>
>  I would like to point out this has nothing to do with any of the
> RFC2833 stuff that has been happening in Asterisk from 1.2 -> on.
> None of the existing options (rfc2833compensate, etc) will help with
> this issue.
>
>  Actually, after looking at this issue for some time I can say that
> Asterisk appears to be as compliant as could be expected given the
> RFCs.  Kudos to you guys for this new RFC2833 implementation.
>
>  I'm looking to get around this a few different ways:
>
> 1)  Detect Sonus UAC from the SDP and enable "the workaround", which
> is to always use different RTP timestamps for EVERY packet.
>
> 2)  Provide a SIP peer option to always use "the workaround"
> (different timestamps for each and every RTP packet sent).  While this
> is a bit of a hammer it shouldn't cause problems with other
> implementations. Actually if this is the behavior Sonus is expecting
> one would think other implementations actually do this by default (as
> wrong as it might be).
>
> 3)  Any better and/or more elegant ideas?
>
>  What have other people done to successfully interop with Sonus gear?
>
> Comments?



Perhaps a hack that will look for RFC2833 packet events and squelch  
any RTP media packets that have the same timestamp?  RFC2833 packets  
"win".  This could be a comparison right before transmission.  Don't  
worry about making unique timestamps, just kill off audio packets that  
have same-time duplicates in RFC2833.  A bit of media packet loss on  
duplicates during RFC2833 should be minimal enough that it would not  
be a problem for stats, and clients are squelched during DTMF  
transmission anyway so they are not expecting to have perfect audio  
during those events anyway.

This might be possible to do with no serious downside all the time, so  
no detection needed or special fiddling around required.  Maybe.   
Opinions?

JT

---
John Todd                       email:jtodd at digium.com
Digium, Inc. | Asterisk Open Source Community Director
445 Jan Davis Drive NW -  Huntsville AL 35806  -   USA
direct: +1-256-428-6083         http://www.digium.com/