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

[noreply at bugs.digium.com]

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:              05-15-2008 09:08 CDT
====================================================================== 
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).
====================================================================== 

---------------------------------------------------------------------- 
 ibc - 05-15-08 09:08  
---------------------------------------------------------------------- 
More info:

There is a RFC handling those issues:
  RFC 5057 - Multiple Dialog Usages in the Session Initiation Protocol

Anyway it's not clear after reading it, but I've got a nice explanation in
sip-implementators maillist (by Paul Kyzivat from Cisco):


----------------------
Now that I look at it, section 5.3 of 5057 may be less than crystal 
clear on this point.

If the OPTIONS is sent within a dialog, AFAIK it will indeed monitor 
dialog state to the extent that it will fail with a 481 if there is no 
dialog matching its from- and to-tags and Call-ID.

However it will not provide any information on the status of any 
particular usage within that dialog.

*If* it is known that the dialog only had a single usage (the normal 
case) then it provides *some* evidence of the continued existence of 
that usage. But it is in general impossible to know there was a single 
usage. For instance, a REFER may have been sent within the dialog, 
resulting in a refer subscription usage sharing the dialog. Then the 
INVITE-usage could have gone away leaving only the refer subscription 
within the dialog. An OPTIONS at that time would still conclude that the 
dialog existed even though the INVITE did not. This would typically not 
be a problem since the INVITE, REFER, and OPTIONS are typically all sent 
by the same entity, but that depends upon application design.
----------------- 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
05-15-08 09:08  ibc            Note Added: 0086900                          
======================================================================