Summary:	ASTERISK-14265: [patch] Bad handling of 488 answer to re-invite
Reporter:	atca_pres (atca_pres)	Labels:
Date Opened:	2009-06-04 10:08:18	Date Closed:	2011-07-26 14:41:59
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) asterisk_r310240_sip_reinvite_488_bye.txt ( 1) BadReInviteHandling.pcap ( 2) chan_sip-reinvite_488_fix.patch ( 3) verbosedebug_SIP.txt ( 4) verbosedebug.txt
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 ****** ADDITIONAL INFORMATION ****** I attached a wireshark capture and full asterisk debug. This is somewhat related to 0008677
Comments:	By: Olle Johansson (oej) 2009-09-10 14:18:49 I know this has been handled before. You are correct in that we should be able to keep the session as before the re-invite. I don't know why Asterisk currently gives p instead of going back to the previous state, but I am sure that another developer who has been working with T.38 can answer. By: Leif Madsen (lmadsen) 2009-09-16 10:33:28 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! By: atca_pres (atca_pres) 2009-09-16 13:14:53 Hi all, I just did a 'svn up' and I tested with "SVN-branch-1.4-r218798" The problem has been reproduced and is not fixed in the latest revision. Thanks ! By: Leif Madsen (lmadsen) 2009-09-18 11:56:37 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! By: atca_pres (atca_pres) 2009-09-21 15:16:16 Hi I was sure I add sip debug enabled, sorry for that. Here is a new log with SIP debug. If you want my opinion, the bug seems to be around the code for the T.38 passthru. If a peer has T38 enabled and refuse a re-invite, it is hang up automatically. Thanks ! By: Michael Cramer (micc) 2009-09-22 03:15:49 I believe this could be what is happening to me, but it happens after some time on a regular call. I have udptl = yes, but I'm just making a normal itsp call to the pstn. I filed an issue, https://issues.asterisk.org/view.php?id=15922 By: Michael Cramer (micc) 2009-09-22 03:50:30 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. By: Leif Madsen (lmadsen) 2009-09-22 09:43:30 Should this be linked, or is this actually a duplicate of 15922? Or rather, just that this is a symptom of the larger issue at hand. Perhaps this issue can be closed and just tracked on 15922? By: atca_pres (atca_pres) 2009-09-22 12:27:39 This might be linked, but so far I have not seen the relation between the two issues so far. By: Michael Cramer (micc) 2009-09-22 13:27:43 There is more information on this one. I would close 15922 and track it here. The link is, that this reinvite problem is the same problem I am seeing that causes my calls to drop after about 20 minutes. They are the same bug. Why its happening on a regular call and after 20+ minutes could be another bug all together. But the reinvite and the 488 and BYE, thats what causes my calls to drop after a while. By: Richard Hamnett (riksta) 2009-09-25 14:03:54 I have been experiencing a hangup at exactly 900sec/15min but with just a SIP->SIP call. I have created a separate bug as I don't believe the issue to be related to FAX or T.38 I have attached a full pcap file for both legs of the call https://issues.asterisk.org/view.php?id=15966 By: Leif Madsen (lmadsen) 2011-02-18 14:29:58.000-0600 This issue is pretty old now. Is this still an issue? By: atca_pres (atca_pres) 2011-03-08 10:36:38.000-0600 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. By: saghul (saghul) 2011-03-10 15:19:28.000-0600 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. By: saghul (saghul) 2011-03-14 17:05:28 Just uploaded chan_sip-reinvite_488_fix.patch which fixes the issue for me. I hope there are no side effects. With the patch applied, the code for tearing down the session is only executed if the request is not a re-INVITE. PS: I signed the license agreement 10 seconds ago, I guess that's why it appears as 'pending'. By: Russell Bryant (russell) 2011-07-26 14:41:42.075-0500 Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks!