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-0600 | Date Closed: | 2011-04-05 10:40:42 | ||
Priority: | Minor | Regression? | No | ||
Status: | Closed/Complete | Components: | Channels/chan_sip/General | ||
Versions: | Frequency of Occurrence | ||||
Related Issues: |
| ||||
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 |