[asterisk-dev] [Code Review] 2619: Add stasis events for transfers

[opticron]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2619/#review8926
-----------------------------------------------------------



/trunk/include/asterisk/stasis_bridging.h
<https://reviewboard.asterisk.org/r/2619/#comment17552>

    This is very similar to the ast_bridge_blob structure in terms of functionality.



/trunk/include/asterisk/stasis_bridging.h
<https://reviewboard.asterisk.org/r/2619/#comment17553>

    s/blind/attended/



/trunk/include/asterisk/stasis_bridging.h
<https://reviewboard.asterisk.org/r/2619/#comment17554>

    Is this correct for this function definition?



/trunk/include/asterisk/stasis_bridging.h
<https://reviewboard.asterisk.org/r/2619/#comment17555>

    This needs to be corrected.



/trunk/include/asterisk/stasis_bridging.h
<https://reviewboard.asterisk.org/r/2619/#comment17556>

    Idem.



/trunk/include/asterisk/stasis_bridging.h
<https://reviewboard.asterisk.org/r/2619/#comment17557>

    Idem.



/trunk/include/asterisk/stasis_bridging.h
<https://reviewboard.asterisk.org/r/2619/#comment17558>

    Idem.



/trunk/main/manager_bridging.c
<https://reviewboard.asterisk.org/r/2619/#comment17559>

    Red blob.



/trunk/main/manager_bridging.c
<https://reviewboard.asterisk.org/r/2619/#comment17560>

    Idem.



/trunk/main/stasis_bridging.c
<https://reviewboard.asterisk.org/r/2619/#comment17561>

    These need to be full snapshots, not just the channel name and bridge ID.



/trunk/main/stasis_bridging.c
<https://reviewboard.asterisk.org/r/2619/#comment17562>

    Same for these.  Also note that we're now using prefixes instead of suffixes for snapshot groupings (enforced by the snapshot->AMI blob conversion function).



/trunk/main/stasis_bridging.c
<https://reviewboard.asterisk.org/r/2619/#comment17563>

    Idem.


- opticron


On June 13, 2013, 1:25 p.m., Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2619/
> -----------------------------------------------------------
> 
> (Updated June 13, 2013, 1:25 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-21337
>     https://issues.asterisk.org/jira/browse/ASTERISK-21337
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This adds two new stasis message types: BlindTransfer and AttendedTransfer.
> 
> The blind transfer message is pretty straightforward. It has a channel snapshot for the transferer channel, a bridge snapshot of the involved bridge, the result of the transfer, an indicator of whether the transfer was externally-initiated, and the context and extension to which the transfer occurred.
> 
> The attended transfer message is more complicated. It has two transferer channel snapshots (the transferer bridged to the transferee and the transferer bridged to the transfer target), two bridge snapshots (the two bridges the transferer channels were in), the result of the transfer, an indicator of whether the transfer was externally initiated, and then some variable data to show the ending state of the transfer, depending on how the transfer was performed. Possibilities for the variable data are:
> * A bridge ID of the surviving bridge of the attended transfer
> * An application name if the transfer resulted in a bridge or channel running a dialplan application
> * A pair of local channel snapshots and bridge IDs that illustrate a link between two bridges.
> 
> Tests have indicated that the stasis messages are being published correctly and the data in the messages is accurate. There are a couple of issues of note:
> 
> * Both external and internal blind transfers have stasis messages published; however only external attended transfers have stasis messages published. This is because internal attended transfers are about to receive a rewrite and I figure I'll put the stasis message publication in when I take on that task.
> * There is a consistency issue regarding when we publish the stasis messages. In the majority of cases, we publish the stasis message after the attended transfer operation has completed. We do this so that the event can have the result of the transfer, and so that, for the case of attended transfers, we know how the transfer was performed. In the case where a single party is transferred out of a bridge to an application, this is accomplished by queuing a bridge channel action. It is when this action is performed (by a separate thread) that the transfer is completed. In this situation, we face several issues:
>     1) Bridge channel action data cannot have any data that must be freed. This is because there is no guarantee that the frame will actually be read and acted upon.
>     2) I attempted to get around 1) by passing the name of a transferer channel as part of the frame data and then using ast_channel_get_by_name() to find the channel once the queued task was run. However, by the time this happened, the channel had already been hung up and removed from the system.
> 
> 
> Diffs
> -----
> 
>   /trunk/main/bridging.c 391698 
>   /trunk/include/asterisk/stasis_bridging.h 391698 
>   /trunk/include/asterisk/bridging.h 391698 
>   /trunk/channels/chan_skinny.c 391698 
>   /trunk/channels/chan_sip.c 391698 
>   /trunk/channels/chan_iax2.c 391698 
>   /trunk/bridges/bridge_builtin_features.c 391698 
>   /trunk/main/manager.c 391698 
>   /trunk/main/manager_bridging.c 391698 
>   /trunk/main/stasis_bridging.c 391698 
> 
> Diff: https://reviewboard.asterisk.org/r/2619/diff/
> 
> 
> Testing
> -------
> 
> I tested by creating a subscription for the transfer events and then printing the values of the data in the messages. I found blind transfers and the various types of attended transfers to have accurate data.
> 
> 
> Thanks,
> 
> Mark Michelson
> 
>

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