[Home]

Summary:ASTERISK-01479: host= in SIP client config not always recognized
Reporter:gdalgliesh (gdalgliesh)Labels:
Date Opened:2004-05-05 19:03:56Date Closed:2011-06-07 14:05:14
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Call comes from ccc.ccc.ccc.ccc to Asterisk and the Invite in Example A in ends up in [inbound] context but in Example B it ends up in [default]. It would appear the something in the construct of the SIP messages btw the 2 is causing the system to react differently. (Running CVS-HEAD-05/05/04-09:31:12)

/etc/asterisk/sip.conf
[general]
port = 5060                     ; Port to bind to
bindaddr = aaa.aaa.aaa.aaa               ; Address to bind to
context = default            ; Default for incoming calls

[carriera]
type=friend
host=ccc.ccc.ccc.ccc
context=inbound

[carrierb]
type=friend
host=bbb.bbb.bbb.bbb
context=inbound

/etc/asterisk/extensions.conf
[inbound]
exten => _.,1,Playback,tt-monkeysintro

[default]
exten => _.,1,Congestion


Example A:
U ccc.ccc.ccc.ccc:5060 -> aaa.aaa.aaa.aaa:5060
 INVITE sip:4445552574@aaa.aaa.aaa.aaa SIP/2.0..
Via: SIP/2.0/UDP ccc.ccc.ccc.ccc:5060;branch=z9hG4bK7ab24dcc..
From: "asterisk" <sip:asterisk@ccc.ccc.ccc.ccc>;tag=as3a541e32..
To: <sip:4445552574@aaa.aaa.aaa.aaa>..Contact:
<sip:asterisk@ccc.ccc.ccc.ccc>..
Call-ID: 75adb4aa7e9ff711120b14f518b44a1b@ccc.ccc.ccc.ccc..
CSeq: 102 INVITE..
User-Agent: Asterisk PBX..Date: Wed, 05 May 2004 21:08:44 GMT..Allow:
INVITE, ACK, CANCEL, OPTIONS, BYE, REFER..
Content-Type: application/sdp..
Content-Length: 211..
..
v=0..
o=root 13122 13122 IN IP4 ccc.ccc.ccc.ccc..
s=session..
c=IN IP4 ccc.ccc.ccc.ccc..
t=0 0..m=audio 18980 RTP/AVP 0 3 8..
a=rtpmap:0 PCMU/8000..
a=rtpmap:3 GSM/8000..
a=rtpmap:8 PCMA/8000..
a=silenceSupp:off - - - -..
#

Example B:
U bbb.bbb.bbb.bbb:44151 -> aaa.aaa.aaa.aaa:5060
 INVITE sip:4445552574@aaa.aaa.aaa.aaa:5060 SIP/2.0..
Call-ID: 7007601020188505154-1083791562@bbb.bbb.bbb.bbb..
From: sip:8889992264@bbb.bbb.bbb.bbb:5060;tag=12436..
To: sip:4445552574@aaa.aaa.aaa.aaa:5060..
Content-Length: 251..
Content-Type: application/sdp..
CSeq: 1 INVITE..
Via: SIP/2.0/UDP bbb.bbb.bbb.bbb:5060;branch=z9hG4bK-61400000000
 03442-414d9af3..
Contact: sip:8889992264@bbb.bbb.bbb.bbb:5060..
Supported: 100rel..
Max-Forwards: 70..
..
v=0..
o=MG4000|1.0 111 12345 IN IP4 65.77.154.6..
s=-..
c=IN IP4 65.77.154.6..
t=0 0..
m=audio 7824 RTP/AVP 18 0 102 103..
a=rtpmap:102 G.723.1a-L/8000..
a=rtpmap:103 telephone-event/8000..
a=fmtp:103 0-15..
a=X-sqn: 0..a=X-cap: 1
image udptl t38..
a=ptime:10..
Comments:By: Brian West (bkw918) 2004-05-05 19:17:26

in this case you don't use type=friend you use type=peer

See if that helps.

bkw
By: gdalgliesh (gdalgliesh) 2004-05-05 19:23:29

Same results with type=peer on the one that works and the one the doesn't.
Thanks
By: Brian West (bkw918) 2004-05-05 19:47:37

accually i'm seeing similar results also.

bkw
By: Brian West (bkw918) 2004-05-05 20:20:05

You MUST have insecure=yes to your peers if you don't auth.
By: gdalgliesh (gdalgliesh) 2004-05-05 21:15:22

Well that seemed to do it but I am a little confused about why one worked without and another didn't.
By: Brian West (bkw918) 2004-05-05 21:17:01

well their is a bug here mark is working on it. :)
By: Mark Spencer (markster) 2004-05-05 21:25:57

This reeks of extreme bogosity.  Working with bkw_ I had discovered a way a call could sneak through if it matched a user entry but failed host entry, and then asterisk wouldn't continue to check the peers.  However, this is extremely rare in a configuration file (but this was in fact the problem that bkw_ was seeing).

I've fixed that behavior, but perhaps more importantly I've added to SIP debug lines showing what user or peer it's matching against to help you diagnose this.
By: Brian West (bkw918) 2004-05-05 22:17:11

We did infact find a bug but not sure if it was related to this problem I think he has it fixed.  If not please let me know and we will reopen.

bkw