Introduction to SIP Protocol: Architecture, Message Structure, Transactions, and Open‑Source Stacks

Protocol Overview

SIP (Session Initiation Protocol) is a text‑based application‑layer signaling protocol used to initiate, maintain, and terminate multimedia sessions such as VoIP calls, video conferences, and IP‑based media distribution. It works together with SDP (Session Description Protocol) for media description and RTP/RTSP for media transport.

SIP Stack Position

SIP can operate over TCP or UDP. Using SDP information (IP address, port, supported codecs) it establishes and maintains sessions, while RTP/RTCP carry the actual audio‑video streams.

SIP Basics

Main Network Entities

A SIP session involves four primary components: SIP User Agent (UA), SIP Registration Server, SIP Proxy Server, and SIP Redirect Server.

UA (User Agent) is the endpoint that negotiates sessions and can act as a client (UAC) when initiating a request or as a server (UAS) when responding. The same device may play both roles depending on the call direction.

SIP Registration Server

Stores the mapping between a user identifier and its current IP address/port. It enables other entities to locate a user.

SIP Proxy Server

Acts like a gateway, forwarding requests, maintaining state, and routing responses.

SIP Redirect Server

Functions similarly to an HTTP 302 redirect, informing the client of an alternate location for the request.

SIP Message Structure

Message Example

Below are simplified request and response examples (images).

SIP messages consist of a start line, header fields, and an optional body. The start line includes Method, Request‑URL, and SIP‑Version for requests, or SIP‑Version, Status‑Code, and Reason‑Phrase for responses.

Example of a SIP URI:

sip: user[:password]@host:port;

Key methods include INVITE, ACK, BYE, REGISTER, CANCEL, and MESSAGE, each serving a specific role in session control.

Essential Header Fields

Header

Description

Format

Via

Path traversed by the request; used for routing responses

Via: SIP/2.0/UDP host:port;branch=...

From

Identifier of the request originator

From: "Alice"

;tag=...

To

Identifier of the request recipient

To: "Bob"

;tag=...

CSeq

Sequence number of the request

CSeq: 314159 INVITE

Call-ID

Globally unique identifier for the dialog

Call-ID: a84b4c76e66710

Max-Forwards

Maximum number of hops the request may traverse

Max-Forwards: 70

SIP Transaction (Transaction)

A SIP transaction comprises a single request and all responses to that request (including provisional and final responses). Transactions exist on both client and server sides and are managed by state machines. Invite transactions have distinct timers compared to non‑Invite transactions.

Client‑side transaction sends the request; server‑side transaction generates the responses. In most deployments a device acts as both client and server transaction participant.

Relation Between Transaction and Dialog

A dialog is identified by Call‑ID, local tag (from header), and remote tag (to header) and represents a long‑lived association between two UAs. A transaction is limited to a single request and its responses; an ACK to a 200 OK for an INVITE starts a new transaction.

Related RFCs

The SIP protocol is defined primarily in RFC 3261. Additional specifications such as RFC 5411 (SIP‑based location services) and RFC 4566 (SDP) are also relevant.

Open‑Source SIP Stacks

Several open‑source implementations are widely used, e.g., PJSIP, OpenSIPS, Kamailio, and others. A comparative table (image) summarizes their main features.

Conclusion

This overview introduced SIP’s role in signaling, its stack placement, core entities, message format, transaction model, and key RFCs, providing a foundation for further study or practical experimentation using tools such as pjsip, OpenSIPS, or Wireshark.