SIP fundamentals: call flow, SDP, RTP, codecs and NAT

Almost every wholesale VoIP call today is set up with SIP — the Session Initiation Protocol. SIP does not carry the voice itself; it is the signalling that sets up, changes and ends calls. The voice travels separately in RTP packets. Reading SIP confidently is the single most useful technical skill in a VoIP NOC.

SIP in one paragraph

SIP is a text-based request/response protocol, a bit like HTTP. One side sends a request (such as INVITE), the other answers with responses that have three-digit codes. Codes in the 1xx range are provisional (“working on it”), 2xx means success, 3xx redirection, 4xx a client or request problem, 5xx a server problem and 6xx a global failure.

A normal call, step by step

1. INVITE – the calling side asks to set up a call. The request line contains the dialled number, and the body contains an SDP offer describing how the caller wants to receive audio.
2. 100 Trying – the next hop confirms it received the INVITE and is working on it. It stops the sender from retransmitting.
3. 180 Ringing or 183 Session Progress – the destination is being alerted. 180 tells the caller’s side to play its own ringback tone; 183 usually comes with SDP so the caller hears “early media” from the network (ringback, announcements) before answer.
4. 200 OK – the called party answered. It carries the SDP answer. This is the moment billing starts.
5. ACK – the caller confirms it received the 200 OK. The call is now established.
6. RTP – voice packets flow in both directions, directly between the media addresses agreed in SDP.
7. BYE – either side hangs up. The other side replies 200 OK and billing stops.

If a call fails, instead of 200 OK you see a final error response (for example 486 Busy Here), which the caller acknowledges with an ACK. Lesson 9 covers the common error codes.

Headers you will read every day

• Request-URI (in the first line) – the number being called, possibly with a technical prefix added by the sender.
• From / To – caller and called party as presented. The user part of From often carries the caller ID.
• P-Asserted-Identity – a caller identity asserted between trusted networks; many carriers use it for CLI.
• Call-ID – a unique identifier for the call; essential when you ask a partner to investigate.
• Via and Contact – where responses and future requests should go.

SDP: describing the media

The Session Description Protocol body inside INVITE and 200 OK says where to send audio and how to encode it. A minimal example with documentation addresses:

c=IN IP4 192.0.2.10
m=audio 49170 RTP/AVP 18 0 101
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000

The c= line is the IP address for media, m= gives the RTP port and the list of codecs offered in order of preference, and the rtpmap lines name them. Payload 101 here is used for DTMF tones. The answering side picks codecs from the offer and returns its own address and port.

RTP: the voice itself

RTP (Real-time Transport Protocol) carries small packets of audio, typically one packet every 20 milliseconds per direction. Each packet has a sequence number and timestamp, which lets the receiver detect loss and smooth out timing differences (jitter). RTP normally runs over UDP, so lost packets are not resent — for live voice, a late packet is as useless as a lost one.

Codecs: G.711 and G.729

• G.711 (PCMU/μ-law and PCMA/A-law) is uncompressed telephone-quality audio. It uses more bandwidth but gives the best quality and handles fax and tones well. PCMA is common outside North America, PCMU inside it.
• G.729 compresses voice heavily, using much less bandwidth per call. Quality is a little lower and it is less tolerant of packet loss, but it is popular in wholesale because it saves capacity.

Both sides must agree on at least one common codec. If they cannot, the call fails (often with 488 Not Acceptable Here). When one leg uses G.711 and the other G.729, something in the middle must transcode, which costs processing power.

NAT: why audio sometimes goes missing

Many devices sit behind NAT (Network Address Translation): they use a private address internally and a public address on the internet. SIP is awkward with NAT because the private address can end up written inside the SIP headers and SDP. The far end then sends audio to an address it cannot reach, and you get one-way or no audio.

Common fixes include configuring the device to advertise its public address, enabling NAT handling (“media proxy” or “symmetric RTP”) on the softswitch so it sends audio back to where packets actually came from, and making sure firewalls allow the RTP port range. Lesson 9 walks through a one-way audio case.

Practical tips for reading traces

• Always start with the time between INVITE and the first 18x response — that is your post-dial delay.
• Check whether 200 OK came after a 180/183. An answer with no ringing at all deserves a second look (see FAS).
• Compare the SDP addresses with the source addresses of the packets. A mismatch is the classic sign of a NAT problem.
• Keep the Call-ID and timestamps of any call you report to a partner.

Examples in this course use invented names (Vendor X, Customer Y, Country Z) and documentation IP ranges. Menu names and options differ between softswitch versions; always check your own system and vendor documentation.