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 12/31/08, Michael Jerris <mike@jerris.com> wrote:Mike,
> 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
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