[asterisk-bugs] [JIRA] (ASTERISK-22352) [patch] IAX2 custom qualify timer is not taken into account

[Frederic Van Espen (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-22352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=209460#comment-209460 ] 

Frederic Van Espen commented on ASTERISK-22352:
-----------------------------------------------

Hello Michael,

Thanks for your feedback and pointing out my error. I did some more tests and I understand the code a bit better now.

That piece of the code determines how long we still wait for a PONG response on a POKE request, and the DEFAULT_MAXMS seconds multiplied by 2 allows us to differentiate between LAGGED and UNREACHABLE for the default value.

However, I still don't understand why the wait time for a response should be any different when the peer is UNREACHABLE or REACHABLE. On top of that, this means that you cannot use any qualify value of over 4000 ms, because the peer will always be marked unreachable after 4000 ms. I know these values are quite extreme, but we're currently dealing with network conditions where a very short delay of more than 4000 ms may happen. If I configure a value higher than 4000 ms, the peer will enter a "flapping" state between REACHABLE and UNREACHABLE.

So, currently when the peer is:
 - REACHABLE: we wait a hardcoded value of 4000 ms for a response;
 - UNREACHABLE: we wait peer->pokefreqnotok (default 10000 ms) for a response.

I modified the patch iax_qualifyv2.patch to always wait "peer->maxms * 2".
                
> [patch] IAX2 custom qualify timer is not taken into account
> -----------------------------------------------------------
>
>                 Key: ASTERISK-22352
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22352
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_iax2
>    Affects Versions: 1.8.23.0
>            Reporter: Frederic Van Espen
>            Severity: Minor
>         Attachments: iax_qualify.patch, iax_qualifyv2.patch
>
>
> When I try to use a qualify timer value for an IAX other than the default 2000ms, this value is not taken into account.
> I can reproduce this with this configuration:
> [remote-host]
> type=friend
> host=172.16.6.45
> username=remote-host
> secret=test
> notransfer=yes
> qualify=16000
> qualifyfreqnotok=30000
> disallow=all
> allow=alaw
> allow=ulaw
> allow=ilbc
> auth=md5
> encryption=no
> On remote host I configure a delay of 6000ms:
> ~# tc qdisc add dev eth0 root netem delay 6000ms
> The result in the logs:
> [Aug 21 10:54:58] NOTICE[13318] chan_iax2.c: Peer 'remote-host' is now REACHABLE! Time: 6001
> [Aug 21 10:56:02] NOTICE[13323] chan_iax2.c: Peer 'remote-host' is now UNREACHABLE! Time: 6001
> [Aug 21 10:56:38] NOTICE[13319] chan_iax2.c: Peer 'remote-host' is now REACHABLE! Time: 6001
> [Aug 21 10:57:42] NOTICE[13324] chan_iax2.c: Peer 'remote-host' is now UNREACHABLE! Time: 6001
> [Aug 21 10:58:18] NOTICE[13318] chan_iax2.c: Peer 'remote-host' is now REACHABLE! Time: 5999
> [Aug 21 10:59:22] NOTICE[13325] chan_iax2.c: Peer 'remote-host' is now UNREACHABLE! Time: 5999
> [Aug 21 10:59:58] NOTICE[13319] chan_iax2.c: Peer 'remote-host' is now REACHABLE! Time: 6001
> [Aug 21 11:01:02] NOTICE[13324] chan_iax2.c: Peer 'remote-host' is now UNREACHABLE! Time: 6001
> [Aug 21 11:01:38] NOTICE[13320] chan_iax2.c: Peer 'remote-host' is now REACHABLE! Time: 6001
> [Aug 21 11:02:42] NOTICE[13325] chan_iax2.c: Peer 'remote-host' is now UNREACHABLE! Time: 6001
> [Aug 21 11:03:18] NOTICE[13319] chan_iax2.c: Peer 'remote-host' is now REACHABLE! Time: 6001
> I believe this is due to a mixup in the chan_iax2.c code. When the peer is REACHABLE, the response appears to be expected within the default timer value*2. When it is UNREACHABLE, it uses the peer->pokefreqnotok value. IMO this timer value should be the same, whatever state it is, and the timer value should be peer->maxms.
> I did not test on asterisk 10 or 11, but by looking at the code it appears to be present in those releases as well

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira