In case you want to know the nitty gritty.
excerpt from switch_types.h
RTP_BUG_SONUS_SEND_INVALID_TIMESTAMP_2833 = (1 << 1)
/*
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.
This flag will cause each packet to have a new timestamp.
*/
On Wed, Dec 31, 2008 at 2:24 PM, Brian West <brian@freeswitch.org> wrote:Brian,
> I would recommend getting the latest SVN since we had to break out the
> cisco and sonus rtp issues... Try this http://wiki.freeswitch.org/wiki/RTP_Issues
>
> /b
>
Thanks, I have and I was well aware of these (I've been lurking).
However, my issue is with another platform and Sonus. I want to
demonstrate that this is a *known* issue with Sonus gear. Plus, I
found it:
http://jira.freeswitch.org/browse/FSCORE-251
Thanks again!
--
Kristian Kielhofner
http://blog.krisk.org
http://www.submityoursip.com
http://www.astlinux.org
http://www.star2star.com
_______________________________________________