<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 (4)</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" >h1. Design <br> <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">h2. High Level Design <br> <br></td></tr>
<tr><td class="diff-unchanged" >Note that the diagram below is not meant to contain all functions and attributes for the objects shown, nor does it show all objects. It is meant to convey the relationships between principle objects in the Bridging Framework. <br> <br></td></tr>
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" >Detailed information about the Bridging Framework APIs can be seen in [Asterisk 12 Bridging API|AST:Asterisk 12 Bridging API]. <br> <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">h2. Richard's Ramblings on Bridging <br> <br>h3. The Existing API and Proposed Changes <br> <br>h4. enum ast_bridge_channel_state ast_bridge_join(struct ast_bridge *bridge, struct ast_channel *chan, struct ast_channel *swap, struct ast_bridge_features *features, struct, ast_bridge_tech_optimizations *tech_args, int pass_reference); <br> <br>* Put a channel into the specified bridge. The bridge takes custody of the channel. <br>** On success, the caller blocks until: <br>*** the channel hangs up <br>*** the channel is kicked out <br>*** the bridge dissolves <br>**** The caller must then run the PBX which runs the h exten, next dialplan location, or ast_async_goto() location. <br>* An error joining the bridge gives the channel back. <br>* The pass_reference flag passes the bridge reference of the caller back to the bridge so the bridge will complete destroying itself when the last channel leaves the bridge. The caller cannot use the bridge pointer when the function returns. <br> <br>h4. int ast_bridge_impart(struct ast_bridge *bridge, struct ast_channel *chan, struct ast_channel *swap, struct ast_bridge_features *features, int independent); <br> <br>* Put a channel into the specified bridge. The bridge takes custody of the channel. <br>* The caller does not block. <br>* An error joining the bridge gives the channel back. <br>* On success, the caller does not get the channel back. <br>* When the channel leaves the bridge the channel will: <br>** wait for another thread to claim it with ast_bridge_depart() if not specified as independent <br>** run a PBX at the set location if exited by AST_SOFTHANGUP_ASYNCGOTO (any exit location datastore is removed) <br>** run a PBX if a location is specified by datastore <br>** run the h exten if specifed by datastore then hangup <br>** hangup <br> <br>h4. int ast_bridge_depart(struct ast_channel *chan); <br>* This function must be removed from the API or severely restricted. <br> <br>API changed that when a channel is imparted, it must be specified that the channel will be departed. These channels can not be moved/merged to another bridge. Channels that can be departed are special channels because the channel must be departed and can not be made to normally execute dialplan when they leave a bridge. <br> <br>With the change that ast_channel has an ast_bridge_channel pointer instead of an ast_bridge pointer, ast_bridge_depart() does not need to be provided an ast_bridge pointer. Also these channels can move to other bridges and still be departed. <br> <br>Departing from the bridge must not interfere with an AST_BRIDGE_CHANNEL_STATE_END in progress since it is likely to dissolve the bridge. (Sorta fixed with AST_BRIDGE_CHANNEL_STATE_DEPART_END. Really need to revamp the depart mess.) <br> <br>h4. int ast_bridge_remove(struct ast_bridge *bridge, struct ast_channel *chan); <br>* Request that the channel be removed from the specified bridge. <br>* If the channel is not in a bridge then return error. <br> <br>Channels are removed when the bridge action kicks the channel out. It does not matter if the channel is currently suspended from the bridge. <br> <br>h4. int ast_bridge_move(struct ast_bridge *bridge, struct ast_channel *chan, struct ast_channel *swap, struct ast_bridge_features *features, struct ast_bridge_tech_optimizations *tech_args); <br>* Move a channel from its current bridge to the specified bridge. <br>* The channel knows which bridge it is in because ast_channel_internal_bridge() returns it. <br>* If the channel is not in a bridge then return error. <br>* If the channel is not moveable then return error. <br>* If the channel is already in the bridge then return error. <br>* If the bridge cannot accept the channel then return error. <br> <br>h4. int ast_bridge_merge(struct ast_bridge *bridge_dest, struct ast_bridge *bridge_src, struct ast_channel **exclude_chans, int num_chans); <br>* Merge bridge_src into bridge_dest and kick out the channels specified by exclude_chans from the bridges. The bridge_src is gutted and may destroy itself. <br>* bridge_dest can be given new properties. <br>* Channel properties/roles may need to change. <br>* Channel driver attended transfers can be accomplished by merging bridges. <br> <br>This is likely only going to be used for local channel optimization. Unfortunately this will as a result be executed by the thread handling the media which would be not good. When local channel is given the go ahead, the local channels need to be suspended and the merge performed by another thread. A good thread would be one of the local channel bridge channels if it doesn't have much to do in its action queue. (Now do it on the bridge thread.) <br> <br>Switching to-from-native to 1-1 bridges is going to need to be done on a bridge channel thread as well. (Now do it on the bridge thread.) <br> <br>Always have a bridge thread. It will control the bridge restructuring, bridge tech selection, bridge hooks, and bridge timer hooks. The bridge thread will also do the bridge media handling depending upon the bridge tech. The early, native, and simple tech will use the bridge thread for media. The multiplexed bridge tech will pass the media duties to a thread common to several bridge instances. The softmix bridge uses the bridge thread for mixing the media after each bridge_channel thread has read it from the channel. Always having a bridge thread means it does not get created/destroyed when the bridge tech is changed by the smart bridge code. <br> <br>The bridge_dest needs to pull the channels from bridge_src for a merge/move. This will avoid the bridge ao2 reference problem if the bridge_src pushes the channels to bridge_dest. <br> <br>h4. int ast_bridge_suspend(struct ast_bridge *bridge, struct ast_channel *chan); <br>h4. int ast_bridge_unsuspend(struct ast_bridge *bridge, struct ast_channel *chan); <br> <br>* Peers of suspended channels need to act like autoserviced channels and save important frames like DTMF and control frames. <br> <br>h5. int ast_is_deferrable_frame(const struct ast_frame *frame); <br> <br>Those frames get sent to the suspended channel and put in its action queue. The bridge needs to generate silence frames to the peer while DTMF is being collected or the chan is suspended. <br> <br>The suspend/unsuspend functions by a third party should be removed. The bridging code mostly assumes that suspends are from the bridge channel thread and not an external party. <br> <br>h4. int ast_bridge_count_channels(struct ast_bridge *bridge); <br> <br>Return number of channels in the bridge. <br> <br>h4. struct ast_channel *ast_bridge_peer(struct ast_bridge *bridge, struct ast_channel *chan); <br> <br>Return the bridge peer channel of the given channel. The peer channel is returned with an increased ref count. <br> <br>This function feels dangerous. <br> <br>h4. int ast_channel_is_bridged(struct ast_channel *chan); <br> <br>Return TRUE if the channel is currently bridged. <br> <br>h4. struct ast_bridge *ast_channel_get_bridge(struct ast_channel *chan); <br> <br>Get the bridge the channel is currently in. <br> <br>h4. int ast_bridge_play_to_chan(struct ast_bridge *bridge, struct ast_channel *chan, const char *file); <br> <br>Play a file to the specified channel in a bridge. <br> Return error if channel not in the specified bridge. <br> <br>h4. int ast_bridge_play_to_bridge(struct ast_bridge *bridge, const char *file); <br> <br>Play a file to the specified bridge. <br> <br>h4. int ast_bridge_transfer_blind(struct ast_channel *transferrer, const char *context, const char *exten, int priority); <br> <br>* The bridge peer of the transferrer channel is blind transferred. <br>* The bridge peer action runs ast_channel_transfer_blind() after UNHOLDing the channel. The target location is also checked for a Parking exten and a park is performed instead. <br> <br>h4. int ast_channel_transfer_blind(struct ast_channel *target, const char *transferrer_chan_name, const char *ctx_exten_pri); <br> <br>* The ctx_exten_pri is a parseable string: "[[context,]exten,]priority". The optional values are filled in by the target channel. transferrer_chan_name can be NULL if done anonymously. <br> <br>* Set BLINDTRANSFER on target channel with transferer channel name. I don't see why it has historically been put on both channels since the Park app is who needs the variable set so it can announce the parking slot. <br>* UNHOLD target. <br>* Post AMI blind transfer event. <br>* Do the ast_async_goto steps. <br> <br>h4. ast_async_goto() <br> <br>This function actually is a blind transfer! <br> <br>* if channel in a bridge <br>** if channel has a PBX <br>*** set PBX location on the channel + 1 because autoloop will decrement <br>** else <br>*** set PBX location on the channel <br>** set AST_SOFTHANGUP_ASYNCGOTO <br>* else if channel has a PBX <br>** set PBX location on the channel + 1 because autoloop will decrement <br>** set AST_SOFTHANGUP_ASYNCGOTO <br>* else <br>** create new channel <br>** set PBX location on the channel <br>** masquerade into it <br> <br>h4. int ast_bridge_transfer_attended(struct ast_channel *party_a, struct ast_channel *party_c); <br>* UNHOLD target party_a peer. <br>* Post AMI attended transfer event. <br>* If party_a and party_c are in bridges, ast_bridge_merge() party_c bridge into party_a bridge removing party_a and party_c channels from the bridges. <br>* If one of the channels is not bridged then we'll have to do it the old way with masquerades. <br>* If neither of the channels are in bridges then return error. <br> <br>Problems if party_c is in the parking bridge. How to get party_a to take party_c's place in that bridge? Need an {{ast_bridge_park(struct ast_bridge *parking_bridge, struct ast_bridge_channel *chan, struct ast_bridge_channel *swap);}} The original party_a bridge is then dissolved. <br> <br>Problem is worse for ConfBridge. You cannot swap a channel into that bridge because ConfBridge maintains a lot of state outside of the bridge module. You can only masquerade into the ConfBridge. <br> <br>To eliminate the masquerade here it is likely that every application needs to become a mini channel driver attaching to a mini bridge associated with every channel. A radical rethink would be necessary for PBX and bridges. <br> <br>{note} <br>We'd really like to do that, but won't have time. :-( <br>{note} <br> <br>h4. int ast_bridge_park(struct ast_bridge *parking_bridge, struct ast_bridge_channel *chan, struct ast_bridge_channel *swap); <br> <br>Moves chan into the parking bridge and replaces the swap channel already in the bridge at the same parking space. This is a specialized ast_bridge_move(). <br> <br>h3. Features and other thoughts <br> <br>h4. chan_agent ideas: <br> <br>* Agent logs in and waits for calls just like now. The agent could be placed into a holding bridge with some kind of monitoring for a caller. <br> <br>* Calls come in and get put into a waiting call list container. These calls can abort if chan_agent is not configured to allow multiple waiting calls or if the agent is not logged in. <br> <br>* Agent thread sees waiting call in the container and finds the early bridge the call is in. The agent can decide when to accept the call. The agent thread then does a Pickup of the incoming call by joining the early bridge. <br> <br>* Incoming calls that are hungup by the caller or are canceled because the agent joined the early bridge are just removed from the waiting container. <br> <br>* Agent channels that are blind transferred create a local channel to run dialplan at the specified location and joins the early bridge. <br> <br>h4. COLP ideas: <br> <br>* COLP updates happen as an optional result of bridge enter/leave and merge events. Local channel optimizations do not request COLP updates when the bridges merge. Transfer merges do request COLP updates. <br> <br>* Bridge join/impart new channel initiates a COLP update exchange if there are two peers or from the bridge COLP setting. <br> <br>* A peer leaving a bridge causes a COLP update if two peers remain in the bridge. <br> <br>* Multi-peer bridges should be given a COLP identity somehow that is user configurable. If none is given, then the bridge won't give any COLP updates when a new peer joins. The COLP could be assigned by an interception macro/gosub when the bridge goes multi-peer. <br> <br>* COLP role flag for exchange/bridge updates. <br> <br>h4. ConfBridge COLP ideas: <br> <br>* Marked users can give a bridge their COLP identity when they join. This could let peers know who is moderating the conference. <br> <br>* Multi-marked users could cause COLP updates when they talk. <br> <br>* The bridge profile used can give it a COLP identity and any COLP update <br>policy options. <br> <br>h4. Parking ideas: <br> <br>* Add parking lot configuration option to give the parking lot a COLP identity. <br> <br>h4. Add new CHANNEL() option: <br> <br>CHANNEL(after_bridge_goto)=<parseable-goto> <br> Sets an after bridge goto datastore property on the channel. <br>CHANNEL(after_bridge_goto)=<empty> <br> Deletes any after bridge goto datastore property on the channel. <br> <br>h4. BridgeWait() <br> <br>Potential new dialplan appliction that puts the channel into a holding bridge that the Bridge application or the Bridge AMI action can move to the real bridge. This will avoid the need for a masquerade when the Wait application is used. The Bridge applicaiton and Bridge AMI action will need to be modified to not use masquerades unconditionally if these channels can be moved from the current bridge they are in. <br> <br>h4. More Stuff <br> <br>The DTMF features could be a channel property datastore so they can be removed/restored to the channel depending upon which bridge they are in at the time. As a property they could be set by the CHANNEL() function. <br> <br>Two party bridges need to keep ast_channel_internal_bridged_channel_set() up to date with the peer. <br> <br>The default controlling channel for impromptu threeway bridges is the oldest channel controls the destruction of the bridge. A channel variable or CHANNEL(value) set by dialplan could be used to alter the bridge controller. <br> <br>It would be nice to implement DTMF attended transfer to be able to toggle back and forth between party A and C like DAHDI analog can do. <br>*1 - Abort transfer and go back to party A <br>*2 - Initiate transfer or just hang up to transfer. <br>*3 - Make threeway <br>*4 - Toggle between party A and C bridges like POTS can do with a flash hook. <br> <br>Bridge channel hooks can move the bridge channel between bridges. This would be needed to implement the toggle between A and C bridges feature. <br> <br>A way to implement the toggle between A and C parties is to have an atxfer bridge subclass. Setup the links this way: <br>{noformat} <br> A -- B1 --Local@special/b -- Batxfer1 -- B -- Batxfer2 -- Local@special/b -- B2 -- C <br>{noformat} <br> <br>The atxfer bridges grant B the transfer menu because it has the TransferrerRoll defined on the channel. When the transfer is completed, the TransferrerRoll is removed. <br> <br>The atxfer bridges have AST_BRIDGE_FLAG_MERGE_INHIBIT_TO set. They also have the inhibit merge count non-zero while the transfer is incomplete to prevent any local channel optimization. <br> <br>The only difference between a self managing bridge and an externally managed bridge is if there is something outside of the bridge referencing it. The bridge destructor posts the AMI bridge destroy event. <br> <br>Suspended channels can still be removed from a bridge. When they try to unsuspend, they find out if they are still part of the bridge or if it is still active. <br> <br>Non-native 1-1 bridges need to generate AST_CONTROL_SRCUPDATE frames. <br> <br>A channel that dissolves the bridge needs to update the peer channels hangup cause as it ejects them. <br> <br>Any channel that later tries to join a dissolved bridge will be immediately ejected with the cause code stored on the bridge. <br> <br>Event hooks are needed for the following type of events: <br> <br>* bridge timeouts(bridge duration, interval), <br>* channel timeouts(duration, interval) <br>** Since only the bridge is aware of time, channel timeouts are managed timeouts on the bridge. The enter/leave/merge code needs to update these channel timer hooks.] <br>* channel DTMF features, <br>* channel enter/leave, <br>* bridge empty, <br>* bridge merge, <br>* bridge tech changes, <br> <br>The bridge channel needs to keep track of the last HOLD/UNHOLD state and any DTMF digit in progress so they can be stopped when the channel is removed from the bridge. <br> <br>The bridge_channel action queue will fix many of the issues I have been having with bridge member updates. The bridge core code determines which bridge_channel to put actions on from a feature hook. For example: <br>* Blind transfer hook triggers <br>* Hook gathers destination digits <br>* Hook validates destination <br>* Hook asks bridge core to post blind transfer action onto peer channel. <br>* Bridge may refuse if the request cannot be put onto a peer channel because it no longer exists or there is more than one. <br>* If the bridge refuses then the blind transfer fails and the hook just returns to the bridge as if the user did not try blind transfer. The queued action also needs a destructor as part of the queued struct. <br> <br>The bridge also needs an action queue to do things like smart bridge, bridge merges, channel join, and channel leave. COLP update action. <br> <br>h4. Masquerades :-( <br> <br>Masquerades are used in two ways: <br># A third party has a channel that they want to take the place of an existing channel. Pickup, Local channel optimization, attended transfer with an application. Running an h exten on the zombie is a good thing. <br># Steal a channel from some other thread. Park, bridging, blind transfers of channels without a PBX. Running an h exten on this zombie does not do much because it was a sacrificial channel anyway. <br> <br>h4. Bridge Merging <br> <br>Bridges can be marked as non-mergable. (Should be a non-mergable count to handle temporary merge blocks.) <br> <br>Maybe this should be done automatically while a bridge channel executes a bridge hook. <br>* This will block local channel optimizations until ready for it. <br>* This will prevent ConfBridge bridges from absorbing foreign bridges. <br>* This will prevent Parking bridges from absorbing foreign bridges. <br> <br>h4. Bridge Event Hooks <br> <br>Event hooks need to be able to be registered/unregistered/destroyed. <br> <br>Need to add to API: calls to register/unregister/destroy event observer callbacks with private pointer data. <br>* Channel bridge enter/exit - notify. <br>* Bridge technology change to/from specific technology - notify. <br>* Bridge stop/destroy hooks - notify. <br>* Bridge merge hooks to direct how merges transform the resulting bridge. <br>** Pre-merge-veto - Multiple callbacks allowed. Any can veto merge. <br>** Pre-merge - Multiple callbacks allowed. <br>** Post-merge - Multiple callbacks allowed to inform of completed merge. <br>* Bridge merge hooks per channel <br>** Pre-merge-veto - Multiple callbacks allowed. Any can veto merge. <br>** Pre-merge - Multiple callbacks allowed. <br>** Post-merge - Multiple callbacks allowed to inform of completed merge. <br> <br>h4. Roles <br> <br>Need to add role concepts for channels in bridge. Channels can change roles using feature hooks. Rolls may be flags. <br>* Caller/Callee for early media bridge and COLP interception macros. <br>* Announcer - Plays messages/music to channels in the bridge. Not considered a peer. <br>* Recorder - Records bridge. Not considered a peer. <br>* Agent - Can hear Supervisor whisper. Considered a peer. Only ability other than default. <br>* Supervisor - Can whisper to Agent. Not considered a peer. <br>* Default - Regular participant in the bridge. Considered a peer. <br>* ConfBridge - Regular participant in the bridge. Not considered a peer. <br> <br>Roll flags: <br>* Caller - Only significant in early media bridge. The caller flag can also be used for COLP interception macros. Attended transfers would need to manipulate the caller role flag for proper roles. Party A is always the caller role and Party C is the callee role. <br>* Peer - Normal bridges exchange control frames when only two channels are marked as peers. Early media bridges (if they but existed) also look at the Caller flag for control frame exchanges. <br>* COLP-exchange - Channel can exchange COLP updates with peer. Exchanges COLP when there are less than three channels in the bridge marked as such. Otherwise, it behaves like the COLP-bridge role flag. <br>* COLP-bridge - Channel can recieve COLP updates from the bridge. ConfBridge users just have this flag set to only receive COLP updates from the bridge. <br> <br>Future role flags (softmix bridge): <br>* Whisper - Channel can only be heard by a channel marked Whisper-receiver <br>* Whisper-receiver <br>* Recorder - Channel receives the recording mix of recordable channels. <br>* NonRecordable - Channel is not heard by a recording channel. <br>* Announcer - Channel can only be heard by a channel marked Announcer-receiver <br>* Announcer-receiver <br> <br>Recorder/Announcer channels need an option flag to exit the bridge if there is noone else in the bridge. Otherwise there is the possibility that the bridge will become orphaned with just those special channels in the bridge. AST_BRIDGE_FLAG_LONELY <br> <br>h3. New Objects <br> <br>h4. Design patterns <br>* The state pattern could be applied to ast_bridge. <br>** ast_bridge could be thought of as a state of ast_bridge_channel. <br>** Changing states is moving to another bridge. This is a bit of a stretch though. <br> <br>ast_bridge_technology is the strategy pattern <br> <br>The decorator pattern could be applied to ast_bridge_channel to decorate the channel with feature hooks. Decorators can be added/removed at run time just like features. Though this pattern may be a bit expensive resource wise. <br> <br>The Basic, Parking, ConfBridge, atxfer, and Queue bridges could be thought of as a strategy instead of subclassing ast_bridge_channel. It is looks more like ast_bridge_technology in relation to ast_bridge/ast_bridge_channel. Changed this back to just subclassing ast_bridge. <br> <br>h4. Bridge Classes <br> <br>Bridge technologies are an embedded object of the abstract bridge class. <br> <br>Park, Queue, ConfBridge could be derivative classes of the abstract bridge class. <br> <br>{noformat} <br>class ast_bridge { <br> join(struct ast_channel *chan); <br> depart(struct ast_channel *chan); <br> remove(struct ast_channel *chan); <br> move_pull(class ast_bridge_channel *chan); <br> Pull a channel out of this bridge to be pushed into another bridge. <br> move_push(class ast_bridge_channel *chan, class ast_bridge_channel *swap); <br> Push a channel into this bridge that was pulled from another bridge. <br> masquerade_pull(class ast_bridge_channel *chan); <br> A masquerade is figuratively pulling this channel out of the bridge <br> to be pushed back in as a new channel. <br> This is done for the clone and original channels because a masquerade <br> swaps the guts of the two channels. <br> masquerade_push(class ast_bridge_channel *chan); <br> Push the channel back into the bridge as a new channel. <br> poke(); <br> new(); <br> The derived bridge classes need to have a default channel <br> configuration for when a channel is pushed into it. <br> Park needs to assign a parking space and timeout. <br> ConfBridge needs to have a default user profile. <br> The class also needs to remove special channel configuration <br> when it it pulled. <br> The class needs to have a channel inherit the configuration <br> of a swapped channel when it is pushed or joined. <br>}; <br>class ast_bridge_channel { <br> class ast_bridge *bridge; <br> suspend(); <br> Mark channel as suspended and poke the bridge to recognize it. <br> unsuspend(); <br> Mark channel as unsuspended and poke the bridge to recognize it. <br>}; <br>{noformat} <br> <br>h4. Locking precedence order: <br>{noformat} <br> bridges ao2_container <br> | <br> ast_bridge <br> | <br> channels ao2_container ast_bridge_channel <br> | _____________/ <br> ast_channel <br> / <br>channel private <br>{noformat} <br> <br>h4. New Bridge Techs <br> <br>h5. Early media bridge tech: <br>* Allowed channel roles: 0-1 Caller / 1-n Callees <br>* The bridge can start with this tech but cannot switch back to it. <br>* At most one Peer channel UP and at least one Peer channel not UP. <br>* Does not do audio mixing. <br>* First call to answer kicks out all other Peer non-Caller channels and answers the Caller channel if needed. <br>* The bridge tech needs to change to a normal bridge type. <br>* The bridge can have a timeout to connect. <br> <br>{note} <br>We are, unfortunately, punting on the Early Media Bridge Technology. Not because it isn't awesome or the right way to do it, but because app_dial and app_queue are a bitch to refactor. <br>{note} <br> <br>h5. Parking bridge tech: <br>* Adds ability to access bridge channels in it by parking space/slot. <br>* Parking bridges are found in a container by parking lot name. <br>* Parking lots can be configured with COLP information. <br>* The parking tech has extra methods to manage the parking lot: <br>** move_bridged_channel_to_parking, <br>** move_bridged_channel_from_parking, <br>** swap_bridged_channel_with_parked <br>* Actually these extra methods look like they should be part of the base bridge class. <br>* Timed out calls leave the parking lot by blind transfer. <br> <br>h4. DTMF Feature Transfers <br> <br>h5. DTMF Blind transfer: <br>* (Transfer will fail if the transferee channel is imparted to be departed.) <br>* Up non-merge count on host bridge. <br>* Get transfer destination. <br>* Validate it is in the dialplan. <br>* Check if it is a parking exten and park instead. <br>* Queue action to bridge peer to blind transfer. <br>** Supply transfering channel, exten@context <br>* Peer channel executes blind transfer action. ast_async_goto(). <br>** Channel leaves bridge and starts executing dialplan. <br>* Drop non-merge count on host bridge. <br> <br>h5. DTMF Attended transfer: <br>* If party A hangs up the original bridge should be set to dissolve and automatically kick out party B from the bridge. <br>* Up non-merge count on host bridge. <br>* Get transfer destination. <br>* Validate it is in the dialplan. <br>* Check if it is a parking exten and park instead. <br>* Create early media bridge. <br>** Bridge does not dissolve, <br>** Bridge times out, <br>** Bridge non-mergable(to prevent local channel optimization) <br>* Dial party C <br>* Pull party B bridge_channel out of the bridge <br>* Create an atxfer caretaker thread to see it through. Pass party B bridge_channel, party C, and early media bridge <br>** The early media bridge is not really viable here unless we want to allow it to be able to keep going with no caller. <br>** If party B hangs up before party C answers we need to save party B channel name, release party B channel, and wait the timeout for party C to answer <br>** If party C answers within the timeout then we can impart it into the original bridge to talk to party A. <br>** If party C does not answer within the timeout, we need to bounce back and forth call attempts to party B and party C. <br>* Impart party C into early media bridge, Party C dissolves bridge when it hangs up. <br>** If Party C is forwarded, the forwarded channel replaces the party C channel and takes Party C's properties. <br>* Join party B into early media bridge (or not :-() <br>* Party B leaves the bridge when <br>** early media bridge times out <br>** Party B cancels/aborts transfer <br>** Party B wishes threeway call <br>** Party B hangs up (early media bridge or normal bridge keeps going) <br>** Party C hangs up <br>* if party B hangs up <br>** if party C is up <br>*** Mark bridge channels as non-dissolving(Only party C should be in the bridge if still there) <br>*** move Party C bridge channel to original bridge <br>*** destroy temporary bridge <br>*** Drop non-merge count on host bridge. <br>*** party B returns to original bridge and leaves bridge <br>*** done <br>** wait for party C to answer or the timeout <br>* else if party B cancels/aborts transfer <br>** destroy temporary bridge <br>** Drop non-merge count on host bridge. <br>** party B returns to original bridge <br>** done <br>* else if party B wishes threeway call <br>** Mark bridge channels as non-dissolving(Only party C should be in the bridge if still there) <br>** mark party B on original bridge as dissolves bridge when it hangs up. <br>** mark original bridge as non-dissolving <br>** move Party C bridge channel to original bridge <br>** destroy temporary bridge <br>** Drop non-merge count on host bridge. <br>** party B returns to original bridge <br>** done <br>* if early media bridge times out <br>** If party C does not answer within the timeout, we need to bounce back and forth <br>** call attempts to party B and party C. <br> <br>h5. Parking (DTMF one-touch-park, DTMF blind transfer, DTMF attended transfer): <br>* Determine parking lot to put peer into. <br>* Create parking space channel for masquerade. <br>* Reserve space in the parking lot. <br>* Queue action to bridge peer to park <br>** Supply parking channel name, parking channel <br>* Peer channel executes park-me action <br>* Park-me action queues play slot number or failure message back to peer <br>* Park-me action masquerades bridge_channel to parking channel. <br>* Parking channel is put into the parking manager thread. <br> <br>h5. Pickup: <br>* Find appropriate ringing channel in early media bridge <br>* Join-swap ringing channel <br>* Need some race condition insurance that some other channel won't win <br>* while the pickup channel is coming into the bridge. Otherwise we would <br>* wind up with a three or more party bridge. <br> <br>{note} <br>This won't be how this works. It's still going to be a masquerade. <br>{note} <br> <br>h5. Local channel optimization: <br>* Needs more thought because we don't want to optimize in the middle of other operations. <br>* Local channel determines it is possible to masquerade. <br>* The non-merge count will block optimizations during inopportune times. <br>* Optimization is done by merging bridges and ejecting the merging local channels from the resulting merged bridge. <br> <br>h5. FollowMe: <br>* For followme need an event-hook/frame-hook to intercept the AST_CONTROL_ANSWER so it can handle the user query. Each outgoing channel needs to have its own timer so it can drop out if it isn't answered. The main followme thread also has a timer to dump the next round of calls into the early-media bridge. <br> <br>h5. Queue: <br>* Like parking, the call can be stuck in a holding bridge until: <br>## an agent gets the call <br>## caller hangs up <br>## caller presses DTMF to goto new location <br>* The holding bridge could periodically or when the number of calls ahead of the caller changes announce to the caller what position in the queue they are in. <br> <br>h3. APIs for Folks <br> <br>h4. CLI commands: <br> <br>{noformat} <br>bridge show all <br> List all current bridges by bridge-id and number of channels in the bridge. <br> <br>bridge show bridge-id <br> Dump information about the specified bridge. <br> bridge-id, bridge tech using, bridge tech could use, channels in bridge, <br> bridge type (normal, parking, queue, ConfBridge), other information <br> <br>bridge destroy all <br> Destroy all bridges in the system. <br> Maybe we should qualify this as destroy only transient bridges. Not <br> bridges that exist as long as the system is running or the module is loaded. <br> <br>bridge destroy bridge-id <br> Destroy the specified bridge. <br> <br>bridge kick <channel> <br> Kick a channel out of a bridge if it is in one. <br> <br> NOTE: Be careful because it does not destroy the bridge. If there is only <br> one channel left in the bridge, that channel may just sit there. <br> <br>bridge suspend <tech> <br> Suspend the bridge technology from use by bridges. <br> Bridges currently using the technology will continue to use it. <br> <br>bridge unsuspend <tech> <br> Unsuspend the bridge technology from use by bridges. <br>{noformat} <br> <br>Corresponding AMI actions should also be created. <br> <br></td></tr>
<tr><td class="diff-unchanged" >h1. Test Plan <br> <br></td></tr>
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" >{note} <br> <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">{note:title=Note #2} <br>Most likely, call pickup will not have an early bridge :-( <br>{note} <br> <br></td></tr>
<tr><td class="diff-unchanged" >h3. Invoking bridges from multiple applications <br> <br></td></tr>
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" >h1. Project Planning <br> <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">h2. High Level Bridging construction tasks: <br> <br>* *DONE* Change ast_bridge_call callers to not expect getting peer back. Part of this is to add an optional goto dialplan location datastore to set where the peer should go when it exits the bridge. The location datastore is removed if a channel exits with AST_SOFTHANGUP_ASYNCGOTO set or the channel is masqueraded. Part of this is to implement the self managing bridge functionality. <br> <br>* *DONE* Make all bridge technologies have a bridging thread to handle bridge restructuring tasks like smart bridge and bridge merges. When the bridge thread is not being used to restructure the <br>bridge, it can be dealing with the bridge media flows. Part of this is adding a bridge action queue like the bridge channel action queue. The softmix bridge may just create a bridge thread to handle the bridge restructuring chores and an auxiliary thread to do the mixing currently done by the bridge thread. Need to implement the non-merge count. <br> <br>* *DONE* Implement a v-method table to subclass struct ast_bridge. Parking, Queues, ConfBridge, and other holding bridges would then be able to subclass ast_bridge to allow merge/moves between bridges. <br> <br>* *DONE*(except for the role support in softmix. It won't be needed until much later if ever.): Add control frame support/processing. Part of this needs to add AST_CONTROL_SRCUPDATE generation on 1-1 bridging. Part of this needs to add the caller role flag for the initial role flags support. Mark normal channels with the peer role flag and respect it. Initially all channels not in a ConfBridge will be marked as a peer. <br> <br>* *DONE* Add bridge CLI commands. Part is to add bridge id support. How unique does the bridge id need to be? UUID, hostname/timestamp/sequence-no, timestamp/sequence-no, or just sequence-no AMI Transfer start/complete events. Implements the global bridges ao2 container. This container is needed for ConfBridge, Parking, BridgeWait, and Queue to find bridges by name. As a consequence of this, bridges must explicitly know when to die rather than counting on the ao2 reference count to drop to zero. <br> <br>* *DONE* Create the Basic bridge subclass. This bridge enables the DTMF features controlled by features.conf: One-touch-parking, Blind transfer, attended transfer, monitor-recording, mixmonitor-recording, dynamic features. The Basic bridge subclass pulls most of the code from ast_bridge_call into itself. <br> <br>* *DONE* Add bridge and bridge channel hooks for enter/leave/answer/merge/tech-change/empty events. An answer hook will not be usable until the early bridge is implemented. <br> <br>* *DONE* (save for complete) Add create/enter/leave/destroy bridge stasis/AMI events. The complete event is needed to indicate if the transfer was successful, aborted, or was turned into a threeway. <br> <br>* Get local channel optimization functional again. I would like to pull chan_local into the bridging module. There seem to be times where it could be useful to create a local channel structure and impart the channels into different bridges or put one end into a bridge and the other executes an application. Pulling chal_local into the bridge module could wait until I actually have a real need to do so. <br> <br>* Implement ast_bridge_transfer_blind() and ast_bridge_transfer_attended(). Attended transfer needs to update the caller role flags on peer channels. Attended transfer will need revisiting when parking is reworked. <br> <br>* Get the channel drivers to use the ast_bridge_transfer_blind() and ast_bridge_transfer_attended() calls. This can be a task for each channel driver: chan_dahdi, chan_sip, chan_misdn, etc... <br> <br>* Implement early bridging. I'm now thinking that the early media bridge will turn into just enhancing the dialing API because of the way Page works. Dial/Queue/FollowMe would need to be converted to use the dialing API. <br> <br>{note} <br>Punt. <br>{note} <br> <br>* Dial/Queue/FollowMe/Pickup updated to use early bridging. <br> <br>{note} <br>Punt. <br>{note} <br> <br>* Get DTMF transfer features on par with current functionality. DTMF attended transfer will need a manager thread to handle operations after Party B hangs up and before Party C answers. Bonus is that the new bridging API allows threeway conferences. Since features.conf is being gutted should we eliminate it in favor of new config files? <br> <br>* Implement parking bridge and get the system to use it. Park(), ParkedCall(), ParkAndAnnounce(), DTMF one touch park. <br> <br>* Implement DTMF one touch record. Monitor and MixMonitor support. <br> <br>* Get chan_agent working again since the chan->_bridge pointer is no more. Must be done after early bridging so the agent channel can Pickup the caller. <br> <br>* Lastly native bridging technology. <br> <br></td></tr>
<tr><td class="diff-unchanged" >h2. JIRA Issues <br> <br></td></tr>
<tr><td class="diff-snipped" >...<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 a living document; expect missing and incomplete information. Still, feel free to discuss on <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" class="external-link" rel="nofollow">asterisk-dev</a>.</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>
<li><a href='#Asterisk12BridgingProject-Design'>Design</a></li>
<ul>
<li><a href='#Asterisk12BridgingProject-HighLevelDesign'>High Level Design</a></li>
<li><a href='#Asterisk12BridgingProject-Richard%27sRamblingsonBridging'>Richard's Ramblings on Bridging</a></li>
<ul>
<li><a href='#Asterisk12BridgingProject-TheExistingAPIandProposedChanges'>The Existing API and Proposed Changes</a></li>
<li><a href='#Asterisk12BridgingProject-Featuresandotherthoughts'>Features and other thoughts</a></li>
<li><a href='#Asterisk12BridgingProject-NewObjects'>New Objects</a></li>
<li><a href='#Asterisk12BridgingProject-APIsforFolks'>APIs for Folks</a></li>
</ul>
</ul>
<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-HighLevelBridgingconstructiontasks%3A'>High Level Bridging construction tasks:</a></li>
<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-7135"
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>
<h1><a name="Asterisk12BridgingProject-Design"></a>Design</h1>
<h2><a name="Asterisk12BridgingProject-HighLevelDesign"></a>High Level Design</h2>
<p>Note that the diagram below is not meant to contain all functions and attributes for the objects shown, nor does it show all objects. It is meant to convey the relationships between principle objects in the Bridging Framework.</p>
<table width="100%">
<tr>
<td align="left" >
<table>
<caption align="bottom">
</caption>
<tr>
<td>
<img style="border: none; width: 1343px;"
usemap="#gliffy-map-22478886-7884"
src="/wiki/download/attachments/22088024/Bridge+API+Design.png?version=2&modificationDate=1362420595200"
alt=""/>
</td>
</tr>
</table>
</td>
</tr>
</table>
<h4><a name="Asterisk12BridgingProject-astbridgecontroller"></a>ast_bridge_controller</h4>
<p>The <tt>ast_bridge_controller</tt> manages one or more bridges. It provides the thread that services actions that are being taken within a bridge and operations between bridges.</p>
<h4><a name="Asterisk12BridgingProject-astbridge"></a>ast_bridge</h4>
<p>An <tt>ast_bridge</tt> object <b>is</b> the bridge. A bridge may have many channels in it, and the bridge object is responsible for keeping track of the state of the bridge and managing the channels. The <tt>ast_bridge_technology</tt> callbacks provide the way in which operations on the bridge and its channels are implemented for different ways of 'bridging'. For example, in a two-party bridge, the bridge technology may only have to pass frames between two channels and can simply swap the frames between two <tt>ast_bridge_channel</tt> objects. In a multi-party bridge, however, the bridge technology has to decide which <tt>ast_bridge_channel</tt> objects receive frames from what other <tt>ast_bridge_channel</tt> objects, how those frames are mixed, etc.</p>
<h4><a name="Asterisk12BridgingProject-astbridgechannel"></a>ast_bridge_channel</h4>
<p>The <tt>ast_bridge_channel</tt> object manages the thread, state, and actions executing on a channel in a bridge. There is a one to one relationship between the <tt>ast_bridge_channel</tt> object and an <tt>ast_channel</tt> object in a bridge. An <tt>ast_bridge</tt> manages channels through the <tt>ast_bridge_channel</tt> object.</p>
<h4><a name="Asterisk12BridgingProject-astbridgetechnology"></a>ast_bridge_technology</h4>
<p>The <tt>ast_bridge_technology</tt> provides the callbacks that specific bridging implementations implement. It is up to the bridging implementations to determine how frames are passed between the <tt>ast_bridge_channel</tt> objects, what Asterisk control frames are processed and how, etc.</p>
<h4><a name="Asterisk12BridgingProject-astbridgefeatures"></a>ast_bridge_features</h4>
<p>The <tt>ast_bridge_features</tt> object provides hooks that can be passed to <tt>ast_bridge_channel</tt> objects when they join that bridge. The feature hooks implement specific interception callbacks that occur on DTMF key presses, after some period of time has passed, or given some other criteria. These callbacks can affect the channels in a bridge but may also affect the entire bridge.</p>
<p>Detailed information about the Bridging Framework APIs can be seen in <a href="/wiki/display/AST/Asterisk+12+Bridging+API" title="Asterisk 12 Bridging API">Asterisk 12 Bridging API</a>.</p>
<h2><a name="Asterisk12BridgingProject-Richard%27sRamblingsonBridging"></a>Richard's Ramblings on Bridging</h2>
<h3><a name="Asterisk12BridgingProject-TheExistingAPIandProposedChanges"></a>The Existing API and Proposed Changes</h3>
<h4><a name="Asterisk12BridgingProject-enumastbridgechannelstateastbridgejoin%28structastbridgebridge%2Cstructastchannelchan%2Cstructastchannelswap%2Cstructastbridgefeaturesfeatures%2Cstruct%2Castbridgetechoptimizationstechargs%2Cintpassreference%29%3B"></a>enum ast_bridge_channel_state ast_bridge_join(struct ast_bridge *bridge, struct ast_channel *chan, struct ast_channel *swap, struct ast_bridge_features *features, struct, ast_bridge_tech_optimizations *tech_args, int pass_reference);</h4>
<ul>
<li>Put a channel into the specified bridge. The bridge takes custody of the channel.
<ul>
<li>On success, the caller blocks until:
<ul>
<li>the channel hangs up</li>
<li>the channel is kicked out</li>
<li>the bridge dissolves
<ul>
<li>The caller must then run the PBX which runs the h exten, next dialplan location, or ast_async_goto() location.</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li>An error joining the bridge gives the channel back.</li>
<li>The pass_reference flag passes the bridge reference of the caller back to the bridge so the bridge will complete destroying itself when the last channel leaves the bridge. The caller cannot use the bridge pointer when the function returns.</li>
</ul>
<h4><a name="Asterisk12BridgingProject-intastbridgeimpart%28structastbridgebridge%2Cstructastchannelchan%2Cstructastchannelswap%2Cstructastbridgefeaturesfeatures%2Cintindependent%29%3B"></a>int ast_bridge_impart(struct ast_bridge *bridge, struct ast_channel *chan, struct ast_channel *swap, struct ast_bridge_features *features, int independent);</h4>
<ul>
<li>Put a channel into the specified bridge. The bridge takes custody of the channel.</li>
<li>The caller does not block.</li>
<li>An error joining the bridge gives the channel back.</li>
<li>On success, the caller does not get the channel back.</li>
<li>When the channel leaves the bridge the channel will:
<ul>
<li>wait for another thread to claim it with ast_bridge_depart() if not specified as independent</li>
<li>run a PBX at the set location if exited by AST_SOFTHANGUP_ASYNCGOTO (any exit location datastore is removed)</li>
<li>run a PBX if a location is specified by datastore</li>
<li>run the h exten if specifed by datastore then hangup</li>
<li>hangup</li>
</ul>
</li>
</ul>
<h4><a name="Asterisk12BridgingProject-intastbridgedepart%28structastchannelchan%29%3B"></a>int ast_bridge_depart(struct ast_channel *chan);</h4>
<ul>
<li>This function must be removed from the API or severely restricted.</li>
</ul>
<p>API changed that when a channel is imparted, it must be specified that the channel will be departed. These channels can not be moved/merged to another bridge. Channels that can be departed are special channels because the channel must be departed and can not be made to normally execute dialplan when they leave a bridge.</p>
<p>With the change that ast_channel has an ast_bridge_channel pointer instead of an ast_bridge pointer, ast_bridge_depart() does not need to be provided an ast_bridge pointer. Also these channels can move to other bridges and still be departed.</p>
<p>Departing from the bridge must not interfere with an AST_BRIDGE_CHANNEL_STATE_END in progress since it is likely to dissolve the bridge. (Sorta fixed with AST_BRIDGE_CHANNEL_STATE_DEPART_END. Really need to revamp the depart mess.)</p>
<h4><a name="Asterisk12BridgingProject-intastbridgeremove%28structastbridgebridge%2Cstructastchannelchan%29%3B"></a>int ast_bridge_remove(struct ast_bridge *bridge, struct ast_channel *chan);</h4>
<ul>
<li>Request that the channel be removed from the specified bridge.</li>
<li>If the channel is not in a bridge then return error.</li>
</ul>
<p>Channels are removed when the bridge action kicks the channel out. It does not matter if the channel is currently suspended from the bridge.</p>
<h4><a name="Asterisk12BridgingProject-intastbridgemove%28structastbridgebridge%2Cstructastchannelchan%2Cstructastchannelswap%2Cstructastbridgefeaturesfeatures%2Cstructastbridgetechoptimizationstechargs%29%3B"></a>int ast_bridge_move(struct ast_bridge *bridge, struct ast_channel *chan, struct ast_channel *swap, struct ast_bridge_features *features, struct ast_bridge_tech_optimizations *tech_args);</h4>
<ul>
<li>Move a channel from its current bridge to the specified bridge.</li>
<li>The channel knows which bridge it is in because ast_channel_internal_bridge() returns it.</li>
<li>If the channel is not in a bridge then return error.</li>
<li>If the channel is not moveable then return error.</li>
<li>If the channel is already in the bridge then return error.</li>
<li>If the bridge cannot accept the channel then return error.</li>
</ul>
<h4><a name="Asterisk12BridgingProject-intastbridgemerge%28structastbridgebridgedest%2Cstructastbridgebridgesrc%2Cstructastchannelexcludechans%2Cintnumchans%29%3B"></a>int ast_bridge_merge(struct ast_bridge *bridge_dest, struct ast_bridge *bridge_src, struct ast_channel **exclude_chans, int num_chans);</h4>
<ul>
<li>Merge bridge_src into bridge_dest and kick out the channels specified by exclude_chans from the bridges. The bridge_src is gutted and may destroy itself.</li>
<li>bridge_dest can be given new properties.</li>
<li>Channel properties/roles may need to change.</li>
<li>Channel driver attended transfers can be accomplished by merging bridges.</li>
</ul>
<p>This is likely only going to be used for local channel optimization. Unfortunately this will as a result be executed by the thread handling the media which would be not good. When local channel is given the go ahead, the local channels need to be suspended and the merge performed by another thread. A good thread would be one of the local channel bridge channels if it doesn't have much to do in its action queue. (Now do it on the bridge thread.)</p>
<p>Switching to-from-native to 1-1 bridges is going to need to be done on a bridge channel thread as well. (Now do it on the bridge thread.)</p>
<p>Always have a bridge thread. It will control the bridge restructuring, bridge tech selection, bridge hooks, and bridge timer hooks. The bridge thread will also do the bridge media handling depending upon the bridge tech. The early, native, and simple tech will use the bridge thread for media. The multiplexed bridge tech will pass the media duties to a thread common to several bridge instances. The softmix bridge uses the bridge thread for mixing the media after each bridge_channel thread has read it from the channel. Always having a bridge thread means it does not get created/destroyed when the bridge tech is changed by the smart bridge code.</p>
<p>The bridge_dest needs to pull the channels from bridge_src for a merge/move. This will avoid the bridge ao2 reference problem if the bridge_src pushes the channels to bridge_dest.</p>
<h4><a name="Asterisk12BridgingProject-intastbridgesuspend%28structastbridgebridge%2Cstructastchannelchan%29%3B"></a>int ast_bridge_suspend(struct ast_bridge *bridge, struct ast_channel *chan);</h4>
<h4><a name="Asterisk12BridgingProject-intastbridgeunsuspend%28structastbridgebridge%2Cstructastchannelchan%29%3B"></a>int ast_bridge_unsuspend(struct ast_bridge *bridge, struct ast_channel *chan);</h4>
<ul>
<li>Peers of suspended channels need to act like autoserviced channels and save important frames like DTMF and control frames.</li>
</ul>
<h5><a name="Asterisk12BridgingProject-intastisdeferrableframe%28conststructastframeframe%29%3B"></a>int ast_is_deferrable_frame(const struct ast_frame *frame);</h5>
<p>Those frames get sent to the suspended channel and put in its action queue. The bridge needs to generate silence frames to the peer while DTMF is being collected or the chan is suspended.</p>
<p>The suspend/unsuspend functions by a third party should be removed. The bridging code mostly assumes that suspends are from the bridge channel thread and not an external party.</p>
<h4><a name="Asterisk12BridgingProject-intastbridgecountchannels%28structastbridgebridge%29%3B"></a>int ast_bridge_count_channels(struct ast_bridge *bridge);</h4>
<p>Return number of channels in the bridge.</p>
<h4><a name="Asterisk12BridgingProject-structastchannelastbridgepeer%28structastbridgebridge%2Cstructastchannelchan%29%3B"></a>struct ast_channel *ast_bridge_peer(struct ast_bridge *bridge, struct ast_channel *chan);</h4>
<p>Return the bridge peer channel of the given channel. The peer channel is returned with an increased ref count.</p>
<p>This function feels dangerous.</p>
<h4><a name="Asterisk12BridgingProject-intastchannelisbridged%28structastchannelchan%29%3B"></a>int ast_channel_is_bridged(struct ast_channel *chan);</h4>
<p>Return TRUE if the channel is currently bridged.</p>
<h4><a name="Asterisk12BridgingProject-structastbridgeastchannelgetbridge%28structastchannelchan%29%3B"></a>struct ast_bridge *ast_channel_get_bridge(struct ast_channel *chan);</h4>
<p>Get the bridge the channel is currently in.</p>
<h4><a name="Asterisk12BridgingProject-intastbridgeplaytochan%28structastbridgebridge%2Cstructastchannelchan%2Cconstcharfile%29%3B"></a>int ast_bridge_play_to_chan(struct ast_bridge *bridge, struct ast_channel *chan, const char *file);</h4>
<p>Play a file to the specified channel in a bridge.<br/>
Return error if channel not in the specified bridge.</p>
<h4><a name="Asterisk12BridgingProject-intastbridgeplaytobridge%28structastbridgebridge%2Cconstcharfile%29%3B"></a>int ast_bridge_play_to_bridge(struct ast_bridge *bridge, const char *file);</h4>
<p>Play a file to the specified bridge.</p>
<h4><a name="Asterisk12BridgingProject-intastbridgetransferblind%28structastchanneltransferrer%2Cconstcharcontext%2Cconstcharexten%2Cintpriority%29%3B"></a>int ast_bridge_transfer_blind(struct ast_channel *transferrer, const char *context, const char *exten, int priority);</h4>
<ul>
<li>The bridge peer of the transferrer channel is blind transferred.</li>
<li>The bridge peer action runs ast_channel_transfer_blind() after UNHOLDing the channel. The target location is also checked for a Parking exten and a park is performed instead.</li>
</ul>
<h4><a name="Asterisk12BridgingProject-intastchanneltransferblind%28structastchanneltarget%2Cconstchartransferrerchanname%2Cconstcharctxextenpri%29%3B"></a>int ast_channel_transfer_blind(struct ast_channel *target, const char *transferrer_chan_name, const char *ctx_exten_pri);</h4>
<ul>
<li>The ctx_exten_pri is a parseable string: "[<a href="/wiki/pages/createpage.action?spaceKey=AST&title=context%2C&linkCreation=true&fromPageId=22088024" class="createlink">context,</a>exten,]priority". The optional values are filled in by the target channel. transferrer_chan_name can be NULL if done anonymously.</li>
</ul>
<ul>
<li>Set BLINDTRANSFER on target channel with transferer channel name. I don't see why it has historically been put on both channels since the Park app is who needs the variable set so it can announce the parking slot.</li>
<li>UNHOLD target.</li>
<li>Post AMI blind transfer event.</li>
<li>Do the ast_async_goto steps.</li>
</ul>
<h4><a name="Asterisk12BridgingProject-astasyncgoto%28%29"></a>ast_async_goto()</h4>
<p>This function actually is a blind transfer!</p>
<ul>
<li>if channel in a bridge
<ul>
<li>if channel has a PBX
<ul>
<li>set PBX location on the channel + 1 because autoloop will decrement</li>
</ul>
</li>
<li>else
<ul>
<li>set PBX location on the channel</li>
</ul>
</li>
<li>set AST_SOFTHANGUP_ASYNCGOTO</li>
</ul>
</li>
<li>else if channel has a PBX
<ul>
<li>set PBX location on the channel + 1 because autoloop will decrement</li>
<li>set AST_SOFTHANGUP_ASYNCGOTO</li>
</ul>
</li>
<li>else
<ul>
<li>create new channel</li>
<li>set PBX location on the channel</li>
<li>masquerade into it</li>
</ul>
</li>
</ul>
<h4><a name="Asterisk12BridgingProject-intastbridgetransferattended%28structastchannelpartya%2Cstructastchannelpartyc%29%3B"></a>int ast_bridge_transfer_attended(struct ast_channel *party_a, struct ast_channel *party_c);</h4>
<ul>
<li>UNHOLD target party_a peer.</li>
<li>Post AMI attended transfer event.</li>
<li>If party_a and party_c are in bridges, ast_bridge_merge() party_c bridge into party_a bridge removing party_a and party_c channels from the bridges.</li>
<li>If one of the channels is not bridged then we'll have to do it the old way with masquerades.</li>
<li>If neither of the channels are in bridges then return error.</li>
</ul>
<p>Problems if party_c is in the parking bridge. How to get party_a to take party_c's place in that bridge? Need an <tt>ast_bridge_park(struct ast_bridge *parking_bridge, struct ast_bridge_channel *chan, struct ast_bridge_channel *swap);</tt> The original party_a bridge is then dissolved.</p>
<p>Problem is worse for ConfBridge. You cannot swap a channel into that bridge because ConfBridge maintains a lot of state outside of the bridge module. You can only masquerade into the ConfBridge.</p>
<p>To eliminate the masquerade here it is likely that every application needs to become a mini channel driver attaching to a mini bridge associated with every channel. A radical rethink would be necessary for PBX and bridges.</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>We'd really like to do that, but won't have time. <img class="emoticon" src="/wiki/images/icons/emoticons/sad.gif" height="20" width="20" align="absmiddle" alt="" border="0"/></td></tr></table></div>
<h4><a name="Asterisk12BridgingProject-intastbridgepark%28structastbridgeparkingbridge%2Cstructastbridgechannelchan%2Cstructastbridgechannelswap%29%3B"></a>int ast_bridge_park(struct ast_bridge *parking_bridge, struct ast_bridge_channel *chan, struct ast_bridge_channel *swap);</h4>
<p>Moves chan into the parking bridge and replaces the swap channel already in the bridge at the same parking space. This is a specialized ast_bridge_move().</p>
<h3><a name="Asterisk12BridgingProject-Featuresandotherthoughts"></a>Features and other thoughts</h3>
<h4><a name="Asterisk12BridgingProject-chanagentideas%3A"></a>chan_agent ideas:</h4>
<ul>
<li>Agent logs in and waits for calls just like now. The agent could be placed into a holding bridge with some kind of monitoring for a caller.</li>
</ul>
<ul>
<li>Calls come in and get put into a waiting call list container. These calls can abort if chan_agent is not configured to allow multiple waiting calls or if the agent is not logged in.</li>
</ul>
<ul>
<li>Agent thread sees waiting call in the container and finds the early bridge the call is in. The agent can decide when to accept the call. The agent thread then does a Pickup of the incoming call by joining the early bridge.</li>
</ul>
<ul>
<li>Incoming calls that are hungup by the caller or are canceled because the agent joined the early bridge are just removed from the waiting container.</li>
</ul>
<ul>
<li>Agent channels that are blind transferred create a local channel to run dialplan at the specified location and joins the early bridge.</li>
</ul>
<h4><a name="Asterisk12BridgingProject-COLPideas%3A"></a>COLP ideas:</h4>
<ul>
<li>COLP updates happen as an optional result of bridge enter/leave and merge events. Local channel optimizations do not request COLP updates when the bridges merge. Transfer merges do request COLP updates.</li>
</ul>
<ul>
<li>Bridge join/impart new channel initiates a COLP update exchange if there are two peers or from the bridge COLP setting.</li>
</ul>
<ul>
<li>A peer leaving a bridge causes a COLP update if two peers remain in the bridge.</li>
</ul>
<ul>
<li>Multi-peer bridges should be given a COLP identity somehow that is user configurable. If none is given, then the bridge won't give any COLP updates when a new peer joins. The COLP could be assigned by an interception macro/gosub when the bridge goes multi-peer.</li>
</ul>
<ul>
<li>COLP role flag for exchange/bridge updates.</li>
</ul>
<h4><a name="Asterisk12BridgingProject-ConfBridgeCOLPideas%3A"></a>ConfBridge COLP ideas:</h4>
<ul>
<li>Marked users can give a bridge their COLP identity when they join. This could let peers know who is moderating the conference.</li>
</ul>
<ul>
<li>Multi-marked users could cause COLP updates when they talk.</li>
</ul>
<ul>
<li>The bridge profile used can give it a COLP identity and any COLP update<br/>
policy options.</li>
</ul>
<h4><a name="Asterisk12BridgingProject-Parkingideas%3A"></a>Parking ideas:</h4>
<ul>
<li>Add parking lot configuration option to give the parking lot a COLP identity.</li>
</ul>
<h4><a name="Asterisk12BridgingProject-AddnewCHANNEL%28%29option%3A"></a>Add new CHANNEL() option:</h4>
<p>CHANNEL(after_bridge_goto)=<parseable-goto><br/>
Sets an after bridge goto datastore property on the channel.<br/>
CHANNEL(after_bridge_goto)=<empty><br/>
Deletes any after bridge goto datastore property on the channel.</p>
<h4><a name="Asterisk12BridgingProject-BridgeWait%28%29"></a>BridgeWait()</h4>
<p>Potential new dialplan appliction that puts the channel into a holding bridge that the Bridge application or the Bridge AMI action can move to the real bridge. This will avoid the need for a masquerade when the Wait application is used. The Bridge applicaiton and Bridge AMI action will need to be modified to not use masquerades unconditionally if these channels can be moved from the current bridge they are in.</p>
<h4><a name="Asterisk12BridgingProject-MoreStuff"></a>More Stuff</h4>
<p>The DTMF features could be a channel property datastore so they can be removed/restored to the channel depending upon which bridge they are in at the time. As a property they could be set by the CHANNEL() function.</p>
<p>Two party bridges need to keep ast_channel_internal_bridged_channel_set() up to date with the peer.</p>
<p>The default controlling channel for impromptu threeway bridges is the oldest channel controls the destruction of the bridge. A channel variable or CHANNEL(value) set by dialplan could be used to alter the bridge controller.</p>
<p>It would be nice to implement DTMF attended transfer to be able to toggle back and forth between party A and C like DAHDI analog can do.<br/>
*1 - Abort transfer and go back to party A<br/>
*2 - Initiate transfer or just hang up to transfer.<br/>
*3 - Make threeway<br/>
*4 - Toggle between party A and C bridges like POTS can do with a flash hook.</p>
<p>Bridge channel hooks can move the bridge channel between bridges. This would be needed to implement the toggle between A and C bridges feature.</p>
<p>A way to implement the toggle between A and C parties is to have an atxfer bridge subclass. Setup the links this way:</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre> A -- B1 --Local@special/b -- Batxfer1 -- B -- Batxfer2 -- Local@special/b -- B2 -- C
</pre>
</div></div>
<p>The atxfer bridges grant B the transfer menu because it has the TransferrerRoll defined on the channel. When the transfer is completed, the TransferrerRoll is removed.</p>
<p>The atxfer bridges have AST_BRIDGE_FLAG_MERGE_INHIBIT_TO set. They also have the inhibit merge count non-zero while the transfer is incomplete to prevent any local channel optimization.</p>
<p>The only difference between a self managing bridge and an externally managed bridge is if there is something outside of the bridge referencing it. The bridge destructor posts the AMI bridge destroy event.</p>
<p>Suspended channels can still be removed from a bridge. When they try to unsuspend, they find out if they are still part of the bridge or if it is still active.</p>
<p>Non-native 1-1 bridges need to generate AST_CONTROL_SRCUPDATE frames.</p>
<p>A channel that dissolves the bridge needs to update the peer channels hangup cause as it ejects them.</p>
<p>Any channel that later tries to join a dissolved bridge will be immediately ejected with the cause code stored on the bridge.</p>
<p>Event hooks are needed for the following type of events:</p>
<ul>
<li>bridge timeouts(bridge duration, interval),</li>
<li>channel timeouts(duration, interval)
<ul>
<li>Since only the bridge is aware of time, channel timeouts are managed timeouts on the bridge. The enter/leave/merge code needs to update these channel timer hooks.]</li>
</ul>
</li>
<li>channel DTMF features,</li>
<li>channel enter/leave,</li>
<li>bridge empty,</li>
<li>bridge merge,</li>
<li>bridge tech changes,</li>
</ul>
<p>The bridge channel needs to keep track of the last HOLD/UNHOLD state and any DTMF digit in progress so they can be stopped when the channel is removed from the bridge.</p>
<p>The bridge_channel action queue will fix many of the issues I have been having with bridge member updates. The bridge core code determines which bridge_channel to put actions on from a feature hook. For example:</p>
<ul>
<li>Blind transfer hook triggers</li>
<li>Hook gathers destination digits</li>
<li>Hook validates destination</li>
<li>Hook asks bridge core to post blind transfer action onto peer channel.</li>
<li>Bridge may refuse if the request cannot be put onto a peer channel because it no longer exists or there is more than one.</li>
<li>If the bridge refuses then the blind transfer fails and the hook just returns to the bridge as if the user did not try blind transfer. The queued action also needs a destructor as part of the queued struct.</li>
</ul>
<p>The bridge also needs an action queue to do things like smart bridge, bridge merges, channel join, and channel leave. COLP update action.</p>
<h4><a name="Asterisk12BridgingProject-Masquerades%3A%28"></a>Masquerades <img class="emoticon" src="/wiki/images/icons/emoticons/sad.gif" height="20" width="20" align="absmiddle" alt="" border="0"/></h4>
<p>Masquerades are used in two ways:</p>
<ol>
<li>A third party has a channel that they want to take the place of an existing channel. Pickup, Local channel optimization, attended transfer with an application. Running an h exten on the zombie is a good thing.</li>
<li>Steal a channel from some other thread. Park, bridging, blind transfers of channels without a PBX. Running an h exten on this zombie does not do much because it was a sacrificial channel anyway.</li>
</ol>
<h4><a name="Asterisk12BridgingProject-BridgeMerging"></a>Bridge Merging </h4>
<p>Bridges can be marked as non-mergable. (Should be a non-mergable count to handle temporary merge blocks.)</p>
<p>Maybe this should be done automatically while a bridge channel executes a bridge hook.</p>
<ul>
<li>This will block local channel optimizations until ready for it.</li>
<li>This will prevent ConfBridge bridges from absorbing foreign bridges.</li>
<li>This will prevent Parking bridges from absorbing foreign bridges.</li>
</ul>
<h4><a name="Asterisk12BridgingProject-BridgeEventHooks"></a>Bridge Event Hooks</h4>
<p>Event hooks need to be able to be registered/unregistered/destroyed.</p>
<p>Need to add to API: calls to register/unregister/destroy event observer callbacks with private pointer data.</p>
<ul>
<li>Channel bridge enter/exit - notify.</li>
<li>Bridge technology change to/from specific technology - notify.</li>
<li>Bridge stop/destroy hooks - notify.</li>
<li>Bridge merge hooks to direct how merges transform the resulting bridge.
<ul>
<li>Pre-merge-veto - Multiple callbacks allowed. Any can veto merge.</li>
<li>Pre-merge - Multiple callbacks allowed.</li>
<li>Post-merge - Multiple callbacks allowed to inform of completed merge.</li>
</ul>
</li>
<li>Bridge merge hooks per channel
<ul>
<li>Pre-merge-veto - Multiple callbacks allowed. Any can veto merge.</li>
<li>Pre-merge - Multiple callbacks allowed.</li>
<li>Post-merge - Multiple callbacks allowed to inform of completed merge.</li>
</ul>
</li>
</ul>
<h4><a name="Asterisk12BridgingProject-Roles"></a>Roles</h4>
<p>Need to add role concepts for channels in bridge. Channels can change roles using feature hooks. Rolls may be flags.</p>
<ul>
<li>Caller/Callee for early media bridge and COLP interception macros.</li>
<li>Announcer - Plays messages/music to channels in the bridge. Not considered a peer.</li>
<li>Recorder - Records bridge. Not considered a peer.</li>
<li>Agent - Can hear Supervisor whisper. Considered a peer. Only ability other than default.</li>
<li>Supervisor - Can whisper to Agent. Not considered a peer.</li>
<li>Default - Regular participant in the bridge. Considered a peer.</li>
<li>ConfBridge - Regular participant in the bridge. Not considered a peer.</li>
</ul>
<p>Roll flags:</p>
<ul>
<li>Caller - Only significant in early media bridge. The caller flag can also be used for COLP interception macros. Attended transfers would need to manipulate the caller role flag for proper roles. Party A is always the caller role and Party C is the callee role.</li>
<li>Peer - Normal bridges exchange control frames when only two channels are marked as peers. Early media bridges (if they but existed) also look at the Caller flag for control frame exchanges.</li>
<li>COLP-exchange - Channel can exchange COLP updates with peer. Exchanges COLP when there are less than three channels in the bridge marked as such. Otherwise, it behaves like the COLP-bridge role flag.</li>
<li>COLP-bridge - Channel can recieve COLP updates from the bridge. ConfBridge users just have this flag set to only receive COLP updates from the bridge.</li>
</ul>
<p>Future role flags (softmix bridge):</p>
<ul>
<li>Whisper - Channel can only be heard by a channel marked Whisper-receiver</li>
<li>Whisper-receiver</li>
<li>Recorder - Channel receives the recording mix of recordable channels.</li>
<li>NonRecordable - Channel is not heard by a recording channel.</li>
<li>Announcer - Channel can only be heard by a channel marked Announcer-receiver</li>
<li>Announcer-receiver</li>
</ul>
<p>Recorder/Announcer channels need an option flag to exit the bridge if there is noone else in the bridge. Otherwise there is the possibility that the bridge will become orphaned with just those special channels in the bridge. AST_BRIDGE_FLAG_LONELY</p>
<h3><a name="Asterisk12BridgingProject-NewObjects"></a>New Objects</h3>
<h4><a name="Asterisk12BridgingProject-Designpatterns"></a>Design patterns</h4>
<ul>
<li>The state pattern could be applied to ast_bridge.
<ul>
<li>ast_bridge could be thought of as a state of ast_bridge_channel.</li>
<li>Changing states is moving to another bridge. This is a bit of a stretch though.</li>
</ul>
</li>
</ul>
<p>ast_bridge_technology is the strategy pattern</p>
<p>The decorator pattern could be applied to ast_bridge_channel to decorate the channel with feature hooks. Decorators can be added/removed at run time just like features. Though this pattern may be a bit expensive resource wise.</p>
<p>The Basic, Parking, ConfBridge, atxfer, and Queue bridges could be thought of as a strategy instead of subclassing ast_bridge_channel. It is looks more like ast_bridge_technology in relation to ast_bridge/ast_bridge_channel. Changed this back to just subclassing ast_bridge.</p>
<h4><a name="Asterisk12BridgingProject-BridgeClasses"></a>Bridge Classes</h4>
<p>Bridge technologies are an embedded object of the abstract bridge class.</p>
<p>Park, Queue, ConfBridge could be derivative classes of the abstract bridge class.</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre>class ast_bridge {
join(struct ast_channel *chan);
depart(struct ast_channel *chan);
remove(struct ast_channel *chan);
move_pull(class ast_bridge_channel *chan);
Pull a channel out of this bridge to be pushed into another bridge.
move_push(class ast_bridge_channel *chan, class ast_bridge_channel *swap);
Push a channel into this bridge that was pulled from another bridge.
masquerade_pull(class ast_bridge_channel *chan);
A masquerade is figuratively pulling this channel out of the bridge
to be pushed back in as a new channel.
This is done for the clone and original channels because a masquerade
swaps the guts of the two channels.
masquerade_push(class ast_bridge_channel *chan);
Push the channel back into the bridge as a new channel.
poke();
new();
The derived bridge classes need to have a default channel
configuration for when a channel is pushed into it.
Park needs to assign a parking space and timeout.
ConfBridge needs to have a default user profile.
The class also needs to remove special channel configuration
when it it pulled.
The class needs to have a channel inherit the configuration
of a swapped channel when it is pushed or joined.
};
class ast_bridge_channel {
class ast_bridge *bridge;
suspend();
Mark channel as suspended and poke the bridge to recognize it.
unsuspend();
Mark channel as unsuspended and poke the bridge to recognize it.
};
</pre>
</div></div>
<h4><a name="Asterisk12BridgingProject-Lockingprecedenceorder%3A"></a>Locking precedence order:</h4>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre> bridges ao2_container
|
ast_bridge
|
channels ao2_container ast_bridge_channel
| _____________/
ast_channel
/
channel private
</pre>
</div></div>
<h4><a name="Asterisk12BridgingProject-NewBridgeTechs"></a>New Bridge Techs</h4>
<h5><a name="Asterisk12BridgingProject-Earlymediabridgetech%3A"></a>Early media bridge tech:</h5>
<ul>
<li>Allowed channel roles: 0-1 Caller / 1-n Callees</li>
<li>The bridge can start with this tech but cannot switch back to it.</li>
<li>At most one Peer channel UP and at least one Peer channel not UP.</li>
<li>Does not do audio mixing.</li>
<li>First call to answer kicks out all other Peer non-Caller channels and answers the Caller channel if needed.</li>
<li>The bridge tech needs to change to a normal bridge type.</li>
<li>The bridge can have a timeout to connect.</li>
</ul>
<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>We are, unfortunately, punting on the Early Media Bridge Technology. Not because it isn't awesome or the right way to do it, but because app_dial and app_queue are a bitch to refactor.</td></tr></table></div>
<h5><a name="Asterisk12BridgingProject-Parkingbridgetech%3A"></a>Parking bridge tech:</h5>
<ul>
<li>Adds ability to access bridge channels in it by parking space/slot.</li>
<li>Parking bridges are found in a container by parking lot name.</li>
<li>Parking lots can be configured with COLP information.</li>
<li>The parking tech has extra methods to manage the parking lot:
<ul>
<li>move_bridged_channel_to_parking,</li>
<li>move_bridged_channel_from_parking,</li>
<li>swap_bridged_channel_with_parked</li>
</ul>
</li>
<li>Actually these extra methods look like they should be part of the base bridge class.</li>
<li>Timed out calls leave the parking lot by blind transfer.</li>
</ul>
<h4><a name="Asterisk12BridgingProject-DTMFFeatureTransfers"></a>DTMF Feature Transfers</h4>
<h5><a name="Asterisk12BridgingProject-DTMFBlindtransfer%3A"></a>DTMF Blind transfer:</h5>
<ul>
<li>(Transfer will fail if the transferee channel is imparted to be departed.)</li>
<li>Up non-merge count on host bridge.</li>
<li>Get transfer destination.</li>
<li>Validate it is in the dialplan.</li>
<li>Check if it is a parking exten and park instead.</li>
<li>Queue action to bridge peer to blind transfer.
<ul>
<li>Supply transfering channel, exten@context</li>
</ul>
</li>
<li>Peer channel executes blind transfer action. ast_async_goto().
<ul>
<li>Channel leaves bridge and starts executing dialplan.</li>
</ul>
</li>
<li>Drop non-merge count on host bridge.</li>
</ul>
<h5><a name="Asterisk12BridgingProject-DTMFAttendedtransfer%3A"></a>DTMF Attended transfer:</h5>
<ul>
<li>If party A hangs up the original bridge should be set to dissolve and automatically kick out party B from the bridge.</li>
<li>Up non-merge count on host bridge.</li>
<li>Get transfer destination.</li>
<li>Validate it is in the dialplan.</li>
<li>Check if it is a parking exten and park instead.</li>
<li>Create early media bridge.
<ul>
<li>Bridge does not dissolve,</li>
<li>Bridge times out,</li>
<li>Bridge non-mergable(to prevent local channel optimization)</li>
</ul>
</li>
<li>Dial party C</li>
<li>Pull party B bridge_channel out of the bridge</li>
<li>Create an atxfer caretaker thread to see it through. Pass party B bridge_channel, party C, and early media bridge
<ul>
<li>The early media bridge is not really viable here unless we want to allow it to be able to keep going with no caller.</li>
<li>If party B hangs up before party C answers we need to save party B channel name, release party B channel, and wait the timeout for party C to answer</li>
<li>If party C answers within the timeout then we can impart it into the original bridge to talk to party A.</li>
<li>If party C does not answer within the timeout, we need to bounce back and forth call attempts to party B and party C.</li>
</ul>
</li>
<li>Impart party C into early media bridge, Party C dissolves bridge when it hangs up.
<ul>
<li>If Party C is forwarded, the forwarded channel replaces the party C channel and takes Party C's properties.</li>
</ul>
</li>
<li>Join party B into early media bridge (or not <img class="emoticon" src="/wiki/images/icons/emoticons/sad.gif" height="20" width="20" align="absmiddle" alt="" border="0"/>)</li>
<li>Party B leaves the bridge when
<ul>
<li>early media bridge times out</li>
<li>Party B cancels/aborts transfer</li>
<li>Party B wishes threeway call</li>
<li>Party B hangs up (early media bridge or normal bridge keeps going)</li>
<li>Party C hangs up</li>
</ul>
</li>
<li>if party B hangs up
<ul>
<li>if party C is up
<ul>
<li>Mark bridge channels as non-dissolving(Only party C should be in the bridge if still there)</li>
<li>move Party C bridge channel to original bridge</li>
<li>destroy temporary bridge</li>
<li>Drop non-merge count on host bridge.</li>
<li>party B returns to original bridge and leaves bridge</li>
<li>done</li>
</ul>
</li>
<li>wait for party C to answer or the timeout</li>
</ul>
</li>
<li>else if party B cancels/aborts transfer
<ul>
<li>destroy temporary bridge</li>
<li>Drop non-merge count on host bridge.</li>
<li>party B returns to original bridge</li>
<li>done</li>
</ul>
</li>
<li>else if party B wishes threeway call
<ul>
<li>Mark bridge channels as non-dissolving(Only party C should be in the bridge if still there)</li>
<li>mark party B on original bridge as dissolves bridge when it hangs up.</li>
<li>mark original bridge as non-dissolving</li>
<li>move Party C bridge channel to original bridge</li>
<li>destroy temporary bridge</li>
<li>Drop non-merge count on host bridge.</li>
<li>party B returns to original bridge</li>
<li>done</li>
</ul>
</li>
<li>if early media bridge times out
<ul>
<li>If party C does not answer within the timeout, we need to bounce back and forth</li>
<li>call attempts to party B and party C.</li>
</ul>
</li>
</ul>
<h5><a name="Asterisk12BridgingProject-Parking%28DTMFonetouchpark%2CDTMFblindtransfer%2CDTMFattendedtransfer%29%3A"></a>Parking (DTMF one-touch-park, DTMF blind transfer, DTMF attended transfer):</h5>
<ul>
<li>Determine parking lot to put peer into.</li>
<li>Create parking space channel for masquerade.</li>
<li>Reserve space in the parking lot.</li>
<li>Queue action to bridge peer to park
<ul>
<li>Supply parking channel name, parking channel</li>
</ul>
</li>
<li>Peer channel executes park-me action</li>
<li>Park-me action queues play slot number or failure message back to peer</li>
<li>Park-me action masquerades bridge_channel to parking channel.</li>
<li>Parking channel is put into the parking manager thread.</li>
</ul>
<h5><a name="Asterisk12BridgingProject-Pickup%3A"></a>Pickup:</h5>
<ul>
<li>Find appropriate ringing channel in early media bridge</li>
<li>Join-swap ringing channel</li>
<li>Need some race condition insurance that some other channel won't win</li>
<li>while the pickup channel is coming into the bridge. Otherwise we would</li>
<li>wind up with a three or more party bridge.</li>
</ul>
<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 won't be how this works. It's still going to be a masquerade.</td></tr></table></div>
<h5><a name="Asterisk12BridgingProject-Localchanneloptimization%3A"></a>Local channel optimization:</h5>
<ul>
<li>Needs more thought because we don't want to optimize in the middle of other operations.</li>
<li>Local channel determines it is possible to masquerade.</li>
<li>The non-merge count will block optimizations during inopportune times.</li>
<li>Optimization is done by merging bridges and ejecting the merging local channels from the resulting merged bridge.</li>
</ul>
<h5><a name="Asterisk12BridgingProject-FollowMe%3A"></a>FollowMe:</h5>
<ul>
<li>For followme need an event-hook/frame-hook to intercept the AST_CONTROL_ANSWER so it can handle the user query. Each outgoing channel needs to have its own timer so it can drop out if it isn't answered. The main followme thread also has a timer to dump the next round of calls into the early-media bridge.</li>
</ul>
<h5><a name="Asterisk12BridgingProject-Queue%3A"></a>Queue:</h5>
<ul>
<li>Like parking, the call can be stuck in a holding bridge until:
<ol>
<li>an agent gets the call</li>
<li>caller hangs up</li>
<li>caller presses DTMF to goto new location</li>
</ol>
</li>
<li>The holding bridge could periodically or when the number of calls ahead of the caller changes announce to the caller what position in the queue they are in.</li>
</ul>
<h3><a name="Asterisk12BridgingProject-APIsforFolks"></a>APIs for Folks</h3>
<h4><a name="Asterisk12BridgingProject-CLIcommands%3A"></a>CLI commands:</h4>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre>bridge show all
List all current bridges by bridge-id and number of channels in the bridge.
bridge show bridge-id
Dump information about the specified bridge.
bridge-id, bridge tech using, bridge tech could use, channels in bridge,
bridge type (normal, parking, queue, ConfBridge), other information
bridge destroy all
Destroy all bridges in the system.
Maybe we should qualify this as destroy only transient bridges. Not
bridges that exist as long as the system is running or the module is loaded.
bridge destroy bridge-id
Destroy the specified bridge.
bridge kick <channel>
Kick a channel out of a bridge if it is in one.
NOTE: Be careful because it does not destroy the bridge. If there is only
one channel left in the bridge, that channel may just sit there.
bridge suspend <tech>
Suspend the bridge technology from use by bridges.
Bridges currently using the technology will continue to use it.
bridge unsuspend <tech>
Unsuspend the bridge technology from use by bridges.
</pre>
</div></div>
<p>Corresponding AMI actions should also be created.</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>
<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 #2</b><br />Most likely, call pickup will not have an early bridge <img class="emoticon" src="/wiki/images/icons/emoticons/sad.gif" height="20" width="20" align="absmiddle" alt="" border="0"/></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>
<tr>
<td class='confluenceTd'> <a href="/wiki/display/AST/Asterisk+11+ManagerEvent_Bridge" title="Asterisk 11 ManagerEvent_Bridge">Bridge</a> </td>
<td class='confluenceTd'> Check that the AMI Bridge event occurs when expected </td>
</tr>
</tbody></table>
</div>
<h1><a name="Asterisk12BridgingProject-ProjectPlanning"></a>Project Planning</h1>
<h2><a name="Asterisk12BridgingProject-HighLevelBridgingconstructiontasks%3A"></a>High Level Bridging construction tasks:</h2>
<ul>
<li><b>DONE</b> Change ast_bridge_call callers to not expect getting peer back. Part of this is to add an optional goto dialplan location datastore to set where the peer should go when it exits the bridge. The location datastore is removed if a channel exits with AST_SOFTHANGUP_ASYNCGOTO set or the channel is masqueraded. Part of this is to implement the self managing bridge functionality.</li>
</ul>
<ul>
<li><b>DONE</b> Make all bridge technologies have a bridging thread to handle bridge restructuring tasks like smart bridge and bridge merges. When the bridge thread is not being used to restructure the<br/>
bridge, it can be dealing with the bridge media flows. Part of this is adding a bridge action queue like the bridge channel action queue. The softmix bridge may just create a bridge thread to handle the bridge restructuring chores and an auxiliary thread to do the mixing currently done by the bridge thread. Need to implement the non-merge count.</li>
</ul>
<ul>
<li><b>DONE</b> Implement a v-method table to subclass struct ast_bridge. Parking, Queues, ConfBridge, and other holding bridges would then be able to subclass ast_bridge to allow merge/moves between bridges.</li>
</ul>
<ul>
<li><b>DONE</b>(except for the role support in softmix. It won't be needed until much later if ever.): Add control frame support/processing. Part of this needs to add AST_CONTROL_SRCUPDATE generation on 1-1 bridging. Part of this needs to add the caller role flag for the initial role flags support. Mark normal channels with the peer role flag and respect it. Initially all channels not in a ConfBridge will be marked as a peer.</li>
</ul>
<ul>
<li><b>DONE</b> Add bridge CLI commands. Part is to add bridge id support. How unique does the bridge id need to be? UUID, hostname/timestamp/sequence-no, timestamp/sequence-no, or just sequence-no AMI Transfer start/complete events. Implements the global bridges ao2 container. This container is needed for ConfBridge, Parking, BridgeWait, and Queue to find bridges by name. As a consequence of this, bridges must explicitly know when to die rather than counting on the ao2 reference count to drop to zero.</li>
</ul>
<ul>
<li><b>DONE</b> Create the Basic bridge subclass. This bridge enables the DTMF features controlled by features.conf: One-touch-parking, Blind transfer, attended transfer, monitor-recording, mixmonitor-recording, dynamic features. The Basic bridge subclass pulls most of the code from ast_bridge_call into itself.</li>
</ul>
<ul>
<li><b>DONE</b> Add bridge and bridge channel hooks for enter/leave/answer/merge/tech-change/empty events. An answer hook will not be usable until the early bridge is implemented.</li>
</ul>
<ul>
<li><b>DONE</b> (save for complete) Add create/enter/leave/destroy bridge stasis/AMI events. The complete event is needed to indicate if the transfer was successful, aborted, or was turned into a threeway.</li>
</ul>
<ul>
<li>Get local channel optimization functional again. I would like to pull chan_local into the bridging module. There seem to be times where it could be useful to create a local channel structure and impart the channels into different bridges or put one end into a bridge and the other executes an application. Pulling chal_local into the bridge module could wait until I actually have a real need to do so.</li>
</ul>
<ul>
<li>Implement ast_bridge_transfer_blind() and ast_bridge_transfer_attended(). Attended transfer needs to update the caller role flags on peer channels. Attended transfer will need revisiting when parking is reworked.</li>
</ul>
<ul>
<li>Get the channel drivers to use the ast_bridge_transfer_blind() and ast_bridge_transfer_attended() calls. This can be a task for each channel driver: chan_dahdi, chan_sip, chan_misdn, etc...</li>
</ul>
<ul>
<li>Implement early bridging. I'm now thinking that the early media bridge will turn into just enhancing the dialing API because of the way Page works. Dial/Queue/FollowMe would need to be converted to use the dialing API.</li>
</ul>
<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>Punt.</td></tr></table></div>
<ul>
<li>Dial/Queue/FollowMe/Pickup updated to use early bridging.</li>
</ul>
<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>Punt.</td></tr></table></div>
<ul>
<li>Get DTMF transfer features on par with current functionality. DTMF attended transfer will need a manager thread to handle operations after Party B hangs up and before Party C answers. Bonus is that the new bridging API allows threeway conferences. Since features.conf is being gutted should we eliminate it in favor of new config files?</li>
</ul>
<ul>
<li>Implement parking bridge and get the system to use it. Park(), ParkedCall(), ParkAndAnnounce(), DTMF one touch park.</li>
</ul>
<ul>
<li>Implement DTMF one touch record. Monitor and MixMonitor support.</li>
</ul>
<ul>
<li>Get chan_agent working again since the chan->_bridge pointer is no more. Must be done after early bridging so the agent channel can Pickup the caller.</li>
</ul>
<ul>
<li>Lastly native bridging technology.</li>
</ul>
<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=12133&tempMax=1000">JIRA Issues</a> (14 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-21352"><img src="https://issues.asterisk.org/jira/images/icons/issuetypes/newfeature.png" alt="New Feature" border="0" /></a>
</td>
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21352">ASTERISK-21352</a>
</td>
<td >
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21352">Bridge API Enhancements - refactor ParkAndAnnounce application to use the new parking bridge</a>
</td>
<td nowrap="true">
Unassigned
</td>
<td nowrap="true">
Matt Jordan
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/priorities/major.png" alt="Major" border="0" />
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/statuses/open.png" alt="" border="0" /> Open
</td>
<td nowrap="true">
<font color="990000">Unresolved</font>
</td>
<td nowrap="true">
Mar 29, 2013
</td>
<td nowrap="true">
Mar 29, 2013
</td>
<td nowrap="true">
</td>
</tr>
<tr class="rowAlternate">
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21338"><img src="https://issues.asterisk.org/jira/images/icons/issuetypes/newfeature.png" alt="New Feature" border="0" /></a>
</td>
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21338">ASTERISK-21338</a>
</td>
<td >
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21338">Bridge API Enhancements - Refactor the Dial API as a bridge mixing technology</a>
</td>
<td nowrap="true">
Joshua Colp
</td>
<td nowrap="true">
Matt Jordan
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/priorities/major.png" alt="Major" border="0" />
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/statuses/open.png" alt="" border="0" /> Open
</td>
<td nowrap="true">
<font color="990000">Unresolved</font>
</td>
<td nowrap="true">
Mar 29, 2013
</td>
<td nowrap="true">
Apr 09, 2013
</td>
<td nowrap="true">
</td>
</tr>
<tr class="rowNormal">
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21337"><img src="https://issues.asterisk.org/jira/images/icons/issuetypes/newfeature.png" alt="New Feature" border="0" /></a>
</td>
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21337">ASTERISK-21337</a>
</td>
<td >
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21337">Bridge API Enhancements - add stasis core messages for blind/attended transfers</a>
</td>
<td nowrap="true">
Unassigned
</td>
<td nowrap="true">
Matt Jordan
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/priorities/major.png" alt="Major" border="0" />
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/statuses/open.png" alt="" border="0" /> Open
</td>
<td nowrap="true">
<font color="990000">Unresolved</font>
</td>
<td nowrap="true">
Mar 29, 2013
</td>
<td nowrap="true">
Apr 17, 2013
</td>
<td nowrap="true">
</td>
</tr>
<tr class="rowAlternate">
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21336"><img src="https://issues.asterisk.org/jira/images/icons/issuetypes/newfeature.png" alt="New Feature" border="0" /></a>
</td>
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21336">ASTERISK-21336</a>
</td>
<td >
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21336">Bridge API Enhancements - add externally initiated attended transfers</a>
</td>
<td nowrap="true">
Unassigned
</td>
<td nowrap="true">
Matt Jordan
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/priorities/major.png" alt="Major" border="0" />
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/statuses/open.png" alt="" border="0" /> Open
</td>
<td nowrap="true">
<font color="990000">Unresolved</font>
</td>
<td nowrap="true">
Mar 29, 2013
</td>
<td nowrap="true">
Apr 16, 2013
</td>
<td nowrap="true">
</td>
</tr>
<tr class="rowNormal">
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21335"><img src="https://issues.asterisk.org/jira/images/icons/issuetypes/newfeature.png" alt="New Feature" border="0" /></a>
</td>
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21335">ASTERISK-21335</a>
</td>
<td >
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21335">Bridge API Enhancements - add externally initiated blind transfers</a>
</td>
<td nowrap="true">
Unassigned
</td>
<td nowrap="true">
Matt Jordan
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/priorities/major.png" alt="Major" border="0" />
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/statuses/open.png" alt="" border="0" /> Open
</td>
<td nowrap="true">
<font color="990000">Unresolved</font>
</td>
<td nowrap="true">
Mar 29, 2013
</td>
<td nowrap="true">
Apr 16, 2013
</td>
<td nowrap="true">
</td>
</tr>
<tr class="rowAlternate">
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21334"><img src="https://issues.asterisk.org/jira/images/icons/issuetypes/newfeature.png" alt="New Feature" border="0" /></a>
</td>
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21334">ASTERISK-21334</a>
</td>
<td >
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21334">Bridge API Enhancements - hide masquerades</a>
</td>
<td nowrap="true">
Unassigned
</td>
<td nowrap="true">
Matt Jordan
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/priorities/major.png" alt="Major" border="0" />
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/statuses/open.png" alt="" border="0" /> Open
</td>
<td nowrap="true">
<font color="990000">Unresolved</font>
</td>
<td nowrap="true">
Mar 29, 2013
</td>
<td nowrap="true">
Mar 29, 2013
</td>
<td nowrap="true">
</td>
</tr>
<tr class="rowNormal">
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21333"><img src="https://issues.asterisk.org/jira/images/icons/issuetypes/newfeature.png" alt="New Feature" border="0" /></a>
</td>
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21333">ASTERISK-21333</a>
</td>
<td >
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21333">Bridge API Enhancements - refactor all uses of a jitter buffer to use func_jitterbuffer</a>
</td>
<td nowrap="true">
Unassigned
</td>
<td nowrap="true">
Matt Jordan
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/priorities/major.png" alt="Major" border="0" />
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/statuses/open.png" alt="" border="0" /> Open
</td>
<td nowrap="true">
<font color="990000">Unresolved</font>
</td>
<td nowrap="true">
Mar 29, 2013
</td>
<td nowrap="true">
Mar 29, 2013
</td>
<td nowrap="true">
</td>
</tr>
<tr class="rowAlternate">
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21332"><img src="https://issues.asterisk.org/jira/images/icons/issuetypes/newfeature.png" alt="New Feature" border="0" /></a>
</td>
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21332">ASTERISK-21332</a>
</td>
<td >
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21332">Bridge API Enhancements - create the Basic Bridge subclass</a>
</td>
<td nowrap="true">
Richard Mudgett
</td>
<td nowrap="true">
Matt Jordan
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/priorities/major.png" alt="Major" border="0" />
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/statuses/open.png" alt="" border="0" /> Open
</td>
<td nowrap="true">
<font color="990000">Unresolved</font>
</td>
<td nowrap="true">
Mar 29, 2013
</td>
<td nowrap="true">
Mar 29, 2013
</td>
<td nowrap="true">
</td>
</tr>
<tr class="rowNormal">
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21272"><img src="https://issues.asterisk.org/jira/images/icons/issuetypes/newfeature.png" alt="New Feature" border="0" /></a>
</td>
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21272">ASTERISK-21272</a>
</td>
<td >
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21272">Bridge API Enhancements - subclass Parking with its own Virtual Method table</a>
</td>
<td nowrap="true">
Jonathan Rose
</td>
<td nowrap="true">
Matt Jordan
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/priorities/major.png" alt="Major" border="0" />
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/statuses/open.png" alt="" border="0" /> Open
</td>
<td nowrap="true">
<font color="990000">Unresolved</font>
</td>
<td nowrap="true">
Mar 15, 2013
</td>
<td nowrap="true">
Mar 29, 2013
</td>
<td nowrap="true">
</td>
</tr>
<tr class="rowAlternate">
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21271"><img src="https://issues.asterisk.org/jira/images/icons/issuetypes/newfeature.png" alt="New Feature" border="0" /></a>
</td>
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21271">ASTERISK-21271</a>
</td>
<td >
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21271">Bridge API Enhancements - subclass ConfBridge with its own Virtual Method table</a>
</td>
<td nowrap="true">
Richard Mudgett
</td>
<td nowrap="true">
Matt Jordan
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/priorities/major.png" alt="Major" border="0" />
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/statuses/open.png" alt="" border="0" /> Open
</td>
<td nowrap="true">
<font color="990000">Unresolved</font>
</td>
<td nowrap="true">
Mar 15, 2013
</td>
<td nowrap="true">
Apr 12, 2013
</td>
<td nowrap="true">
</td>
</tr>
<tr class="rowNormal">
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21059"><img src="https://issues.asterisk.org/jira/images/icons/issuetypes/improvement.png" alt="Improvement" border="0" /></a>
</td>
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21059">ASTERISK-21059</a>
</td>
<td >
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21059">Bridge API Enhancements - Refactor the Park family of applications</a>
</td>
<td nowrap="true">
Jonathan Rose
</td>
<td nowrap="true">
Matt Jordan
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/priorities/major.png" alt="Major" border="0" />
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/statuses/inprogress.png" alt="" border="0" /> In Progress
</td>
<td nowrap="true">
<font color="990000">Unresolved</font>
</td>
<td nowrap="true">
Feb 08, 2013
</td>
<td nowrap="true">
Mar 15, 2013
</td>
<td nowrap="true">
</td>
</tr>
<tr class="rowAlternate">
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21058"><img src="https://issues.asterisk.org/jira/images/icons/issuetypes/improvement.png" alt="Improvement" border="0" /></a>
</td>
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21058">ASTERISK-21058</a>
</td>
<td >
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21058">Bridge API Enhancements - rework Local channels/Local channel bridging</a>
</td>
<td nowrap="true">
Richard Mudgett
</td>
<td nowrap="true">
Matt Jordan
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/priorities/major.png" alt="Major" border="0" />
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/statuses/open.png" alt="" border="0" /> Open
</td>
<td nowrap="true">
<font color="990000">Unresolved</font>
</td>
<td nowrap="true">
Feb 08, 2013
</td>
<td nowrap="true">
Apr 12, 2013
</td>
<td nowrap="true">
</td>
</tr>
<tr class="rowNormal">
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21057"><img src="https://issues.asterisk.org/jira/images/icons/issuetypes/improvement.png" alt="Improvement" border="0" /></a>
</td>
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21057">ASTERISK-21057</a>
</td>
<td >
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21057">Bridge API Enhancements - add Stasis-Core events</a>
</td>
<td nowrap="true">
Kinsey Moore
</td>
<td nowrap="true">
Matt Jordan
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/priorities/major.png" alt="Major" border="0" />
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/statuses/open.png" alt="" border="0" /> Open
</td>
<td nowrap="true">
<font color="990000">Unresolved</font>
</td>
<td nowrap="true">
Feb 08, 2013
</td>
<td nowrap="true">
Apr 10, 2013
</td>
<td nowrap="true">
</td>
</tr>
<tr class="rowAlternate">
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-20869"><img src="https://issues.asterisk.org/jira/images/icons/issuetypes/improvement.png" alt="Improvement" border="0" /></a>
</td>
<td nowrap="true">
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-20869">ASTERISK-20869</a>
</td>
<td >
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-20869">Bridge API Enhancements - add support for native bridging</a>
</td>
<td nowrap="true">
Joshua Colp
</td>
<td nowrap="true">
Matt Jordan
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/priorities/major.png" alt="Major" border="0" />
</td>
<td nowrap="true">
<img src="https://issues.asterisk.org/jira/images/icons/statuses/open.png" alt="" border="0" /> Open
</td>
<td nowrap="true">
<font color="990000">Unresolved</font>
</td>
<td nowrap="true">
Jan 03, 2013
</td>
<td nowrap="true">
Apr 15, 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=20&originalVersion=19">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>