[Home]

Summary:ASTERISK-16997: [patch] No answer to OPTIONS packet because Asterisk not looking for 's' in default context
Reporter:shmaize (shmaize)Labels:
Date Opened:2010-11-22 02:54:10.000-0600Date Closed:2011-04-05 10:40:42
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
is duplicated byASTERISK-18107 Asterisk is not answering correctly the OPTIONS messages sent by SIP provider.
Environment:Attachments:( 0) issue18348_v1.8.patch
Description:Hello,

asterisk-1.8.0 installed through yum on CentOS 5.5 32bit.

My SIP provider is checking if I'm alive with OPTIONS. I must answer to that request with "SIP/2.0 200 OK". The default behavior is to check if I have a peer with that IP, then check for "s" in it's context. If not check for "s" in the guests context (context=XX from general section of sip.conf). Or I'm missing something?

With 1.8.0 the extension part is missing. Some debug logs:
1.1.1.1 is the SIP provider, 2.2.2.2 is my IP.

/var/log/asterisk/full:
[Nov 18 16:38:05] DEBUG[6942] chan_sip.c: = Looking for  Call ID: 269dd7c535d89368dbb1770a86cd13df@1.1.1.1 (Checking From) --From tag 24178 --To-tag  
[Nov 18 16:38:05] DEBUG[6942] acl.c: For destination '1.1.1.1', our source address is '2.2.2.2'.
[Nov 18 16:38:05] DEBUG[6942] chan_sip.c: Setting SIP_TRANSPORT_UDP with address 2.2.2.2:5060
[Nov 18 16:38:05] DEBUG[6942] chan_sip.c: Allocating new SIP dialog for 269dd7c535d89368dbb1770a86cd13df@1.1.1.1 - OPTIONS (No RTP)
[Nov 18 16:38:05] DEBUG[6942] chan_sip.c: **** Received OPTIONS (3) - Command in SIP OPTIONS
[Nov 18 16:38:05] DEBUG[6942] chan_sip.c: Trying to put 'SIP/2.0 404' onto UDP socket destined for 1.1.1.1:5080
[Nov 18 16:38:05] DEBUG[6942] chan_sip.c: SIP message could not be handled, bad request: 269dd7c535d89368dbb1770a86cd13df@1.1.1.1


<--- SIP read from UDP:1.1.1.1:5080 --->
OPTIONS sip:2.2.2.2:5060 SIP/2.0
Call-ID: 7ee61f3291443916e4d631a411c231b5@1.1.1.1
CSeq: 100 OPTIONS
From: "Voxbone Monitoring" <sip:voxmon@1.1.1.1>;tag=95055
To: <sip:2.2.2.2:5060>
Max-Forwards: 30
Route: <sip:2.2.2.2:5060>
Via: SIP/2.0/UDP 1.1.1.1:5080;branch=z9hG4bKfabde850548854ad76efa0335e4bfe82
Content-Length: 0

<------------->
--- (9 headers 0 lines) ---
Looking for  in guests (domain 2.2.2.2:5060)

<--- Transmitting (no NAT) to 1.1.1.1:5080 --->
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 1.1.1.1:5080;branch=z9hG4bKfabde850548854ad76efa0335e4bfe82;received=1.1.1.1
From: "Voxbone Monitoring" <sip:voxmon@1.1.1.1>;tag=95055
To: <sip:2.2.2.2:5060>;tag=as5967e5ef
Call-ID: 7ee61f3291443916e4d631a411c231b5@1.1.1.1
CSeq: 100 OPTIONS
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Accept: application/sdp
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog '7ee61f3291443916e4d631a411c231b5@1.1.1.1' in 32000 ms (Method: OPTIONS)

In the part "Looking for  in guests" it should be "Looking for s in guests".

sip.conf
[general]

bindport=5060           ; Port to bind to (SIP is 5060)
srvlookup=yes
bindaddr=2.2.2.2
disallow=all                                                        
allow=alaw                                                          
dtmfmode=rfc2833
allowguest=no
canreinvite=no
context=guests ; Send unknown SIP callers to this context          
callerid=Unknown
allowoverlap=no                 ; Disable overlap dialing support. (Default is yes)
allowtransfer=no
useragent=Asterisk PBX
externip=2.2.2.2


When testing with 1.6.2.14 (installed from yum) it's OK:
<------------->
--- (9 headers 0 lines) ---
Looking for s in guests (domain 2.2.2.2)

<--- Transmitting (no NAT) to 1.1.1.1:5080 --->
SIP/2.0 200 OK
Comments:By: Stefan Schmidt (schmidts) 2010-11-22 15:27:03.000-0600

i am not sure but it could be the pedantic=yes (default) part of 1.8 which cause this.
please try to add a pedantic=no to your sip.conf and tell us if its changing the behavior.

thx

Stefan
By: shmaize (shmaize) 2010-11-24 03:23:38.000-0600

Nope, still the same behavior.
By: Paul Belanger (pabelanger) 2010-11-24 19:51:58.000-0600

Why not create a SIP peer?
By: shmaize (shmaize) 2010-11-25 02:47:06.000-0600

[voxmon]
type=peer
port=5080
host=1.1.1.1
insecure=invite,port
context=bla

Still not working..
And if it was working it's not a solution. The VoIP provider can ping me with OPTIONS from different IPs.

So is this a bug or feature?
By: Leif Madsen (lmadsen) 2010-12-06 14:36:04.000-0600

This is a bug, but I know I've seen this issue already opened. I'll try to find it and relate it here.
By: Dan Ohnesorg (danoh) 2010-12-22 04:29:22.000-0600

I have also similiar problem. I need to respond to:

OPTIONS sip:ASTERISK-859@1.1.1.1 SIP/2.0

With SIP/2.0 200 OK

which works in 1.6, when I create this extension:

 exten => _ASTERISK-859,1,NoOp(${EXTEN})

in untrusted context (we have context=untrusted in [general] section of sip.conf)

but stopped to work after upgrade to 1.8

pedantic=no seems not solve it.

We use this to switch between primary and backup asterisk, SIP trunk provider routes the calls to the one, which responds to OPTIONS packets.
By: Jorge Kleinerman (jkleinerman) 2010-12-22 09:45:38.000-0600

I see the same problem in Asterisk 1.8.1.1.
Also, I continue seeing the issue setting pedantic=no en sip.conf
By: shmaize (shmaize) 2011-02-02 06:17:14.000-0600

What is the status of this issue? Any progress?
I think it's a big problem. Many VoIP providers are checking if the peer is alive with OPTIONS packets and considering "dead" if no response is send back. So right now asterisk 1.8 DO NOT support that kind of trunks.
By: Jorge Kleinerman (jkleinerman) 2011-02-02 08:18:58.000-0600

shmaize, did you test it in the last version: 1.8.2.3??
By: shmaize (shmaize) 2011-02-07 03:22:41.000-0600

I tryed with 1.8.2.2-1_centos5 from the repository, not working..

Also the chan_sip.c from asterisk-1.8.2.3.tar.gz and asterisk-1.8.2.2.tar.gz are identical.
By: Marcin Kowalczyk (kowalma) 2011-02-28 17:55:02.000-0600

same happens with 1.8.3
There is:
Looking for  in default (domain 192.168.85.133:5060)
(note - double space between for and in - like there should be sth)


By: ks-steven (ks-steven) 2011-03-15 10:09:26

I don't see why you would want to go through the dialplan for this anyway. I think changing channels/chan_sip.c > line 20622 from:

/* must go through authentication before getting here */
res = (get_destination(p, req, NULL) == SIP_GET_DEST_EXTEN_FOUND ? 0 : -1);
build_contact(p);

if (ast_strlen_zero(p->context))
       ast_string_field_set(p, context, sip_cfg.default_context);

if (ast_shutting_down())
       transmit_response_with_allow(p, "503 Unavailable", req, 0);
else if (res < 0)
       transmit_response_with_allow(p, "404 Not Found", req, 0);
else
       transmit_response_with_allow(p, "200 OK", req, 0);

to:
/* must go through authentication before getting here */
build_contact(p);

if (ast_strlen_zero(p->context))
       ast_string_field_set(p, context, sip_cfg.default_context);

if (ast_shutting_down())
       transmit_response_with_allow(p, "503 Unavailable", req, 0);
else
       transmit_response_with_allow(p, "200 OK", req, 0);

solves the problem.
Also not going through the dialplan for SIP-OPTIONS saves unnecessary cpu cycles :-)
By: shmaize (shmaize) 2011-03-17 04:59:41

Confirmed, that patch works.
So... will it be added to the official release?
By: Richard Mudgett (rmudgett) 2011-04-04 18:06:37

The issue18348_v1.8.patch should take care of this issue.
By: shmaize (shmaize) 2011-04-05 02:59:43

Yes, the patch works.
By: Digium Subversion (svnbot) 2011-04-05 10:38:16

Repository: asterisk
Revision: 312866

U   branches/1.8/channels/chan_sip.c

------------------------------------------------------------------------
r312866 | rmudgett | 2011-04-05 10:38:15 -0500 (Tue, 05 Apr 2011) | 15 lines

Responding to OPTIONS packet with 404 because Asterisk not looking for "s" extension.

The get_destination() function was not using the "s" extension when the
request URI did not specify an extension.  This is a regression caused
when the URI parsing code was extracted into parse_uri().

Made get_destination() substitute the "s" extension when the parsed URI
results in an empty string.

(closes issue ASTERISK-16997)
Reported by: shmaize
Patches:
     issue18348_v1.8.patch uploaded by rmudgett (license 664)
Tested by: shmaize

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=312866
By: Digium Subversion (svnbot) 2011-04-05 10:40:40

Repository: asterisk
Revision: 312868

_U  trunk/
U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r312868 | rmudgett | 2011-04-05 10:40:39 -0500 (Tue, 05 Apr 2011) | 22 lines

Merged revisions 312866 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

........
 r312866 | rmudgett | 2011-04-05 10:38:14 -0500 (Tue, 05 Apr 2011) | 15 lines
 
 Responding to OPTIONS packet with 404 because Asterisk not looking for "s" extension.
 
 The get_destination() function was not using the "s" extension when the
 request URI did not specify an extension.  This is a regression caused
 when the URI parsing code was extracted into parse_uri().
 
 Made get_destination() substitute the "s" extension when the parsed URI
 results in an empty string.
 
 (closes issue ASTERISK-16997)
 Reported by: shmaize
 Patches:
       issue18348_v1.8.patch uploaded by rmudgett (license 664)
 Tested by: shmaize
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=312868