[asterisk-bugs] [Asterisk 0009431]: Modify connection: Response 491 not handled according to RFC3261
noreply at bugs.digium.com
noreply at bugs.digium.com
Mon Nov 19 12:48:07 CST 2007
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=9431
======================================================================
Reported By: alex-911
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 9431
Category: Channels/chan_sip/Interoperability
Reproducibility: always
Severity: minor
Priority: normal
Status: acknowledged
Asterisk Version: 1.4.2
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Disclaimer on File?: No
Request Review:
======================================================================
Date Submitted: 03-30-2007 12:41 CDT
Last Modified: 11-19-2007 12:48 CST
======================================================================
Summary: Modify connection: Response 491 not handled
according to RFC3261
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
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
related to 0010481 SIP with canreinvite=yes through multip...
related to 0010868 1.4.11 Stable - Polycom phones hang up ...
======================================================================
----------------------------------------------------------------------
oej - 11-19-07 12:48
----------------------------------------------------------------------
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.
Issue History
Date Modified Username Field Change
======================================================================
11-19-07 12:48 oej Note Added: 0073987
======================================================================
More information about the asterisk-bugs
mailing list