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

Michael L. Young (JIRA) noreply at issues.asterisk.org
Wed Aug 21 13:29:03 CDT 2013


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

Michael L. Young edited comment on ASTERISK-22352 at 8/21/13 1:28 PM:
----------------------------------------------------------------------

Frederic,

I don't think the qualify setting is used as a timer.  It is used to determine when to consider a peer is lagged or unreachable.  The default (qualify=yes) is when it takes more than 2 seconds to get a response back from the peer.  In your case, you are setting it to consider anything over 16 seconds as being lagged or unreachable.

The attached patch to use peer->maxms, is incorrect.

                
      was (Author: elguero):
    Frederic,

I don't think the qualify setting is used as a timer.  It is used to determine when to consider a peer is lagged or unreachable.  The default (qualify=yes) is when it takes more than 2 seconds to get a response back from the peer.  In your case, you are setting it to consider anything over 16 seconds as being lagged or unreachable.

So, I don't think there is a bug here since we do not use the qualify setting as a timer setting.  The attached patch is therefore incorrect.
                  
> [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
>
>
> 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



More information about the asterisk-bugs mailing list