[asterisk-dev] RTP interop with Sonus: hack

[Kristian Kielhofner]

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?

-- 
Kristian Kielhofner
http://blog.krisk.org
http://www.submityoursip.com
http://www.astlinux.org
http://www.star2star.com