|Summary:||ASTERISK-01479: host= in SIP client config not always recognized|
|Date Opened:||2004-05-05 19:03:56||Date Closed:||2011-06-07 14:05:14|
|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)|
port = 5060 ; Port to bind to
bindaddr = aaa.aaa.aaa.aaa ; Address to bind to
context = default ; Default for incoming calls
exten => _.,1,Playback,tt-monkeysintro
exten => _.,1,Congestion
U ccc.ccc.ccc.ccc:5060 -> aaa.aaa.aaa.aaa:5060
INVITE sip:firstname.lastname@example.org SIP/2.0..
Via: SIP/2.0/UDP ccc.ccc.ccc.ccc:5060;branch=z9hG4bK7ab24dcc..
From: "asterisk" <sip:email@example.com>;tag=as3a541e32..
CSeq: 102 INVITE..
User-Agent: Asterisk PBX..Date: Wed, 05 May 2004 21:08:44 GMT..Allow:
INVITE, ACK, CANCEL, OPTIONS, BYE, REFER..
o=root 13122 13122 IN IP4 ccc.ccc.ccc.ccc..
c=IN IP4 ccc.ccc.ccc.ccc..
t=0 0..m=audio 18980 RTP/AVP 0 3 8..
a=silenceSupp:off - - - -..
U bbb.bbb.bbb.bbb:44151 -> aaa.aaa.aaa.aaa:5060
INVITE sip:firstname.lastname@example.org:5060 SIP/2.0..
CSeq: 1 INVITE..
Via: SIP/2.0/UDP bbb.bbb.bbb.bbb:5060;branch=z9hG4bK-61400000000
o=MG4000|1.0 111 12345 IN IP4 22.214.171.124..
c=IN IP4 126.96.36.199..
m=audio 7824 RTP/AVP 18 0 102 103..
a=X-sqn: 0..a=X-cap: 1
image udptl t38..
|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.
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.
By: Brian West (bkw918) 2004-05-05 19:47:37
accually i'm seeing similar results also.
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.