Looking for a specific bug in jira - was Sonus and RFC 2833 related
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
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:
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!
On Wed, Dec 31, 2008 at 2:24 PM, Brian West <brian@freeswitch.org> wrote:
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
Brian, 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
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:
On Wed, Dec 31, 2008 at 2:24 PM, Brian West <brian@freeswitch.org> wrote:
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
Brian,
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
_______________________________________________ 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
On 12/31/08, Michael Jerris <mike@jerris.com> wrote:
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
Mike, Thanks but I (think) I basically figured it out... I am using G.729 and RFC 2833 DTMF. If you send a 2833 event and voice packet with the same timestamp Sonus will drop the event (maybe both) EVEN IF they have different sequence numbers. Nevermind that this behavior (same timestamps) is quite possible and even desired in some cases and violates both RFC 1889/3550 and RFC 2833/4733. I didn't dig into the code but it looks like the Freeswitch workaround just tweaks the timestamps to get around this if a Sonus originator is detected (by parsing the SDP). Nice. Did I get it? -- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com
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> wrote:
On 12/31/08, Michael Jerris <mike@jerris.com> wrote:
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
Mike,
Thanks but I (think) I basically figured it out...
I am using G.729 and RFC 2833 DTMF.
If you send a 2833 event and voice packet with the same timestamp Sonus will drop the event (maybe both) EVEN IF they have different sequence numbers. Nevermind that this behavior (same timestamps) is quite possible and even desired in some cases and violates both RFC 1889/3550 and RFC 2833/4733.
I didn't dig into the code but it looks like the Freeswitch workaround just tweaks the timestamps to get around this if a Sonus originator is detected (by parsing the SDP). Nice.
Did I get it?
-- 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
On 12/31/08, Anthony Minessale <anthony.minessale@gmail.com> wrote:
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 =(
Anthony, Thanks for the pointer. It's nice to also know that I won't be able to implement *proper* jitter buffering in my network as long as Sonus is involved somewhere in the call path. Sheesh. -- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com
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> wrote:
On Wed, Dec 31, 2008 at 2:24 PM, Brian West <brian@freeswitch.org> wrote:
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
Brian,
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
_______________________________________________ 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
On 12/31/08, Anthony Minessale <anthony.minessale@gmail.com> wrote:
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. */
Thanks Anthony! -- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com
participants (4)
-
Anthony Minessale
-
Brian West
-
Kristian Kielhofner
-
Michael Jerris