RFC 3261
SIP: Session Initiation Protocol
Standards Track Obsoletes: RFC 2543 June 2002
Abstract: SIP is a signaling protocol for creating, modifying, and terminating multimedia sessions. In 3GPP, SIP is the core signaling protocol for IMS (IP Multimedia Subsystem), handling VoLTE/VoNR call setup, registration, and session management.
Canonical source: https://www.rfc-editor.org/rfc/rfc3261
| IETF Datatracker
1. Introduction
▶SIP is a text-based, HTTP-like signaling protocol for initiating, managing, and terminating multimedia sessions over IP networks. It supports user location, user availability, user capabilities, session setup, and session management.
In 3GPP IMS, SIP is used for VoLTE/VoNR call signaling, video calls, supplementary services, emergency calls, and multimedia messaging. The IMS Call Session Control Functions (P-CSCF, I-CSCF, S-CSCF) are SIP servers/proxies.
2. SIP Methods
▶| Method | Description | 3GPP Usage |
|---|---|---|
| REGISTER | Register user location with registrar | UE to P-CSCF → I-CSCF → S-CSCF registration |
| INVITE | Initiate a session (call) | VoLTE/VoNR call setup with SDP offer |
| ACK | Confirm INVITE final response | Three-way handshake completion |
| BYE | Terminate an existing session | Call teardown |
| CANCEL | Cancel a pending INVITE | Abort call attempt before answer |
| OPTIONS | Query capabilities | Feature/codec discovery |
| SUBSCRIBE | Subscribe to event notification | Presence, reg-event, dialog-event |
| NOTIFY | Deliver event notification | Push event state to subscriber |
| UPDATE | Modify session parameters (no dialog change) | Preconditions, codec renegotiation |
| PRACK | Provisional ACK (reliable provisional response) | Required for IMS (100rel) |
| MESSAGE | Instant message | SIP-based IM |
| REFER | Transfer/redirect | Call transfer |
3. IMS Registration Flow
▶IMS registration uses a two-pass authentication flow: the first REGISTER is challenged with a 401 containing AKA authentication vectors (nonce, AUTN); the second REGISTER carries the UE's response (RES).
UE P-CSCF I-CSCF S-CSCF HSS | | | | | | REGISTER | | | | | (no auth) | | | | |--------------->| REGISTER | | | | |--------------->| UAR | | | | | (User-Auth-Req)| | | | |--------------->| | | | | UAA | | | | | (S-CSCF addr) | | | | |<---------------| | | | | REGISTER | | | | |--------------->| MAR | | | | | (Auth-Req) | | | | |-------------->| | | | | MAA (AV) | | | | |<--------------| | 401 Unauth | | | | | (nonce, AUTN) | | | | |<---------------|<---------------|<---------------| | | | | | | | REGISTER | | | | | (RES response)| | | | |--------------->|--------------->|--------------->| | | | | | SAR | | | | | (Svr-Assign) | | | | |-------------->| | | | | SAA | | | | |<--------------| | 200 OK | | | | | (P-Assoc-URI) | | | | |<---------------|<---------------|<---------------| |
4. SIP Transaction Model
▶- Transaction: Request + all responses (provisional + final). Identified by Via branch parameter
- Dialog: Peer-to-peer relationship established by INVITE/200/ACK. Identified by Call-ID + From-tag + To-tag
- Forking: Proxy can fork INVITE to multiple endpoints — first 200 OK wins
- Record-Route: Proxies insert themselves in the route set to stay in signaling path
- IMS requirement: All CSCFs use Record-Route to remain in the signaling path for billing, lawful intercept, and policy
5. Security Considerations
▶- SIP is text-based and susceptible to header manipulation — integrity protection is essential
- Registration attacks (impersonation, deregistration) mitigated by IMS-AKA authentication
- SIP messages may contain sensitive information (IMPU, IMPI, location) — TLS protects hop-by-hop
- P-CSCF enforces security on the UE-facing interface (Gm) via IPsec or TLS
- Topology hiding (THIG) via I-CSCF prevents exposing internal network topology