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

Asterisk Bug Tracker noreply at bugs.digium.com
Thu Mar 10 15:19:29 CST 2011


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-10 15:19 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
====================================================================== 

---------------------------------------------------------------------- 
 (0132826) saghul (reporter) - 2011-03-10 15:19
 https://issues.asterisk.org/view.php?id=15270#c132826 
---------------------------------------------------------------------- 
Hi,

Please, don't close this, the issue persists as of r310240. I uploaded a
file with a SIP trace from the Asterisk CLI:
asterisk_r310240_sip_reinvite_488_bye.txt. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-03-10 15:19 saghul         Note Added: 0132826                          
======================================================================




More information about the asterisk-bugs mailing list