How telephony works in LiveKit

Your dental receptionist from Course 1.1 works beautifully over WebRTC in a browser. But your patients are not going to open a web app to schedule a cleaning -- they are going to pick up a phone and dial a number. In this chapter, you will learn how LiveKit bridges the century-old phone network into modern WebRTC rooms so your AI agent can answer real phone calls without a single line of telephony code.

What you'll learn

• How the SIP protocol works at a high level (signaling vs media)
• How LiveKit bridges phone calls into rooms as SIP participants
• Why your agent does not need to know it is talking to a phone
• The full architecture from phone network to AI agent

SIP: the protocol that powers phone calls

SIP -- Session Initiation Protocol -- is the standard protocol for initiating, managing, and terminating voice calls over IP networks. When you make a phone call today, SIP is almost certainly involved somewhere in the chain, even if the first hop is still analog.

SIP handles two distinct concerns:

Signaling -- the control plane. SIP messages set up and tear down calls. "I want to call this number." "Ringing." "Answered." "Hang up." These are text-based messages (similar to HTTP) that negotiate the call parameters: who is calling whom, what audio codecs to use, where to send media. Signaling does not carry any voice audio.

Media -- the data plane. Once SIP signaling establishes a call, the actual voice audio flows over RTP (Real-time Transport Protocol). RTP packets carry the encoded audio between endpoints. Media and signaling travel on separate paths -- signaling might go through multiple SIP proxies while media flows directly between endpoints.

The bridge: PSTN to LiveKit Room

Here is the full path a phone call takes to reach your AI agent:

The architecture looks like this:

ParticipantKind.SIP: a phone caller in the room

When a phone caller enters a LiveKit Room through the SIP bridge, they appear as a Participant with kind set to ParticipantKind.SIP. This is the only difference between a phone caller and a WebRTC caller from your agent's perspective.

Your agent code from Course 1.1 works without modification. The AgentSession receives audio from the caller's Track, transcribes it, sends it to the LLM, synthesizes the response, and publishes it back. Whether that audio came from a browser microphone over WebRTC or from a phone over SIP/RTP is invisible to your application logic.

You can detect that a caller is on the phone if you need to adapt behavior:

from livekit import rtc

for participant in session.room.remote_participants.values():
  if participant.kind == rtc.ParticipantKind.PARTICIPANT_KIND_SIP:
      # This participant is on a phone
      print(f"Phone caller: {participant.identity}")

import { ParticipantKind } from "@livekit/rtc-node";

for (const participant of session.room.remoteParticipants.values()) {
if (participant.kind === ParticipantKind.SIP) {
  // This participant is on a phone
  console.log(`Phone caller: ${participant.identity}`);
}
}

In practice, you rarely need this check. Your dental receptionist greets everyone the same way, checks availability the same way, and books appointments the same way regardless of how the caller connected.

What changes with phone callers

While your agent code stays the same, there are a few practical differences to be aware of when callers are on phones:

Audio quality -- Phone audio defaults to narrowband codecs like G.711 (8kHz sampling rate) rather than Opus (48kHz). This means the STT model receives lower-fidelity audio. You will learn how to upgrade to HD voice in Chapter 6.

No visual interface -- Phone callers cannot see buttons, forms, or screen shares. Any interaction must be voice-only or use DTMF keypad tones (Chapter 5).

Caller identity -- Phone callers are identified by their phone number (E.164 format like +15559876543) rather than a username or email. This appears in the Participant's attributes.

Call control -- Phone-specific actions like transfers, hold, and hang-up use SIP-specific APIs rather than WebRTC track controls.

SIP deep dive: what is actually on the wire

Understanding SIP at the protocol level is not strictly necessary for building voice agents, but it is invaluable when things go wrong. When calls fail to connect, audio is one-way, or quality degrades, the answers are in the SIP messages and RTP streams. This section gives you the vocabulary and tools to diagnose telephony issues.

SIP message anatomy

SIP is a text-based protocol, structurally similar to HTTP. A SIP message has a request line (or status line), headers, and an optional body. Here is a simplified SIP INVITE — the message that initiates a call:

INVITE sip:+15551234567@sip.livekit.io SIP/2.0
Via: SIP/2.0/UDP 203.0.113.10:5060;branch=z9hG4bK776asdhds
From: "Patient" <sip:+15559876543@trunk.twilio.com>;tag=1928301774
To: <sip:+15551234567@sip.livekit.io>
Call-ID: a84b4c76e66710@203.0.113.10
CSeq: 314159 INVITE
Contact: <sip:+15559876543@203.0.113.10:5060>
Content-Type: application/sdp
Content-Length: 142

v=0
o=- 2890844526 2890844526 IN IP4 203.0.113.10
s=-
c=IN IP4 203.0.113.10
t=0 0
m=audio 49170 RTP/AVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 opus/48000/2

Key parts to understand:

The SDP (Session Description Protocol) body is where codec negotiation happens. The caller offers codecs it supports; the answering side responds with the codecs it accepts. If your trunk offers only G.711 and your LiveKit config prefers Opus, the response SDP will reflect the negotiated choice.

The SIP call flow

A successful inbound call follows this exchange:

Caller (Trunk)              LiveKit SIP Bridge
   |                              |
   |------- INVITE (SDP offer) -->|  "I want to call +15551234567"
   |                              |
   |<------ 100 Trying -----------|  "Working on it"
   |                              |
   |<------ 180 Ringing ----------|  "Ringing the destination"
   |                              |
   |<------ 200 OK (SDP answer) --|  "Call accepted, here are my media params"
   |                              |
   |------- ACK ----------------->|  "Got it, let's talk"
   |                              |
   |<======= RTP audio =========>|  Bidirectional audio flows
   |                              |
   |------- BYE ----------------->|  "Hanging up"
   |                              |
   |<------ 200 OK ---------------|  "Goodbye acknowledged"
   |                              |

This is the "happy path." When debugging, you are looking for where this flow breaks down:

• No 100 Trying: LiveKit is not receiving the INVITE — check network connectivity, DNS, and firewall rules (SIP uses port 5060 for UDP/TCP, 5061 for TLS).
• 408 Request Timeout: INVITE was sent but no response — the SIP bridge may be unreachable.
• 403 Forbidden: Authentication failure — check trunk credentials and IP allowlisting.
• 404 Not Found: The dialed number does not match any configured trunk — verify the number in your trunk config matches exactly (E.164 format).
• 488 Not Acceptable Here: Codec negotiation failed — the caller and LiveKit could not agree on a common codec. Check allowed_codecs on your trunk.
• 503 Service Unavailable: The SIP bridge is overloaded or down — check LiveKit service status.

Capturing and reading SIP traffic with pcaps

When Cloud Insights is not enough — when you need to see the raw protocol exchange — packet captures (pcaps) are the definitive debugging tool. A pcap file captures every network packet, letting you reconstruct the exact SIP messages and RTP streams.

Capturing with tcpdump

# Capture SIP signaling on port 5060 (save to file for analysis)
sudo tcpdump -i any -s 0 -w sip-debug.pcap port 5060

# Capture both SIP signaling and RTP media
sudo tcpdump -i any -s 0 -w full-call.pcap "port 5060 or portrange 10000-60000"

# Filter to a specific trunk provider IP
sudo tcpdump -i any -s 0 -w trunk-debug.pcap host 54.172.60.0 and port 5060

# Capture TLS-encrypted SIP on port 5061
sudo tcpdump -i any -s 0 -w sip-tls.pcap port 5061

Analyzing with Wireshark

Open the pcap in Wireshark and use its SIP/RTP analysis tools:

1. Open sip-debug.pcap in Wireshark
2. Filter: "sip" to see only SIP messages
3. Telephony → SIP Flows — shows the complete call ladder diagram
4. Select an INVITE → inspect the SDP body for codec offers
5. Select the 200 OK → inspect the SDP answer for negotiated codecs
6. Filter: "rtp" to see media packets
7. Telephony → RTP → RTP Streams — shows jitter, packet loss, codec in use
8. Telephony → RTP → RTP Stream Analysis — graphs jitter over time

What to look for in Wireshark:

Using sngrep for live SIP debugging

For quick SIP debugging without capturing full pcaps, sngrep provides a real-time terminal UI for SIP traffic:

# Install sngrep
# Debian/Ubuntu: sudo apt install sngrep
# macOS: brew install sngrep

# Watch live SIP traffic
sudo sngrep

# Filter to a specific call
sudo sngrep -d any -c "INVITE"

# Watch only traffic to/from your trunk provider
sudo sngrep -d any host 54.172.60.0

sngrep shows the SIP ladder diagram in real time — you can see INVITEs, responses, and BYEs as they happen. It is faster than capturing a pcap when you just need to verify that signaling is flowing correctly.

Common telephony debugging scenarios

Scenario: Calls ring but agent never answers

Scenario: Audio works in one direction only

One-way audio is almost always a NAT or firewall issue. The SDP body in the INVITE and 200 OK contains the IP addresses and ports for RTP media. If one side advertises a private IP (e.g., 192.168.x.x) that the other side cannot reach, audio flows only in the direction where the address is routable.

Scenario: Poor audio quality (choppy, robotic, dropping)

What you learned

• SIP is the protocol that sets up phone calls (signaling) while RTP carries the actual voice audio (media)
• LiveKit's SIP bridge translates between the phone network and WebRTC rooms
• Phone callers appear as Participants with ParticipantKind.SIP -- your agent code needs no changes
• The full path is: Phone -> PSTN -> SIP Trunk Provider -> LiveKit SIP Bridge -> Room -> Agent
• Practical differences include audio quality, no visual interface, and phone-number-based identity
• SIP messages are text-based (like HTTP) with an SDP body that negotiates codecs and media addresses
• Use tcpdump to capture pcaps and Wireshark to analyze them — look at SIP flows, SDP bodies, and RTP stream quality
• Use sngrep for quick real-time SIP debugging in the terminal
• Common issues (one-way audio, no audio, codec mismatches) are diagnosed by examining SDP addresses and RTP streams

Next up

In the next chapter, you will get a real phone number, configure an inbound SIP trunk, and point it at LiveKit so calls can start flowing into your rooms.