Summary:	ASTERISK-11075: Initial OPTIONS not sent to "peer" context (IP matching) but to the general one
Reporter:	Iñaki Baz Castillo (ibc)	Labels:
Date Opened:	2007-12-18 10:19:22.000-0600	Date Closed:	2008-01-22 09:18:03.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Interoperability
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Hi, I configure a peer:  [sip-provider]  type=peer  insecure=invite  context=from-sip-provider  host=66.66.66.66  port=5060 and in sip.conf I define:  [general]  context=none I receive periodical OPTIONS from the provider with empty username in the RURI (so "s" is matched), but Asterisk doesn't send the request to "from-sip-provider" context, but to "none" (the context defined in [general] section). Of course the OPTIONS comes from IP 66.66.66.66 (defined as "host" in peer configuration as you can see above), so IMHO the request should be sent to "from-sip-provider" context (source IP matches) where the "s" extension exists just to reply a "200 OK" (this makes happy the provider XD). This is the debug: <--- SIP read from 66.66.66.66:5060 ---> OPTIONS sip:111.111.111.111 SIP/2.0 From: <sip:66.66.66.66>;tag=-13c4-4767f048-4a46ee13-b9b39a7 To: <sip:111.111.111.111> Call-ID: 787c73e8-90000e3e-13c4-4767f048-4a46ee13-11c7aac1@66.66.66.66 CSeq: 2052108902 OPTIONS Via: SIP/2.0/UDP 66.66.66.66:5060;maddr=66.66.66.66;branch=z9hG4bK-4767f048-4a46ee13-3ad29e54 User-agent: CS2000_NGSS/8.0 Max-Forwards: 70 Accept: application/isup, application/sdp, application/dtmf-relay, audio/telephone-event Supported: 100rel Allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK Content-Length: 0 <-------------> --- (12 headers 0 lines) --- Looking for s in none (domain 111.111.111.111) <--- Transmitting (no NAT) to 66.66.66.66:5060 ---> SIP/2.0 404 Not Found Via: SIP/2.0/UDP 66.66.66.66:5060;maddr=66.66.66.66;branch=z9hG4bK-4767f048-4a46ee13-3ad29e54;received=66.66.66.66 From: <sip:66.66.66.66>;tag=-13c4-4767f048-4a46ee13-b9b39a7 To: <sip:111.111.111.111>;tag=as6dbbab89 Call-ID: 787c73e8-90000e3e-13c4-4767f048-4a46ee13-11c7aac1@66.66.66.66 CSeq: 2052108902 OPTIONS User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Accept: application/sdp Content-Length: 0 As you see: "Looking for s in none". IMHO it's a bug, isn't it? PD: I've generated an usual debug but the info provided is less than in CLI (the only place where I read "Looking for s in none").
Comments:	By: Olle Johansson (oej) 2007-12-19 01:03:33.000-0600 This is a known issue, there's already a note of it in the source. However, it requires a lot of changes to the code and will take more processing power of the server, especially since in some cases it will require proper authentication to match the peer. Is it really worth it? By: Iñaki Baz Castillo (ibc) 2007-12-19 02:18:36.000-0600 Thanks for the info. I'll try today if replying 200 OK to those initial OPTIONS is a need for the SIP provider, maybe it just use them as a ping without the need of receiving 200 OK. By: Iñaki Baz Castillo (ibc) 2007-12-19 05:04:24.000-0600 Ops, unfortunatelly my SIP provider requires my Asterisk reply a 200 OK for that OPTIONS. So I have to do a dirty trick: ** sip.conf:  [general]  context = dirty-trick-context  [sip-provider]  context=from-sip-provider  host=66.66.66.66 ** extensions.conf:  [dirty-trick-context]  ; Initial OPTIONS not sent to "peer" context (IP matching)  ; but to the general one  ; http://bugs.digium.com/view.php?id=11591  exten => s,1,NoOp(Incoming OPTIONS probably from sip-provider) so sip-provider receives a 200 OK when sending OPTIONS. Dirty trick...  :( By: Olle Johansson (oej) 2007-12-19 07:51:15.000-0600 Sorry for not giving you the workaround earlier, but I still see this as a problem. The solution is not beautiful, so I'm kind of in pains trying to make a decision here. By: Iñaki Baz Castillo (ibc) 2007-12-19 07:56:16.000-0600 Ok, don't worry for me, I can live with it ;) By: Olle Johansson (oej) 2008-01-22 09:17:46.000-0600 Ok, I've made a note about it in the source code for future problem solving. Thanks for your patience.