How to disable context matching by username?

Asterisk Asterisk Support
1

Hi,

I’m running asterisk 1.2.13 which is registered as a SIP client at another asterisk server. Calling out works fine; incoming calls work as long as the username of the calling party does not exist in my configuration.
According to the description in voip-info.org/tiki-index.php … 20Channels asterisk “first tries to find a [user] section matching the caller name (From: username)”.

The domain name seems to be ignored, so asterisk thinks the caller is a local user and requires Proxy Authentication. (For users not existing locally the request is correctly matched with a corresponding peer context based on the caller’s IP address). The relevant section of the debug output is included below.

Is there any way to prevent asterisk from trying to do a context lookup by username? In particular, when the caller on the other asterisk calls me (i.e. extension 14 on the other system), it works as long as he doesn’t have the username 13, in which case asterisk seems to try to authenticate against context [13].

I’ve spent hours on this but haven’t found a solution. I’m looking forward to any ideas you might have
Eddie.

sip.conf:

[code]register => 14:xxx@192.168.0.123/97

[…]

[13]
type=friend
context=local
callerid=13
canreinvite=no
secret=yyy
username=13
host=dynamic
nat=yes

[asterisk-test-out]
type=peer
secret=test
callerid=14
username=14
fromuser=14
host=192.168.0.123
canreinvite=no
insecure=very
nat=no
context=from-external
[/code]

debug output:

[code]
<-- SIP read from 192.168.0.123:5060:
INVITE sip:97@10.1.5.6 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.123:5060;branch=z9hG4bK14bf4a88;rport
From: “Joe” sip:13@192.168.0.123;tag=as2d7632b3
To: sip:97@10.1.5.6
Contact: sip:13@192.168.0.123
Call-ID: 57f2109745f7ec44491ed09d2bb8d248@192.168.0.123
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Fri, 07 Sep 2007 09:37:06 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Type: application/sdp
Content-Length: 263

v=0
o=root 2494 2494 IN IP4 192.168.0.123
s=session
c=IN IP4 192.168.0.123
t=0 0
m=audio 14402 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -

— (13 headers 12 lines) —
Using INVITE request as basis request - 57f2109745f7ec44491ed09d2bb8d248@192.168.0.123
Sending to 192.168.0.123 : 5060 (NAT)
Reliably Transmitting (NAT) to 192.168.0.123:5060:
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 192.168.0.123:5060;branch=z9hG4bK14bf4a88;received=192.168.0.123;rport=5060
From: “Joe” sip:13@192.168.0.123;tag=as2d7632b3
To: sip:97@10.1.5.6;tag=as452f5a35
Call-ID: 57f2109745f7ec44491ed09d2bb8d248@192.168.0.123
CSeq: 102 INVITE
User-Agent: rysavy.net SIP client
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Proxy-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce="40a650b6"
Content-Length: 0

Scheduling destruction of call ‘57f2109745f7ec44491ed09d2bb8d248@192.168.0.123’ in 15000 ms
Found user '13’
rom059*CLI>
<-- SIP read from 192.168.0.123:5060:
ACK sip:97@10.1.5.6 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.123:5060;branch=z9hG4bK14bf4a88;rport
From: “Joe” sip:13@192.168.0.123;tag=as2d7632b3
To: sip:97@10.1.5.6;tag=as452f5a35
Contact: sip:13@192.168.0.123
Call-ID: 57f2109745f7ec44491ed09d2bb8d248@192.168.0.123
CSeq: 102 ACK
User-Agent: Asterisk PBX
Max-Forwards: 70
Content-Length: 0

INVITE sip:97@10.1.5.6 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.123:5060;branch=z9hG4bK06732597;rport
From: “Joe” sip:13@192.168.0.123;tag=as2d7632b3
To: sip:97@10.1.5.6
Contact: sip:13@192.168.0.123
Call-ID: 57f2109745f7ec44491ed09d2bb8d248@192.168.0.123
CSeq: 103 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Proxy-Authorization: Digest username=“97”, realm=“asterisk”, algorithm=MD5, uri="sip:97@10.1.5.6", nonce=“40a650b6”, response=“aa84fb2266bb9e8c98adaa66cd3e442c”, opaque=""
Date: Fri, 07 Sep 2007 09:37:06 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Type: application/sdp
Content-Length: 263

v=0
o=root 2494 2495 IN IP4 192.168.0.123
s=session
c=IN IP4 192.168.0.123
t=0 0
m=audio 14402 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -

— (14 headers 12 lines) —
Using INVITE request as basis request - 57f2109745f7ec44491ed09d2bb8d248@192.168.0.123
Sending to 192.168.0.123 : 5060 (NAT)
Found user '13’
Sep 7 13:12:16 NOTICE[12309]: chan_sip.c:10545 handle_request_invite: Failed to authenticate user “Joe” sip:13@192.168.0.123;tag=as2d7632b3
Reliably Transmitting (NAT) to 192.168.0.123:5060:
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 192.168.0.123:5060;branch=z9hG4bK06732597;received=192.168.0.123;rport=5060
From: “Joe” sip:13@192.168.0.123;tag=as2d7632b3
To: sip:97@10.1.5.6;tag=as452f5a35
Call-ID: 57f2109745f7ec44491ed09d2bb8d248@192.168.0.123
CSeq: 103 INVITE
User-Agent: rysavy.net SIP client
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0
[/code][/code]

2

If the realm on both machines is asterisk try to change one of them (sip.conf) I’m not sure but it might solve the problem

3

Changing the realms was one of my first thoughts, but it doesn’t make a difference.
The problem seems to occur in an earlier stage, which is when asterisk decides if it needs authentication for this particular INVITE at all.

If there doesn’t exist a context with the same username like the one calling, then the matching is correctly done by looking for a matching peer configuration.

In this call I have disabled context “13” on my lokal asterisk. Look at the “Found peer ‘asterisk-test-out’” as opposed to “Found user ‘13’” in my previous post. Matching to the peer (which has set “insecure=very”) no proxy authentication is requested. This is what I want, regardless of the username of the calling party / if it matches any local username or not.

[code]
INVITE sip:97@10.1.5.6 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.123:5060;branch=z9hG4bK73ec9299;rport
From: “13” sip:13@192.168.0.123;tag=as2988b6da
To: sip:97@10.1.5.6
Contact: sip:13@192.168.0.123
Call-ID: 1e4a8d8b4e46b74303f19a6405a2ac33@192.168.0.123
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Wed, 12 Sep 2007 05:42:44 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Type: application/sdp
Content-Length: 265

v=0
o=root 25234 25234 IN IP4 192.168.0.123
s=session
c=IN IP4 192.168.0.123
t=0 0
m=audio 13086 RTP/AVP 8 3 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -

— (13 headers 12 lines) —
Using INVITE request as basis request - 1e4a8d8b4e46b74303f19a6405a2ac33@192.168.0.123
Sending to 192.168.0.123 : 5060 (NAT)
Found peer 'asterisk-test-out’
Found RTP audio format 8
Found RTP audio format 3
Found RTP audio format 0
Found RTP audio format 101
Peer audio RTP is at port 192.168.0.123:13086
Found description format PCMA
Found description format GSM
Found description format PCMU
Found description format telephone-event
Capabilities: us - 0x60e (gsm|ulaw|alaw|speex|ilbc), peer - audio=0xe (gsm|ulaw|alaw)/video=0x0 (nothing), combined - 0xe (gsm|ulaw|alaw)
Non-codec capabilities: us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
Looking for 97 in from-external (domain 10.1.5.6)
list_route: hop: sip:13@192.168.0.123
Transmitting (no NAT) to 192.168.0.123:5060:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.0.123:5060;branch=z9hG4bK73ec9299;rport;received=192.168.0.123
From: “13” sip:13@192.168.0.123;tag=as2988b6da
To: sip:97@10.1.5.6
Call-ID: 1e4a8d8b4e46b74303f19a6405a2ac33@192.168.0.123
CSeq: 102 INVITE
User-Agent: rysavy.net SIP client
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: sip:97@10.1.5.6
Content-Length: 0
[/code][/code]

4

Hi,

no answers so far …

Can you confirm this behaviour?
Is there a way to work around this problem?
Do later versions of asterisk behave differently?

Looking forward for any help :smile: