On Thu, Dec 6, 2012 at 12:28 PM, David M. Lee <span dir="ltr">&lt;<a href="mailto:dlee@digium.com" target="_blank">dlee@digium.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div class="im"><div>Thanks! Good history about UniqueID. For those playing along at home, I&#39;m keeping my notes at <a href="https://wiki.asterisk.org/wiki/x/IwBRAQ" target="_blank">https://wiki.asterisk.org/wiki/x/IwBRAQ</a>.</div>
</div></div></blockquote><div> </div><div>For channel masquerades, probably the one I deal with the most is SIP attended transfers. I think it&#39;s also the most complicated case... These involve up to 4 channels.</div><div>
A calls B1.  B1 decides to do an attended transfer (but asterisk doesn&#39;t get clued in on this until later).</div><div><br></div><div>In a seemly unrelated call, B2 calls C.</div><div><br></div><div>C might be an actual channel that B2 is bridged to, or C might just be an application. Channel B2 might be bridged, might be waiting for voicemail, or might be waiting in a queue or might be in a MeetMe.</div>
<div><br></div><div>A REFER packet is sent (this is the point asterisk knows a transfer is even happening), and now A needs to take the place of B2. If C exists, A is bridged to C. In any event, A is masqueraded into B2, and may be taking over in the middle of the app. </div>
<div><br></div><div>In this case, A keeps B2&#39;s uniqueid. (So it doesn&#39;t just get a new uniqueid like it does for many other uses of masquerade, it actually takes over an old one from a previous valid call).</div><div>
<br></div><div>In this case, I would think Stasis would need to fire an event to say that A is now taking B2&#39;s place in whatever Stasis API that was being ran, and is joining it in progress, as opposed to starting from the beginning like normal.</div>
<div><br></div><div><br></div><div>For LinkID&#39;s, I thought the intent was to be able to tell that a series of channels were related. If A creates B who creates C who creates D, they all share the same LinkID. I think the idea is to figure out which channel has to pay the bill for all of this. Or to be able to query the CEL table and find all related events, even if they were for other channels with different uniqueids.</div>
<div><br></div><div>One thing that I think sucks about it you can&#39;t see the whole tree. You see that D was created by A instead of A-&gt;B-&gt;C-&gt;D. I&#39;m not sure how much this matters. (I&#39;ve been meaning to build some reporting based on CEL, and have thought about it a little but I haven&#39;t actually done it yet.)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>You also had a list of use cases from an earlier email:</div>
</div></blockquote><div><br></div><div>Two important things that I left out: TTS and ARS.</div><div><br></div><div>Related to playing sounds: SayDigit/SayTime/SayNumber/etc. Sure, the application doesn&#39;t need those if it can play arbitrary sounds, but that&#39;s non-trivial, especially if you need multi-lingual support.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div class="im"><div></div><div> * record a file - sure<br></div></div><div>
<div> * that will automatically be deleted when the call is over - automatic, no. But the application can explicitly delete the file when it wants</div></div></div></blockquote><div><br></div><div>More generic to that, what about &quot;run at hangup&quot;?  I guess that&#39;s not really needed as long as there&#39;s a good &quot;hangup&quot; event.</div>
<div><br></div><div>Since we&#39;re also talking about masquerades, one of the problems they cause is the &quot;h&quot; extension is run twice, once on the &lt;ZOMBIE&gt; and once for real. And it&#39;s not a simple as just not doing that, e.g. in the SIP attended transfer case, B2 was a real channel that probably should run hangup code.</div>
<div><br></div><div>--Tim</div></div></div>