Mod loopback will let you loop a call back into the dialplan through the loopback endpoint. As soon as the loopback channel is able to connect two channels together it will disappear as if the two channels had been connected directly.
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.
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 Cdr#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 a 2 second call. OR the exported vars to #4 properly stay there. Test yourself.
'is_loopback' channel variable
As of 6/26/2013, the 'is_loopback' channel variable was added to distinguish between a loopback channel and a non-loopback channel. This is useful for sorting through CDRs. Please note the variable is added during the hangup phase, so it will not be useable except after the channel has ended.
Call Leg Options
See Variable_loopback_bowout_on_execute for more options on how to handle the call legs.
Call a local extension
Example 1: Simple Extension
Would inherit the context and dialplan from the other leg.
Example 2: Extension with context
Would force the context.
Example 3: Extension, context, and dialplan
Would force both the dialplan and context.
Example 4: loopback with 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