VoIP Mailing List Archives

[kristian.kielhofner at...]

Hey everyone,

A few days ago I was reading about a bug with Sonus gear and
FreeSwitch. I remember it because Tony implemented a workaround the
buggy Sonus gear based on the SDP, all while adding a snarky (yet
hilarious) log message.

You guessed it, I'm having 2833 timestamp problems with Sonus...

I can't find this issue for the life of me in Jira. Does anyone
know where it is? It was fixed in rev 10744 with the commit message
"sonus, sonus, sonus sonus is a four letter word".

Thanks!

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

_______________________________________________
Freeswitch-users mailing list
Freeswitch-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

[brian at freeswitch.org]

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

On Dec 31, 2008, at 12:44 PM, Kristian Kielhofner wrote:

[kristian.kielhofner at...]

On Wed, Dec 31, 2008 at 2:24 PM, Brian West <brian@freeswitch.org> wrote:

[mike at jerris.com]

If your looking for specifics of where they are being stupid and/or
violating rfc's pop on by and let us know, we can probably detail some
stuff that is not in the bugs as well.

Mike

On Dec 31, 2008, at 3:14 PM, Kristian Kielhofner wrote:

[kristian.kielhofner at...]

On 12/31/08, Michael Jerris <mike@jerris.com> wrote:

[anthony.minessale at g...]

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:14 PM, Kristian Kielhofner <kristian.kielhofner@gmail.com (kristian.kielhofner@gmail.com)> wrote:

[kristian.kielhofner at...]

On 12/31/08, Anthony Minessale <anthony.minessale@gmail.com> wrote:

[anthony.minessale at g...]

in case you want to know the other big annoying one:

If you suddenly change timestamp base mid call, sonus will lose 2 sec of audio trying to adjust.

Say you have an ivr that asks you to dial an ext then places the call.
While the ivr is the far end and interacting with the sonus there is a series of timestamps generated by FS.
Then when the call is placed we start passing through the timestamps from the new farther far end so the jitter can
be preserved. (if we rewrite the timestamps to our original ones, any jitter would be locked in place).

With sonus, you pretty much have to set FS to rewrite the timestamps or live with the audio drop =(




On Wed, Dec 31, 2008 at 3:01 PM, Kristian Kielhofner <kristian.kielhofner@gmail.com (kristian.kielhofner@gmail.com)> wrote:

[kristian.kielhofner at...]

On 12/31/08, Anthony Minessale <anthony.minessale@gmail.com> wrote: