The Loopback special channel emulates an endpoint to route a call back into the start of the specified dialplan. As soon as the loopback channel is able to connect together the two real channels it will disappear as if the two channels had been connected originally. Note well the cautions about erroneous call detail records, as loopback is only for very limited use cases. If loopback is your first attempt at solving a problem, keep looking elsewhere until you have no alternatives remaining.
Click here to expand Table of Contents
- 1 Usage
- 2 Precautions
- 3 CDR Handling
- 4 Applicable Channel Variables
- 5 Examples
If dialplan and context are omitted, the inherited values from the channel are used. If dialplan is specified, then context must be specified.
Implemented by: mod_loopback
Please take extra precautions in regard to CDR records. They may not display the information you are looking for after a call has been bridged through the loopback endpoint. Using the loopback channel requires extra dialplan programming and post-call processing to ensure that you get all the desired call detail data needed for billing and reporting. Be careful with using proxy media or T.38 pass-through (this is not supported with loopback/ channels).
- Call comes in, that's the A leg. (#1 - defaults to Leg *B*, see Putting Together CDRs)
- It creates a B loopback leg to handle the routing (#2 - default to leg B)
- That gets connected to a new leg that traverses the dial plan accordingly (#3 - default to leg A)
- If you bridge, then we have a new leg, too. (#4 - defaults to leg B.)
Once the call connects, after 1-2 seconds #2 and #3 drop out, with a billsec of about 2 seconds.
If you do billing on leg B of the initial call, then your billing will be for only a 2 second call. OR the exported vars to #4 properly stay there. Test extensively before committing to production mode.
Applicable Channel Variables
boolean A variable added during the hangup phase that distinguishes loopback channels from real channels. This is useful for processing CDRs.
is_loopback was made available as of 6/26/2013
this variable is only available after the channel has ended.
boolean Set to
true to have one-legged loopback channels "bow out" (remove the loopback legs) of the call.
loopback_bowout_on_execute is only useful to single leg calls. You never have to set it:
true by default. It tries to remove loopback by doing uuid_bridge.
loopback_bowout=false, a bridged loopback call results in 4 legs (a-leg, loopback-a, loopback-b, b-leg).
loopback_bowout=true, a bridged loopback call results in 2 legs (a-leg, b-leg).
During the call setup phase even with
loopback_bowout=true there will always be 4 legs, however. loopback-a and loopback-b will be destroyed when a-leg and b-leg are successfully bridged.
<action application="set" data="loopback_bowout_on_execute=true"/>
string A list of channel variables to pass from loopback-a to loopback-b.
Would inherit the context and dialplan from the other leg.
Extension With Context
Would force the default context.
Extension, Context, and Dialplan
Would force both the dialplan and context.
A-leg Inline Dialplan
originate loopback/set:job=1234\,answer\,park/default/inline lua:loop.lua inline
|Not confirmed, but if you are trying to use hangup_after_bridge=false with a call to a loopback endpoint, you likely need to set loopback_bowout=false on the call - otherwise it seems to not take effect. Posted by nneul at Mar 28, 2017 10:18|