SESSION INITIATION PROTOCOL
SIP — Session Initiation Protocol
A complete theory section covering SIP fundamentals, call flow, messages, servers, methods, response codes, headers, related protocols, H.323 and 3GPP/IMS.
1. SIP and the Internet
SIP (Session Initiation Protocol) is an application-layer signaling protocol used to create, modify, and terminate multimedia sessions such as voice, video, instant messaging and gaming between two or more participants over IP networks. SIP was originally defined by RFC 3261 and standardized through the IETF.
SIP sits at the application layer of the Internet protocol stack, above the transport layer. SIP can use UDP, TCP, TLS and SCTP, which operate above IP and the physical/link layers.
SIP relies on supporting protocols and conventions including:
- DNS — resolves domain names to IP addresses and servers.
- URLs/URIs — address users using
sip:andsips:schemes. - Multicast — can be used for some session types.
- ABNF — defines SIP message syntax.
SIP borrows heavily from HTTP, particularly its text-based request/response model, and from SMTP for addressing. This makes SIP human-readable and relatively easy to extend.
2. Introduction to SIP — Core Concepts
Basic call flow
A simple call is set up between two User Agents with the following messages:
- INVITE — invites the other party into a session; the body can contain an SDP payload describing the desired media, such as audio/video codec, IP address and port.
- 180 Ringing — informational response indicating that the called party is being alerted.
- 200 OK — the called party accepts and can include its own SDP answer.
- ACK — confirms the final response to the INVITE; the media session can then proceed using RTP.
- BYE — either party terminates the established session, followed by 200 OK.
Key message anatomy
- Request line / status line: a request contains method + Request-URI + SIP version; a response contains SIP version + status code + reason phrase.
- Header fields: use the
Header: Valueform. Header lines end in CRLF, and a blank line separates headers from the body. - Mandatory request headers: Via, Max-Forwards, To, From, Call-ID and CSeq; Contact is used for INVITE-type dialog-forming requests.
- Via: records the path a request takes; each hop stamps its own address and the
branchparameter acts as a transaction identifier. - Max-Forwards: is decremented at each hop and provides loop prevention.
- To / From: identify the direction of the request and include tags used to identify the dialog. The tuple Call-ID + From-tag + To-tag identifies a dialog.
- Call-ID: provides a unique identifier for the session/dialog context.
- CSeq: contains a sequence number and method name and helps distinguish new requests from retransmissions, including re-INVITEs.
- Content-Type / Content-Length: describe the message body, commonly
application/sdp.
SIP responses are grouped into six classes: 1xx informational, 2xx success, 3xx redirection, 4xx client error, 5xx server error and 6xx global failure.
Other examples
- Proxy-mediated calls: proxy servers forward requests/responses and can use a location service to find the callee.
- Registration: a User Agent tells a registrar its current contact address using REGISTER, binding an Address-of-Record (AOR) to a Contact URI.
- Presence and Instant Messaging: use SUBSCRIBE/NOTIFY and MESSAGE.
Transport
- UDP — simple, no guaranteed delivery; SIP provides retransmission mechanisms.
- TCP — reliable transport and useful for larger SIP messages or when reliability at each hop matters.
- TLS — encrypted and authenticated transport; used with the
sips:scheme. - SCTP — alternative transport with multi-streaming, particularly relevant in some telecom-core environments.
3. SIP Clients and Servers
- User Agent (UA): an end device capable of establishing sessions. It contains the logical roles UAC (initiates requests) and UAS (generates responses). Dialog state includes tags, Call-ID, CSeq and route information.
- Presence Agent (PA): handles SUBSCRIBE/NOTIFY for presence information and can aggregate information from multiple sources.
- Back-to-Back User Agent (B2BUA): terminates a request as a UAS and re-originates a new request as a UAC. It can be used for anonymization, services and application-layer gateway functions. It changes SIP's end-to-end behavior and introduces additional state.
- SIP Gateway: interfaces SIP with another signaling system such as H.323, PSTN/ISDN, SS7 or CAS. It may terminate signaling only or both signaling and media.
SIP servers
- Proxy servers: forward requests on behalf of User Agents. They can be stateless or stateful.
- Forking proxy: sends an INVITE to multiple possible destinations and manages the resulting responses.
- SIP Trapezoid: a model with an outbound proxy, DNS/location lookup, inbound proxy and User Agents at both ends; media can flow directly between the endpoints.
- Redirect server: returns a 3xx response containing alternate locations rather than forwarding the request itself.
- Registrar: accepts REGISTER requests and updates AOR/contact bindings in a location database.
Reliability, authentication and NAT
- Reliability: SIP uses application-layer retransmission mechanisms to compensate for unreliable transports such as UDP; 100 Trying provides a single-hop indication that processing has begun.
- Authentication: SIP supports HTTP Digest challenge/response using 401 and 407 responses and authentication headers.
- S/MIME: can be used to encrypt/sign SIP message bodies.
- Multicast: supports one-to-many session setup in applicable scenarios.
- NAT/firewalls: SIP can have traversal problems because IP addresses and ports may appear in Via, Contact and SDP.
- STUN: lets a User Agent discover its public IP/port.
- TURN: relays media when direct connectivity fails.
- ICE / ALGs: are other mechanisms relevant to SIP/SDP NAT traversal.
4. SIP Request Messages
Core SIP methods defined by RFC 3261 and extensions include:
| Method | Purpose |
|---|---|
| INVITE | Initiates a session; can carry an SDP offer. |
| REGISTER | Binds an AOR to a Contact address. |
| BYE | Terminates an established session. |
| ACK | Confirms the final response to INVITE. |
| CANCEL | Cancels a pending request, for example during a forked search. |
| OPTIONS | Queries a User Agent/server for capabilities. |
| REFER | Asks the recipient to contact a third party, such as for call transfer. |
| SUBSCRIBE | Requests notification of an event. |
| NOTIFY | Sends event state information. |
| MESSAGE | Sends instant messaging content. |
| INFO | Carries mid-session signaling information, such as DTMF. |
| PRACK | Acknowledges reliable provisional responses. |
| UPDATE | Updates session parameters before a final response. |
URI schemes: sip: is used for SIP addressing, sips: for secure SIP using TLS, and tel: for telephone numbers. Tags distinguish dialogs, and message bodies can contain SDP or other MIME content.
5. SIP Response Messages
SIP responses are organized into six classes:
- 1xx Informational: 100 Trying, 180 Ringing, 181 Call Is Being Forwarded, 182 Call Queued, 183 Session Progress.
- 2xx Success: 200 OK, 202 Accepted.
- 3xx Redirection: 300 Multiple Choices, 301 Moved Permanently, 302 Moved Temporarily, 305 Use Proxy, 380 Alternative Service.
- 4xx Client Error: 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 405 Method Not Allowed, 407 Proxy Authentication Required, 408 Request Timeout, 486 Busy Here, 487 Request Terminated, 493 Undecipherable, and others.
- 5xx Server Error: 500 Server Internal Error, 501 Not Implemented, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout.
- 6xx Global Failure: 600 Busy Everywhere, 603 Decline, 604 Does Not Exist Anywhere, 606 Not Acceptable.
If a User Agent receives an unrecognized response code, it falls back to treating it according to the response class indicated by the first digit.
6. SIP Header Fields
General request/response headers
Call-ID, Contact, CSeq, Date, From, To, Via, Record-Route, Route, Supported, Timestamp, User-Agent, Organization, Retry-After and Subject.
Request-only headers
Accept, Accept-Encoding/Language, Authorization, Max-Forwards, Priority, Privacy, Proxy-Authorization, Refer-To, Referred-By, Replaces, Require, RAck, Session-Expires, Subscription-State, P-Asserted-Identity and P-Preferred-Identity.
Response-only headers
Proxy-Authenticate, Server, Unsupported, Warning, WWW-Authenticate and RSeq.
Message body headers
Allow, Content-Encoding, Content-Disposition, Content-Length, Content-Type, Expires and MIME-Version.
Record-Route / Route: these mechanisms allow proxies to remain involved in the signaling path for the rest of a dialog, which can be important for routing, policy and other network functions.
7. Related Protocols
SDP — Session Description Protocol
SDP provides a description syntax for session and media information. It describes items such as IP address, port, media type/encoding, session information and timing. Common SDP fields include:
v=— versiono=— origin/session IDs=— session namec=— connection addresst=— timingm=— media, port, protocol and formata=— attributes such asrtpmap
RTP / RTCP
RTP carries the actual media stream. RTCP provides control and quality-related feedback. RTP/AVP maps codec numbers used in SDP media descriptions.
PSTN interworking
Related signaling technologies include SS7/ISUP, CAS and SIP-T, which can be used for PSTN interworking.
UPnP
UPnP can be relevant to local network device/service discovery and some SIP device/NAT environments.
8. Comparison to H.323
H.323 is an ITU-T umbrella recommendation for multimedia communication over packet networks. It includes components such as terminals, gatekeepers, gateways and MCUs.
A gatekeeper manages a zone and can handle registration, admission, address translation and bandwidth control. H.323 uses mechanisms including RAS, H.225/Q.931 and H.245.
- SIP: text-based and IETF standardized.
- H.323: binary and based on ASN.1/PER encoding.
- SIP borrows from Internet conventions such as HTTP/SMTP.
- H.323 is more closely associated with traditional telephony concepts such as Q.931 and H.245.
- SIP is generally viewed as simpler, modular and extensible, while H.323 is more complete in some legacy telephony environments but heavier.
- Both can interoperate through gateways.
9. Wireless and 3GPP
3GPP adopted SIP for IMS (IP Multimedia Subsystem) call control.
Important mobility concepts include:
- Terminal mobility: the device changes network attachment.
- Personal mobility: a stable identity such as a SIP URI can be associated with different devices/contacts.
- Service mobility: services remain consistent across devices.
SIP's REGISTER method supports personal mobility by rebinding an AOR to a new Contact as the device or network attachment changes.
3GPP/IMS deployments also use SIP extensions and headers such as:
- P-Asserted-Identity
- P-Preferred-Identity
- Service-Route
- Path
- Other P-headers used in IMS for identity assertion and route discovery.
SIP learning path
Use the sections above to move from SIP fundamentals to messages, headers, protocols and 3GPP/IMS concepts.