Summary:ASTERISK-00622: [tracking] Sip to Sip call quality with latent networks
Reporter:denon (denon)Labels:
Date Opened:2003-12-05 03:32:29.000-0600Date Closed:2004-09-25 02:53:45
Versions:Frequency of
Description:I was playing with a Grandstream on a remote network (about 8 hops away, 22ms or so), which I figured should be about ideal conditions.  However, we're having problems with choppy voice talking to a local to * lan user on a 7960.  The 7960 heard most of the choppy voice, the grandstream end (on the cable) sounded fine for the most part. Bandwidth was fine.

I talked to Mark, and it sounds like it's really a design issue.  He said when the call is sip to sip, the timestamp is munged, and with a little latency, that's gonna happen.  I won't really happen if you're terminating to a zap.  I believe it's the same story in IAX, but I'm not sure.

I figured I'd throw it up here in case anyone else had some time to dig into it.
Comments:By: pliew (pliew) 2003-12-14 15:15:29.000-0600

I'm not sure whether its a native SIP issue. We have a few external extensions on our system, in locations from Melbourne, Brisbane (in Australia) and in Hong Kong, with varying latencies from 20ms to 180ms (figures from qualify in sip show peers). All using Grandstreams, no choppiness, even the latency is not noticable. Might have something to do codecs and the phones used. Try replacing the 7960 with a GS phone and see what happens. Just our experiences.

By: John Todd (jtodd) 2003-12-21 09:24:35.000-0600

Yeah, I'm not sure what's going on with this either.  I push calls cross-continent to GS phones, at 140ms latency on a regular basis, with 7960's on either side (in fact, in the exact configuration as described above, along with a few others.)  I have had no chop problems except those due to network issues.  Denon - try reversing the locations of the GS phone and the 7960 and see if it's consistent.  Try sending out a Zap channel.  I think this is jitter introduced by the network _only in one direction_, though Mark's comments are interesting.  More data needed.

By: zoa (zoa) 2004-01-10 20:40:56.000-0600

If this isnt fixed already maybe this is something for 0.7.0 ?

By: denon (denon) 2004-01-26 16:19:16.000-0600

[16:01] <bkw_> denon go comment on it so its up on top when we go to lookin thru these bitches

By: z_smurf (z_smurf) 2004-02-16 19:43:14.000-0600

I found this on the wiki for SIP.conf:

"Asterisk uses the incoming RTP Stream as a timing source for sending its outgoing Stream. If the incoming stream is interrupted due to silence suppression then musiconhold will be choppy. So in conclusion, you cannot use silence suppresion. Make sure ALL SIP phones have disabled silence suppression."

This mean that a connection with some packetloss in the direction Phone --> Asterisk not only causes the sound from phone to asterisk to be choppy, but also the media back to phone.

Is it possible to introduce a local timing source to Asterisk to reduce the choppiness over bad networks? Is there a reason to depend on the recieveing datas timer?

By: Olle Johansson (oej) 2004-03-21 11:32:21.000-0600

Still a problem in the current CVS code?

By: Mark Spencer (markster) 2004-03-27 12:34:50.000-0600

This is the very issue that is fixed by the timestamp carrying stuff.  There is a tracking bug for problems people still might be having with it.