Summary:	ASTERISK-25104: Unnecessary Unlink event on reINVITE when using Monitor()
Reporter:	Luca Pradovera (lucapradovera)	Labels:
Date Opened:	2015-05-19 16:36:16	Date Closed:	2015-05-27 10:44:11
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Resources/res_ari
Versions:	11.7.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	Ubuntu package 11.7.0~dfsg-1ubuntu1 running on Ubuntu 12.04	Attachments:	( 0) ami_logs_ast13.txt ( 1) ami.txt ( 2) asterisk13_logs.txt ( 3) dialplan.txt ( 4) pcap.txt
Description:	When using a simple dialplan with Monitor() and the 'm' option, and a reINVITE (line 2970 in pcap.txt below) is issued for any reason, an unwanted Unlink event (line 361 in ami.txt as attached) is sent over AMI, thus breaking connected applications that rely on that kind of event. Its emission should avoided when recording for the same reason that masquerades are undesirable. The same event is not emitted if there is no Monitor() running.
Comments:	By: Ben Klang (bklang) 2015-05-19 16:40:53.212-0500 To add some context behind this issue: extra applications that rely on Bridge state events to determine whether a bridge is still active, will break when this event is raised. The upshot is that those applications may determine that the call is ready to end because the bridge has apparently ended (even though it hasn't, really).  In one particular case, this is causing Adhearsion applications to hang up after exactly 15 minutes, which is when the SIP provider is sending a re-INVITE with no session changes. By: Rusty Newton (rnewton) 2015-05-19 18:24:14.767-0500 Thanks for the report. [~lucapradovera] it is required that you attach your debug and config files directly to the issue. You may want to look over the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] before posting any further issues. Thanks! Use "Send Back" or "Enter Feedback" to send the issue back to us. By: Luca Pradovera (lucapradovera) 2015-05-20 08:25:56.952-0500 Attaching documentation of the bug as requested. By: Matt Jordan (mjordan) 2015-05-21 09:12:17.978-0500 Honestly: I'm not sure this is going to get much, if any, traction. Admittedly, the {{Bridge}} events with their "Link" and "Unlinks" are kind of ... dumb. I think we're all aware of that :-) This would be why we spent the past two years rearchitecting Asterisk and providing a sane view of the world in 12+. The {{BridgeEnter}} and {{BridgeLeave}} events are now consistent and predictable, and certainly aren't going to be affected by a re-INVITE. This is one of those bugs where we would be: # Addressing a hopelessly poorly architected event to address a single errant behaviour, when the entire fundamental design behind those events is flawed # Injecting additional risk into an LTS version which would affect those poor individuals who did build some application that required those events I'm not saying it isn't a bug... I'm just thinking we already fixed this in 12+, and the risk of doing anything with this event in 11 probably outweighs the pain you're experiencing. By: Ben Langfeld (benlangfeld) 2015-05-23 11:05:54.802-0500 Thanks for the feedback Matt. We did not necessarily expect this to be fixed in Asterisk 11, but Luca came across it while debugging an application and we considered it a case worth documenting, given that it took a little while to track down and that it is exposed only by the combination of recording a bridge and a re-INVITE on one of the channels. I'm glad to hear that you expect the work on 12+ to have done away with this stuff, and we appreciate the effort that was put in to those releases. Luca will shortly confirm that this specific case does not occur simply to robustly round out this issue and then we can close it as documentation of an interesting little adventure. Assuming that confirmation is positive, which I don't doubt, this will push our customer to upgrade to Asterisk 13 (yay) and ensure full compatibility between 12+ and Adhearsion 2.x. Thanks! By: Luca Pradovera (lucapradovera) 2015-05-26 08:04:20.156-0500 These logs taken from Asterisk 13 show the absence of a spurious Unjoin event on a reinvite. By: Ben Langfeld (benlangfeld) 2015-05-27 10:08:55.301-0500 Thanks Luca. Matt / Rusty, this issue can now be closed as documentation of the issue.