Call Legs

From FreeSWITCH Wiki
Jump to: navigation, search



Call legs describe active pieces of a call. The connections from a SIP provider to FreeSWITCH or from FreeSWITCH to a OpenZAP channel are examples of a call leg. From FreeSWITCH's point of view, there are legs going to each party of the call. Looking at it that way, call legs could be over-simplified as representing each half of the call.

In FreeSWITCH, each call leg has a UUID that can be used programatically to manipulate the call, or reported on in call detail records.

A leg vs B leg

The terminology of A Leg and B Leg can sometimes be confusing. In the strictest technical sense, the A leg represents ingress to the switch while the B leg represents egress from the switch. In most cases this means that the originator of the call is the A leg and the recipient of the call is the B leg.

One legged calls

Calls that are in an IVR, checking voicemail, etc - ones that don't have an egress leg, are sometime called one legged calls. In this scenario, the switch itself acts as the B leg.

Bridged calls

Once an A leg is connected to a B leg, the channels are bridged. Usually this means that if one leg hangs up the other leg continues with the dialplan (unless it doesn't have any more actions, or a dialplan at all). Bridges can be broken in other ways too (like intercept, or transferring one leg somewhere else, or bridging a leg to something else). Variables that affect what happens to the other leg when the bridge ends include hangup_after_bridge, park_after_bridge and transfer_after_bridge.

Propogating variables from the A leg to the B leg

Sometimes you want to propogate variables from the A leg to the B leg or set new variables there. From the dialplan this can be done via the export command.