[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:all-tabpanel ]

Frederic Van Espen updated ASTERISK-22352:
------------------------------------------

    Status: Waiting for Feedback  (was: Waiting for Feedback)

Hello Matt,

Thanks for looking into this again.

I don't agree that this patch removes the option qualifyfreqnotok. The poke frequency is scheduled in a different part of the code: lines 10960 to 10965 and line 12053 of current asterisk 1.8.23.1 release. In those places there is legitimate use of the qualifyfreqnotok value (pokefreqnotok in the code).

My patch actually just removes a piece of the code that should IMO not be there. In that part of the code we are actually scheduling a call to a function that should be called when the peer does not respond to the poke within the given qualify time (qualify=<maxms). It makes no sense to use qualifyfreqnotok (pokefreqnotok) in this part of the code. I'll try to explain with extreme values. Say you have a peer with these settings:
qualify=2000
qualifyfreqnotok=1

If at some point the peer becomes unreachable, we have to receive a PONG within 1 ms of a POKE for the peer to become reachable again because the __iax2_poke_noanswer function would be called before the PONG can be received. This function destroys the callno. This makes doesn't make any sense. I still believe there is a mixup between qualify=<maxms> and qualifyfreqnotok=<pokefreqnotok> in this part of the code.

Let me know if you don't understand my point and I'd be happy to explain further
                
> [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
>            Assignee: 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