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:31Date Closed:2011-06-07 14:08:14
Versions:Frequency of
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.


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.