[asterisk-dev] latency bursts (qualify=yes)

[fadey]

Thanks a lot for your answer, John.

> I'm not sure if anyone else responded to this or not but I'll put in my
> 2cents.
> 
> First of all, this is a user question so it shouldn't be on the
> developer list.
> 
> Asterisk's qualify system has always been problematic. Quite frankly it
> shouldn't be used for exactly the reason you described. It does not
> scale very well.
> 
> It has several problems, chief among them is the fact it sends out all
> of it's qualify messages in one huge burst which is exactly what you are
> experiencing.
> 
> Please have a look at my very eloquently worded posting on this topic
> from 2006 ;)
> 
> http://lists.digium.com/pipermail/asterisk-dev/2006-June/021394.html
> 
> The correct and much more reliable solution is to ask your endpoints to
> issue their own keep-alive messages.
> 
> This works much better. Unfortunately not all devices have that
> feature. 
> 
> All Linksys devices have it and so do Polycom, but not Aastra phones.
> 
> A bad work-around is to set the registration interval to something very
> low, like 120 so that there is activity at least every 2 minutes.
> 
> -- 
> John Lange
> www.johnlange.ca
> 
> 
> On Wed, 2008-06-11 at 12:18 +0200, Vincent Nonnenmacher wrote:
> > >¤Hi, everyone
> > >
> > >I'm curently debugging an issue in a small cable network (about 150
> > >SIP-enabled EMTAs) with asterisk as their sip proxy. I have qualify=yes
> > >in sip.conf. The problem is sporadic latency bursts as seen with "sip
> > >show peers". Normaly EMTAs would show 30-100 ms. But once every 2-3
> > >minutes you'd see a random EMTA showing 1000-3000 ms (I had to change
> > >qualify=yes to qualify=90000 to actualy see it). I've seen this behavior
> > >both with asterisk 1.2 and 1.4.
> > >First I though it's a networking issue. To check it I wrote a simple
> > >tester, which would send INVITE packets to EMTAs and note the responce
> > >time. And it shows stable 30-100 ms. So I'm pretty sure it is the
> > >asterisk that causes those bursts.
> > >Has anyone seen this behavior before? Does it affect voice calls as well
> > >(I mean, are there the same latency bursts in RTP voice traffic? I
> > >couldn't find a way to measure that)?
> > >Thanks in advance
> > >
> > 
> > we have seen the same problem (smaller number of 
> > phones ‰ 50 on two sites) and same conclusion 
> > (2000 to 3000ms and becoming unreacble unless 
> > qualify is more than 5000).
> > 
> > Still unable to find/qualify audible rtp problems 
> > at those occurence, we are working on making some 
> > Sipp test cases in order to find a way to push 
> > asterisk in order to reproduce it, but not seen 
> > them yet.
> > 
> > We came to the same conclusion about the need of 
> > a network probe that could be integrated inside 
> > asterisk, based on a sort of 'time sloted' UDP 
> > echo tester that could report (CLI) from * to any 
> > networked counterpart infos about packet loss, 
> > jitter, latencies and al.
> > 
> > So to be able (without any rtp complication) to 
> > check the network transport as seen be asterisk 
> > and how timing could affect the * internal frames 
> > handling.
> > 
> > Anyonw working on that kind of *_app ?
> > 
> > 
> 
> 
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev