[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-22 03:50 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
====================================================================== 

---------------------------------------------------------------------- 
 (0111125) Micc (reporter) - 2009-09-22 03:50
 https://issues.asterisk.org/view.php?id=15270#c111125 
---------------------------------------------------------------------- 
Yup, this was my problem. So there seems to be a bug in there even if
canreinvite=no and there is no t38 going on at all. I changed udptl=yes to
udptl=no and now my calls aren't dropping. m15922 maybe should be linked to
this issue. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-09-22 03:50 Micc           Note Added: 0111125                          
======================================================================