[asterisk-dev] poke retries

[Dmitry Andrianov]

Well, it looks like it is. Honestly I just could not follow logic of
smoothing. To me it looks like as soon as iax2_poke_noanswer called for
the first time, peer is marked as unreachable. And I do not see how
smoothed ping time is involved in this process.
Also to me it looks like the very first delayed response will
immediately trigger logging "Peer '%s' is now TOO LAGGED" because
average time is calculated later.
So the bottom line, after reading the sources I could not understand how
this stuff can help...

-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Eric
"ManxPower" Wieling
Sent: Wednesday, October 03, 2007 2:14 AM
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] poke retries

I'm curious as to why the current IAX2 qualify smoothing is not what you

need.

/path/to/src/asterisk/configs/iax.conf.sample:

;qualify=yes              ; Make sure this peer is alive
;qualifysmoothing = yes   ; use an average of the last two PONG
                           ; results to reduce falsely detected LAGGED
hosts
                           ; Default: Off
;qualifyfreqok = 60000    ; how frequently to ping the peer when
                           ; everything seems to be ok, in milliseconds
;qualifyfreqnotok = 10000 ; how frequently to ping the peer when it's
                           ; either LAGGED or UNAVAILABLE, in
milliseconds


Dmitry Andrianov wrote:
> Hello.
> 
> I'm thinking about modifying chan_iax2.c to allow N (2 or 3) unreplied
> pokes before reporting peer as unreachable. Are there any objections
> against such an approach?


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