VoIP Fundamentals for Call Centers: SIP, Codecs, Trunks and DIDs

Most call center problems that look like software bugs are actually one of five networking concepts being misunderstood. This page covers those five, without vendor marketing.

SIP and RTP are two different things

This is the single most useful thing to understand.

SIP (Session Initiation Protocol) is signalling. It negotiates who is calling whom, whether the call is accepted, what codecs both sides support, and when to hang up. It normally runs on port 5060 (UDP or TCP), or 5061 for TLS.

RTP (Real-time Transport Protocol) carries the actual audio. It runs on a wide range of UDP ports, commonly 10000-20000.

They are separate. This explains the most common failure in VoIP:

The call connects, both sides see it as answered, and neither can hear the other.

SIP got through the firewall. RTP did not. Open the RTP port range, or fix NAT.

The call flow, simplified

Your server                          Carrier
    |                                   |
    |------------ INVITE -------------->|   "I want to call +14155550123"
    |<--------- 100 Trying -------------|
    |<--------- 180 Ringing ------------|   phone is ringing
    |<--------- 200 OK -----------------|   answered
    |------------- ACK ---------------->|
    |                                   |
    |<========= RTP audio =============>|   the actual conversation
    |                                   |
    |------------- BYE ---------------->|   hang up
    |<--------- 200 OK -----------------|

The response codes are worth learning because they tell you exactly what failed:

Codecs decide bandwidth and quality

A codec compresses audio for transmission. The trade-off is bandwidth against quality and CPU.

\* Per direction, with 20ms packetisation, including RTP/UDP/IP and Ethernet headers. Overhead is substantial: G.711's 64 kbps of audio becomes about 87 kbps on the wire because each 20ms packet carries 40 bytes of headers for 160 bytes of audio.

Practical advice: pin your codec explicitly. In Asterisk:

disallow=all
allow=ulaw

Letting the system negotiate freely leads to transcoding, which burns CPU and can degrade audio for no benefit. If your carrier terminates in alaw and your agents speak ulaw, one transcode is unavoidable — but you want to know it is happening.

Trunks, DIDs, and CLI

A SIP trunk is a connection to a carrier over which calls are sent and received. It is not physical. Practically, it is a set of credentials and an IP address, with a channel limit and a rate table attached.

Authentication is either:

• Registration — your server logs in with username and password. Works from dynamic IPs.
• IP authentication — the carrier accepts calls from your fixed IP without a password. More common for volume, and one less credential to leak.

A DID (Direct Inward Dialling number) is a real phone number pointing at your system. You need them for inbound campaigns, and you use them as outbound caller ID. Typically $1-3/month, sometimes with a per-minute inbound charge.

CLI (Calling Line Identity) is the number you present when calling out. Present a number you actually control. Presenting numbers you do not own damages call authentication scores, gets your traffic labelled as spam, and in the US may violate the Truth in Caller ID Act. See DIDs and caller ID reputation.

Number formatting

Most termination problems that produce 404s are formatting problems.

E.164 is the international standard: + then country code then national number, no spaces or punctuation. +14155550123. Many carriers want it without the plus: 14155550123.

The recurring mistake is passing the national format with its trunk prefix — 07700900123 instead of 447700900123. Strip the national prefix, add the country code.

Billing: rate and increment

Two numbers determine your cost, and beginners compare only the first.

The rate is per minute for a destination prefix. Longer prefixes are more specific and win — a rate on 4477 (UK mobile) overrides one on 44 (UK).

The increment is how time is rounded, written as first/subsequent:

On short calls this dominates. An outbound campaign averaging 40-second calls pays 50% more on 60/60 than on 1/1 at the same headline rate. Always compare rate and increment together.

Our public rate directory shows both for every one of 19,172 routes without requiring an account.

NAT: the cause of most audio problems

If your server sits behind a router doing network address translation, SIP breaks in a specific way. SIP messages contain IP addresses inside the message body, and NAT rewrites only the packet headers. The result: your server tells the carrier to send audio to 192.168.1.50, an address the carrier cannot reach.

Symptoms: one-way audio, or audio that stops after 30 seconds.

Fixes, in order of preference:

1. Put the server on a public IP. Eliminates the problem entirely. This is why VPS deployments are simpler than office ones.
2. Configure NAT traversal properly in Asterisk:

externip=203.0.113.45
localnet=192.168.1.0/255.255.255.0
nat=force_rport,comedia

1. Forward the ports — 5060/UDP and your full RTP range.

Avoid SIP ALG. Most consumer routers have a "SIP ALG" feature that attempts to rewrite SIP messages and almost always corrupts them. Turn it off. It is responsible for a remarkable share of unexplained VoIP failures.

Measuring quality

Three numbers determine whether calls sound acceptable:

Note that raw bandwidth is rarely the problem. A stable 10 Mbps connection outperforms a congested 200 Mbps one. Consistency matters more than capacity — see bandwidth and audio quality.

MOS (Mean Opinion Score) condenses these into 1-5. Above 4.0 is good; below 3.5 users complain.

Where to go next

• Bandwidth and audio quality for call centers — sizing and diagnosing your connection.
• ViciDial installation guide — putting these settings into practice.
• DIDs and caller ID reputation — keeping answer rates up.
• How to start a call center with $200 — the wider build.