Page tree
Skip to end of metadata
Go to start of metadata

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

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

1 Comment

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