[prev in list] [next in list] [prev in thread] [next in thread]
List: asterisk-dev
Subject: Re: [asterisk-dev] [Code Review] 2619: Add stasis events for transfers
From: "svnbot" <reviewboard () asterisk ! org>
Date: 2013-06-28 18:56:56
Message-ID: 20130628185656.11110.77901 () hotblack ! digium ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2619/
-----------------------------------------------------------
(Updated June 28, 2013, 1:56 p.m.)
Status
------
This change has been marked as submitted.
Review request for Asterisk Developers.
Changes
-------
Committed in revision 393182
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/bridges/bridge_builtin_features.c 392727
/trunk/channels/chan_iax2.c 392727
/trunk/channels/chan_sip.c 392727
/trunk/channels/chan_skinny.c 392727
/trunk/include/asterisk/bridging.h 392727
/trunk/include/asterisk/stasis_bridging.h 392727
/trunk/main/bridging.c 392727
/trunk/main/manager.c 392727
/trunk/main/manager_bridging.c 392727
/trunk/main/stasis_bridging.c 392727
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
[Attachment #5 (text/html)]
<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/2619/">https://reviewboard.asterisk.org/r/2619/</a>
</td>
</tr>
</table>
<br />
<table bgcolor="#e0e0e0" width="100%" cellpadding="8" style="border: 1px gray \
solid;"> <tr>
<td>
<h1 style="margin-right: 0.2em; padding: 0; font-size: 10pt;">This change has been \
marked as submitted.</h1> </td>
</tr>
</table>
<br />
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" \
style="background-image: \
url('https://reviewboard.asterisk.org/static/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.</div>
<div>By Mark Michelson.</div>
<p style="color: grey;"><i>Updated June 28, 2013, 1:56 p.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Changes</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;">Committed in revision 393182</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-21337">ASTERISK-21337</a>
</div>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
Asterisk
</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;">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.</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;">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.</pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>/trunk/bridges/bridge_builtin_features.c <span style="color: \
grey">(392727)</span></li>
<li>/trunk/channels/chan_iax2.c <span style="color: grey">(392727)</span></li>
<li>/trunk/channels/chan_sip.c <span style="color: grey">(392727)</span></li>
<li>/trunk/channels/chan_skinny.c <span style="color: grey">(392727)</span></li>
<li>/trunk/include/asterisk/bridging.h <span style="color: \
grey">(392727)</span></li>
<li>/trunk/include/asterisk/stasis_bridging.h <span style="color: \
grey">(392727)</span></li>
<li>/trunk/main/bridging.c <span style="color: grey">(392727)</span></li>
<li>/trunk/main/manager.c <span style="color: grey">(392727)</span></li>
<li>/trunk/main/manager_bridging.c <span style="color: grey">(392727)</span></li>
<li>/trunk/main/stasis_bridging.c <span style="color: grey">(392727)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/2619/diff/" style="margin-left: \
3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic