[asterisk-bugs] [Asterisk 0011591]: Initial OPTIONS not sent to "peer" context (IP matching) but to the general one
noreply at bugs.digium.com
noreply at bugs.digium.com
Wed Dec 19 07:56:17 CST 2007
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 07:56 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 07:56
----------------------------------------------------------------------
Ok, don't worry for me, I can live with it ;)
Issue History
Date Modified Username Field Change
======================================================================
12-19-07 07:56 ibc Note Added: 0075701
======================================================================
More information about the asterisk-bugs
mailing list