SIP GAMES

Posted on Aug 18

🎭 SIP Requests Unmasked: The Moves Behind the Game

#sip #voip #telephony #networking

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.

DEV Community