[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:                     feedback
Asterisk Version:           SVN 
JIRA:                        
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-18 11:56 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
====================================================================== 

---------------------------------------------------------------------- 
 (0111007) lmadsen (administrator) - 2009-09-18 11:56
 https://issues.asterisk.org/view.php?id=15270#c111007 
---------------------------------------------------------------------- 
Thanks for testing!

Can you provide the SIP information per the bug guidelines at
http://www.asterisk.org/developers/bug-guidelines ?

We'll need the sip debug, sip history, console output (including
debugging), and any other information you feel may be related to
reproducing this issue.

Thanks! 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-09-18 11:56 lmadsen        Note Added: 0111007                          
======================================================================