DEV Community: SIP GAMES

🛠️ RTCP - The RTP Caretaker

SIP GAMES — Sat, 04 Oct 2025 12:36:14 +0000

So far in our series we have discussed RTP: The Voice Courier and how it is crucial for carrying voice and video. But how do we know if those packets are arriving on time, or if the call quality is suffering?

Introducing RTCP (Real-Time Control Protocol). While RTP carries voice or video, RTCP monitors quality, synchronizes streams, and reports stats like jitter, packet loss, and delay. Defined in RFC 3550 (the same spec as RTP), RTCP is the control plane for RTP streams.

🧩 What is RTCP?

RTP sends the media stream (voice, video, etc.).
RTCP sends control and quality feedback alongside RTP.

👉 Together, they make a complete real-time transport framework.

🎯 Why RTCP Exists?

Quality Feedback → Reports on packet loss, jitter, delay
Synchronization → Aligns RTP streams (e.g., audio & video) using NTP + RTP timestamps
Participant Identification → Each SSRC gets a unique ID so you know who’s who
Scalability → Bandwidth control ensures RTCP doesn’t eat into RTP’s share

RTCP packets travel periodically (every few seconds) to:

Report on packet loss, jitter, and round-trip time (RTT).
Provide sender statistics (how many RTP packets were sent).
Carry source descriptions (like CNAMEs for sync).
Enable feedback mechanisms (NACK, picture loss indication, etc.).

🔍 RTCP in the Protocol Stack

Protocol Stack
Application Signaling (SIP/SDP)
RTCP (control, reporting) / RTP (media transport)
Transport (UDP / DTLS)
IP

RTP: Media stream
RTCP: Control/feedback stream
Both usually run on adjacent UDP ports

📦 RTCP Packet Structure

Every RTCP packet starts with a common header:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Count | Packet Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

V (2 bits): Protocol version (always 2).
P (1 bit): Padding.
Count (5 bits): Varies by packet type (e.g., number of reports).
Packet Type (PT): Identifies RTCP message type.
Length: Length of this RTCP packet in 32-bit words.

📑 Types of RTCP Messages

RTCP defines multiple packet types, each with a specific purpose.

1. Sender Report (SR) – PT=200

Sent by active senders.
Contains:
- NTP timestamp (wall clock).
- RTP timestamp (media clock).
- Count of packets/bytes sent.
Used for synchronization and quality monitoring.

2. Receiver Report (RR) – PT=201

Sent by receivers.
Contains:
- Packet loss percentage.
- Jitter.
- Last SR timestamp and delay.
Gives feedback to the sender about stream quality.

3. Source Description (SDES) – PT=202

Provides metadata about streams.
Example: CNAME, name, email, tool used.

4. BYE – PT=203

Indicates end of participation.
Graceful “leaving the game.”

5. APP – PT=204

Application-specific RTCP extensions.
Rare, custom use cases.

6. Extended Reports (XR)

Defined later to carry detailed stats (e.g., round-trip delay, burst metrics).

7. Feedback Messages (RTP/AVPF extensions)

NACK (Negative ACK) → Request retransmission.
PLI (Picture Loss Indication) → Request a new video keyframe.
FIR (Full Intra Request) → Force a full intra-frame.

🛠️ Real RTCP Packet Example

Let’s look at a real RTCP Sender Report (SR) packet captured with Wireshark:

0000 81 c8 00 06 12 34 56 78 00 00 01 63 89 ab cd ef
0010 11 22 33 44 00 00 27 10 00 00 09 f6 00 00 00 01
0020 5e f6 7a 2c 00 00 00 00

📖 Field Breakdown

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P=0|RC=1| PT=200 (SR) | length=6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

81 c8 00 06
- V=2 → RTP version 2
- P=0 → No padding
- RC=1 → 1 report block will follow
- PT=200 → Packet Type = SR (Sender Report)
- length=6 → This RTCP packet is 7 words (28 bytes) long

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

12 34 56 78 → SSRC = 0x12345678 (unique sender identifier)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

00 00 01 63 89 ab cd ef → NTP timestamp
- High 32 bits: 0x00000163
- Low 32 bits: 0x89abcdef
- Used to sync RTP streams to real wall-clock time

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

11 22 33 44 → RTP timestamp = 0x11223344
- Media timestamp used for jitter calculation and sync with NTP

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's packet count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's octet count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

00 00 27 10 → Sender’s packet count = 10000 packets
00 00 09 f6 → Sender’s octet count = 2550 bytes

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report Block (for one source) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

00 00 00 01 5e f6 7a 2c 00 00 00 00
- SSRC=0x00000001 (source being reported)
- Fraction lost, cumulative lost, extended highest seq received, jitter, and delay since last SR

🧩 Why This Matters

This single RTCP packet tells us:

Who the sender is (SSRC)
When media was sent (NTP + RTP timestamps)
How much was sent (packet & octet counts)
How the receiver is doing (loss/jitter stats from the report block)

Together, SRs and RRs form the control loop that makes RTP reliable for real-time communication.

🎮 Real Life Examples

Monitoring Voice Call Quality
- RTCP RRs reveal packet loss % and jitter.
- VoIP monitoring tools (like Wireshark) use these stats.
Video Call Resync
- Receiver sends PLI when frames are corrupted.
- Sender reacts by sending a new keyframe.
Conference Systems
- SRs synchronize multiple media streams (audio + video).

🔗 Port Usage

Traditionally:

RTP uses port N.
RTCP uses port N+1.

But in practice:

RTCP Mux (RFC 5761): RTP and RTCP share the same port to save resources (common in WebRTC).
Bundle (RFC 8843): Multiple media streams (audio, video, data) share a single 5-tuple (IP, port pair).

👉 Why?

NAT/firewall traversal is easier.
Fewer ports to manage.
Cleaner for ICE/STUN/TURN usage.

📝 Quick RTCP Reference Table

PT	Message	Purpose
200	Sender Report	Stats from sender + sync
201	Receiver Report	Feedback on quality from receiver
202	Source Description	Metadata (CNAME, user, tool)
203	BYE	End participation
204	APP	Application specific
XR	Extended Reports	Detailed metrics
NACK	Feedback	Retransmission request
PLI	Feedback	Request video keyframe
FIR	Feedback	Request full intra-frame

🏁 Wrap Up

RTP carries the voice/video. RTCP monitors it.
With reports, feedback, and metadata, RTCP keeps the real-time flow honest.
In modern deployments, RTCP-mux and Bundle simplify port usage.

RTCP is the quiet referee in the SIP Games — not in the spotlight, but making sure everything runs fair. ⚖️

🎮 Thanks for playing another round of SIP Games!

👉 Follow @sip_games to unlock the next level.

💬 Presence, Messaging, and Subscriptions - It's that SIMPLE

SIP GAMES — Mon, 22 Sep 2025 17:04:24 +0000

Our SIP journey has focused mostly on calls (INVITE, ACK, BYE, RTP…). But SIP is more than just voice.

SIP SIMPLE is an extension framework that enables instant messaging, presence, and event notifications over SIP. This article introduces SIP SIMPLE, explains why it was created, and walks through some example scenarios.

🧩 What is SIP SIMPLE?

SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) is a set of SIP extensions defined by multiple RFCs.

It was designed to make SIP more than a “phone call protocol” — by adding:

Presence → Is a user available, busy, offline?
Subscriptions → Letting clients subscribe to events.
Messaging → Sending short instant messages over SIP.

🛠️ SIP Requests in SIMPLE

SIMPLE reuses existing SIP request methods and adds new ones:

SUBSCRIBE → Client subscribes to presence/events.
NOTIFY → Server notifies subscriber of updates (e.g., presence change).
MESSAGE → Instant messaging.
PUBLISH → User publishes their own presence state.

👀 Presence with SIMPLE

Presence is about letting others know your status.

Example flow:

Watcher (UA A).       Presence Server

 SUBSCRIBE (presence of B) -------->
 <--------------------------- 200 OK
 <--------------- NOTIFY (B=offline)
                 ...
 <---------------- NOTIFY (B=online)

UA A (Watcher) sends SUBSCRIBE to the server for UA B’s presence.
The Presence Server responds with 200 OK and then NOTIFYs updates as B’s status changes.

SUBSCRIBE sip:bob@example.com SIP/2.0
From: sip:alice@example.com;tag=1111
To: sip:bob@example.com
Call-ID: pres-1234@example.com
CSeq: 1 SUBSCRIBE
Event: presence
Expires: 3600

NOTIFY

NOTIFY sip:alice@example.com SIP/2.0
From: sip:bob@example.com;tag=2222
To: sip:alice@example.com;tag=1111
Call-ID: pres-1234@example.com
CSeq: 2 NOTIFY
Event: presence
Subscription-State: active
Content-Type: application/pidf+xml

<presence entity="sip:bob@example.com">
<tuple id="t1">
<status>
<basic>open</basic>
</status>
</tuple> >
</presence>

💬 Messaging with SIMPLE

SIP SIMPLE also defines MESSAGE, a lightweight request for sending instant messages.

Unlike MSRP (Message Session Relay Protocol, used for large chat/file sessions), MESSAGE is page-mode messaging — think SMS-like.

Example Flow

UA A                           UA B

 MESSAGE "Hi Bob!"  ------------->
 <------------------------- 200 OK

MESSAGE

MESSAGE sip:bob@example.com SIP/2.0
From: sip:alice@example.com;tag=aaaa
To: sip:bob@example.com
Call-ID: msg-5555@example.com
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 7

Hello!

📡 PUBLISH presence with SIMPLE

SIP PUBLISH is how a user tells the network “here’s my current status” — online, busy, or away.

Think of PUBLISH as posting a status update in SIP — presence servers read it, watchers get notified.
PUBLISH doesn’t go peer-to-peer; it’s a signal to the presence server, which relays the info.
Each PUBLISH comes with an Expires — like saying “I’m online for the next 30 mins unless I update.”
With PUBLISH, SIP users share context (chat-ready, in a call, do-not-disturb) across the network.

Example Flow

Presentity (UA B)          Presence Server

 PUBLISH (I'm online)   ---------------->
 <-------------------------------- 200 OK

          NOTIFY all subscribers
        ( Server tells watchers )
 <-------------------------------- NOTIFY

PUBLISH sets the status.
The server distributes updates via NOTIFY to watchers.

PUBLISH

PUBLISH sip:presence.example.com SIP/2.0
Via: SIP/2.0/UDP alicepc.example.com;branch=z9hG4bK776sgdkse
Max-Forwards: 70
From: "Alice" <sip:alice@example.com>;tag=1928301774
To: <sip:alice@example.com>
Call-ID: a84b4c76e66710@alicepc.example.com
CSeq: 314159 PUBLISH
Contact: <sip:alice@alicepc.example.com>
Event: presence
Expires: 3600
Content-Type: application/pidf+xml
Content-Length: 178

<presence xmlns="urn:ietf:params:xml:ns:pidf"entity="sip:alice@example.com">
<tuple id="t123">
<status>
<basic>open</basic>
</status>
<note>Available for chat</note>
</tuple>
</presence>

⚔️ SIMPLE vs XMPP Presence

XMPP (Extensible Messaging and Presence Protocol) was designed from the ground up for chat and presence.

👉 dedicated protocol for messaging ecosystems.

SIP SIMPLE was created for environments that already used SIP, to avoid running a completely separate protocol for messaging/presence.

👉 extend what you already have in SIP networks.

Presence workflow comparison

+---------------------------+  +----------------------------+
|        SIP SIMPLE         |  |           XMPP             |
+---------------------------+  +----------------------------+
| UA A (Watcher)            |  | Client A                   |
|   SUBSCRIBE presence ---->|  |   <presence to="server">   |
|                           |  |--------------------------->|
| Presence Server           |  | XMPP Server                |
|   200 OK ---------------->|  |   Routes to B’s roster     |
|   NOTIFY (offline/online)>|  |   Broadcast presence       |
|                           |  |<---------------------------|
| UA A learns status        |  | Client B status to A       |
+---------------------------+  +----------------------------+

SIMPLE → Presence is explicitly subscribed and managed with SUBSCRIBE/NOTIFY.
XMPP → Presence is broadcast automatically by the server when a client’s status changes.

🎬 Real-world SIMPLE scenario

Alice subscribes to Bob’s presence, learns when he comes online, and then sends him a message.

Alice (Watcher)            Presence Server                Bob (Presentity)
--------------------------------------------------------------------------
 SUBSCRIBE (presence of Bob) ------->
 <---------------------------- 200 OK
 <-------------- NOTIFY (Bob=offline)


                                     <------------------ PUBLISH (online)
                                     200 OK ---------------------------->
 <--------------- NOTIFY (Bob=online)

 MESSAGE "Hey Bob!" ---------------------------------------------------->
 <---------------------------------------------------------------- 200 OK

Alice subscribes to Bob’s presence.
Initially, Bob is offline.
Later, Bob publishes “I’m online.”
The server notifies Alice that Bob is now online.
Alice sends a MESSAGE.

🏁 Wrap Up

SIP SIMPLE Request Messages

Request	Purpose
SUBSCRIBE	Ask to follow an event (e.g. presence)
NOTIFY	Deliver updates to subscribers
MESSAGE	Send a short IM
PUBLISH	Publish own state (presence info)

SIP SIMPLE turns SIP into more than a voice protocol.
It enables presence, messaging, and subscriptions using standard SIP transactions.
SIMPLE shines in SIP-native environments but is less common than XMPP or modern WebRTC chat solutions.
SIMPLE builds on SIP’s event notification framework (RFC 3265).
Apart from presence, SUBSCRIBE/NOTIFY can track:
- Message-summary → Voicemail indicators (MWI)
- Conference state
- Registration state

👉 Follow @sip_gamesto unlock the next level.

🤔 VoIP NAT Traversal – Getting Through the Maze

SIP GAMES — Thu, 04 Sep 2025 16:56:01 +0000

If you have ever tried setting up VoIP calls over the internet, you have probably run into the NAT wall.

Packets go out and somehow don’t come back. SIP signaling breaks, RTP streams vanish, and you’re left staring at dead air.

This article explores NAT traversal in SIP and RTP: why NAT complicates things, what types of NAT exist, and how tools like STUN, TURN, and ICE help us get calls working.

🌐 Quick Primer: What is NAT?

NAT (Network Address Translation) allows multiple devices on a private network to share a single public IP.

Problem? SIP and RTP are peer-to-peer by design, and they often embed private IPs inside signaling (SIP/SDP).

The outside world can’t route to 192.168.x.x.

🧩 Types of NAT

Different NAT behaviors affect how easily SIP/RTP can traverse:

Type of NAT	Behavior
Full Cone NAT	Any external host can send to mapped port
Restricted Cone NAT	Only hosts previously contacted can reply
Port Restricted Cone	Same as above but also checks source port
Symmetric NAT	New mapping for each destination

👉 Symmetric NAT is the hardest for VoIP — it breaks simple hole punching.

☎️ Navigating SIP Through NAT

SIP headers often carry contact addresses that may be private (e.g., Contact: sip:alice@192.168.1.10).

If the proxy or callee tries to respond there — 💥 call fails.

Key SIP Helpers:

rport (RFC 3581): Client adds rport to Via → Server responds back to the source port, not the private IP in the header. Example:

Via: SIP/2.0/UDP 192.168.1.10:5060;branch=z9hG4bK123;rport

Contact rewriting (NAT-aware SBCs): SIP servers (B2BUA/SBC) may rewrite Contact headers to reflect the public IP/port.

🎶 Navigating RTP Through NAT

RTP streams face the same NAT issues:

SDP offers may contain private IP addresses (e.g., c=IN IP4 192.168.1.10).
Even if SIP signaling connects, media won’t flow.

Solution → ICE Framework

ICE (Interactive Connectivity Establishment) gathers multiple candidates (possible addresses) and tries them in priority order.

Types of candidates:

Host candidates → Direct local IPs
Server reflexive → From STUN server (public-facing IP/port)
Relay candidates → Allocated via TURN server (media relay)

❄️ STUN: Simple Traversal of UDP

STUN lets a client discover its public IP/port as seen by a server.

It works well with cone NATs.

Example: SDP with STUN candidates

a=candidate:1 1 UDP 2130706431 192.168.1.10 54400 typ host
a=candidate:2 1 UDP 1694498815 203.0.113.45 60000 typ srflx raddr 192.168.1.10 rport 54400

Candidate 1: Local private address (host)
Candidate 2: Public IP/port discovered via STUN (server reflexive)

Trickle ICE

Instead of sending all candidates upfront, clients can send them as they’re found. Speeds up call setup.

🌀 TURN: Traversal Using Relays

When NAT is symmetric or firewalls block UDP, STUN fails.

That’s where TURN steps in — media is relayed through a public TURN server.

Higher latency and resource cost.
Guaranteed connectivity fallback.

🔗 STUN Binding in RTP Setup

When RTP starts, peers send STUN Binding Requests over the selected candidate pair.

This validates the path and confirms bidirectional connectivity.

Caller (UA A)                     Callee (UA B)

- Send STUN Binding ------------> Respond Binding OK
<---------------:- STUN Binding - Respond Binding OK

Once validated, RTP media flows over that same path.

📜 Example: SIP INVITE with ICE Candidates

Here’s what a NAT-traversed SIP INVITE might look like when a UA (behind NAT) sends an offer using ICE with STUN:

INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.10:5060;branch=z9hG4bK1234;rport
Max-Forwards: 70
From: "Alice" sip:alice@example.com;tag=1928301774
To: sip:bob@example.com
Call-ID: a84b4c76e66710@192.168.1.10
CSeq: 314159 INVITE
Contact: sip:alice@203.0.113.45:60000
Content-Type: application/sdp
Content-Length: 420

v=0
o=alice 2890844526 2890844526 IN IP4 192.168.1.10
s=-
c=IN IP4 192.168.1.10
t=0 0
m=audio 54400 RTP/AVP 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 opus/48000/2
a=ice-ufrag:8hhY
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=candidate:1 1 UDP 2130706431 192.168.1.10 54400 typ host
a=candidate:2 1 UDP 1694498815 203.0.113.45 60000 typ srflx raddr 192.168.1.10 rport 54400
a=end-of-candidates

🔎 Breaking it Down

SIP Headers
- Via + rport: Ensures responses come back through the NAT’s mapped port.
- Contact: Rewritten (or discovered via STUN/SBC) to include the public IP:port.
- Call-ID, From tag, To tag: Tie requests and responses into the same dialog.
SDP Offer
- m=audio 54400 RTP/AVP 0 96: Proposes an RTP stream at port 54400 with codecs G.711 (0) and Opus (96).
- a=ice-ufrag + a=ice-pwd: ICE credentials used to authenticate connectivity checks.
- a=candidate:1 typ host: Local private address (192.168.1.10:54400).
- a=candidate:2 typ srflx: Public server-reflexive candidate discovered via STUN (203.0.113.45:60000).
- a=end-of-candidates: Marks candidate gathering complete.
How This Works
1. Alice sends the INVITE with both private and public candidates.
2. Bob replies with his own candidates in the 200 OK SDP.
3. Both sides perform STUN Binding requests across candidates.
4. The best working path (host → srflx → relay) is selected.
5. RTP flows over the chosen pair.

📌 In practice:

If Alice and Bob are both behind cone NAT, the server-reflexive (STUN) candidate usually works.
If either side is behind symmetric NAT, ICE will fall back to TURN relay.
This all happens automatically once ICE/STUN/TURN are implemented by the SIP stack or media engine.

🏁 Wrap Up

SIP needs help (rport, Contact rewriting, SBCs) to work behind NAT.
RTP needs ICE → STUN for discovery, TURN for relaying.
STUN binding checks ensure the media path is alive.
Symmetric NAT remains the final boss, and TURN is the safety net.

👉 Follow @sip_games for the next level.

🎯 SIP Responses: Talking Back

SIP GAMES — Wed, 20 Aug 2025 14:08:35 +0000

In the previous round, we explored SIP Requests — the moves you make to start, manage, and end a SIP session. But what happens when your move lands?

That’s where SIP Responses come in. Every request gets an answer. Some are good, some bad, and some just say, "Hold up, we’re thinking about it."

This post will cover:

Categories of SIP responses (1xx → 6xx).
How to interpret them.
Examples for quick understanding.
A handy response code reference table.
How unique identifiers (tags, Call-ID) tie requests and responses together.
How SIP timers behave with responses.

🧩 SIP Response Categories

SIP responses follow a status code system (like HTTP, but SIP-flavored).

🔹 1xx: Provisional Responses

These don’t finish the transaction. They’re progress updates.
Examples:
- 100 Trying → “Got your request, working on it.”
- 180 Ringing → “User is being alerted.”
- 183 Session Progress → “Here’s early media info.”

🔹 2xx: Success Responses

Everything went fine.
Examples:
- 200 OK → The Swiss Army knife of SIP. Success for INVITE, BYE, REGISTER, etc.
- With INVITE, it establishes the dialog (when To-tag is set).

🔹 3xx: Redirection Responses

The called party isn’t here, but they suggest where to go.
Examples:
- 302 Moved Temporarily → “Try this other address.”

🔹 4xx: Client Error Responses

Something’s wrong with the request. Caller must fix it.
Examples:
- 400 Bad Request → Syntax or formatting error.
- 401 Unauthorized → Challenge for authentication (with WWW-Authenticate).
- 404 Not Found → User not registered / unknown.
- 415 Unsupported Media Type → Codec/SDP mismatch.

🔹 5xx: Server Error Responses

The server understood the request but failed to process it.
Examples:
- 500 Server Internal Error → General failure.
- 503 Service Unavailable → Overloaded or temporarily down.

🔹 6xx: Global Failure Responses

Final “no” that applies everywhere.
Examples:
- 603 Decline → Callee doesn’t want to talk.
- 606 Not Acceptable → Callee’s capabilities don’t match caller’s request.

📊 SIP Response Code Reference Table

Here’s a quick reference for the most common responses:

Code	Category	Meaning
100	Provisional	Trying
180	Provisional	Ringing
183	Provisional	Session Progress (early media)
200	Success	OK
202	Success	Accepted (rare in INVITE, more in SUB)
302	Redirection	Moved Temporarily
400	Client Error	Bad Request
401	Client Error	Unauthorized
403	Client Error	Forbidden
404	Client Error	Not Found
415	Client Error	Unsupported Media Type
480	Client Error	Temporarily Unavailable
486	Client Error	Busy Here
500	Server Error	Internal Server Error
503	Server Error	Service Unavailable
603	Global Failure	Decline
606	Global Failure	Not Acceptable

🏷️ How IDs Tie It Together

Remember from our last post:

Call-ID: Shared across all requests and responses in a dialog.
From-tag: Caller’s unique dialog identifier.
To-tag: Set by callee in the first final response (like 200 OK to INVITE).
Via branch parameter: Identifies the specific transaction so responses can find their way back.

Example:

INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.10;branch=z9hG4bK123
From: Alice sip:alice@example.com
;tag=111
To: Bob sip:bob@example.com

Call-ID: 1234567890@example.com

CSeq: 1 INVITE
...

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.0.2.10;branch=z9hG4bK123
From: Alice sip:alice@example.com
;tag=111
To: Bob sip:bob@example.com
;tag=222
Call-ID: 1234567890@example.com

CSeq: 1 INVITE

The branch matches the INVITE transaction.
The To-tag creates the dialog.
Call-ID stays constant for all dialog messages.

📞 Example Call Flow with Responses

Here’s a simple ASCII call flow showing requests + responses:

Alice                           Bob
| INVITE ---------------------> |
| <---------- 100 Trying -------|
| <---------- 180 Ringing ------|
| <---------- 200 OK -----------|
| ACK ------------------------->|
|========= Media (RTP) =========|
| BYE ------------------------->|
| <---------- 200 OK -----------|

100 Trying → Provisional, no retransmission of INVITE needed.
180 Ringing → Alerts Alice, doesn’t complete transaction.
200 OK → Final response, completes the INVITE transaction.
ACK → Separate request confirming the dialog setup.

⏱️ SIP Timers and Responses

SIP uses timers to ensure requests don’t get lost forever. Some key ones:

Timer A → INVITE retransmission interval (UDP). Stops when 100 Trying is received.
Timer B → INVITE transaction timeout (default 32s). If no final response (2xx–6xx), transaction fails.
Timer D → Wait time after sending final response to INVITE (to absorb stray retransmissions).
Timer F → Non-INVITE transaction timeout.
Timer K → Wait time before cleaning up after final response in non-INVITE.

How responses affect them:

100 Trying: Stops retransmission (Timer A).
200 OK: Ends INVITE transaction → Caller must send ACK.
4xx/5xx/6xx: Also final, but may trigger re-INVITE or fallback by application.

🔎 Quick-Reference: Timers vs Responses

Timer	Triggered / Stopped By	Notes
Timer A	Stopped by 100 Trying	INVITE retransmission timer (UDP)
Timer B	Stopped by final resp	INVITE timeout (32s if no reply)
Timer D	After sending final resp	Keeps transaction state to absorb stray retransmits (INVITE server)
Timer F	Stopped by final resp	Non-INVITE timeout (client side)
Timer K	After final resp (non-INVITE)	Waits before cleanup

📞 Example: Timers in Action

Caller (UAC)                      Callee (UAS)

INVITE ---------------------------> (Start Timer A, B)

[ Timer A running: Retransmit INVITE if no response ]
[ Timer B running: Fail after 32s if no final response ]
        <----------------------- 100 Trying
         (Stops Timer A)

        <----------------------- 180 Ringing
         (Timer B still running)

        <----------------------- 200 OK
         (Stops Timer B)

👉 In this flow:

Timer A makes sure the INVITE doesn’t vanish (stopped by 100 Trying).
Timer B guarantees the call won’t hang forever if the other side stays silent.
The 200 OK stops Timer B and the transaction is finalized with the ACK.

This ties responses directly to timers, helping you debug retransmissions, timeouts, or why a SIP phone “gives up” after a while.

⚡ Quick Recap

SIP Responses = feedback for SIP Requests.
Categories: 1xx progress, 2xx success, 3xx redirect, 4xx client error, 5xx server error, 6xx global failure.
IDs (Call-ID, tags, branch) bind everything together.
Timers ensure SIP doesn’t wait forever.

⏭️ Next Round: SIP in Action with Scenarios

Up next, we’ll dive into real-world call scenarios with SIP Requests + Responses, and build toward understanding all the different SIP methods in actual use.

🕹 Follow @sip_games to survive the signaling jungle.

🎭 SIP Requests Unmasked: The Moves Behind the Game

SIP GAMES — Mon, 18 Aug 2025 14:30:48 +0000

In the previous articles, we explored SIP basics, SDP, RTP, and even the sneaky tools and security layers that keep VoIP calls safe.

Now, it’s time to dive into the moves of the SIP game — the SIP Requests.

If SIP is a game of signaling, then SIP Requests are the cards you play.

Each request has a role, its own headers, and strict rules about when and how it can be used.

🥇 What is a SIP Request?

A SIP Request is a message sent by a SIP User Agent (UA) or SIP Server to initiate, modify, or terminate a session.

They are the verbs of the SIP protocol — telling the other party what to do.

Example (simplified SIP INVITE request):

INVITE sip:bob@voip.games SIP/2.0
Via: SIP/2.0/UDP 192.168.1.20:5060;branch=z9hG4bK-524287-1---d2f5d8
Max-Forwards: 70
From: "Alice" sip:alice@voip.games;tag=1928301774
To: sip:bob@voip.games
Call-ID: a84b4c76e66710@192.168.1.20
CSeq: 314159 INVITE
Contact: sip:alice@192.168.1.20:5060
Content-Type: application/sdp
Content-Length: 142

📦 The Mandatory Headers in SIP Requests

Every SIP request must carry some key headers for routing, identification, and handling.

Header	Purpose
Via	Records the path taken by the request. Includes the `branch` parameter.
Max-Forwards	Prevents loops; decremented at each hop.
From	Caller identity (with `tag` to differentiate multiple calls).
To	Callee identity (tag added later during responses).
Call-ID	Globally unique ID for the call/dialog.
CSeq	Sequence number + method (e.g., `314159 INVITE`).
Contact	Where to send future requests to this UA.
Content-Type	Type of body (usually `application/sdp`).
Content-Length	Size of the body.

These headers are like the uniform and ID badges for each SIP request, ensuring they are recognized and routed properly.

📖 The SIP Requests Explained

Here’s the full list of SIP Requests and their roles:

1. INVITE

Purpose: Initiates a call/session. Can also re-INVITE to modify an existing session.
Carries SDP in the body (media details).
Example: Alice invites Bob to a call.

Alice               Bob
|----- INVITE ----->|
|<---- 180 Ringing--|
|<----- 200 OK -----|
|------ ACK ------->|
|<==== RTP Media ==>|

2. ACK

Purpose: Confirms final responses to INVITE (e.g., 200 OK).
Critical for completing the 3-way handshake.

3. BYE

Purpose: Terminates an existing session (ends a call).
Sent by either side.

Alice               Bob
|<==== RTP Media ==>|
|------ BYE ------->|
|<----- 200 OK -----|

4. CANCEL

Purpose: Cancels a pending INVITE before it’s accepted.
Example: Hang up before the other side answers.

Alice                      Bob
|----- INVITE ------------>|
|------ CANCEL ----------->|
|<----- 487 Req Terminated |
|<----- 200 OK (CANCEL) ---|

5. REGISTER

Purpose: Binds a user’s SIP URI to their current IP/Contact address.
Tells the SIP Registrar where the UA can be reached.

Alice           Registrar
|---- REGISTER ---->|
|<---- 200 OK ------|

6. OPTIONS

Purpose: Query capabilities of another UA or server.
Example: “Do you support video?”

Alice              Bob
|---- OPTIONS ---->|
|<---- 200 OK -----|

7. INFO

Purpose: Mid-session signaling (e.g., DTMF, statistics).
Not used for session setup.

8. PRACK

Purpose: Provisional Acknowledgement.
Used to reliably acknowledge 1xx provisional responses.

9. SUBSCRIBE / NOTIFY

Purpose: Event notification framework (e.g., presence, voicemail).
SUBSCRIBE asks for updates, NOTIFY sends them.

10. UPDATE

Purpose: Modify session parameters before final response is sent.
Lighter than re-INVITE.

11. MESSAGE

Purpose: Instant messaging in SIP.
Example: Sending a text via SIP SIMPLE.

12. REFER

Purpose: Ask a UA to initiate a new request (e.g., call transfer).
Example: “Please call this third party instead.”

Alice                    Bob
|---- REFER ------------>|
|<---- 202 ACCEPTED -----|

🧩 SIP Transaction vs Dialog

Transaction:

A request + all responses to it.
Example: An INVITE and the 100 Trying, 180 Ringing, 200 OK, and ACK.

Dialog:

A persistent peer-to-peer association created by INVITE, SUBSCRIBE, or REFER.
Identified by Call-ID + To Tag + From Tag.
Example: The ongoing session between Alice and Bob after INVITE completes.

Caller (UA A)                           Callee (UA B)
     |                                       |
     |---------- INVITE -------------------->|   \
     |<--------- 100 Trying -----------------|    \
     |<--------- 180 Ringing ----------------|     }  INVITE transaction (T1)
     |<--------- 200 OK ---------------------|    /
                                                 /
     |----------- ACK ---------------------->|    }   ACK to 2xx is a separate transaction (T2)

     |<====== RTP Media (within dialog) ====>|

     |------------ BYE --------------------->|   \   BYE transaction (T3)
     |<----------- 200 OK -------------------|   /
     |                                       |

===================== SIP DIALOG LIFETIME ======================
Created by the 200 OK to INVITE (when To-tag is set)
and ends after BYE / 200 OK completes.
Call-ID: same
From-tag: set by Caller
To-tag:   set by Callee in 200 OK
===============================================================

What’s What?

Transactions (short-lived):
- T1 (INVITE transaction): INVITE + all provisional/final responses (100/180/200).
- T2 (ACK for 2xx): The ACK to a 2xx is its own transaction.
- T3 (BYE transaction): BYE + 200 OK.
Dialog (long-lived):
- Created when the 2xx to INVITE is received and the To-tag is set.
- Identified by Call-ID + From-tag + To-tag.
- Persists across multiple transactions (e.g., re-INVITE, UPDATE, BYE).

🔑 Unique Identifiers in SIP Requests

Call-ID: Unique per call across the entire network.
Via Branch Parameter (branch=z9hG4bK...): Unique per transaction, ensures no loops(changes between INVITE, ACK(2xx), BYE).
Tags (From and To): Differentiate multiple dialogs with same Call-ID.
- From tag: Set by caller in the initial INVITE.
- To tag: Set by callee in the first 2xx (or reliable 1xx) creating the dialog.

Think of them like game tokens — no two can be identical in the same round.

⏲️ SIP Timers

SIP uses timers to avoid hanging transactions and retransmit when needed.

Timer A: INVITE request retransmit interval.
Timer B: INVITE transaction timeout.
Timer D: Wait time for response retransmits.
Timer E/F: Non-INVITE request retransmit and timeout.
Timer H/J: Wait for ACK and cleanup.

These ensure SIP is reliable even over UDP.

📑 SIP Requests Cheatsheet

Here’s a handy quick reference for the most common SIP Requests:

Request	Purpose	Example Use Case	Example Flow
INVITE	Initiate/modify a call	Alice calls Bob	INVITE → 180 Ringing → 200 OK → ACK
ACK	Confirm INVITE final response	Completes 3-way handshake	ACK after 200 OK
BYE	Terminate a session	End the call	BYE → 200 OK
CANCEL	Cancel a pending INVITE	Caller hangs up before callee answers	CANCEL → 487 Req Terminated
REGISTER	Register user’s current location	Alice tells Registrar where she can be reached	REGISTER → 200 OK
OPTIONS	Query capabilities	Check if peer supports video	OPTIONS → 200 OK
INFO	Mid-session signaling	Send DTMF digits in a call	INFO → 200 OK
PRACK	Provisional acknowledgement	Reliable delivery of 183 Session Progress	PRACK → 200 OK
SUBSCRIBE	Subscribe to events	Presence/voicemail notifications	SUBSCRIBE → 200 OK
NOTIFY	Send event notifications	Inform watcher of presence changes	NOTIFY → 200 OK
UPDATE	Update session before final answer	Early media changes before call established	UPDATE → 200 OK
MESSAGE	Instant messaging in SIP	Send chat message	MESSAGE → 200 OK
REFER	Ask UA to initiate a request	Call transfer	REFER → 202 Accepted

🏁 Wrapping Up

SIP Requests are the moves of the game — INVITE to start, BYE to quit, REGISTER to log in, and so on.

They’re powered by headers, tied together with transactions and dialogs, and kept safe by timers.

👉 Next up: SIP Responses — the reactions to these moves. Because every request deserves an answer, right?

🕹 Follow @sip_games for more VoIP magic — minus the RFC migraines.

🔒 VoIP Security 101

SIP GAMES — Sun, 17 Aug 2025 17:02:06 +0000

"In VoIP, it’s not enough to play the game — sometimes you need to play it in stealth mode."

In previous levels, we built up VoIP basics:

SIP to set up calls
SDP to negotiate media
RTP to carry voice and video

But what happens when the arena is hostile? Eavesdroppers, man-in-the-middle attacks, or even malicious proxies could steal or tamper with calls. That’s where VoIP security comes in.

🎭 Securing the Two Worlds: Signaling vs Media

VoIP has two layers to protect:

Signaling (SIP) — Who’s calling, how, where to connect.
Media (RTP) — The actual voice/video packets.

Both require different protection strategies.

📞 Securing Signaling with SIPS

SIP normally rides on plain UDP or TCP. That’s like mailing postcards — anyone along the route can read them.

The fix? Transport Layer Security (TLS).

SIP over TLS (SIPS) encrypts SIP signaling between endpoints and proxies.
Port convention: 5061 instead of 5060.
Certificates are used to authenticate servers (and optionally clients).

Example flow:

[Caller SIP UA] --TLS--> [SIP Proxy] --TLS--> [Callee SIP UA]

Think of it as wrapping your SIP messages in an armored envelope.

🎧 Securing Media with SRTP

While SIPS hides setup instructions, the media path (RTP) still needs protection. That’s where Secure RTP (SRTP) comes in.

SRTP encrypts and authenticates RTP streams, ensuring that:

Nobody can eavesdrop on your audio/video.
Nobody can inject fake packets into the stream.

But SRTP alone isn’t enough — it needs a way to exchange keys. This is where different methods come in.

🔑 Key Exchange Mechanisms for SRTP

1. SRTP with SDES (Session Description Protocol Security Descriptions)

With SDES, keys are shared inside the SDP body of SIP messages.

Example SDP with SDES:

v=0
o=- 12345 67890 IN IP4 192.0.2.1
s=VoIP Call
c=IN IP4 192.0.2.1
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:MTIzNDU2Nzg5MDEyMzQ1Ng==

a=crypto defines the encryption algorithm and key.
AES_CM_128_HMAC_SHA1_80 = AES with HMAC authentication.
The inline: value is the base64-encoded SRTP key.

⚠️ Risk: If SIP isn’t protected with TLS, anyone sniffing the signaling path can steal the SRTP key.

👉 Best for: Controlled/trusted networks where SIP signaling is already protected with TLS.

2. SRTP with DTLS (Datagram Transport Layer Security)

DTLS provides a handshake (like TLS for UDP) to exchange SRTP keys directly between endpoints.
Instead of placing keys in SDP, endpoints exchange fingerprints for certificate verification.

Example SDP with DTLS-SRTP:

v=0
o=- 46117326 2 IN IP4 192.0.2.10
s=VoIP Call
c=IN IP4 192.0.2.10
t=0 0
m=audio 54000 RTP/SAVPF 111 0
a=rtpmap:111 opus/48000/2
a=rtpmap:0 PCMU/8000
a=setup:actpass
a=fingerprint:sha-256 12:34:56:78:90:AB:CD:EF:12:34:56:78:90:AB:CD:EF:12:34:56:78:90:AB:CD:EF:12:34:56:78:90:AB:CD:EF
a=ice-ufrag:abcd
a=ice-pwd:efghijklmnop

Key lines explained:

a=setup:
- actpass → Caller offers to act as either client or server.
- active → Endpoint will initiate DTLS handshake.
- passive → Endpoint will wait for DTLS handshake.
a=fingerprint: → Hash of the certificate used for DTLS session. Ensures authenticity.
RTP/SAVPF → Secure RTP profile with feedback (commonly used in WebRTC).

👉 Best for: WebRTC and modern SIP deployments. Provides stronger end-to-end protection.

🌐 Transport Security Recap

SIP signaling:
- UDP/TCP → Plaintext, insecure.
- TLS → Encrypted (SIPS).
RTP media:
- Plain RTP → Insecure.
- SRTP/SDES → Keys in SIP/SDP, simpler.
- SRTP/DTLS → Keys exchanged via DTLS handshake, stronger.

📊 Quick Comparison Table

Layer	Plain Protocol	Secure Protocol	Notes
SIP	SIP over UDP/TCP	SIPS (SIP over TLS)	Protects signaling from eavesdropping
RTP	RTP	SRTP	Encrypts and authenticates media
SRTP Keying	N/A	SDES	Keys exchanged via SDP (requires SIPS)
SRTP Keying	N/A	DTLS	Keys exchanged via DTLS handshake (WebRTC)

🎮 TL;DR

SIPS (TLS) secures SIP signaling.
SRTP secures the media path.
- SDES = simpler, but requires trusted signaling.
- DTLS = modern, secure, and WebRTC-approved.

🧠 Up Next in SIP GAMES:

“Choose Your Fighter: SIP Call Scenarios” 🎬
We’ll break down real-world call flows and SIP requests — INVITE, BYE, REFER, REGISTER, and more — showing how signaling changes in different situations (basic calls, transfers, forking).

Stay tuned, because the next level is all about SIP Requests in Action.

Follow @sip_games

🕵️‍♂️ Spy Tools for VoIP Agents

SIP GAMES — Sat, 09 Aug 2025 15:16:31 +0000

"The game isn’t just about playing — it’s about watching, analyzing, and winning."

In the last level of SIP GAMES, we learned about RTP — the courier that runs your media across the network. But what happens when the game lags, drops, or mysteriously fails?

You don’t guess. You spy.

Not on people, but on packets.

Here’s your VoIP agent toolkit — categorized, explained, and ready for action.

🛡 1. Surveillance Tools — Capture & Analyze Traffic

When something goes wrong in a VoIP call, your first job is to see the traffic. These tools let you peek inside packets like a movie detective flipping through secret files.

🐬 Wireshark

Purpose: Capture and inspect SIP, SDP, RTP (and more) packets.
Use case: Call drops after 30 seconds? See if a BYE or timeout happened. No audio? Check if RTP is flowing.
How to use:
1. Install from wireshark.org
2. Start capture on the correct network interface.
3. Apply filters like:
  - sip → Show only SIP messages
  - rtp → Show only RTP packets
  - ip.addr == 192.168.1.50 → Show traffic for a specific IP
4. Right-click → “Follow” → “UDP Stream” for audio flow.
Pro tip: Enable VoIP Calls under Telephony → VoIP Calls to reconstruct call flow.

🧪 2. Simulation Tools — Generate Test Calls

Sometimes you can’t wait for a bug to happen — you need to force it. That’s where call simulators come in.

📞 sipp

Purpose: SIP traffic generator and test tool.
Use case: Stress-test your SIP server with thousands of calls, or simulate specific SIP scenarios (registration floods, custom headers, delayed responses).
How to use:
1. Install from sipp.sourceforge.net
2. Basic call test:
```
 sipp -sn uac 192.168.1.20
```
(This sends an INVITE to 192.168.1.20 using the default UAC scenario.)
1. Use XML scenario files to define custom call flows.
Pro tip: Combine with Wireshark to capture the generated traffic for later analysis.

🔀 3. Media Manipulation Tools — Intercept & Modify RTP

When you need to play with the media path — for debugging, transcoding, or rerouting — these tools take control.

🎯 rtpengine

Purpose: RTP proxy for relaying and modifying RTP streams.
Use case: NAT traversal issues, transcoding between codecs, or enabling SRTP on one side while keeping RTP on the other.
How to use:
1. Install from rtpengine.org
2. Use via CLI or integrate with SIP proxies like Kamailio/OpenSIPS.
3. Control with commands like:
```
 ngcp-rtpengine-ctl list
```
(Lists active RTP sessions.)
Pro tip: Use it to simulate one-way audio problems by blocking one RTP direction.

🛠 Example Debugging Scenarios

Scenario	Tool	How It Helps
One-way audio	Wireshark, rtpengine	Capture RTP to see which side isn’t sending
Call setup delay	Wireshark, sipp	Compare SIP INVITE timestamps with responses
Codec mismatch	Wireshark	Inspect SDP offers/answers for supported codecs
NAT traversal failure	Wireshark, rtpengine	Verify if private IPs appear in SDP
Stress testing	sipp	Generate high call volume to see when servers fail

🎮 TL;DR

Wireshark = See everything
sipp = Simulate anything
rtpengine = Control media flow
Debugging VoIP isn’t about guessing — it’s about capturing, analyzing, and proving where the problem lives.

🧠 Up Next in SIP GAMES:

“Keeping It Secret: VoIP Security 101” 🔒

We’ll explore SIPS, SRTP, SIP over TLS, RTP over DTLS, and SDES — because in VoIP, sometimes the game isn’t just about speed, but keeping your cards hidden.

Follow @sip_games and stay in the game.

🎤 The Voice Courier: Meet RTP

SIP GAMES — Sat, 28 Jun 2025 19:49:03 +0000

“SDP made the rules, RTP plays the game.”

In the previous episode of SIP GAMES, we peeked inside the SDP invite that tells your opponent how you'd like to play: what codecs, what ports, and what IPs. But who actually carries the media?

🎮 Enter RTP — Real-time Transport Protocol.

🧳 What is RTP?

Think of RTP as the courier that carries your voice across the network — broken into little time-stamped, sequence-numbered packages.

SIP sets up the call
SDP describes the media setup
RTP sends the actual media (voice/video)

RTP runs on top of UDP (User Datagram Protocol) because it’s fast and tolerant of occasional loss — just like a real conversation.

🧬 RTP Packet Structure

Here’s the basic layout of an RTP packet:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|CC|M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Synchronization Source (SSRC) Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contributing Source (CSRC) Identifiers (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload (audio/video) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Let’s decode this header:

🔍 RTP Header Fields

Field	What It Means
`V`	Version (always 2)
`P`	Padding (if extra bytes added)
`X`	Extension header present
`CC`	CSRC count (used in conferencing)
`M`	Marker bit (e.g. start of a talkspurt)
`PT`	Payload type (codec, e.g., 0 = PCMU, 96 = dynamic)
`Sequence Number`	Increments by 1 per packet — used to detect loss
`Timestamp`	Used for media playback timing
`SSRC`	Sender’s unique ID
`CSRC`	IDs of other contributing streams (optional)
`Payload`	Actual audio or video data

🕒 Packetization Time (a.k.a. ptime)

What is packetization time?

It’s the duration of audio in each RTP packet, often advertised in SDP using a=ptime:20 (means 20 ms per packet).

Common values:

Codec	Typical ptime	Result
PCMU	20 ms	50 packets/sec
Opus	Variable	Can do 20–60 ms
G.729	20 ms	Small, compressed

🧮 Frequency of RTP Transmission

The number of RTP packets per second depends on the codec’s ptime.

Example:

If ptime is 20ms, that’s 50 packets/second
If it’s 30ms, ~33.3 packets/sec
Higher ptime = fewer packets = less overhead
Lower ptime = smoother audio but more packets

🧠 Why Do I Care?

If you're implementing RTP or trying to debug call quality:

Jitter? Check packet arrival times and timestamps
Audio out of sync? Sequence or timestamp mismatch
Silence or gaps? Packets lost or arriving too late
Wrong codec? Check the Payload Type (PT) field

RTP is everywhere in VoIP — and understanding this header lets you trace, debug, and build your own media streamers.

🛠️ Example: A Real RTP Packet (with G.711)

Let’s say we're using G.711 with 20ms ptime.

Payload Type: 0 (PCMU)
Sequence Number: 10567
Timestamp: 160000
SSRC: 0x789ABC
Payload: 160 bytes of G.711 data (8-bit PCM at 8000 Hz)

That’s 160 samples × 8 kHz × 20ms = 160 bytes

🎮 TL;DR

RTP carries media after SIP/SDP sets things up
Each RTP packet has headers: version, PT, seq, timestamp, etc.
Ptime defines how much media is in each packet
Frequency of packets is based on ptime
Use RTP headers to debug and analyze VoIP issues

📦 Up Next in SIP GAMES:

“Spy Tools for VoIP Agents” 🕵️‍♂️

We’ll break down the best open-source tools like Wireshark, sipp, and rtpengine, and show you how to capture, simulate, and troubleshoot your VoIP calls like a pro.

Follow @sip_games to keep leveling up your VoIP game.

📦 What’s in the SIP Envelope? (A Peek at SDP)

SIP GAMES — Mon, 23 Jun 2025 10:17:12 +0000

“SDP: The tiny contract that decides how we talk.”

Remember that SIP message we saw last time? It was polite. It said “Hi, want to talk?” But it also had a little payload, tucked inside like a secret note in a game invitation. That note was SDP — Session Description Protocol.

Let’s unpack it, casually.

🧠 What Is SDP?

SDP is not a protocol that sends media — it’s just a description.

It tells the other side things like:

What IP and port to send media to
What kind of media we support (audio, video, fax, etc.)
Which codecs we can use
How many media streams we want

Think of SDP as the cheat sheet you give your opponent before a Squid Game round. It says:

“We’ll play audio only. You send it to this IP, this port. Here are the rules (codecs) I speak.”

📃 A Sample SDP Offer

Here’s a simplified version of what might be inside the body of an INVITE:

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

Let’s decode this bit by bit.

✏️ Mandatory Fields in SDP

Field	What It Means
`v=`	Version — always 0
`o=`	Origin — username, session ID, IP of sender
`s=`	Session Name — can be `-` if not used
`c=`	Connection Info — IP address to send media
`t=`	Timing — start and stop time (0 0 = forever)
`m=`	Media Description — media type, port, transport, codecs
`a=`	Attributes — like codec details, encryption, etc.

🎙 What Are Codecs?

A codec (short for coder-decoder) compresses and decompresses media like voice or video. In VoIP, we use codecs to:

Save bandwidth (fewer bits = faster calls)
Improve audio quality
Handle different devices and network conditions

🔊 Common Audio Codecs

Codec	Description	Bandwidth	Notes
PCMU (G.711 µ-law)	Classic PSTN quality	~64 kbps	Good quality, high bandwidth
PCMA (G.711 A-law)	EU version of µ-law	~64 kbps	Similar to PCMU
G.729	Compressed voice	~8 kbps	Low bandwidth, licensed
Opus	Modern, flexible	6–510 kbps	Great quality, dynamic bitrate
G.722	HD voice	~64 kbps	Wideband audio

📹 Common Video Codecs

Codec	Description	Use Case
H.264	Standard for video calls	Widely used
VP8 / VP9	Open-source codecs	Used in WebRTC
H.265 (HEVC)	Next-gen, better compression	Not always supported

🎮 SIP + SDP: Setting the Game Rules

Let’s update our SIP message to imagine it has the voice rules included:

INVITE sip:bob@example.com SIP/2.0
...
Content-Type: application/sdp
Content-Length: 151

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

It’s saying:

“Hey Bob, send me voice on 192.168.1.10:49170. I speak PCMU and Opus. You pick.”

Bob can then reply with:

“Cool, I speak Opus too” (and use a=rtpmap:96 opus/48000/2)
Or “Let’s just stick with PCMU.”

📦 TL;DR

SDP is metadata — it tells the other side how to stream media
SIP uses SDP to offer codecs, IPs, and ports
Audio codecs like PCMU, Opus, G.729 define voice quality + size
Video codecs like H.264 and VP8 make video calls possible
SDP doesn’t send media — it just describes it

🧠 Up Next in SIP GAMES:

“The Real MVP — RTP: The Voice Inside the Wires”

Now that SIP + SDP agreed on how we’ll talk, it’s time to learn how your voice actually hops across the internet in real time.

Stay tuned for packet magic!

🎮 Follow @sip_games for more VoIP fun with less RFC-induced stress.

📡 You’re Invited… to the Session! (What Even is SIP?)

SIP GAMES — Mon, 16 Jun 2025 11:22:39 +0000

“SIP sets up the game. RTP plays it.”

🧩 So... What is SIP?

SIP (Session Initiation Protocol) is the VoIP equivalent of the game master — it sets the rules, gets the players into the arena, and then steps back once the game (the voice conversation) begins.

In plain terms:

SIP handles call setup, ringing, answering, and tear-down. It does not carry your voice — that’s RTP’s job.

Think of SIP like sending someone a party invite. It tells them:

Who’s calling
Where the call should happen
How they can reach you
And whether they want to accept it or ghost you

☎️ The Call Flow (Simplified)

Here’s how a basic SIP call between two softphones works:

User A            SIP Server            User B
  |                   |                   |
  |--- INVITE ------->|                   |
  |                   |--- INVITE ------->|
  |                   |<-- 180 RINGING ---|
  |<-- 180 RINGING ---|                   |
  |                   |<-- 200 OK --------|
  |<-- 200 OK --------|                   |
  |--- ACK ---------->|                   |
  |                   |--- ACK ---------->|
  |                   |                   |
  |<==== RTP Media Stream (Voice) ======>|
  |                   |                   |
  |--- BYE ---------->|                   |
  |                   |--- BYE ---------->|
  |                   |<-- 200 OK --------|
  |<-- 200 OK --------|                   |

🧠 Key SIP Messages

Message	What it Means
INVITE	“Hey, want to talk?”
180 RINGING	“They’re being notified”
200 OK	“They picked up!”
ACK	“Cool, let’s connect”
BYE	“Gotta go, bye!”

🎯 SIP in Action — What You See in Logs

If you’ve ever looked at SIP logs (Wireshark, anyone?), you’ll see something like:

INVITE sip:bob@example.com SIP/2.0
From: "Alice" sip:alice@example.net
To: sip:bob@example.com
Call-ID: 789abc123@example.net
CSeq: 1 INVITE
Contact: sip:alice@192.168.1.10:5060
Content-Type: application/sdp
Content-Length: 151

Notice that last part? Content-Type: application/sdp 👀

Yup — SIP includes something called SDP inside it. It’s like the fine print in your call invitation — it lists what codecs you'll use, what port to send media to, and more.

🧩 SIP ≠ Voice

SIP doesn’t carry your voice.

Instead, once the SIP call is accepted, RTP (Real-time Transport Protocol) takes over to actually move the media (voice, video, etc.) between endpoints.

So:

SIP = The call setup (the RSVP)
RTP = The actual voice (the conversation)

🔁 What Happens When You Hang Up?

A typical SIP BYE exchange:

User A --> BYE --> SIP Server --> BYE --> User B
User B --> 200 OK --> SIP Server --> 200 OK --> User A

Simple. Fast. And very polite.

🎯 TL;DR

SIP is a signaling protocol, not a media protocol
It helps set up, modify, and end VoIP calls
It uses messages like INVITE, RINGING, ACK, and BYE
It wraps media setup details using SDP (coming next)
After the call setup, RTP moves the actual voice packets

🧠 Up Next in SIP GAMES:

“What’s in the Envelope? Unpacking SDP”

SDP (Session Description Protocol) tells your devices what media codecs to use, how to send the audio, and more — it’s like the secret note inside your SIP envelope.

Stay tuned as we dive into how a voice call actually finds its voice.

🕹 Follow @sip_games for more VoIP magic — minus the RFC migraines.

📟 From Switchboards to Softswitches: The Players Behind the Voice

SIP GAMES — Tue, 10 Jun 2025 16:28:45 +0000

“Know your environment. Understand who’s running the game.”

☎️ Let’s Rewind

Once upon a time, calling someone meant a person literally plugged cables into a board to connect your voice to theirs.

Those were the manual switchboards, followed by automated telephone exchanges. That era used circuit-switched networks — where a dedicated line was held for your entire call.

Fast forward ⏩ — and now your voice zips through packet-switched networks, hopping across routers, firewalls, clouds, and code.

🛠 The Game Board: Old vs New

Concept	Circuit-Switched World	Packet-Switched (VoIP) World
Call Routing	PSTN (Public Switched Telephone Network)	Internet (IP networks)
Central Device	PBX / Exchange	IP-PBX / Softswitch
Physical Wiring	Dedicated copper circuits	IP network, Ethernet, Wi-Fi
Call Setup/Teardown	Controlled by Telco systems	Controlled by SIP or similar
Call Audio Path	Fixed voice circuit	Dynamic RTP media stream

🧠 Circuit vs Packet Switching — The Core Shift

🎚 Circuit Switching (Old School)

Like renting an entire highway just for your car
Fixed bandwidth, reliable, expensive
Example: Landline call from your grandma’s rotary phone

📦 Packet Switching (Modern VoIP)

Your voice is chopped into chunks (packets), each taking the best route
More efficient, shared bandwidth
Like a backpacker using public transport
Example: WhatsApp call on patchy airport Wi-Fi

🔄 Enter the VoIP Equivalents

Let’s meet the players behind modern voice traffic:

🏢 IP-PBX (Internet Protocol Private Branch Exchange)

The VoIP version of a PBX (Private Branch Exchange)
Manages internal extensions, call routing, voicemail, IVR
Runs on software, sometimes even cloud-based (like FreePBX or 3CX)

⚙️ Softswitch

Software-powered switchboard
Routes calls between networks — VoIP ↔ PSTN or VoIP ↔ VoIP
Used by telcos and service providers (FreeSWITCH, Kamailio, OpenSIPS)

📱 SIP Endpoints

Devices or apps that speak SIP (VoIP protocol)
Can be a softphone app, VoIP desk phone, or even a smart fridge (yep)

🧩 Visual Time

📈 Circuit Switched Call Flow

User A ---[Analog Signal]---> PBX ---[TDM Circuit]---> Telco Switch ---[TDM Circuit]---> User B

|<------Dedicated voice circuit maintained throughout------>|

🌐 VoIP / Packet Switched Call Flow (SIP + RTP)

User A (Softphone)
|
|---[SIP INVITE (Signaling)]---> SIP Server
|
|<--[SIP 200 OK / ACK]----------|
|
|---[RTP Media Stream]----------> User B (Softphone)

🧠 Why This Matters

Knowing who's doing what behind the scenes helps you debug, design, and build better voice applications.

Bad call quality? Might be RTP path or NAT issue
Can’t make internal calls? Could be IP-PBX config
Confused by latency? Maybe your packets are playing hopscotch through the cloud

🏁 TL;DR – Survived Another Round?

Circuit-switched = old-school dedicated lines
Packet-switched = modern, flexible, efficient
IP-PBX = the office call controller
Softswitch = the telecom traffic cop
You’re not just making a call — you’re crossing systems, formats, and protocols

⏭️ Up Next in SIP GAMES:

"You’re Invited… to the Session" – A deep dive into SIP and how calls are actually set up.

🕹 Follow @sip_games to learn SIP without reading the RFCs.

[Boost]

SIP GAMES — Tue, 10 Jun 2025 12:36:26 +0000

SIP GAMES

Jun 10 '25

🎭 What Even Is VoIP?

#voip #sip #beginners #telephony

Comments 3

2 min read