[asterisk-bugs] [JIRA] (ASTERISK-26044) chan_sip: Realtime peer matching wrong peer despite match_auth_username=yes
Asterisk Team (JIRA)
noreply at issues.asterisk.org
Tue Jun 7 12:00:56 CDT 2016
[ https://issues.asterisk.org/jira/browse/ASTERISK-26044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=230926#comment-230926 ]
Asterisk Team commented on ASTERISK-26044:
------------------------------------------
Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].
[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines
> chan_sip: 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
> Assignee: 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)
More information about the asterisk-bugs
mailing list