[asterisk-bugs] [JIRA] (ASTERISK-26044) Realtime peer matching wrong peer despite match_auth_username=yes

[Richard Mudgett (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-26044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Mudgett updated ASTERISK-26044:
---------------------------------------

    Component/s: Channels/chan_sip/Registration
                 Channels/chan_sip/DatabaseSupport

> Realtime peer matching wrong peer despite match_auth_username=yes
> -----------------------------------------------------------------
>
>                 Key: ASTERISK-26044
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26044
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/DatabaseSupport, Channels/chan_sip/Registration
>    Affects Versions: 13.7.2
>         Environment: Centos Linux
>            Reporter: Richard Wilkinson
>
> Asterisk is not correctly matching a a realtime SIP peer when a call comes in if there are multiple peers behind the same IP address.
> Both allowguest=no and match_auth_username=yes in the 'general' section of sip.conf
> Peer 'A' is registered as a friend, with insecure=port.
> The from URI Is 3198300 (the CLI to be presented)
> The SIP username is 15000
> When peer 'A' dials a number, asterisk performs the following SQL queries. 
> (ast_sip is the table name for sip.conf)
> {noformat}
> SELECT * FROM ast_sip WHERE name = '3198300' AND host = 'dynamic'
> {noformat}
> Surely this should be using '15000' for the name (as per match_auth_username) as using the SIP URI won't return any peers.  
> It then proceeds to try 
> {noformat}
> SELECT * FROM ast_sip WHERE name = '3198300'
> {noformat}
> Again, no results as it's using the SIP URI
> Next query is:-
> {noformat}
> SELECT * FROM ast_sip WHERE host = xxx.xxx.xxx.xxx' AND port = '5060'
> {noformat}
> At this point, as there are several different peers behind this IP address, asterisk becomes very confused and starts adding the wrong peer to its internal peer database.  Peer 000088 is also behind the same IP.  A new entry for this will appear after each call made by 15000.  
> This is the output from CLI command SIP SHOW PEERS
> {noformat}
> Name/username             Host                                    Dyn Forcerport Comedia    ACL Port     Status      Description                      Realtime
> 000088/000088             xxx.xxx.xxx.xxx                            D  Yes        Yes            5060     OK (29 ms)                                   Cached RT
> 000088/000088             xxx.xxx.xxx.xxx                            D  Yes        Yes            5060     OK (154 ms)                                  Cached RT
> 000088/000088             xxx.xxx.xxx.xxx                            D  Yes        Yes            5060     OK (167 ms)                                  Cached RT
> 000088/000088             xxx.xxx.xxx.xxx                            D  Yes        Yes            5060     OK (175 ms)                                  Cached RT
> 000088/000088             xxx.xxx.xxx.xxx                            D  Yes        Yes            5060     OK (210 ms)                                  Cached RT
> 000088/000088             xxx.xxx.xxx.xxx                            D  Yes        Yes            5060     OK (216 ms)                                  Cached RT
> 000088/000088             xxx.xxx.xxx.xxx                            D  Yes        Yes            5060     OK (216 ms)                                  Cached RT
> 000088/000088             xxx.xxx.xxx.xxx                            D  Yes        Yes            5060     OK (224 ms)                                  Cached RT
> 000088/000088             xxx.xxx.xxx.xxx                            D  Yes        Yes            5060     OK (234 ms)                                  Cached RT
> 000088/000088             xxx.xxx.xxx.xxx                            D  Yes        Yes            5060     OK (243 ms)                                  Cached RT
> 000088/000088             xxx.xxx.xxx.xxx                            D  Yes        Yes            5060     OK (254 ms)                                  Cached RT
> 000088/000088             xxx.xxx.xxx.xxx                            D  Yes        Yes            5060     OK (264 ms)                                  Cached RT
> 000088/000088             xxx.xxx.xxx.xxx                            D  Yes        Yes            5060     OK (273 ms)                                  Cached RT
> 000088/000088             xxx.xxx.xxx.xxx                            D  Yes        Yes            5060     OK (283 ms)                                  Cached RT
> 000088/000088             xxx.xxx.xxx.xxx                            D  Yes        Yes            5060     OK (294 ms)                                  Cached RT
> 000088/000088             xxx.xxx.xxx.xxx                            D  Yes        Yes            5060     OK (303 ms)                                  Cached RT
> 000088/000088             xxx.xxx.xxx.xxx                            D  Yes        Yes            5060     OK (313 ms)                                  Cached RT
> {noformat}
> One will continue to add each time a call is made by 15000.
> Surely the first SQL query asterisk makes should be using '15000' (SIP authentication user), NOT 3198300 (SIP URI) because match_auth_username is set to yes.  If it does this, the peer would be found immediately and the rest of the strange behaviour would never be triggered.
> Also, when running a SIP RELOAD to clear off all the 0000088 entries, this line in the CLI appears, which suggests something is also wrong.
> {noformat}
> [May 20 15:30:10] ERROR[21109]: stasis_cache.c:845 caching_topic_exec: Attempting to remove an item from the SIP/000088-cached cache that isn't there: ast_endpoint_snapshot_type SIP/000088
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)