Summary:ASTERISK-20784: Failure to receive an ACK to a SIP Re-INVITE results in a SIP channel leak
Reporter:NITESH BANSAL (nbansal)Labels:
Date Opened:2012-12-12 03:50:38.000-0600Date Closed:2014-10-10 02:30:20
Versions:SVN Frequency of
duplicatesASTERISK-15879 [patch] Failure to receive an ACK to a SIP Re-INVITE results in a SIP channel leak
Environment:Debian squeeze x86_64Attachments:( 0) patch_asterisk_20784.txt
A INVITE> asterisk INVITE> B
A <200 OK asterisk <200 OK B
A -ACK-> asterisk --ACK--> B
asterisk <INVITE B
asterisk 200 OK> B
(ack lost)
A -BYE--> asterisk
A <200 OK asterisk
No bye is generated on the B leg and there is a hanging sip channel also.
This issue was detected as regression of the issue ASTERISK-15879
Comments:By: NITESH BANSAL (nbansal) 2012-12-12 03:57:06.630-0600

I have fixed the issue, attached is the patch file.
Patch detects the non-critical invite transaction times out, and clears the invite pending and checks for any pending messages.

By: Rusty Newton (rnewton) 2012-12-14 16:47:26.670-0600

You note this as a regression. What was the latest version or revision in which this was working, and do you know what other fix might have broken it and caused the regression?

By: Matt Jordan (mjordan) 2012-12-17 09:26:48.280-0600

That is the exact same issue and patch as the one on ASTERISK-15879. In the future, if you are able to reproduce an issue that was suspended, please simply ask a bug marshal to re-open an issue.

By: NITESH BANSAL (nbansal) 2013-01-08 05:23:58.099-0600

Hi Rusty,
Actually we are migrating from Asterisk 1.4 to Asterisk 11. We had the exact same issue on Asterisk 1.4 and it was fixed.
A lot has changed from 1.4 to 1.11, that is why i created a new issue instead of reopening an old one.

By: NITESH BANSAL (nbansal) 2013-03-11 05:14:45.300-0500

Hi Rusty,
Awaiting your feedback on this issue.

By: Michael L. Young (elguero) 2013-03-11 20:49:58.712-0500

Nitesh, so you are saying that the fix was applied to Asterisk?  I see that the issue this duplicates was suspended.

If it was never committed to the Asterisk code base, then this is not a regression.  It is a bug that was never fixed in Asterisk itself.

Please help clarify if this fix was ever applied to Asterisk and not just within your organization copy of Asterisk.  Thanks.

By: NITESH BANSAL (nbansal) 2013-03-12 04:56:10.606-0500

The issue was reported on 1.4 but was suspended because you guys had stopped looking at issues reported on Asterisk 1.4.
So the fix never became a part of Asterisk and the issue is still present in Asterisk 11.

By: Walter Doekes (wdoekes) 2014-08-12 09:09:47.915-0500

Looks like I ran into this right now.

In my case it always goes like this:

cseq 103
(asterisk reschedules the reinvite)

peer-cseq 4

cseq 104
(the 481 is lost)

Not entirely sure if it's the same, since in this case we fail to receive a final response to the invite, but it looks pretty related.

The refcount of the sip dialog object is 3. The open calls are 0.

By: Walter Doekes (wdoekes) 2014-10-09 02:25:01.883-0500

Thanks Nitesh.

As you may have noticed, chan_sip support for rare issues is not always the most prioritized.

I've put up your patch for review
and created a test case for it.