I need to debug a call quality issue with remote users on the other end of a satellite link. The symptoms are: we here on the Internet side can hear them just fine. On their end, things work sorta OK most times, but they often suffer from severe dropouts and digital warbling, both of which I attribute to them missing packets. Often times they can't make out a word we are saying while we can hear them crystal clearly. Various pings and other network tests indicate that the underlying network is functioning as well as can be expected for a sat link. In fact, the overall jitter seems to be pretty low (avg 20ms). Packet loss is around 1-2%, and latency is around 700ms on average. I'm left to assume that the jitter buffer on that end isn't functioning properly. Both ends of the call have the same jitter buffer settings. The call is carried by IAX2 and encoded with ILBC. The iax.conf files on each end start like this: > [general] > trunk=no > notransfer=yes > iaxcompat=no > > bandwidth=low > > disallow=all > allow=ilbc > > jitterbuffer=yes > dropcount=3 > maxjitterbuffer=500 > maxexcessbuffer=150 > minexcessbuffer=40 > jittershrinkrate=1 Of course, perhaps the jitter buffer isn't to blame, but given that one side of the call sounds perfect, I can't think of anything else obvious that would cause this. Is there any way to extract from asterisk some idea of why it thinks the calls sound bad? For example, when the jitter buffer notices that packets are discarded because they are too late, when excessive packets are completely missing, etc. I've been collecting a giant debug log for a while now, so I could pretty easily sift through it if there's something good to look for. Thanks. -- Matt Ranney - mjr@ranney.com
mjr, Satellite links can be pretty tough to troubleshoot. It sounds like you are running into a uplink buffer issue. On heavily loaded uplinks, the input buffers can get quite large, and if the satellite provider isn't using some form of buffer handling that prioritizes udp traffic, it may be that most of your voice packets are falling on the floor of the uplink facility... -Chris On 10 Sep 2004 11:37:33 -0700, mjr-asterisk@ranney.com <mjr-asterisk@ranney.com> wrote:> I need to debug a call quality issue with remote users on the other > end of a satellite link. The symptoms are: we here on the Internet > side can hear them just fine. On their end, things work sorta OK most > times, but they often suffer from severe dropouts and digital > warbling, both of which I attribute to them missing packets. Often > times they can't make out a word we are saying while we can hear them > crystal clearly. > > Various pings and other network tests indicate that the underlying > network is functioning as well as can be expected for a sat link. In > fact, the overall jitter seems to be pretty low (avg 20ms). Packet > loss is around 1-2%, and latency is around 700ms on average. > > I'm left to assume that the jitter buffer on that end isn't > functioning properly. Both ends of the call have the same jitter > buffer settings. The call is carried by IAX2 and encoded with ILBC. > > The iax.conf files on each end start like this: > > > [general] > > trunk=no > > notransfer=yes > > iaxcompat=no > > > > bandwidth=low > > > > disallow=all > > allow=ilbc > > > > jitterbuffer=yes > > dropcount=3 > > maxjitterbuffer=500 > > maxexcessbuffer=150 > > minexcessbuffer=40 > > jittershrinkrate=1 > > Of course, perhaps the jitter buffer isn't to blame, but given that > one side of the call sounds perfect, I can't think of anything else > obvious that would cause this. > > Is there any way to extract from asterisk some idea of why it thinks > the calls sound bad? For example, when the jitter buffer notices that > packets are discarded because they are too late, when excessive > packets are completely missing, etc. > > I've been collecting a giant debug log for a while now, so I could > pretty easily sift through it if there's something good to look for. > > Thanks. > -- > Matt Ranney - mjr@ranney.com > _______________________________________________ > Asterisk-Users mailing list > Asterisk-Users@lists.digium.com > http://lists.digium.com/mailman/listinfo/asterisk-users > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >
Hi all, Do you monitor call quality ? If positive, how do you proceed ? How do you estimate user's experience from rough lattency, MOS, throughput and so on ? Which issues (echo ? call interruption ?) do you prevent with such monitoring and which conter-measures do you engage when a problem occurs ? Cheers Olivier -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20060118/e54f3e38/attachment.htm
Hi all, Do you monitor call quality ? If positive, how do you proceed ? How do you estimate user's experience from rough lattency, MOS, throughput and so on ? Which issues (echo ? call interruption ?) do you prevent with such monitoring and which conter-measures do you engage when a problem occurs ? Cheers Olivier -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20060120/74911fcc/attachment.htm