VoIP and telephony basics: how a call path fits together

01 / 05

A phone call has control and media planes

VoIP (Voice over IP) carries phone services over ordinary IP networks instead of dedicated copper lines. SIP commonly negotiates a session — who is calling whom, and which media formats both sides are willing to use — while RTP usually carries the audio itself, and a codec is the specific method used to encode and decode that audio into a stream of bits. DTMF is the touch-tone signal a caller generates by pressing a key, and depending on how the endpoints negotiate it, it can travel as audio, as SIP INFO messages, or as a dedicated RTP payload type.

These four roles interact constantly but are not interchangeable, and confusing them is one of the fastest ways to misdiagnose a call problem: a codec mismatch, a signaling rejection and a one-way-audio NAT issue all feel like "the call is broken" to a caller, but each one needs a completely different fix.

Each call leg needs a compatible codec. Asterisk may translate between different codecs on separate legs when the required translation is available and configured. G.711 is a common codec; inspect the codecs negotiated on each leg when diagnosing audio.

02 / 05

Public numbers and trunks have distinct jobs

A DID (direct inward dial number) is a telephone number a carrier assigns for inbound routing to your system. A trunk is the logical connection to that carrier — the pipe, not the number. A call leg is one side of a bridged call, so an agent's leg, a customer's leg and, during a transfer, a third party's leg can all exist at once, each potentially using a different codec or transport.

None of this requires a live carrier to understand. Draw it on paper first, with no real numbers or credentials anywhere on the page, and the vocabulary will already be familiar the day you configure a real trunk.

A single trunk commonly carries many simultaneous calls, each identified by its own signaling dialogue and its own pair of media streams — the trunk is the relationship with the carrier, not a count of one call at a time, which is why a carrier contract usually limits trunks by a maximum number of concurrent channels rather than by a single fixed line.

03 / 05

Optional lab: read Asterisk's codec table

This no-run preview is optional. After installing and verifying a disposable Asterisk lab, return here and run the exact command below to inspect that build’s codec table; the linked Express lesson does not execute this command.

asterisk -rx 'core show codecs'

04 / 05

Guided sample: write a call-path inventory on paper

Draw the intended path before you ever test a real call: caller, then carrier, then SIP trunk, then Asterisk or VICIdial, then queue, then agent endpoint, with RTP media negotiated directly or indirectly between the two end points. Mark every NAT boundary and firewall on the page so you can check those points when media or signaling fails.

Do this exercise for both directions separately. An outbound call and an inbound call to the same system pass through a different order of components — outbound work starts inside your own dialer's queue of leads to call, while inbound work starts with a DID and an inbound routing group instead — and a diagram that tries to merge both into one arrow hides exactly the detail you need when only one direction is broken.

Inbound: DID -> carrier -> SIP trunk -> Asterisk -> queue -> agentOutbound: agent -> VICIdial campaign -> Asterisk -> trunk -> carrier -> customerMedia: RTP address/port pair negotiated for each call leg

05 / 05

Audio trouble is not always SIP trouble

One-way or choppy audio usually points to the RTP path — an address, a NAT mapping, or a firewall rule — while a call that never connects at all usually points to signaling: credentials, routing, or a policy rejection. Let evidence decide which one you are looking at rather than assuming, because the fix for one looks nothing like the fix for the other.

This lesson deliberately has no capture sample of its own: Asterisk is not installed at this point in the curriculum, and there is no equivalent bare-Linux command that substitutes for asking Asterisk what it knows about codecs. The preview command and the paper worksheet above are the honest ceiling for this stage — the real, captured version of that same command is one of the first things you will run once the ViciBox lab exists.

• I can state what SIP negotiates versus what RTP actually carries.
• I can distinguish a DID from a trunk from a call leg.
• I know this lesson's codec command is a preview — I run it for real in the ViciBox lab, not on a host without Asterisk installed.