[asterisk-bugs] [Asterisk 0011591]: Initial OPTIONS not sent to "peer" context (IP matching) but to the general one

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11591 
====================================================================== 
Reported By:                ibc
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11591
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.15  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             12-18-2007 10:19 CST
Last Modified:              12-19-2007 01:03 CST
====================================================================== 
Summary:                    Initial OPTIONS not sent to "peer" context (IP
matching) but to the general one
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 at 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 at 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").
====================================================================== 

---------------------------------------------------------------------- 
 oej - 12-19-07 01:03  
---------------------------------------------------------------------- 
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? 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
12-19-07 01:03  oej            Note Added: 0075692                          
======================================================================