[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 05:04 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").
====================================================================== 

---------------------------------------------------------------------- 
 ibc - 12-19-07 05:04  
---------------------------------------------------------------------- 
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...  :( 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
12-19-07 05:04  ibc            Note Added: 0075696                          
======================================================================