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

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
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:                     acknowledged
Asterisk Version:           SVN 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
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:              2011-03-08 10:36 CST
====================================================================== 
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
====================================================================== 

---------------------------------------------------------------------- 
 (0132724) atca_pres (reporter) - 2011-03-08 10:36
 https://issues.asterisk.org/view.php?id=15270#c132724 
---------------------------------------------------------------------- 
Hello Imadsen,

I just checked out the latest 1.4 trunk and the problem is solved. The
call stays up and all the endpoints are happy.

This issue can be closed. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-03-08 10:36 atca_pres      Note Added: 0132724                          
======================================================================