[asterisk-dev] Updated API wiki page

[Tim Ringenbach]

On Thu, Dec 6, 2012 at 12:28 PM, David M. Lee <dlee at digium.com> wrote:

> Thanks! Good history about UniqueID. For those playing along at home, I'm
> keeping my notes at https://wiki.asterisk.org/wiki/x/IwBRAQ.
>

For channel masquerades, probably the one I deal with the most is SIP
attended transfers. I think it's also the most complicated case... These
involve up to 4 channels.
A calls B1.  B1 decides to do an attended transfer (but asterisk doesn't
get clued in on this until later).

In a seemly unrelated call, B2 calls C.

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.

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.

In this case, A keeps B2's uniqueid. (So it doesn'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).

In this case, I would think Stasis would need to fire an event to say that
A is now taking B2'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.


For LinkID'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.

One thing that I think sucks about it you can't see the whole tree. You see
that D was created by A instead of A->B->C->D. I'm not sure how much this
matters. (I've been meaning to build some reporting based on CEL, and have
thought about it a little but I haven't actually done it yet.)


> You also had a list of use cases from an earlier email:
>

Two important things that I left out: TTS and ARS.

Related to playing sounds: SayDigit/SayTime/SayNumber/etc. Sure, the
application doesn't need those if it can play arbitrary sounds, but that's
non-trivial, especially if you need multi-lingual support.


>  * record a file - sure
>  * that will automatically be deleted when the call is over - automatic,
> no. But the application can explicitly delete the file when it wants
>

More generic to that, what about "run at hangup"?  I guess that's not
really needed as long as there's a good "hangup" event.

Since we're also talking about masquerades, one of the problems they cause
is the "h" extension is run twice, once on the <ZOMBIE> and once for real.
And it'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.

--Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20121206/cb25172e/attachment-0001.htm>