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?



--
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/

AIM: anthm
MSN:anthony_minessale@hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
iax:guest@conference.freeswitch.org/888
googletalk:conf+888@conference.freeswitch.org
pstn:213-799-1400