Summary: | ASTERISK-12349: Asterisk incorrectly requires an ACK of it's response to an OPTIONS request | ||
Reporter: | Richard Brady (rnbrady) | Labels: | |
Date Opened: | 2008-07-09 10:17:55 | Date Closed: | 2011-06-07 14:07:29 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Channels/chan_sip/General |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ||
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. | ||
Comments: | By: Richard Brady (rnbrady) 2008-07-09 10:25:56 Could an admin please remove the trace from this ticket. Thank you. By: Olle Johansson (oej) 2008-07-09 15:07:27 I don't see any need for an ACK for an OPTIONS in ASterisk. I need however to get a log from your asterisk to see where the problem really is. See the bug guidelines and upload a log file as an attachment. Thanks. By: Tilghman Lesher (tilghman) 2008-08-06 17:05:20 rnbrady: we need a response from you or this issue will be closed. By: Tilghman Lesher (tilghman) 2008-09-11 17:33:19 No response from reporter for 2 months. |