[asterisk-bugs] [Asterisk 0015270]: Bad handling of 488 answer to re-invite

[Asterisk Bug Tracker]

The following issue requires your FEEDBACK. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15270 
====================================================================== 
Reported By:                atca_pres
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   15270
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 199022 
Request Review:              
====================================================================== 
Date Submitted:             2009-06-04 10:08 CDT
Last Modified:              2009-09-16 10:33 CDT
====================================================================== 
Summary:                    Bad handling of 488 answer to re-invite
Description: 
This is a minor bug that can be easily workaround (in my scenario), still I
thought I should report it.

Scenario :
A calls B
A sends a re-invite to *
* sends a re-invite to B
B answers 488 Not acceptable here
* ACK BYE B

In my scenario, the re-invite is for T.38 and B rejects it. The easy
workaround would be to put t38udptl=no, BUT here is what the RFC (3261)
says about re-invites :

If a UA receives a non-2xx final response to a re-INVITE, the session
   parameters MUST remain unchanged, as if no re-INVITE had been issued.

Sending a ACK-BYE hardly seems like "as if no re-invite had been issued".

Furthermore, the call between A and * is left hanging, no BYE, no answer
to the trying.

So I'm guessing we have 2 part to this bug :

1. ACK-BYE for a Re-invite instead of just passing the 488 to the other
peer (and change nothing to codecs)
2. If you hangup B,  you need to hangup A
====================================================================== 

---------------------------------------------------------------------- 
 (0110799) lmadsen (administrator) - 2009-09-16 10:33
 https://issues.asterisk.org/view.php?id=15270#c110799 
---------------------------------------------------------------------- 
This is an older revision that you've mentioned in the bug report. Does
this still happen in the latest from the branch? I know a lot of T.38 work
went on recently, and I'm pretty sure it was well beyond that 199xxx
revision that is mentioned in the bug report.

If it is fixed, then we can just close this issue out. Thanks! 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-09-16 10:33 lmadsen        Note Added: 0110799                          
2009-09-16 10:33 lmadsen        Status                   new => feedback     
======================================================================