[Home]

Summary:ASTERISK-03361: insecure= does not function as anticipated
Reporter:John Todd (jtodd)Labels:
Date Opened:2005-01-27 02:35:43.000-0600Date Closed:2011-06-07 14:10:07
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:chan_sip does not allow IP-based INVITEs through, regardless of the invite= setting being either "very" or "yes", which is contrary to what I believe the intent is of this setting.

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


This is an extremely simple configuration.  The only entries in sip.conf on 128.151.22.62 are as follows (I kept boiling things down to eliminate any possible cross-contamination of bugs):


--------------
[general]

[128.151.22.35]
host=128.151.22.35
type=friend
context=star69
insecure=yes

---------------


I would expect that this configuration would take all SIP INVITEs from 128.151.22.35 and then send them to context "star69" without asking for an authentication.  However, that is not the case.  It appears that Asterisk is asking for authentication, regardless of the "insecure=" status.  I've tried "insecure=yes" and "insecure=very" with the same results.  This is using CVS-HEAD chan_sip /chan_sip.c/1.638/Tue Jan 25 06:10:20 2005//.

If I am doing something wrong, please let me know.  It seems from the examples and my past (painful) experiences with "insecure=" that this should work without authentication challenge, but apparently not in this version of chan_sip.


web1*CLI> sip debug
SIP Debugging Enabled
web1*CLI>

Sip read:
INVITE sip:*69@128.151.22.62:5060 SIP/2.0
Via: SIP/2.0/UDP 128.151.22.35:5061;branch=z9hG4bK5de6f7c50c542e843ff85e527c6519d4;rport
Max-Forwards: 70
From: 14107010060 <sip:14107010060@128.151.22.62>;tag=7031736e2067fb1267ff08f9e7cdcdd8
To: <sip:*69@128.151.22.62>
Call-ID: 24cb12025cccf5dd990eae585d0ba773@10.0.1.44
CSeq: 200 INVITE
Contact: Anonymous <sip:128.151.22.35:5061>
Expires: 300
User-Agent: Sippy
cisco-GUID: 2095331047-228421992-837507892-3109471574
h323-conf-id: 2095331047-228421992-837507892-3109471574
Content-Length: 312
Content-Type: application/sdp

v=0
o=14107010060 1125609516 1125609516 IN IP4 10.0.1.44
s=SIP Call
c=IN IP4 128.151.22.35
t=0 0
m=audio 35346 RTP/AVP 18 0 8 2 101
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=abcde:20
a=nortpproxy:yes

14 headers, 14 lines
Using latest request as basis request
Sending to 128.151.22.35 : 5061 (non-NAT)
Found RTP audio format 18
Found RTP audio format 0
Found RTP audio format 8
Found RTP audio format 2
Found RTP audio format 101
Peer audio RTP is at port 128.151.22.35:35346
Found description format G729
Found description format PCMU
Found description format PCMA
Found description format G726-32
Found description format telephone-event
Capabilities: us - 0x8000e (gsm|ulaw|alaw|h263), peer - audio=0x11c (ulaw|alaw|g726|g729)/video=0x0 (nothing), combined - 0xc (ulaw|alaw)
Non-codec capabilities: us - 0x1 (g723), peer - 0x1 (g723), combined - 0x1 (g723)
Reliably Transmitting (NAT):
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 128.151.22.35:5061;branch=z9hG4bK5de6f7c50c542e843ff85e527c6519d4;received=128.151.22.35;rport=5061
From: 14107010060 <sip:14107010060@128.151.22.62>;tag=7031736e2067fb1267ff08f9e7cdcdd8
To: <sip:*69@128.151.22.62>;tag=as1049db73
Call-ID: 24cb12025cccf5dd990eae585d0ba773@10.0.1.44
CSeq: 200 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:*69@128.151.22.62>
Proxy-Authenticate: Digest realm="asterisk", nonce="1542a511"
Content-Length: 0


to 128.151.22.35:5061
Scheduling destruction of call '24cb12025cccf5dd990eae585d0ba773@10.0.1.44' in 15000 ms
Found user '14107010060'
web1*CLI>

Sip read:
ACK sip:*69@128.151.22.62:5060 SIP/2.0
Via: SIP/2.0/UDP 128.151.22.35:5061;rport;branch=z9hG4bK5de6f7c50c542e843ff85e527c6519d4
Max-Forwards: 70
From: 14107010060 <sip:14107010060@128.151.22.62>;tag=7031736e2067fb1267ff08f9e7cdcdd8
To: <sip:*69@128.151.22.62>;tag=as1049db73
Call-ID: 24cb12025cccf5dd990eae585d0ba773@10.0.1.44
CSeq: 200 ACK
Expires: 300
User-Agent: Sippy


9 headers, 0 lines
web1*CLI> exit
Comments:By: Mark Spencer (markster) 2005-01-27 09:17:35.000-0600

This is a configuration issue.  As you can see in your debug you are matching  user 14107010060, not your peer.  As a result it is using the user's authentication.  If you don't want to authenticate, remove the user or make the user not match the callerid.
By: John Todd (jtodd) 2005-01-27 15:38:13.000-0600

OK, I modified the sip.conf file as requested, but I'm still not getting the anticpated results; now I get a 404 error instead of an authentication prompt.

I included in the Additional Information the entire sip.conf file - there are no other peers/users.  It's only an 8 line file.

---
[general]

[fleeb]
host=128.151.22.35
type=friend
context=star69
canreinvite=no
---

(from "messages"):
Jan 27 13:39:21 DEBUG[7875]: Peer audio RTP is at port 66.165.175.35:48372
Jan 27 13:39:21 DEBUG[7875]: Check for res for
Jan 27 13:39:21 DEBUG[7875]:  is not a local user
Jan 27 13:39:21 NOTICE[7875]: Cannot find extension context 'default'
Jan 27 13:39:21 DEBUG[7875]:  is not a local user
Jan 27 13:39:21 DEBUG[7875]: Stopping retransmission on 'a8b2144b37ed1f06ea15226192c10a5c@10.0.1.44' of Response 200: Found


The functionality that's required is pretty simple: any INVITEs from a SRC address of 128.151.22.35 should just be accepted; no authentication challenge should be transmitted.   I don't know why it thinks it should be matching on the "From:" address as an authentication user, or anything else.  Asterisk should just look at the source IP address of the SIP packet, and use that as the magic key to allow this INVITE to happen, and pass it to the context specified in the first peer that happens to have that IP address specified in the 'host=' line.  (I can understand if this can't use DNS, since only one IP address should map to the permitted host= line, and using forward DNS may result in multiple A records as a result.)


web1*CLI>

Sip read:
INVITE sip:*69@128.151.22.62:5060 SIP/2.0
Via: SIP/2.0/UDP 128.151.22.35:5061;branch=z9hG4bKbe501b3b93db5f4ef5082fb00a471ea3;rport
Max-Forwards: 70
From: 14107010060 <sip:14107010060@128.151.22.62>;tag=ae1e329ace97e5d3d6961486cdb57533
To: <sip:*69@128.151.22.62>
Call-ID: a8b2144b37ed1f06ea15226192c10a5c@10.0.1.44
CSeq: 200 INVITE
Contact: Anonymous <sip:128.151.22.35:5061>
Expires: 300
User-Agent: Sippy
cisco-GUID: 2842383466-3953145543-3374048480-1596895256
h323-conf-id: 2842383466-3953145543-3374048480-1596895256
Content-Length: 312
Content-Type: application/sdp

v=0
o=14107010060 1123389621 1123389621 IN IP4 10.0.1.44
s=SIP Call
c=IN IP4 128.151.22.35
t=0 0
m=audio 48372 RTP/AVP 18 0 8 2 101
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=abcde:20
a=nortpproxy:yes

14 headers, 14 lines
Using latest request as basis request
Sending to 128.151.22.35 : 5061 (non-NAT)
Found RTP audio format 18
Found RTP audio format 0
Found RTP audio format 8
Found RTP audio format 2
Found RTP audio format 101
Peer audio RTP is at port 128.151.22.35:48372
Found description format G729
Found description format PCMU
Found description format PCMA
Found description format G726-32
Found description format telephone-event
Capabilities: us - 0x8000e (gsm|ulaw|alaw|h263), peer - audio=0x11c (ulaw|alaw|g726|g729)/video=0x0 (nothing), combined - 0xc (ulaw|alaw)
Non-codec capabilities: us - 0x1 (g723), peer - 0x1 (g723), combined - 0x1 (g723)
Found no matching peer or user for '128.151.22.35:5061'
Looking for *69 in default
Reliably Transmitting (no NAT):
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 128.151.22.35:5061;branch=z9hG4bKbe501b3b93db5f4ef5082fb00a471ea3
From: 14107010060 <sip:14107010060@128.151.22.62>;tag=ae1e329ace97e5d3d6961486cdb57533
To: <sip:*69@128.151.22.62>;tag=as36ad7906
Call-ID: a8b2144b37ed1f06ea15226192c10a5c@10.0.1.44
CSeq: 200 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:*69@128.151.22.62>
Content-Length: 0


to 128.151.22.35:5061
web1*CLI>

Sip read:
ACK sip:*69@128.151.22.62:5060 SIP/2.0
Via: SIP/2.0/UDP 128.151.22.35:5061;rport;branch=z9hG4bKbe501b3b93db5f4ef5082fb00a471ea3
Max-Forwards: 70
From: 14107010060 <sip:14107010060@128.151.22.62>;tag=ae1e329ace97e5d3d6961486cdb57533
To: <sip:*69@128.151.22.62>;tag=as36ad7906
Call-ID: a8b2144b37ed1f06ea15226192c10a5c@10.0.1.44
CSeq: 200 ACK
Expires: 300
User-Agent: Sippy


9 headers, 0 lines
Destroying call 'a8b2144b37ed1f06ea15226192c10a5c@10.0.1.44'
web1*CLI>
By: Mark Spencer (markster) 2005-01-27 18:33:03.000-0600

Am I missing something?  You don't have insecure = yes and the port number 5061 does not match the default 5060 port and this should not (and does not) match the peer.
By: Olle Johansson (oej) 2005-01-28 01:27:40.000-0600

Jtodd: In the latest debug, this is the important part:
<pre>
--------
Looking for *69 in default
Reliably Transmitting (no NAT):
SIP/2.0 404 Not Found
--------
</pre>
Asterisk in this case accepts the invite - but does not find the *69 extension in the dialplan, context default. As Mark said, it doesn't match the peer and goes to the default context in [general], which is "default" by default if you do not configure it.
By: Mark Spencer (markster) 2005-01-30 01:07:13.000-0600

John, is this something to be closed or do you still feel there is a problem?
By: Mark Spencer (markster) 2005-02-03 00:06:04.000-0600

Closing on the assumption this is a configuration issue.  John can re-open if he has more to add.