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

[John Lange]

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 ?
> 
>