[asterisk-bugs] [Asterisk 0011264]: Asterisk doesn't reply well to in-dialog OPTIONS in pedantic mode

noreply at bugs.digium.com noreply at bugs.digium.com
Wed Nov 21 02:37:35 CST 2007


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11264 
====================================================================== 
Reported By:                ibc
Assigned To:                oej
====================================================================== 
Project:                    Asterisk
Issue ID:                   11264
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.4.13  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             11-15-2007 14:04 CST
Last Modified:              11-21-2007 02:37 CST
====================================================================== 
Summary:                    Asterisk doesn't reply well to in-dialog OPTIONS in
pedantic mode
Description: 
A way to monitorize a SIP dialog is by sending in-dialog OPTIONS so the
UAC/UAS replies with 200 OK if that dialog exists or 404 if not.

Asterisk with pedantic=no replies a "404 Not Found" correctly but in
pedantic=yes it replies with a "481 Call/Transaction Does Not Exist".

I'm not 100% sure (I'll try to confirm it) but I think it should reply
with a 404 instead of 481 in this case (OPTIONS in-dialog).
====================================================================== 

---------------------------------------------------------------------- 
 oej - 11-21-07 02:37  
---------------------------------------------------------------------- 
The big issue here, and cause of this issue, is that you are sending out a
call without a proper caller ID. If you set the caller ID number to
something that exists in the dialplan and can be reached, asterisk would
answer 200 OK on the options.

There is another big issue in Asterisk with OPTIONs handling though, which
is that since we don't authenticate, we might check the wrong context and
end up with the wrong answer. Adding authentication to OPTIONs seems like a
lot of extra processing in many cases where it's only used as a keep-alive
and the answer is ignored...

So we have three cases:

1. OPTIONs out of dialog for keepalives ("ping")
2. OPTIONs out of dialog for callee capability checking/extension
checking
3. OPTIONs inside a dialog

Seems to me like we handle 2 and 3 the wrong way. I'm still not very
convinced on the in-dialog always answering 200 OK, so that's something we
need to check with other implementations. In this case the OPTION is using
a request uri that doesn't exist in the dialplan, so an INVITE formed like
this would fail too. Maybe not a re-invite where you mostly ignore the
request URI, which might be the point here. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-21-07 02:37  oej            Note Added: 0074126                          
======================================================================




More information about the asterisk-bugs mailing list