[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:              11-19-2007 16:11 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).
====================================================================== 

---------------------------------------------------------------------- 
 ibc - 11-19-07 16:11  
---------------------------------------------------------------------- 
So in fact if the OPTIONS is in-dialog it's not treated as an initial
request since the dialog parameters are matched. But *just* if the
"Contact" header is a valid extension for the UAC sending the OPTIONS.

IMHO this is not a solid behaviour, it seems a mix between what 11.2
section says and what devices monitorizing dialogs using OPTIONS do.

I tell again the case where A calls B but B is not able to call A.
In this case only A can send in-dialog OPTIONS to B (if B sends it it will
get a 404).
So, in order to get a 200 OK for an in-dialog OPTIONS it must occurs:
- The UAC sending the OPTIONS can call to the username in received
"Contact" header.
- The dialog parameters match an existing dialog.

Anyway, if definitively you consider this as the expected behaviour I just
can **wish** Asterisk to support in-dialog OPTIONS (matching parameters)
even if the caller can't call to he other. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-19-07 16:11  ibc            Note Added: 0074008                          
======================================================================