Summary:	ASTERISK-09155: Modify connection: Response 491 not handled according to RFC3261
Reporter:	Alexander Tull (alex-911)	Labels:
Date Opened:	2007-03-30 12:41:31	Date Closed:	2011-06-07 14:08:14
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Interoperability
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) response-491-20070329.txt
Description:	when asterisk receives a reINVITE while a reINVITE from it's own is still in progress, it answers with a 491 which is basically correct. but in the RFC, there is a UAC behaviour described how a client should retry to modify a connection. what asterisk is doing here is already providing call release codes in the 491 and terminating the session with a BYE afterwards. according to the RFC a timer should be fired at each client (times depending who owns the call ID) and the modification should be retried. find the log attached for a session modification from G.711 to T.38
Comments:	By: Olle Johansson (oej) 2007-04-10 02:14:49 Yes, the 491 support is broken and needs to be fixed. This is a known issue. By: Olle Johansson (oej) 2007-05-09 09:05:18 Hmm. Maybe we could set a channel variable and let the dialplan handle the next call setup and the wait time... By: Raj Jain (rjain) 2007-10-11 14:47:56 Regarding the previous comment made about using the dialplan to initiate the next call setup, I think that is probably not the right solution for this problem. The issue here is RE-INVITE glare. RE-INVITEs happen mid-session so the call is already up from the dialplan perspective. I'd imagine this will have to handled within chan_sip itself and in fact a 491 occurrence should be transparent to the dialplan. Also, as a rule of the SIP protocol a RE-INVITE can fail but that doesn't effect the original call. By the way, this is a duplicate of 10481. Either 10481 or this bug report should be closed as duplicate. http://bugs.digium.com/view.php?id=10481 By: Olle Johansson (oej) 2007-11-15 06:05:44.000-0600 Please try with latest code. Thanks. By: Olle Johansson (oej) 2007-11-19 12:48:06.000-0600 Since this is T.38, it's another ball game and that's we have the hangup. If it wasn't T.38, Asterisk would have given up on the re-invite and continued the call as before without a BYE. By: Olle Johansson (oej) 2007-11-19 12:50:39.000-0600 The call release codes - as you call them - is just a status report that shouldn't be there. It's not an indication of a hangup. By: Olle Johansson (oej) 2007-11-19 12:54:26.000-0600 Ok, the 491 part is a feature request, not a bug report really. We have no support of 491 today. That we can't handle a failure in T.38 call setup and go back to G.711 is reported in open bug reports. File is working on that issue. I feel ready to close this bug report.