Skip to main content

Loopback Endpoint

About​

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

Usage​

loopback/<exten>[/context[/dialplan]]

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

Precautions​

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).

CDR Handling​

  • 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​

is_loopback​

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

(warning) this variable is only available after the channel has ended.

loopback_bowout_on_execute​

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: loopback_bowout is true by default. It tries to remove loopback by doing uuid_bridge.

When setting loopback_bowout=false, a bridged loopback call results in 4 legs (a-leg, loopback-a, loopback-b, b-leg).

When setting 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.

Usage

<action application="set" data="loopback_bowout_on_execute=true"/>

loopback_export​

string A list of channel variables to pass from loopback-a to loopback-b.

loopback_leg​

string

other_loopback_leg_uuid​

string

Examples​

Registered Extension​

loopback/1000

Would inherit the context and dialplan from the other leg.

Extension With Context​

loopback/1000/companyA

Would force the default context.

Extension, Context, and Dialplan​

loopback/1000/companyA/XML

Would force both the dialplan and context.

A-leg Inline Dialplan​

originate loopback/set:job=1234\,answer\,park/default/inline lua:loop.lua inline

Executes set app, then answer app, then park app on the B leg then bridges to the Lua app on the A leg

Comments:​

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