<html>
<head>
<base href="https://wiki.asterisk.org/wiki">
<link rel="stylesheet" href="/wiki/s/en/2176/25/9/_/styles/combined.css?spaceKey=AST&forWysiwyg=true" type="text/css">
</head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
<h2><a href="https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Bridging+Project">Asterisk 12 Bridging Project</a></h2>
<h4>Page <b>edited</b> by <a href="https://wiki.asterisk.org/wiki/display/~mjordan">Matt Jordan</a>
</h4>
<br/>
<h4>Changes (65)</h4>
<div id="page-diffs">
<table class="diff" cellpadding="0" cellspacing="0">
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" > <br>{code:title=A comment from ast_do_masquerade} <br></td></tr>
<tr><td class="diff-unchanged" >/* XXX This operation is a bit odd. We're essentially putting the guts of <br></td></tr>
<tr><td class="diff-unchanged" > * the clone channel into the original channel. Start by killing off the <br> * original channel's backend. While the features are nice, which is the <br></td></tr>
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" >Not all channels get an execution thread ({{pbx_thread}}) in Asterisk. In general, an inbound channel get's a thread; outbound channels do not. As a result, a two-party bridge that is created between the two channels uses the inbound channel's {{pbx_thread}} to service frames between the two channels. Regardless of the two-party bridge type in play, this is how it works in Asterisk. <br> <br></td></tr>
<tr><td class="diff-changed-lines" >This made sense when most bridges were two-party bridges. They probably still are, but it's very common now to have scenarios that require a lot more than a two-party bridge. Say, for example, we want to blind transfer the outbound channel to a new dialplan extension. The outbound channel has no {{pbx_thread}} <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">-</span> <span class="diff-added-words"style="background-color: #dfd;">\-</span> so how can we get him there? <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-changed-lines" ><span class="diff-changed-words">Simple<span class="diff-added-chars"style="background-color: #dfd;">\</span>!</span> We use a Masquerade. The Masquerade creates a new channel (with a {{pbx_thread}}) and swaps the guts of the outbound channel with the new channel. The new channel (with the guts of the outbound channel) starts to execute, and the old outbound channel dies. <br></td></tr>
<tr><td class="diff-unchanged" > <br>You can see what happened next: everything started to use Masquerades to get around the fact that there were channels without threads. Transfers, Asynchronous Gotos, Parking, Local channel optimization... lots of things ended up needing to use Masquerades to work around the threading model. <br></td></tr>
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" >h1. Requirements and Specification <br> <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">The purpose of this section is to provide the minimum requirements the project must fulfill. This can take several forms depending on the project; project developers should choose the schemes that best fit the project they are developing. This section should also provide details about the project from an end-user perspective. This can include dialplan configuration, sample configuration files, API descriptions, etc. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">Functionally, Bridging should remain as much the same as possible when compared with previous versions. When this is not possible, the difference should be documented. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">If needed, break this section up into multiple subsections. Several subsection examples are provided below; feel free to use/remove these as your project dictates. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">The following will require specifications for Asterisk 12: <br>* CDRs <br>* CEL <br>* Queue Log <br>* AMI (see [AST:AMI 1.4 Specification]) <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">{info} <br>If sufficiently complex, subpages should be used to provide reference information. In particular, sufficiently large configuration schemas and detailed API descriptions may benefit from their own subpage. <br>{info} <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">For Use Cases, see [Bridging Use Cases|AST:Asterisk 12 Bridging Use Cases]. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h2. Use Cases <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">h2. APIs <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">Assuming a use case approach is used, the following can be used as a model. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">For the specific Bridging Framework API, see @@@@. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h3. Use Case: Bob calls Alice <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">h1. Design <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">Actor: Alice <br>Actor: Bob <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">For sufficiently complex projects, a high level design may be needed to illustrate how the project plugs into the overall Asterisk architecture. Sufficiently detailed design of the project should be provided such that newcomers to the Asterisk project are provided a conceptual view of the construction of the implementation. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">Scenario: <br>* Bob picks up his phone. He dials Alice's extension. <br>* Bob hears a ringing indication. <br>* Alice's phone rings. <br>* Alice picks up her phone. <br>* Both Bob and Alice's phones stop ringing. <br>* Both Bob and Alice can talk to each other and hear the other person. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">Note that the design should be independent of the implementation, i.e., if the code is not drastically changed, it should not require updates to this section. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h2. User Stories <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">h1. Test Plan <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">Assuming a user story approach is used, the following can be used as a model. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">Bridging has wide-ranging affects on a call. While each bridging test will have some aspect of bridging as its fundamental focus, each will also have common elements that are checked as well, independent of the primary purpose of the test. For example, even if the focus of the test is a feature such as Auto-Monitor, fundamental attributes such as CDRs should be checked for correctness as well. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">* As a user of a SIP phone, I want to be able to pick up my SIP phone, dial an extension, and hear a ringing indication while I wait for the other phone to be picked up. <br>* As a user of a SIP phone, I want to be able to speak with another user using a SIP phone if they answer when I call them. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">Tests need to be crafted not only to test the nominal path for features. For instance, it is not enough to write a transfer test wherein all parties behave as expected. There should be tests where a transfer is made to a non-existent extension, or a test where a transfer is started but an extension is not typed in within the appropriate time limit. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h2. Configuration <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">See [Asterisk 12 Bridging Test Plan|AST:Asterisk 12 Bridging Test Plan] for mappings between the Asterisk tests and the defined Use Cases. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h3. project.conf <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">h2. Features Not to Test <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h4. \[general\] <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">There are some features and applications in Asterisk that, upon first glance, appear to be in the realm of a bridging test plan. Upon further inspection, however, they do not belong in the test plan. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">|| Parameter || Description || Type || Default Value || <br>| foo | Turns feature foo on or off | Boolean | True | <br>| bar | A comma delineated list of bar items (pun intended?) | String | | <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">h3. Bridge Manager Action/Application <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h3. RealTime schemas <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">These only represent different ways of erecting bridges between parties. They don't actually affect the operations and machinations of the bridge that gets created. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h2. APIs <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">h3. Call Pickup <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">Add an entry for each Application, Function, AMI command, AMI event, AGI command, CLI command, or other external way of interacting with the features provided by the project. Different APIs require different sets of documentation; in general, sufficient documentation should be provided to create the standard XML documentation for that particular item. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">Call pickup occurs entirely before a bridge is formed, therefore it does not belong in a suite of bridge tests. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h1. Design <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">{note:title=Note} <br>This may actually change, if channels are placed into a new bridge technology that performs early media playback ("Early Bridge"). This would be advantageous as the channel picking up the call would simply join the bridge with the channel in early media, and the bridge technology would swap from the Early Bridge technology to a compatible Two-Party bridge technology. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">For sufficiently complex projects, a high level design may be needed to illustrate how the project plugs into the overall Asterisk architecture. Sufficiently detailed design of the project should be provided such that newcomers to the Asterisk project are provided a conceptual view of the construction of the implementation. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">If that occurs, this test plan will be updated. <br>{note} <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">Note that the design should be independent of the implementation, i.e., if the code is not drastically changed, it should not require updates to this section. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">h3. Invoking bridges from multiple applications <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h1. Test Plan <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">Since we're concerned with the operation of the actual bridge, it does not matter how the bridge gets invoked. Whether app_dial, app_queue, or app_followme is used to create the bridge, it makes no difference in the way the bridge ends up operating. This also means the various forms of call origination don't need to be tested, either. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">Project should include automated testing, using either the Asterisk Unit Test Framework or the Asterisk Test Suite. Automated testing not only helps collaborators and reviewers verify functionality, but also helps to future proof new functionality against breaking changes in the future. A test plan maps Use Cases, User Stories, or specific APIs to tests that exercise that functionality. Test plans should be broken up by specific pieces of functionality, and should enumerate the tests for each function. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">h2. Common elements to check during tests <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">Each test description should provide, at a minimum, the name of the test, the test level (Unit, Integration, or System), and a description of what the test covers. For System level tests (which implies manual testing), a detailed description should be provided such that the test is reproducible by any third party. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">During all bridging tests, the bridge should be checked to make sure that media frames are being passed properly. The easiest way to do this is to pass DTMF between the two parties and ensure that they are received properly on the opposite side. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h2. Tests for Use Case: Bob calls Alice <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">The table below lists the items that should be checked in each test. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">|| Test || Level || Description || <br>| sip_basic_call | Integration | Test a basic call scenario between two SIP UAs and Asterisk | <br>| sip_uri_parse_nominal | Unit | Nominal parsing of SIP URIs | <br>| sip_uri_parse_off_nominal | Unit | Tests that ensure that off nominal SIP URIs are handled properly | <br>| sip_invite_request_test_nominal | Unit | Test INVITE request handling | <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">|| Item || Rationale || <br>| CDRs | The content of these will vary from test to test, but for common two-party bridges, these should be remarkably similar | <br>| CELs | Same applies for these as for CDRs | <br>| CallerID | Check that the Caller ID for each channel involved in the bridge is what it is expected to be | <br>| Connected Line | Check that connected line for each channel involved is what is expected | <br>| Common Channel variables | BRIDGEPEER, BRIDGEPVTCALLID should be set appropriately | <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h1. Project Planning <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">The following manager events should be checked while the test is running: <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">Provide links to the appropriate JIRA issues tracking work related to the project using the \{jiraissues\} macro (for more information on its usage, see [JIRA Issues Macro|https://confluence.atlassian.com/display/DOC/JIRA+Issues+Macro]). The sample below uses a public Triage filter - you will need to set up a JIRA issue filter for the macro to pull issues from that is shared with the *Public* group. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">* [Bridge|AST:Asterisk 11 ManagerEvent_Bridge] <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">h1. Project Planning <br> <br></td></tr>
<tr><td class="diff-unchanged" >h2. JIRA Issues <br> <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">{info} <br>The configuration of Jira/Confluence still needs a few tweaks to show the issues in the macro below. --Matt <br>{info} <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">{jiraissues:url=https://issues.asterisk.org/jira/sr/jira.issueviews:searchrequest-xml/11639/SearchRequest-11822.xml?tempMax=1000|anonymous=true} <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">{jiraissues:url=https://issues.asterisk.org/jira/sr/jira.issueviews:searchrequest-xml/11639/SearchRequest-11822.xml?tempMax=1000|anonymous=true} <br> <br></td></tr>
<tr><td class="diff-unchanged" >h2. Contributors <br> <br>|| Name || E-mail Address || <br>| [Matt Jordan|~mjordan] | mjordan@digium.com | <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">| [Richard Mudgett|~rmudgett] | rmudgett@digium.com | <br>| [Jonathan Rose|~jrose] | jrose@digium.com | <br></td></tr>
<tr><td class="diff-unchanged" > <br>h1. Reference Information <br> <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">Include links to code reviews, asterisk-dev mailing list discussions, and any other related information. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">h2. Test Reviews <br> <br>|| Review || Link || <br>| Bridging Test Suite Object | https://reviewboard.asterisk.org/r/2065/ | <br>| Timed Features Tests | https://reviewboard.asterisk.org/r/2247/ | <br>| Connected Line Tests | https://reviewboard.asterisk.org/r/2249/ | <br>| Auto-monitor, -mix-monitor, blind transfer detection; CDR/CEL integration Tests | https://reviewboard.asterisk.org/r/2067/ | <br>| Auto-monitor, -mix-monitor basic Tests | https://reviewboard.asterisk.org/r/2250/ | <br>| Call Parking (basic) Tests | https://reviewboard.asterisk.org/r/2273/ | <br>| Call Parking Timeout (comebacktoorigin=yes) Tests | https://reviewboard.asterisk.org/r/2306/ | <br>| Call Parking Timeout (comebacktoorigin=no) Tests | https://reviewboard.asterisk.org/r/2301/ | <br>| Transfer Capability Tests | https://reviewboard.asterisk.org/r/2268/ | <br></td></tr>
</table>
</div> <h4>Full Content</h4>
<div class="notificationGreySide">
<div class='panelMacro'><table class='noteMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>This page is still under construction.</td></tr></table></div>
<div>
<ul>
<li><a href='#Asterisk12BridgingProject-ProjectOverview'>Project Overview</a></li>
<ul>
<li><a href='#Asterisk12BridgingProject-WhatisaMasquerade'>What is a Masquerade</a></li>
<li><a href='#Asterisk12BridgingProject-WhyBridgingUsesMasqueradesandwhatWecandoaboutit'>Why Bridging Uses Masquerades and what We can do about it</a></li>
<li><a href='#Asterisk12BridgingProject-TheFutureofMasqueradesisGrim'>The Future of Masquerades is Grim</a></li>
</ul>
<li><a href='#Asterisk12BridgingProject-RequirementsandSpecification'>Requirements and Specification</a></li>
<ul>
<li><a href='#Asterisk12BridgingProject-APIs'>APIs</a></li>
</ul>
<li><a href='#Asterisk12BridgingProject-Design'>Design</a></li>
<li><a href='#Asterisk12BridgingProject-TestPlan'>Test Plan</a></li>
<ul>
<li><a href='#Asterisk12BridgingProject-FeaturesNottoTest'>Features Not to Test</a></li>
<ul>
<li><a href='#Asterisk12BridgingProject-BridgeManagerAction%2FApplication'>Bridge Manager Action/Application</a></li>
<li><a href='#Asterisk12BridgingProject-CallPickup'>Call Pickup</a></li>
<li><a href='#Asterisk12BridgingProject-Invokingbridgesfrommultipleapplications'>Invoking bridges from multiple applications</a></li>
</ul>
<li><a href='#Asterisk12BridgingProject-Commonelementstocheckduringtests'>Common elements to check during tests</a></li>
</ul>
<li><a href='#Asterisk12BridgingProject-ProjectPlanning'>Project Planning</a></li>
<ul>
<li><a href='#Asterisk12BridgingProject-JIRAIssues'>JIRA Issues</a></li>
<li><a href='#Asterisk12BridgingProject-Contributors'>Contributors</a></li>
</ul>
<li><a href='#Asterisk12BridgingProject-ReferenceInformation'>Reference Information</a></li>
<ul>
<li><a href='#Asterisk12BridgingProject-TestReviews'>Test Reviews</a></li>
</ul>
</ul></div>
<h1><a name="Asterisk12BridgingProject-ProjectOverview"></a>Project Overview</h1>
<p>At <a href="/wiki/display/AST/AstriDevCon+2012" title="AstriDevCon 2012">AstriDevCon 2012</a>, one of the focus points of development was determined to be the <a href="/wiki/display/AST/Asterisk+12+API+Improvements" title="Asterisk 12 API Improvements">Asterisk APIs</a>. In particular, some common complaints were:</p>
<ul>
<li>Asterisk changes the name of a channel during masquerades. As the name is used as the handle to the channel, this requires a lot of state replication by consumers of the APIs.</li>
<li>Asterisk's APIs tend to expose internal implementation details (such as masquerades), when consumers of the APIs would rather not be aware of these details.</li>
</ul>
<p>Both of these topics often come back to the same problem: masquerades. But why are masquerades such a problem?</p>
<h2><a name="Asterisk12BridgingProject-WhatisaMasquerade"></a>What is a Masquerade</h2>
<p>A channel masquerade is a fundamental yet incredibly confusing concept in Asterisk. It exists as a way for a thread to 'take' control of a channel that happens to be on another thread. This is a critically important operation when you need to, say, move a channel from the VoiceMail application and have it start executing logic at a different place in the dialplan.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeHeader panelHeader" style="border-bottom-width: 1px;"><b>A comment from ast_do_masquerade</b></div><div class="codeContent panelContent">
<pre class="theme: Confluence; brush: java; gutter: false">/* XXX This operation is a bit odd. We're essentially putting the guts of
* the clone channel into the original channel. Start by killing off the
* original channel's backend. While the features are nice, which is the
* reason we're keeping it, it's still awesomely weird. XXX */</pre>
</div></div>
<p>The way the operation works is to take two channels and 'swap' portions of them. In the diagram below, assume that Thread A has a channel that Thread B wants to take over. Thread B creates a new channel ("Original") and starts a Masquerade operation on the channel owned by Thread A ("Clone"). Both channels are locked, and the state of the Clone channel is moved into the Original channel, while the Clone channel obtains the Original channel's state. In order to denote that the channel is about to die, a special ZOMBIE flag is put on the channel and the name renamed to Clone<ZOMBIE>. The lock is released, and the Original channel - which now has the state associated with Clone channel - executes in Thread B, while the Clone channel (which is now quite dead) see's that its dead and goes off to silently contemplate its demise in an <tt>h</tt> extension.</p>
<table width="100%">
<tr>
<td align="left" >
<table>
<caption align="bottom">
</caption>
<tr>
<td>
<img style="border: none; width: 852px;"
usemap="#gliffy-map-22478880-9832"
src="/wiki/download/attachments/22088024/Asterisk_12_Masquerades.png?version=3&modificationDate=1360596453981"
alt=""/>
</td>
</tr>
</table>
</td>
</tr>
</table>
<p>Except, of course, that this is a dramatic simplification. It's never quite that easy.</p>
<ul>
<li>What is a channel's state? For the purposes of the operation, we consider it to be the channel's datastores, technology, and other pertinent data - but there's plenty of data that shouldn't be transferred over. That includes things like locking primitives on the channel, file descriptors, and other resources that Thread A is probably using (and depending on). Other information - such as CDR related information - sometimes can be moved, and sometimes shouldn't.</li>
<li>The locking picture is complicated. Thread B has no idea what Thread A is doing with the channel when it tries to get the channel lock for the Clone channel. If Thread B is holding a lock and tries to get Clone's channel lock, and Thread A is holding Clone's channel lock and needs a lock held by Thread B, a deadlock occurs.</li>
<li>Lots of things care a lot when the name of a channel is swapped out from underneath the actual channel pointer. Channel technologies care a lot, and so there are masquerade callbacks that go into the channel technologies and notify them when a masquerade occurs. This creates another locking point, complicating the locking picture further (and causing more deadlocks).</li>
</ul>
<p>So, Masquerades are bad. But why are they used everywhere?</p>
<h2><a name="Asterisk12BridgingProject-WhyBridgingUsesMasqueradesandwhatWecandoaboutit"></a>Why Bridging Uses Masquerades and what We can do about it</h2>
<div class='panelMacro'><table class='tipMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/check.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td><b>Channel Farm</b><br />"All channels are created equal, but some channels are created more equal than others."</td></tr></table></div>
<p>Not all channels get an execution thread (<tt>pbx_thread</tt>) in Asterisk. In general, an inbound channel get's a thread; outbound channels do not. As a result, a two-party bridge that is created between the two channels uses the inbound channel's <tt>pbx_thread</tt> to service frames between the two channels. Regardless of the two-party bridge type in play, this is how it works in Asterisk.</p>
<p>This made sense when most bridges were two-party bridges. They probably still are, but it's very common now to have scenarios that require a lot more than a two-party bridge. Say, for example, we want to blind transfer the outbound channel to a new dialplan extension. The outbound channel has no <tt>pbx_thread</tt> - so how can we get him there?</p>
<p>Simple! We use a Masquerade. The Masquerade creates a new channel (with a <tt>pbx_thread</tt>) and swaps the guts of the outbound channel with the new channel. The new channel (with the guts of the outbound channel) starts to execute, and the old outbound channel dies.</p>
<p>You can see what happened next: everything started to use Masquerades to get around the fact that there were channels without threads. Transfers, Asynchronous Gotos, Parking, Local channel optimization... lots of things ended up needing to use Masquerades to work around the threading model.</p>
<p>Then, along came <a href="/wiki/display/AST/ConfBridge+10" title="ConfBridge 10">ConfBridge</a>.</p>
<div class='panelMacro'><table class='noteMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td><b>We All Do</b><br />Ignore MeetMe.</td></tr></table></div>
<p>ConfBridge used a brand spiffy "new" (as in Asterisk 1.6 timeframe) Bridging API developed by Joshua Colp. A bridge becomes a first class object, and no longer a state that two channels happen to find themselves in. Channels owned by a bridge object are each given a thread. Even more interesting, the Bridging API provided an abstraction above how the media of the channels in the bridge was mixed. ConfBridge, for example, used the softmix bridging technology, suitable for multiple channels in a bridge. However, there are other bridging technologies - some optimized for managing two channels (or sets of two channels). Others - such as bridging technologies developed for special purpose applications - are possible. The Bridging API itself provides safe mechanisms to move channels between bridges, merge bridges, and generally do things without the need for masquerades.</p>
<p>As a side effect, the view from the outside world of what Asterisk is doing to channels in a bridge becomes sane.</p>
<h2><a name="Asterisk12BridgingProject-TheFutureofMasqueradesisGrim"></a>The Future of Masquerades is Grim</h2>
<p>Unfortunately, there is still one reason to use a Masquerade: when you have to steal it out of an application. This occurs in situations where an attended transfer is performed and the party starting the attended transfer does not transfer the other party into a bridge but rather into an application. So they aren't going to go away completely.</p>
<p>But, a wholesale migration to the Bridging API let's us:</p>
<ul>
<li>Do away with Masquerades in lots of situations</li>
<li>Optimize the hell out of two party bridging</li>
<li>Switch between two and multi-party bridging seamlessly</li>
<li>Present a sane model of the bridging world to the APIs</li>
</ul>
<div class='panelMacro'><table class='tipMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/check.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td><b>A word of advice</b><br />If you're familiar with the bridging code in <tt>features.c</tt>, you probably have a good idea of how big a task this work is. When you do away with the bridging loop, lots of things break, and they aren't all obvious. CDRs break. CEL breaks. Queue Logs probably break. AMI is wonky. DTMF handling has to be tweaked significantly. Lots change.
<p>This is scary, but it's time.</p></td></tr></table></div>
<h1><a name="Asterisk12BridgingProject-RequirementsandSpecification"></a>Requirements and Specification</h1>
<p>Functionally, Bridging should remain as much the same as possible when compared with previous versions. When this is not possible, the difference should be documented.</p>
<p>The following will require specifications for Asterisk 12:</p>
<ul>
<li>CDRs</li>
<li>CEL</li>
<li>Queue Log</li>
<li>AMI (see <a href="/wiki/display/AST/AMI+1.4+Specification" title="AMI 1.4 Specification">AMI 1.4 Specification</a>)</li>
</ul>
<p>For Use Cases, see <a href="/wiki/display/AST/Asterisk+12+Bridging+Use+Cases" title="Asterisk 12 Bridging Use Cases">Bridging Use Cases</a>.</p>
<h2><a name="Asterisk12BridgingProject-APIs"></a>APIs</h2>
<p>For the specific Bridging Framework API, see @@@@.</p>
<h1><a name="Asterisk12BridgingProject-Design"></a>Design</h1>
<p>For sufficiently complex projects, a high level design may be needed to illustrate how the project plugs into the overall Asterisk architecture. Sufficiently detailed design of the project should be provided such that newcomers to the Asterisk project are provided a conceptual view of the construction of the implementation.</p>
<p>Note that the design should be independent of the implementation, i.e., if the code is not drastically changed, it should not require updates to this section.</p>
<h1><a name="Asterisk12BridgingProject-TestPlan"></a>Test Plan</h1>
<p>Bridging has wide-ranging affects on a call. While each bridging test will have some aspect of bridging as its fundamental focus, each will also have common elements that are checked as well, independent of the primary purpose of the test. For example, even if the focus of the test is a feature such as Auto-Monitor, fundamental attributes such as CDRs should be checked for correctness as well.</p>
<p>Tests need to be crafted not only to test the nominal path for features. For instance, it is not enough to write a transfer test wherein all parties behave as expected. There should be tests where a transfer is made to a non-existent extension, or a test where a transfer is started but an extension is not typed in within the appropriate time limit.</p>
<p>See <a href="/wiki/display/AST/Asterisk+12+Bridging+Test+Plan" title="Asterisk 12 Bridging Test Plan">Asterisk 12 Bridging Test Plan</a> for mappings between the Asterisk tests and the defined Use Cases.</p>
<h2><a name="Asterisk12BridgingProject-FeaturesNottoTest"></a>Features Not to Test</h2>
<p>There are some features and applications in Asterisk that, upon first glance, appear to be in the realm of a bridging test plan. Upon further inspection, however, they do not belong in the test plan.</p>
<h3><a name="Asterisk12BridgingProject-BridgeManagerAction%2FApplication"></a>Bridge Manager Action/Application</h3>
<p>These only represent different ways of erecting bridges between parties. They don't actually affect the operations and machinations of the bridge that gets created.</p>
<h3><a name="Asterisk12BridgingProject-CallPickup"></a>Call Pickup</h3>
<p>Call pickup occurs entirely before a bridge is formed, therefore it does not belong in a suite of bridge tests.</p>
<div class='panelMacro'><table class='noteMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td><b>Note</b><br />This may actually change, if channels are placed into a new bridge technology that performs early media playback ("Early Bridge"). This would be advantageous as the channel picking up the call would simply join the bridge with the channel in early media, and the bridge technology would swap from the Early Bridge technology to a compatible Two-Party bridge technology.
<p>If that occurs, this test plan will be updated.</p></td></tr></table></div>
<h3><a name="Asterisk12BridgingProject-Invokingbridgesfrommultipleapplications"></a>Invoking bridges from multiple applications</h3>
<p>Since we're concerned with the operation of the actual bridge, it does not matter how the bridge gets invoked. Whether app_dial, app_queue, or app_followme is used to create the bridge, it makes no difference in the way the bridge ends up operating. This also means the various forms of call origination don't need to be tested, either.</p>
<h2><a name="Asterisk12BridgingProject-Commonelementstocheckduringtests"></a>Common elements to check during tests</h2>
<p>During all bridging tests, the bridge should be checked to make sure that media frames are being passed properly. The easiest way to do this is to pass DTMF between the two parties and ensure that they are received properly on the opposite side.</p>
<p>The table below lists the items that should be checked in each test.</p>
<div class='table-wrap'>
<table class='confluenceTable'><tbody>
<tr>
<th class='confluenceTh'> Item </th>
<th class='confluenceTh'> Rationale </th>
</tr>
<tr>
<td class='confluenceTd'> CDRs </td>
<td class='confluenceTd'> The content of these will vary from test to test, but for common two-party bridges, these should be remarkably similar </td>
</tr>
<tr>
<td class='confluenceTd'> CELs </td>
<td class='confluenceTd'> Same applies for these as for CDRs </td>
</tr>
<tr>
<td class='confluenceTd'> CallerID </td>
<td class='confluenceTd'> Check that the Caller ID for each channel involved in the bridge is what it is expected to be </td>
</tr>
<tr>
<td class='confluenceTd'> Connected Line </td>
<td class='confluenceTd'> Check that connected line for each channel involved is what is expected </td>
</tr>
<tr>
<td class='confluenceTd'> Common Channel variables </td>
<td class='confluenceTd'> BRIDGEPEER, BRIDGEPVTCALLID should be set appropriately </td>
</tr>
</tbody></table>
</div>
<p>The following manager events should be checked while the test is running:</p>
<ul>
<li><a href="/wiki/display/AST/Asterisk+11+ManagerEvent_Bridge" title="Asterisk 11 ManagerEvent_Bridge">Bridge</a></li>
</ul>
<h1><a name="Asterisk12BridgingProject-ProjectPlanning"></a>Project Planning</h1>
<h2><a name="Asterisk12BridgingProject-JIRAIssues"></a>JIRA Issues</h2>
<p>
<table cellspacing="0" class="grid" style="width: 100%">
<tr>
<th colspan="11" style="text-align: left; ">
<a rel="nofollow" href="https://issues.asterisk.org/jira/secure/IssueNavigator.jspa?requestId=11822&tempMax=1000">JIRA Issues</a> (10 issues) </th>
</tr>
<tr>
<th style="text-align: left; text-transform: capitalize;">Type</th>
<th style="text-align: left; text-transform: capitalize;">Key</th>
<th style="text-align: left; text-transform: capitalize;">Summary</th>
<th style="text-align: left; text-transform: capitalize;">Assignee</th>
<th style="text-align: left; text-transform: capitalize;">Reporter</th>
<th style="text-align: left; text-transform: capitalize;">Priority</th>
<th style="text-align: left; text-transform: capitalize;">Status</th>
<th style="text-align: left; text-transform: capitalize;">Resolution</th>
<th style="text-align: left; text-transform: capitalize;">Created</th>
<th style="text-align: left; text-transform: capitalize;">Updated</th>
<th style="text-align: left; text-transform: capitalize;">Due</th>
</tr>
<tr class="rowNormal">
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21061"><img src="https://issues.asterisk.org/jira/images/icons/bug.gif" alt="Bug" border="0" /></a>
</td>
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21061">ASTERISK-21061</a>
</td>
<td >
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21061">Nortel I2004 unwanted autoanswer</a>
</td>
<td nowrap="true">
Unassigned
</td>
<td nowrap="true">
MihaiMircea
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/priority_major.gif" alt="Major" border="0" />
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/status_document.gif" alt="" border="0" /> Triage
</td>
<td nowrap="true">
<font color="990000">Unresolved</font>
</td>
<td nowrap="true">
Feb 09, 2013
</td>
<td nowrap="true">
Feb 11, 2013
</td>
<td nowrap="true">
</td>
</tr>
<tr class="rowAlternate">
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21047"><img src="https://issues.asterisk.org/jira/images/icons/bug.gif" alt="Bug" border="0" /></a>
</td>
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21047">ASTERISK-21047</a>
</td>
<td >
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21047">asterisk crashes during an attended transfer</a>
</td>
<td nowrap="true">
Unassigned
</td>
<td nowrap="true">
piero ferraresso
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/priority_critical.gif" alt="Critical" border="0" />
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/status_document.gif" alt="" border="0" /> Triage
</td>
<td nowrap="true">
<font color="990000">Unresolved</font>
</td>
<td nowrap="true">
Feb 07, 2013
</td>
<td nowrap="true">
Feb 08, 2013
</td>
<td nowrap="true">
</td>
</tr>
<tr class="rowNormal">
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21046"><img src="https://issues.asterisk.org/jira/images/icons/bug.gif" alt="Bug" border="0" /></a>
</td>
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21046">ASTERISK-21046</a>
</td>
<td >
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21046">res_xmpp refcount issue</a>
</td>
<td nowrap="true">
Unassigned
</td>
<td nowrap="true">
marcelloceschia
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/priority_critical.gif" alt="Critical" border="0" />
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/status_document.gif" alt="" border="0" /> Triage
</td>
<td nowrap="true">
<font color="990000">Unresolved</font>
</td>
<td nowrap="true">
Feb 07, 2013
</td>
<td nowrap="true">
Feb 07, 2013
</td>
<td nowrap="true">
</td>
</tr>
<tr class="rowAlternate">
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21045"><img src="https://issues.asterisk.org/jira/images/icons/bug.gif" alt="Bug" border="0" /></a>
</td>
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21045">ASTERISK-21045</a>
</td>
<td >
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21045">Session refresh reinvites an in progress T.38 dialog back to G.711</a>
</td>
<td nowrap="true">
Unassigned
</td>
<td nowrap="true">
Trevor Peirce
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/priority_minor.gif" alt="Minor" border="0" />
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/status_document.gif" alt="" border="0" /> Triage
</td>
<td nowrap="true">
<font color="990000">Unresolved</font>
</td>
<td nowrap="true">
Feb 06, 2013
</td>
<td nowrap="true">
Feb 06, 2013
</td>
<td nowrap="true">
</td>
</tr>
<tr class="rowNormal">
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21042"><img src="https://issues.asterisk.org/jira/images/icons/bug.gif" alt="Bug" border="0" /></a>
</td>
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21042">ASTERISK-21042</a>
</td>
<td >
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21042">pbx_spool: callfile variables overriding/lost in __ast_request_and_dial()</a>
</td>
<td nowrap="true">
Unassigned
</td>
<td nowrap="true">
Roman S.
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/priority_trivial.gif" alt="Trivial" border="0" />
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/status_document.gif" alt="" border="0" /> Triage
</td>
<td nowrap="true">
<font color="990000">Unresolved</font>
</td>
<td nowrap="true">
Feb 06, 2013
</td>
<td nowrap="true">
Feb 06, 2013
</td>
<td nowrap="true">
</td>
</tr>
<tr class="rowAlternate">
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21041"><img src="https://issues.asterisk.org/jira/images/icons/bug.gif" alt="Bug" border="0" /></a>
</td>
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21041">ASTERISK-21041</a>
</td>
<td >
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21041">segfault at b ip 00007f4dd3a2abd0 sp 00007f4dacb58408 error 4 in libc-2.11.3.so[7f4dd39ab000+159000]</a>
</td>
<td nowrap="true">
Unassigned
</td>
<td nowrap="true">
Benjamin
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/priority_critical.gif" alt="Critical" border="0" />
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/status_document.gif" alt="" border="0" /> Triage
</td>
<td nowrap="true">
<font color="990000">Unresolved</font>
</td>
<td nowrap="true">
Feb 06, 2013
</td>
<td nowrap="true">
Feb 06, 2013
</td>
<td nowrap="true">
</td>
</tr>
<tr class="rowNormal">
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21040"><img src="https://issues.asterisk.org/jira/images/icons/bug.gif" alt="Bug" border="0" /></a>
</td>
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21040">ASTERISK-21040</a>
</td>
<td >
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21040">Deadlock</a>
</td>
<td nowrap="true">
Unassigned
</td>
<td nowrap="true">
Andrew Nowrot
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/priority_major.gif" alt="Major" border="0" />
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/status_document.gif" alt="" border="0" /> Triage
</td>
<td nowrap="true">
<font color="990000">Unresolved</font>
</td>
<td nowrap="true">
Feb 06, 2013
</td>
<td nowrap="true">
Feb 10, 2013
</td>
<td nowrap="true">
</td>
</tr>
<tr class="rowAlternate">
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21011"><img src="https://issues.asterisk.org/jira/images/icons/bug.gif" alt="Bug" border="0" /></a>
</td>
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21011">ASTERISK-21011</a>
</td>
<td >
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21011">Asterisk to Asterisk IAX2 trunk registration does not register</a>
</td>
<td nowrap="true">
David Brillert
</td>
<td nowrap="true">
David Brillert
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/priority_major.gif" alt="Major" border="0" />
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/status_document.gif" alt="" border="0" /> Triage
</td>
<td nowrap="true">
<font color="990000">Unresolved</font>
</td>
<td nowrap="true">
Jan 29, 2013
</td>
<td nowrap="true">
Feb 07, 2013
</td>
<td nowrap="true">
</td>
</tr>
<tr class="rowNormal">
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21009"><img src="https://issues.asterisk.org/jira/images/icons/bug.gif" alt="Bug" border="0" /></a>
</td>
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21009">ASTERISK-21009</a>
</td>
<td >
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21009">xmpp_pubsub_unsubscribe: Could not create IQ when creating pubsub unsubscription on client</a>
</td>
<td nowrap="true">
Rusty Newton
</td>
<td nowrap="true">
marcelloceschia
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/priority_major.gif" alt="Major" border="0" />
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/status_document.gif" alt="" border="0" /> Triage
</td>
<td nowrap="true">
<font color="990000">Unresolved</font>
</td>
<td nowrap="true">
Jan 29, 2013
</td>
<td nowrap="true">
Feb 07, 2013
</td>
<td nowrap="true">
</td>
</tr>
<tr class="rowAlternate">
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-20748"><img src="https://issues.asterisk.org/jira/images/icons/bug.gif" alt="Bug" border="0" /></a>
</td>
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-20748">ASTERISK-20748</a>
</td>
<td >
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-20748">Asterisk system didn't accept some dtmf digits when It called by a external PBX phone</a>
</td>
<td nowrap="true">
Ankit Mittal
</td>
<td nowrap="true">
Ankit Mittal
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/priority_major.gif" alt="Major" border="0" />
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/status_document.gif" alt="" border="0" /> Triage
</td>
<td nowrap="true">
<font color="990000">Unresolved</font>
</td>
<td nowrap="true">
Nov 28, 2012
</td>
<td nowrap="true">
Feb 06, 2013
</td>
<td nowrap="true">
</td>
</tr>
</table>
</p>
<h2><a name="Asterisk12BridgingProject-Contributors"></a>Contributors</h2>
<div class='table-wrap'>
<table class='confluenceTable'><tbody>
<tr>
<th class='confluenceTh'> Name </th>
<th class='confluenceTh'> E-mail Address </th>
</tr>
<tr>
<td class='confluenceTd'> <a href="/wiki/display/~mjordan" class="confluence-userlink" data-username="mjordan" >Matt Jordan</a> </td>
<td class='confluenceTd'> mjordan@digium.com </td>
</tr>
<tr>
<td class='confluenceTd'> <a href="/wiki/display/~rmudgett" class="confluence-userlink" data-username="rmudgett" >Richard Mudgett</a> </td>
<td class='confluenceTd'> rmudgett@digium.com </td>
</tr>
<tr>
<td class='confluenceTd'> <a href="/wiki/display/~jrose" class="confluence-userlink" data-username="jrose" >Jonathan Rose</a> </td>
<td class='confluenceTd'> jrose@digium.com </td>
</tr>
</tbody></table>
</div>
<h1><a name="Asterisk12BridgingProject-ReferenceInformation"></a>Reference Information</h1>
<h2><a name="Asterisk12BridgingProject-TestReviews"></a>Test Reviews</h2>
<div class='table-wrap'>
<table class='confluenceTable'><tbody>
<tr>
<th class='confluenceTh'> Review </th>
<th class='confluenceTh'> Link </th>
</tr>
<tr>
<td class='confluenceTd'> Bridging Test Suite Object </td>
<td class='confluenceTd'> <a href="https://reviewboard.asterisk.org/r/2065/" class="external-link" rel="nofollow">https://reviewboard.asterisk.org/r/2065/</a> </td>
</tr>
<tr>
<td class='confluenceTd'> Timed Features Tests </td>
<td class='confluenceTd'> <a href="https://reviewboard.asterisk.org/r/2247/" class="external-link" rel="nofollow">https://reviewboard.asterisk.org/r/2247/</a> </td>
</tr>
<tr>
<td class='confluenceTd'> Connected Line Tests </td>
<td class='confluenceTd'> <a href="https://reviewboard.asterisk.org/r/2249/" class="external-link" rel="nofollow">https://reviewboard.asterisk.org/r/2249/</a> </td>
</tr>
<tr>
<td class='confluenceTd'> Auto-monitor, -mix-monitor, blind transfer detection; CDR/CEL integration Tests </td>
<td class='confluenceTd'> <a href="https://reviewboard.asterisk.org/r/2067/" class="external-link" rel="nofollow">https://reviewboard.asterisk.org/r/2067/</a> </td>
</tr>
<tr>
<td class='confluenceTd'> Auto-monitor, -mix-monitor basic Tests </td>
<td class='confluenceTd'> <a href="https://reviewboard.asterisk.org/r/2250/" class="external-link" rel="nofollow">https://reviewboard.asterisk.org/r/2250/</a> </td>
</tr>
<tr>
<td class='confluenceTd'> Call Parking (basic) Tests </td>
<td class='confluenceTd'> <a href="https://reviewboard.asterisk.org/r/2273/" class="external-link" rel="nofollow">https://reviewboard.asterisk.org/r/2273/</a> </td>
</tr>
<tr>
<td class='confluenceTd'> Call Parking Timeout (comebacktoorigin=yes) Tests </td>
<td class='confluenceTd'> <a href="https://reviewboard.asterisk.org/r/2306/" class="external-link" rel="nofollow">https://reviewboard.asterisk.org/r/2306/</a> </td>
</tr>
<tr>
<td class='confluenceTd'> Call Parking Timeout (comebacktoorigin=no) Tests </td>
<td class='confluenceTd'> <a href="https://reviewboard.asterisk.org/r/2301/" class="external-link" rel="nofollow">https://reviewboard.asterisk.org/r/2301/</a> </td>
</tr>
<tr>
<td class='confluenceTd'> Transfer Capability Tests </td>
<td class='confluenceTd'> <a href="https://reviewboard.asterisk.org/r/2268/" class="external-link" rel="nofollow">https://reviewboard.asterisk.org/r/2268/</a> </td>
</tr>
</tbody></table>
</div>
</div>
<div id="commentsSection" class="wiki-content pageSection">
<div style="float: right;" class="grey">
<a href="https://wiki.asterisk.org/wiki/users/removespacenotification.action?spaceKey=AST">Stop watching space</a>
<span style="padding: 0px 5px;">|</span>
<a href="https://wiki.asterisk.org/wiki/users/editmyemailsettings.action">Change email notification preferences</a>
</div>
<a href="https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Bridging+Project">View Online</a>
|
<a href="https://wiki.asterisk.org/wiki/pages/diffpagesbyversion.action?pageId=22088024&revisedVersion=13&originalVersion=12">View Changes</a>
|
<a href="https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Bridging+Project?showComments=true&showCommentArea=true#addcomment">Add Comment</a>
</div>
</div>
</div>
</div>
</div>
</body>
</html>