[asterisk-bugs] [Asterisk 0013037]: Asterisk incorrectly requires an ACK of it's response to an OPTIONS request

[Asterisk Bug Tracker]

The following issue has been CLOSED 
====================================================================== 
http://bugs.digium.com/view.php?id=13037 
====================================================================== 
Reported By:                rnbrady
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   13037
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   tweak
Priority:                   normal
Status:                     closed
Asterisk Version:           1.4.18 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
Resolution:                 suspended
Fixed in Version:           
====================================================================== 
Date Submitted:             2008-07-09 10:17 CDT
Last Modified:              2008-09-11 17:33 CDT
====================================================================== 
Summary:                    Asterisk incorrectly requires an ACK of it's
response to an OPTIONS request
Description: 
An OPTIONS request from a peer to Asterisk generates a response. Because
this is a non-INVITE request, the peer is not required to ACK the response
from Asterisk.

However, if the peer does not ACK the response, Asterisk responds to
subsequent re-INVITES with a 491 Request Pending. This is probably because
of RFC3261 section 14.2:

   A UAS that receives an INVITE on a dialog while an INVITE it had sent
   on that dialog is in progress MUST return a 491 (Request Pending)
   response to the received INVITE.

Now an OPTIONS request is supposed to be treated just like an INVITE in
most respects. However, it is strictly speaking a non-INVITE request and
therefore does not require an ACK.

The result is that if a peer uses an OPTIONS request to test whether a
re-INVITE will succeed, when it actually does the re-INVITE, it fails with
a 491.
====================================================================== 

---------------------------------------------------------------------- 
 (0092365) Corydon76 (administrator) - 2008-09-11 17:33
 http://bugs.digium.com/view.php?id=13037#c92365 
---------------------------------------------------------------------- 
No response from reporter for 2 months. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-09-11 17:33 Corydon76      Note Added: 0092365                          
2008-09-11 17:33 Corydon76      Status                   feedback => closed  
2008-09-11 17:33 Corydon76      Resolution               open => suspended   
======================================================================