[Home]

Summary:ASTERISK-06247: Incoming SIP calls to empty usernames do not trigger 's' extension rules
Reporter:Enzo Michelangeli (enzo michelangeli)Labels:
Date Opened:2006-02-03 00:10:00.000-0600Date Closed:2006-03-27 17:13:43.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) nousernameinuri.txt
Description:SIP INVITEs sent to a null user (e.g.:
"INVITE sip:jaxhk.hn.org SIP/2.0", generated by a "Dial(SIP/@jaxhk.hn.org)" in the dialplan) do not trigger, as they should, the "exten => s,..." lines in the receiving peer (running * 1.2.4). Instead, the latter appears to look for a _user_ equal to the actual domain, in an empty domain:

  Looking for jaxhk.hn.org in default (domain )

In other words, "sip:jaxhk.hn.org" gets interpreted as "sip:jaxhk.hn.org@" rather than "sip:@jaxhk.hn.org". A "sip debug" trace is included in the "Additional Information" field.

Note that chan_sip.c seems to be aware of this problem, because at line 3222, in the sip_register() function, it contains a workaround to convert an empty user to the "s" user in the URI sent for registration:

       if (ast_strlen_zero(contact))
               contact = "s";

...and that's why "register" lines in sip.conf lacking the trailing /nnn extension specifier, such as:

register => myuser:mypassword@remotepeer

...result in SIP "Contact:" headers with a synthetized "s" user:

Contact: <sip:s@remotepeer>

See example:

Feb  3 14:42:35 NOTICE[26171]: chan_sip.c:5239 sip_reregister:    -- Re-registration for  jaxhk@voipstunt
REGISTER 13 headers, 0 lines
Reliably Transmitting (NAT) to 80.239.235.201:5060:
REGISTER sip:voipstunt SIP/2.0
Via: SIP/2.0/UDP 203.198.106.87:5060;branch=z9hG4bK7441975c;rport
From: <sip:jaxhk@sip.voipstunt.com>;tag=as4b1593be
To: <sip:jaxhk@sip.voipstunt.com>
Call-ID: 371bd05a1227bade160e414b7eef3da8@192.168.0.1
CSeq: 202 REGISTER
User-Agent: Asterisk PBX
Max-Forwards: 70
Authorization: Digest username="jaxhk", realm="sipdiscount.com", algorithm=MD5, uri="sip:voipstunt", nonce="912207890", response="154215e17a8f72d3e6c5a17dade910cc", opaque=""
Expires: 120
Contact: <sip:s@203.198.106.87>
Event: registration
Content-Length: 0

This makes the subsequent "INVITEs" work, because they are sent to "s@remotepeer", but it's an ad-hoc hack masking the real problem...

In the source code, I suspect that the problem may lie in the following lines of  get_destination():

       /* Get the target domain */
       if ((a = strchr(uri, '@'))) {
               char *colon;
               *a = '\0';
               a++;
               colon = strchr(a, ':'); /* Remove :port */
               if (colon)
                       *colon = '\0';
               ast_copy_string(p->domain, a, sizeof(p->domain));
       }

This means that if the '@' character is not present in the saved contact URI, the "if" block is not executed, and p->domain is left empty. Instead, the _username_ should be left empty.

****** ADDITIONAL INFORMATION ******

sip debug of INVITE with no "user@" part that is not properly understood:

burning*CLI>
<-- SIP read from 218.103.207.95:5060:
INVITE sip:jaxhk.hn.org SIP/2.0
Via: SIP/2.0/UDP 218.103.207.95:5060;branch=z9hG4bK4ae032b0
From: "Enzo Michelangeli" <sip:+85227109517@218.103.207.95>;tag=as11610026
To: <sip:jaxhk.hn.org>
Contact: <sip:+85227109517@218.103.207.95>
Call-ID: 3702a90d19a5c90a6d35612103d9be13@218.103.207.95
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Date: Thu, 02 Feb 2006 15:44:59 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Content-Type: application/sdp
Content-Length: 294

v=0
o=root 25983 25983 IN IP4 218.103.207.95
s=session
c=IN IP4 218.103.207.95
t=0 0
m=audio 16128 RTP/AVP 0 8 3 2 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -

--- (12 headers 13 lines)---
Using INVITE request as basis request -
3702a90d19a5c90a6d35612103d9be13@218.103.207.95
Sending to 218.103.207.95 : 5060 (non-NAT)
Found no matching peer or user for '218.103.207.95:5060'
Found RTP audio format 0
Found RTP audio format 8
Found RTP audio format 3
Found RTP audio format 2
Found RTP audio format 101
Peer audio RTP is at port 218.103.207.95:16128
Found description format PCMU
Found description format PCMA
Found description format GSM
Found description format G726-32
Found description format telephone-event
Capabilities: us - 0x8000e (gsm|ulaw|alaw|h263), peer - audio=0x1e
(gsm|ulaw|alaw|g726)/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 jaxhk.hn.org in default (domain )
Reliably Transmitting (no NAT) to 218.103.207.95:5060:
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP
218.103.207.95:5060;branch=z9hG4bK4ae032b0;received=218.103.207.95
From: "Enzo Michelangeli" <sip:+85227109517@218.103.207.95>;tag=as11610026
To: <sip:jaxhk.hn.org>;tag=as47a8b4cf
Call-ID: 3702a90d19a5c90a6d35612103d9be13@218.103.207.95
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:jaxhk.hn.org@203.198.106.87>
Content-Length: 0

Comments:By: Olle Johansson (oej) 2006-03-05 03:56:46.000-0600

Thank you for a very detailed bug report. Please try the attached patch to Asterisk 1.2

/O
By: Benoit Panizzon (woody) 2006-03-24 06:39:16.000-0600

Hi oej

I suppose being victim of the same problem. Asterisk 1.2.5 but your patch does not work:

## sip.conf
[general]
context=anonymous

As a generic fallback for connections that get in from unknown SIP origins.

Of course all known SIP origins have their own context.

I have a PBX sending in calls to my asterisk. Most calls have a caller ID, so they work fine. Sometimes a call comes in, without caller ID (without user part of the SIP url).

Here Asterisk seams to fail to find out to which context they belong and falls back to my 'anonymous' context.

Example of such a session:
---------------------------
<-- SIP read from 157.161.10.x:5060:
INVITE sip:41444004463@157.161.57.x:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 157.161.10.x:5060;branch=z9hG4bK0957
From: sip:@157.161.10.x;tag=6a29201d
To: <sip:41444004463@157.161.57.x:5060>
Call-ID: 00000049990000825827040855429922118752830@157.161.10.x
CSeq: 21 INVITE
Contact: <sip:157.161.10.x:5060>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 118

v=0
o=- 1957115401 0 IN IP4 157.161.10.x
s=-
c=IN IP4 157.161.10.x
t=0 0
m=audio 4170 RTP/AVP 8
a=ptime:20

--- (10 headers 7 lines)---
Using INVITE request as basis request - 00000049990000825827040855429922118752830@157.161.10.x
Sending to 157.161.10.x : 5060 (NAT)
Found RTP audio format 8
Peer audio RTP is at port 157.161.10.x:4170
Peer video RTP is at port 157.161.10.x:65535
Capabilities: us - 0x1f060e (gsm|ulaw|alaw|speex|ilbc|jpeg|png|h261|h263|h263p), peer - audio=0x8 (alaw)/video=0x0 (nothing), combined - 0x8 (alaw)
Non-codec capabilities: us - 0x1 (telephone-event), peer - 0x0 (nothing), combined - 0x0 (nothing)
Looking for 41444004463 in anonymous (domain 157.161.57.x)
list_route: hop: <sip:157.161.10.x:5060>
Transmitting (NAT) to 157.161.10.x:5060:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 157.161.10.x:5060;branch=z9hG4bK0957;received=157.161.10.x
From: sip:@157.161.10.x;tag=6a29201d
To: <sip:41444004463@157.161.57.x:5060>
Call-ID: 00000049990000825827040855429922118752830@157.161.10.x
CSeq: 21 INVITE
User-Agent: Fake Ast-erisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:41444004463@157.161.57.x>
Content-Length: 0

Any idea?
By: Olle Johansson (oej) 2006-03-27 16:41:25.000-0600

woody: THat's not related to this bug. Asterisk always requires a From: username to match users on incoming call.
By: Olle Johansson (oej) 2006-03-27 16:56:17.000-0600

Committed patch to asterisk 1.2 and svn trunk.
By: Olle Johansson (oej) 2006-03-27 17:13:42.000-0600

Rev 15375 in trunk.