<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://reviewboard.asterisk.org/r/1819/">https://reviewboard.asterisk.org/r/1819/</a>
</td>
</tr>
</table>
<br />
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.org/media/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Asterisk Developers, Mark Michelson and Matt Jordan.</div>
<div>By jrose.</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">The call setup for this bug was sort of elaborate, but roughly 50% of the time, it would create a situation where chanspy can latch onto a zombie channel which would keep the zombie alive forever and keep itself in a perpetual loop. The approach of this patch is to keep that from happening by preventing chanspy from attaching audiohooks to zombies.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">The test for this was against a configuration similar to the one described in the bug report.
I started by spying on a local channel...
<extensions.conf>
exten => 038,1,ChanSpy(Local/s@phones,qs)
...
That local channel was a member of a queue and when it picked up, it would dial a SIP peer.
<queues.conf>
[markq]
member => Local/s@phones/n
<extensions.conf>
[phones]
exten => s,1,Dial(SIP/gold)
and I had a sip peer dial into that queue.
<extensions.conf>
exten => 037,1,Queue(markq)
Between all of these, five channels were established:
1 - SIP channel spying on the "local channel"
1 - SIP channel dialing into the queue
1 - SIP channel being dialed by a local channel
and 2 local channels bot with the name s@phones,qs with the difference between them being ;1 and ;2 at the end.
At this point, the chanspy could bind to either channel, and it would screw up as described in the bug report if the spy went to ;2. What would happen is, channel 1 and 2 would hang up, but because they were both part of the same autochan group, if the chanspy was on 2, it would try to go and grab 1 before it could be destroyed. From there it would go into the spying loop and never come out.
This patch fixed that behavior, but displays the new warning that can be seen in the diff.
I'm going to go ahead and note that this is probably a silly way to use chanspy in the first place since that seems like something better suited for extenspy... but there is some potential for this patch to fix other bugs, so... eh, might be worth doing.</pre>
</td>
</tr>
</table>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-19493">ASTERISK-19493</a>
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>/branches/1.8/apps/app_chanspy.c <span style="color: grey">(358857)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/1819/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>