[Home]

Summary:ASTERISK-05398: Broadworks servers apperently (ab)use "OPTIONS" as a status PING, ast should return OK, not 404
Reporter:Tommy McNeely (tommythekid)Labels:
Date Opened:2005-10-30 01:33:34.000-0600Date Closed:2006-03-29 16:14:58.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) new-sip-uri-decoding-2.patch
( 1) sip-broadworks.patch
( 2) sip-debug.txt
Description:My coworkers broadworks servers would not route calls to my asterisk gateway. I found that it was sending us OPTIONS queries (several times per minute) that we were saying "404 NOT FOUND" to. I believe a more proper response is "200 OK" which means that get_destination needs to return 0

I have a little patch that checks for OPTIONS method with NO user portion (as user portions should be caught by the normal return 0 or get -1 (404) if they don't exist.

$ cvs diff channels/chan_sip.c
Index: channels/chan_sip.c
===================================================================
RCS file: /usr/cvsroot/asterisk/channels/chan_sip.c,v
retrieving revision 1.899
diff -u -r1.899 chan_sip.c
--- channels/chan_sip.c 28 Oct 2005 13:37:31 -0000      1.899
+++ channels/chan_sip.c 30 Oct 2005 01:21:26 -0000
@@ -6570,7 +6570,12 @@
           !strncmp(uri, ast_pickup_ext(),strlen(uri))) {
               return 1;
       }
-
+
+       /* Return 0 for "OPTIONS" requests with no user@ part (application level ping) */
+       if ((req->method == SIP_OPTIONS) && (strcmp(uri, "@"))) {
+               return 0;
+       }
+
       return -1;
}



I developed this from *HOME* even tho it was for a problem I was seeing at work. I give digium the right to use this code as they see fit (or whatever).

Tommy
Comments:By: Leif Madsen (lmadsen) 2005-10-30 01:45:21.000-0600

Contacted via IRC re: bug guidelines and disclaimer form.
By: Mark Spencer (markster) 2005-10-30 01:57:33.000-0600

Can you supply a SIP debug of these options, please?
By: Olle Johansson (oej) 2005-10-30 03:03:41.000-0600

We need to see the the OPTIONs packet. We response 404 if the extension they ask for is not found. If you add the extension to the context in the default context under [general] we will respond 200 OK. If there is no user name part in the URI, you should add an "s" extension to the context.

The idea with OPTIONS is to respond the same way we should have done on a similar INVITE. That's what we are doing and that's why your patch is causing an error instead of fixing the problem.

Please respond if you can fix the problem following this advice. If not, add a SIP debug trace.
By: Tommy McNeely (tommythekid) 2005-10-30 12:39:36.000-0600

I am totally willing to believe its a configuration issue :)

I de-patched, and created an "s" extension in both the "default" context and the "lucentaes" context. It should be going to lucentaes per the peer definition, but I think it may be looking in default by looking at the sip debug.. anyhow still getting "404 NOT FOUND" that way.

(sip.conf)
....
[lucentaes-mpk]
context=lucentaes
type=peer
nat=no
host=10.6.4.43
promiscredirect=yes     ;this doesnt work yet, must be set globally
insecure=invite,port

[lucentaes-brm]
context=lucentaes
type=peer
nat=no
host=10.1.224.33
promiscredirect=yes     ;this doesnt work yet, must be set globally
insecure=invite,port



(extensions.conf)
....
[lucentaes]

exten => s,1,Noop(CALL CAME IN WITH NO EXTENSION IN lucentaes)
exten => s,2,Goto(default,i,1)

include => inbound
include => internal
include => international
include => longdistance
include => local

...

[default]

; for security reasons we are not using the default context
; if a user somehow ends up here, they should get some sort
; of error and the line should be disconnected.

exten => s,1,Noop(CALL IN DEFAULT CONTEXT)
exten => s,2,Goto(i)


exten => i,1,Noop(ERROR: Call from ${CALLERID} to ${EXTEN} ended up in default context!)
exten => i,n,Answer
exten => i,n,Wait,1
exten => i,n,Playtones(info)
exten => i,n,Wait,2
exten => i,n,Playback(tt-weasels)
exten => i,n,Playback(goodbye)
exten => i,n,hangup


<-- SIP read from 10.6.4.43:32799:
OPTIONS sip:10.6.4.61:5060 SIP/2.0
Via:SIP/2.0/UDP 10.6.4.43;branch=z9hG4bK-BroadWorks.10.6.4.43-10.6.4.61V5060-0-560291510-1312113796-1130696981868
From:<sip:10.6.4.43>;tag=1312113796-1130696981868
To:<sip:10.6.4.61:5060>
Call-ID:BW112941869301005671282459@10.6.4.43
CSeq:560291510 OPTIONS
Max-Forwards:10
Content-Length:0


--- (8 headers 0 lines)---
Looking for 10.6.4.61:5060 in default (domain )
Transmitting (no NAT) to 10.6.4.43:32799:
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 10.6.4.43;branch=z9hG4bK-BroadWorks.10.6.4.43-10.6.4.61V5060-0-560291510-1312113796-1130696981868;received=10.6.4.43
From: <sip:10.6.4.43>;tag=1312113796-1130696981868
To: <sip:10.6.4.61:5060>;tag=as744ef150
Call-ID: BW112941869301005671282459@10.6.4.43
CSeq: 560291510 OPTIONS
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Max-Forwards: 70
Contact: <sip:10.6.4.61>
Accept: application/sdp
Content-Length: 0


---
Destroying call 'BW112941869301005671282459@10.6.4.43'

(repeats like 5 times each minute, where as when we say "OK" it seems "happier")
By: Tommy McNeely (tommythekid) 2005-10-30 12:42:59.000-0600

ffwiw, I noticed a typo in default context after I submitted..

exten => s,2,Goto(default,i,1)


... but its still giving 404 :)
By: Olle Johansson (oej) 2005-10-30 14:19:42.000-0600

You need to set verbose to 4 and debug to 4 before capturing output, so we see how we match and enter the dial plan. Please add the debug as a separate file, not inline in the bug report. Thank you!
By: Tommy McNeely (tommythekid) 2005-10-30 18:52:44.000-0600

I saw no change in the sip debug output from the verb = 3 / debug = 0 to both set to 4 or even 5.
By: Tommy McNeely (tommythekid) 2005-10-30 20:41:19.000-0600

** I think this is what you are lookgin for:
Looking for 10.6.4.61:5060 in default (domain )

I don't see any logic that looks for exten => s .. matter of fact, the "host part" should be stripped off by...
       /* Get the target domain */
       if ((a = strchr(uri, '@'))) {
               char *colon;
               *a = '\0';
               a++;
               colon = strchr(a, ':'); /* Remove :port */
               if (colon)
                       *colon = '\0';
               ast_copy_string(p->domain, a, sizeof(p->domain));
       }


.. so as I understand it.. its actually doing TWO things there.. its changing the '@' to a '\0' which effectively splits the "extension" from the "domain" (and then subsequently removes the port). However, there is no "@" in the SIP URI's I pasted, its just "sip:10.6.4.61:5060", so, the domain part never gets set. and uri = "sip:10.6.4.61:5060" .. which ofcourse is not going to match any of my extensions. I think that *maybe* the logic of the code above needs some "help" .. then uri (which is used as exten later) should be ""?
By: Tommy McNeely (tommythekid) 2005-10-30 21:41:35.000-0600

.. continuing from my last note...

I have changed the function as such for testing...
*****
       /* Get the target domain */
       if ((a = strchr(uri, '@'))) {
               char *colon;
               *a = '\0';
               a++;
               colon = strchr(a, ':'); /* Remove :port */
               if (colon)
                       *colon = '\0';
               ast_copy_string(p->domain, a, sizeof(p->domain));
       } else {
               /* there is no "@" in uri, thus no exten, so we should go to "s"
                  - this breakes the "domain" part, but thats not getting parsed properly above anyhow
                  - there is probably a constant for "s" incase that should ever change? */
               uri = "s";
       }

       /* Skip any options */
       /* Tommy thinks this should NEVER catch as the options will be stripped with the port */
       if ((a = strchr(uri, ';'))) {
               *a = '\0';
       }
*****

if I set uri = NULL, ast crashes
if I set uri = '\0' ast crashes (ofcourse)
if I set uri = "" ast returns "484 Address Incomplete" (this is like sip:@host.domain")
if I set uri = "s" ast returns "200 OK" (like I want, provided "s" exists ofcourse)

.. so, anyways.. I think that whole section needs some "work":

- the "strip port" needs to be *outside* the if statement for "@"
- the "strip options" doesn't actually accomplish anything on a normal "user@host:port;options" URI, because its working on the "uri" pointer which is way back at the beginning, we need to increment "a" and work from there like "strip port" does if its desireable to use the "port" without the "options" otherwise its just pointless :)

I do *not* believe setting uri = "s" is the proper thing to do, however, the RFC doesn't seem to make a distinction on what we should do in the case of a "sip options ping" :) .. I still like my original patch that just checked for method of SIP_OPTIONS and no "@" sign :)

~tommy

~tommy
By: Tommy McNeely (tommythekid) 2005-10-30 23:44:47.000-0600

eeek... can someone delete the patch named "new-sip-uri-decoding.patch" .. I changed something at the last minute like a dumbass and forgot to "test" .. the -2 one is working. Comments?
By: Olle Johansson (oej) 2005-10-31 02:00:06.000-0600

You need to make sure that verbose and debug logging is sent to the console in the logging configuration file.
By: Tommy McNeely (tommythekid) 2005-10-31 23:47:53.000-0600

Sorry for the delay, it became Monday, and this is a production server :)

IN the debug output:
Oct 31 21:34:33] Looking for 10.6.4.61:5060 in default (domain )

says a couple things to me..
1: it thinks the dialed extension is "10.6.4.61:5060"
2: its matching the "default" context, altho it should be "lucentaes-mpk" as per the config posted earlier
3: the domain is not getting parsed properly (new-sip-uri-decoding-2.patch fixes that)

What are the next steps? I have preliminary approval to sign the disclaimer, waiting on "written" :)

~tommy
By: Olle Johansson (oej) 2006-01-05 12:08:59.000-0600

Any update on the disclaimer?
By: Tommy McNeely (tommythekid) 2006-01-17 16:51:47.000-0600

D'oh,

I am re-pinging management. We were investigating whether I needed approval or not, since I did this on my own time. Anyhow, will keep you posted. I do think something has changed since this bug was filed, as I upgraded to 1.2.1 and I *think* its "200 OK" now. However, we also ended our period of unable to talk with Lucent and got them to help us workaround the issue in their configuration.

~tommy
By: Tommy McNeely (tommythekid) 2006-01-20 19:03:33.000-0600

I can sign the disclaimer... now I just need to find somewhere thats still living in the like 80s so I can FAX it. :)
By: Olle Johansson (oej) 2006-01-30 04:42:19.000-0600

Is this still an issue in svn trunk or Asterisk 1.2.3 or are we ready to close this report?

/O
By: Tommy McNeely (tommythekid) 2006-02-04 00:53:21.000-0600

I *think* it was resolved in 1.2.1, but I am out of the office, we are planning an upgrade to 1.2.3 as soon as early next week, or this weekend maybe :) I will let you know.

~tommy
By: Olle Johansson (oej) 2006-03-05 03:58:22.000-0600

Please try the patch in bug ASTERISK-6247. Thanks.
By: Olle Johansson (oej) 2006-03-29 16:14:45.000-0600

Resolved in another bug report. No answer from reporter...