[asterisk-bugs] [Asterisk 0017468]: Asterisk can't match peer

Asterisk Bug Tracker noreply at bugs.digium.com
Fri Jun 4 08:17:17 CDT 2010


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17468 
====================================================================== 
Reported By:                jamicque
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17468
Category:                   Channels/chan_sip/General
Reproducibility:            have not tried
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.1 - SECURITY ONLY! Test 1.6.2 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-06-04 07:48 CDT
Last Modified:              2010-06-04 08:17 CDT
====================================================================== 
Summary:                    Asterisk can't match peer
Description: 
If you configure two peers between two Asterisks, Asterisk has a problem to
match the correct peer for incoming connection if "From" header is
different than sip name account.

I've configured two peers between asterisks test005 and test006. If there
is an incoming connection for peer test006 everything is ok. However if I
call on peer test005 I have an error message:
[Jun  4 14:41:42] WARNING[1382]: chan_sip.c:11874 check_auth: username
mismatch, have <test006>, digest has <test005>
[Jun  4 14:41:42] NOTICE[1382]: chan_sip.c:19049 handle_request_invite:
Failed to authenticate device "zzZxZ zxczxczxczxc"
<sip:+48587396006 at 10.0.0.190>;tag=as309ab937

It seems that asterisk matches every connection on test006. I've made
similar test with friends instead of peers, the result is the same.
Can asterisk match the proper peer based on Digest username?

Beneath the full log:

<--- SIP read from UDP://10.0.0.249:5060 --->
INVITE sip:+48586204003 at 10.0.0.190:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.249:5060;branch=z9hG4bK421353b6;rport
Max-Forwards: 70
From: "zzZxZ zxczxczxczxc" <sip:+48587396006 at 10.0.0.190>;tag=as309ab937
To: <sip:+48586204003 at 10.0.0.190:5060>
Contact: <sip:+48587396006 at 10.0.0.249>
Call-ID: 46379e5a62fcb95a041fb631081792df at 10.0.0.190
CSeq: 102 INVITE
User-Agent: Datera CalleX IP PBX
Date: Fri, 04 Jun 2010 12:41:42 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 300

v=0
o=DATERA 119415426 119415426 IN IP4 10.0.0.249
s=Call-eX IP PBX
c=IN IP4 10.0.0.249
t=0 0
m=audio 15206 RTP/AVP 8 18 101
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

<------------->
--- (14 headers 14 lines) ---
  == Using SIP RTP TOS bits 136
  == Using SIP RTP CoS mark 4
  == Using SIP VRTP TOS bits 136
  == Using SIP VRTP CoS mark 4
  == Using UDPTL TOS bits 136
  == Using UDPTL CoS mark 4
Sending to 10.0.0.249 : 5060 (no NAT)
Using INVITE request as basis request -
46379e5a62fcb95a041fb631081792df at 10.0.0.190
Found peer 'test006' for '+48587396006' from 10.0.0.249:5060
CalleX-DATERA*CLI>
<--- Reliably Transmitting (NAT) to 10.0.0.249:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP
10.0.0.249:5060;branch=z9hG4bK421353b6;received=10.0.0.249;rport=5060
From: "zzZxZ zxczxczxczxc" <sip:+48587396006 at 10.0.0.190>;tag=as309ab937
To: <sip:+48586204003 at 10.0.0.190:5060>;tag=as2e3f468f
Call-ID: 46379e5a62fcb95a041fb631081792df at 10.0.0.190
CSeq: 102 INVITE
Server: Datera CalleX IP PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="Call-eX", nonce="0679e576"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog
'46379e5a62fcb95a041fb631081792df at 10.0.0.190' in 32000 ms (Method: INVITE)
CalleX-DATERA*CLI>
<--- SIP read from UDP://10.0.0.249:5060 --->
ACK sip:+48586204003 at 10.0.0.190:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.249:5060;branch=z9hG4bK421353b6;rport
Max-Forwards: 70
From: "zzZxZ zxczxczxczxc" <sip:+48587396006 at 10.0.0.190>;tag=as309ab937
To: <sip:+48586204003 at 10.0.0.190:5060>;tag=as2e3f468f
Contact: <sip:+48587396006 at 10.0.0.249>
Call-ID: 46379e5a62fcb95a041fb631081792df at 10.0.0.190
CSeq: 102 ACK
User-Agent: Datera CalleX IP PBX
Content-Length: 0


<------------->
--- (10 headers 0 lines) ---
CalleX-DATERA*CLI>
<--- SIP read from UDP://10.0.0.249:5060 --->
INVITE sip:+48586204003 at 10.0.0.190:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.249:5060;branch=z9hG4bK787d56d9;rport
Max-Forwards: 70
From: "zzZxZ zxczxczxczxc" <sip:+48587396006 at 10.0.0.190>;tag=as309ab937
To: <sip:+48586204003 at 10.0.0.190:5060>
Contact: <sip:+48587396006 at 10.0.0.249>
Call-ID: 46379e5a62fcb95a041fb631081792df at 10.0.0.190
CSeq: 103 INVITE
User-Agent: Datera CalleX IP PBX
Authorization: Digest username="test005", realm="Call-eX", algorithm=MD5,
uri="sip:+48586204003 at 10.0.0.190:5060", nonce="0679e576",
response="f1c5f6cf7e064c1fcebb8e374163d20f"
Date: Fri, 04 Jun 2010 12:41:42 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 300

v=0
o=DATERA 119415426 119415427 IN IP4 10.0.0.249
s=Call-eX IP PBX
c=IN IP4 10.0.0.249
t=0 0
m=audio 15206 RTP/AVP 8 18 101
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

<------------->
--- (15 headers 14 lines) ---
Sending to 10.0.0.249 : 5060 (NAT)
Using INVITE request as basis request -
46379e5a62fcb95a041fb631081792df at 10.0.0.190
Found peer 'test006' for '+48587396006' from 10.0.0.249:5060
[Jun  4 14:41:42] WARNING[1382]: chan_sip.c:11874 check_auth: username
mismatch, have <test006>, digest has <test005>
[Jun  4 14:41:42] NOTICE[1382]: chan_sip.c:19049 handle_request_invite:
Failed to authenticate device "zzZxZ zxczxczxczxc"
<sip:+48587396006 at 10.0.0.190>;tag=as309ab937

<--- Reliably Transmitting (NAT) to 10.0.0.249:5060 --->
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP
10.0.0.249:5060;branch=z9hG4bK787d56d9;received=10.0.0.249;rport=5060
From: "zzZxZ zxczxczxczxc" <sip:+48587396006 at 10.0.0.190>;tag=as309ab937
To: <sip:+48586204003 at 10.0.0.190:5060>;tag=as2e3f468f
Call-ID: 46379e5a62fcb95a041fb631081792df at 10.0.0.190
CSeq: 103 INVITE
Server: Datera CalleX IP PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog
'46379e5a62fcb95a041fb631081792df at 10.0.0.190' in 32000 ms (Method: INVITE)
CalleX-DATERA*CLI>
<--- SIP read from UDP://10.0.0.249:5060 --->
ACK sip:+48586204003 at 10.0.0.190:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.249:5060;branch=z9hG4bK787d56d9;rport
Max-Forwards: 70
From: "zzZxZ zxczxczxczxc" <sip:+48587396006 at 10.0.0.190>;tag=as309ab937
To: <sip:+48586204003 at 10.0.0.190:5060>;tag=as2e3f468f
Contact: <sip:+48587396006 at 10.0.0.249>
Call-ID: 46379e5a62fcb95a041fb631081792df at 10.0.0.190
CSeq: 103 ACK
User-Agent: Datera CalleX IP PBX
Content-Length: 0


<------------->
--- (10 headers 0 lines) ---
CalleX-DATERA*CLI>
Disconnected from Asterisk server

====================================================================== 

---------------------------------------------------------------------- 
 (0122960) davidw (reporter) - 2010-06-04 08:17
 https://issues.asterisk.org/view.php?id=17468#c122960 
---------------------------------------------------------------------- 
This is a support issue/feature request, not a bug.  Asterisk matches on IP
address in this context.  It can't use the authentication user name, as
that will not necessarily be sent until the sender is challenged.

Duplicate of https://issues.asterisk.org/view.php?id=5177 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-06-04 08:17 davidw         Note Added: 0122960                          
======================================================================




More information about the asterisk-bugs mailing list