What Is a Call Leg? A-Leg vs B-Leg in Programmable Voice

June 16, 2026 · By Piyush Sahoo If you’ve read about call transfers, escalations, or looked at a CDR, you’ve run into terms like A-leg, B-leg, and “transfer the caller leg.” A call leg is one of the most useful concepts in programmable voice, and one of the least explained. This post fixes that: what a leg actually is, the difference between the A-leg and the B-leg, how a single phone call ends up with two (or more) legs, and why the distinction shows up everywhere, in transfers, recordings, billing, and call events.

​

What is a call leg?

A call leg (sometimes just “leg”) is a single, independent connection between the telephony platform and one endpoint, one phone, SIP device, or carrier. Think of the platform as sitting in the middle: every party on the call has their own leg into it. That middle position is the key idea. Modern voice platforms run as a back-to-back user agent (B2BUA): instead of connecting two phones directly, the platform terminates a separate call to each party and then joins those calls in the middle. Each of those separate calls is a leg. At the protocol level, a leg corresponds to a SIP dialog (one INVITE/200 OK/ACK exchange and the media that follows). Because each leg is its own dialog with its own identity, the platform can control them independently, which is exactly what makes voice programmable. A simple way to hold it: a “call” is what the humans experience; “legs” are how the platform actually wires it up. One conversation between two people is usually two legs bridged together.

​

A-leg vs B-leg

In a two-party programmable call, the two legs have conventional names: The A-leg is the side that exists first; the B-leg is the side that gets added to complete the connection. When the B-leg answers, the platform bridges the two legs, audio from the A-leg flows to the B-leg and back, and the two people are talking. Until that bridge happens they’re two separate calls that simply share a session.

​

How a call ends up with two legs

Walk through a typical inbound flow:

1. A customer (+1 415 555 0142) dials your Vobiz number. That inbound call is the A-leg.
2. Vobiz invokes your answer URL; your app returns XML, say a <Dial> to an agent (+1 202 555 0188).
3. Vobiz places a new outbound call to the agent. That’s the B-leg.
4. When the agent picks up, Vobiz bridges the A-leg and B-leg. Now the customer and agent hear each other; the audio rides over both legs through the platform.

An outbound campaign is the mirror image: the call you place to the customer via the Make Call API is the A-leg, and if your flow dials a third party (a human agent, a supervisor), that becomes the B-leg.

​

Parent, child, and conference legs

Because the B-leg is created from the A-leg, platforms model the relationship as parent → child. On Vobiz, the call object exposes parent_call_uuid, which holds the UUID of the A-leg, so a child (B-) leg always knows its parent. This is how you correlate the two halves of one conversation in logs and webhooks. A conference generalizes the idea: instead of one A-leg bridged to one B-leg, each participant has their own leg into a shared room, three participants means three legs, all mixed in the conference rather than directly bridged. (This is also why a conference recording usually can’t cleanly separate every party onto its own channel the way a two-leg call can.)

​

Why call legs matter

The reason “leg” is worth learning is that almost every advanced voice operation is scoped to a leg, not to the whole call:

• Transfers and redirects. You rarely want to move everyone. You transfer the A-leg (send the caller somewhere new while the agent leg ends) or the B-leg (swap the agent without dropping the caller). On Vobiz the Transfer API makes this explicit with legs=aleg (caller), bleg (callee), or both, and when you transfer one leg, the other keeps running its current flow. (See context-aware call transfers.)
• Billing and CDRs. Each leg is metered separately, an inbound A-leg and an outbound B-leg are two different rated segments. Vobiz’s CDR records a per-leg cost, with the originating number and destination per leg, so reconciliation and cost attribution work at leg granularity.
• Recording. Recording the bridge with each party on a separate channel (stereo) only works because the platform sees the A-leg and B-leg as distinct audio sources, which is what makes per-speaker transcription clean. (See call recording APIs.)
• Call events and status. Ring, answer, and hangup events fire per leg, the A-leg can be live while the B-leg is still ringing or has failed. A <Dial> status callback reports how the B-leg ended (completed, busy, no-answer, failed), which is exactly the signal you use to escalate or retry. Hangup causes are likewise per leg (see hangup causes).
• Answering machine detection. AMD runs on the B-leg (the party you dialed), so your agent or message only starts once that leg is confirmed human. (See automated calling & AMD.)

Miss the leg distinction and these all get confusing, “why did my transfer drop the customer?” is almost always “you transferred the wrong leg.”

​

How Vobiz exposes call legs

Vobiz gives you direct, per-leg control:

• Address a leg by UUID. Every leg has its own call_uuid; a child leg references its parent through parent_call_uuid (the A-leg). Pass the UUID of the leg you mean to act on.
• Transfer per leg. POST .../Call/{call_uuid}/ with legs=aleg / bleg / both and a URL per leg redirects exactly the side you intend, leaving the other side untouched unless you choose both.
• Bridge with <Dial>. <Dial> creates and bridges the B-leg from an active A-leg; its action URL reports the B-leg’s outcome so your app can react.
• Per-leg records. The CDR API returns per-leg cost and metadata, so each leg is independently auditable.

Because legs are first-class, you compose transfers, escalations, conferences, and recording flows precisely, on the rails Vobiz provides, without managing raw SIP dialogs yourself.

​

Frequently asked questions

​

Sources

• RFC 3261 — SIP: Session Initiation Protocol (dialogs)
• Back-to-back user agent (B2BUA)
• Vobiz — Transfer a Call · Make Call API · <Dial> · CDR