| 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-0600 | Date Closed: | 2014-10-10 02:30:20 | ||
| Priority: | Major | Regression? | No | ||
| Status: | Closed/Complete | Components: | Channels/chan_sip/General | ||
| Versions: | SVN | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | Debian squeeze x86_64 | Attachments: | ( 0) patch_asterisk_20784.txt | ||
| Description: | {noformat}
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 {noformat} 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: {noformat} cseq 103 --reINVITE--> <----100----- <----491----- -----ACK----> (asterisk reschedules the reinvite) peer-cseq 4 <----BYE----- -----200----> cseq 104 --reINVITE--> <----100----- (the 481 is lost) {noformat} 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 https://reviewboard.asterisk.org/r/4052/ and created a test case for it. https://reviewboard.asterisk.org/r/4051/ | ||||