Goals for an Asterisk Live Channel Merge

It is useful in a PBX or phone control context to be able to join two active channels to one another. Typically the active channels will be served by dialplan scripts (an IVR) and then be connected together. This is also how a screened transfer can work.

Channels can be merged through a bridge, such as the meetme conference application. This hairpins (routes) their audio through the server, which has two big disadvantages. One, it uses bandwidth on the server, and two, it adds latency to the call if the callers are distant from the PBX. They would rather their audio flow directly.

Hairpining audio does have one big advantage -- the PBX can listen for commands from the users (such as DTMF) and more easily break in to announce things to the users, either to both or via "whisper" to one of them. It is also possible to monitor and record the conversation in this case.

A merge should be able to merge two channels as long as they are not in the Down state. This means it should be possible to merge a channel which is still ringing its destination. In this case, the early media (ringback) should flow from that channel. If there is not early media, other ringing indications should flow so the other party hears ringback.

Manager Actions and Events

Mostly briding would be done from the manager interface, since dialplan scripts don't usually readily know the real channel name of another channel.

Bridge Action

Channel1, Channel 2: The two channels to bridge, full channel ID.
Tone: Play a tone to both channels when joining them
OrphanPlan: Can be set to a context/extension/priority. If set, if one channel hangs up or is redirected or rebridged or otherwise disconnected, the other (orphan) channel will be redirected to this dialplan. An Unlink and single Hangup event will be generated. The Unlink should perhaps be extended to note that one channel is an orphan. If no OrphanPlan is set, disconnect of one channel disconnects the other. An Unlink and two hangups would be sent.
Hairpin: Optional: If true, insist on hairpining audio or DTMF even if the channels can be directly connected. Can specify channel 1, 2 or both. Can specify modes like "audio" (insist everything be hairpined), "dtmf" (prefer only DTMF be hairpinned), "trydtmf" (try to hairpin DTMF, but don't do it if it forces hairpin of the audio) and "no" -- avoid hairpinning. Note that hairpinning may occur in any event due to codec bridging etc.
DTMF: Requests DTMF events from channel 1, 2 or both.

Note that it would be nice if this action could be re-invoked on two channels that are already connected, in order to alter the Hairpin and DTMF flag states.

Immediate return would indicate various failure states or success. If the bridge was already active, this would be noted in a success return, with the new Hairpin and DTMF state. The actual hairpin result should be returned if possible.

Link Event

A Link event will be generated when the channels are joined. The extra parameters (DTMF, hairpin) may be ahdded to it. Unlink as well.

DTMF Event

If DTMF monitoring is taking place on a channel, the detection of DTMF would trigger an event.

Audio and DTMF

If the calls are voip, and transmit DTMF out of band (SIP INFO) instead of via audio, it can be possible to allow the PBX to process DTMF commands from such channels even without bridging the audio directly. This is ideal. As such, when joining, the command would indicate these possibilities:

Always bridge audio -- I wish to monitor the audio of channel A, B or both.
I wish to monitor DTMF of A, B or both -- bridge audio one way or both if the DTMF is in audio for a channel, and send events if DTMF is detected. (Note it is possible on a call between A, B and PBX for the audio to flow directly from A to B, but from B to A via the PBX.
I don't wish to monitor audio or DTMF -- try to send audio directly if you can.

It can be useful to swtich between these states, though this will probably cause a clicking or interruption in the call. For example, a PBX may wish to break into a call which has direct audio. It could do so by switching the audio to bridged in one direction or both, and then do the interruption.

It also may make sense to ask for DTMF or audio access at the start of a call, since most DTMF requests would come then, and then switch to unbridged. After the switch, hangup would be the only way for a call to get the attention of the PBX. (It could then call back if it had more business for the endpoint.)

Control logic should ideally be able to learn just how the calls were joined, and whether the audio is bridged or not, and independently the DTMF. (Though it is presumed if audio is bridged that DTMF is too, though not necessarily that the system is listening for DTMF and generating events.)

Hangup

Control logic should be able to set what happens when one of the channels hangs up. The main choice is whether hangup of one leg triggers hangup of the other leg. For a joined call in which the control logic has no further interest, dual-hangup is right. If the logic wants to retake control of the leg that didn't hang up, and send it to a new dialplan script, single hangup is right. The single-hangup would trigger an event and the control logic would then redirect the channel to a new dialplan script.

What's possible with this functionality?

This allows functions like click-to-call with announcement. A computer wants to connect two phones by ringing them both. For speed, it wants to ring them together. It rings them both and provides an announcement/screen IVR to the first to answer. Then, that party can be connected to the channel of the other party, hearing ringback or their voice. Or, there can be announcement to the other party as well, with the two joined only after both have heard announcement. The alternative (call one party, play announcement, then dial 2nd party) connects people far more slowly.

This sort of join is also what's needed by general call park and blind transfer logic.

Finally, it is important for agent queue systems. With an agent queue system, the agent indicates they are ready for a call, and they are connected to the caller. When that caller is done, the agent does not hang up, instead, they are connected to the next caller, possibly with a small announcement or IVR.

This can also be useful for calling card apps and callback, and for simple two-person conference applications. For example, people may be in a multiparty conference room, and wish to break off for a one on one conversation. This could be done by creating a new conference room for just the two of them (at the cost of bandwidth and latency) but is better served with a direct connection. DTMF must be monitored in one direction to allow them to break the 2 person conference, however.