Understanding the SIP Protocol: Difference between revisions

From VoIPmonitor.org
No edit summary
 
(Rewrite: condensed verbose sections, preserved all tables/diagrams, reduced from 1157 to 663 lines)
 
(8 intermediate revisions by 3 users not shown)
Line 1: Line 1:
__NOTOC__
__NOTOC__
Session Initiation Protocol (SIP) is an application-layer signaling protocol designed for creating, modifying, and terminating multimedia sessions over IP networks. These sessions can include Internet telephone calls (VoIP), video conferences, or any combination of multimedia streams. SIP itself handles the signaling and control portion - it establishes the session parameters - while the actual media (audio, video, etc.) is carried over separate protocols (typically RTP). SIP messages are text-based (similar to HTTP) and use a request/response model. SIP invitations to sessions carry session descriptions (usually using the SDP protocol) so that participants can agree on media types and formats. A key design goal of SIP is protocol agility: it is independent of the underlying transport (UDP, TCP, TLS, etc. on port 5060/5061 by default) and of the type of session being established.
{| class="wikitable" style="width:100%; background:#f8f9fa; border:2px solid #00A7E3; margin-bottom:20px;"
|-
! colspan="3" style="background:#00A7E3; color:white; font-size:1.2em; padding:10px;" | Quick Navigation
|-
! style="width:33%; background:#e0f4fc; padding:8px; vertical-align:top;" | Architecture & Basics
! style="width:33%; background:#fef3e2; padding:8px; vertical-align:top;" | Messages & Call Flow
! style="width:33%; background:#f1f5f9; padding:8px; vertical-align:top;" | Advanced Topics
|-
| style="vertical-align:top; padding:10px;" |
'''Core Components'''
* [[#User Agent (UA)|User Agent (UAC/UAS)]]
* [[#Proxy Server|Proxy Server]]
* [[#Registrar|Registrar]]
* [[#Back-to-Back User Agent (B2BUA)|B2BUA]]
 
'''Addressing & Transport'''
* [[#Addressing|SIP URIs]]
* [[#Transport|UDP/TCP/TLS/WebSocket]]
| style="vertical-align:top; padding:10px;" |
'''SIP Methods'''
* [[#Core SIP Methods|INVITE, ACK, BYE, CANCEL]]
* [[#Extension Methods|PRACK, REFER, SUBSCRIBE]]
 
'''Response Codes'''
* [[#SIP Response Codes|1xx-6xx Classes]]
 
'''Call Flows'''
* [[#SIP Call Flow Example|Basic Call Setup]]
* [[#Canceling a Call|CANCEL Flow]]
| style="vertical-align:top; padding:10px;" |
'''Core Concepts'''
* [[#Transaction|Transactions]]
* [[#Dialog|Dialogs]]
* [[#Session|Sessions]]
 
'''Registration'''
* [[#Registration and Location Service|REGISTER Flow]]


SIP was originally defined in RFC 2543 and later refined in RFC 3261 (2002), which became the core SIP standard. Over time, numerous extension RFCs have expanded SIP's capabilities (for reliability, events, IM, security, etc.), making SIP a broad and powerful framework for signaling.
'''Extensions'''
* [[#Reliability of Provisional Responses (RFC 3262)|PRACK (100rel)]]
* [[#Session Timer (RFC 4028)|Session Timers]]
* [[#REFER Method (RFC 3515)|Call Transfer]]


== SIP Architecture and Core Components ==
'''Reference'''
* [[#Key RFCs|RFC Links]]
|}


SIP is a peer-to-peer protocol with a client-server design for message exchange. Its architecture defines several types of network entities, each with specific roles:
'''Session Initiation Protocol (SIP)''' is an application-layer signaling protocol for creating, modifying, and terminating multimedia sessions over IP. SIP handles signaling; actual media uses RTP. Messages are text-based (like HTTP) using a request/response model with session descriptions in SDP.


=== User Agent (UA) ===
Core specification: [https://datatracker.ietf.org/doc/html/rfc3261 RFC 3261] (2002). Extended by numerous RFCs for reliability, events, IM, security, etc.


A UA is an endpoint in SIP, typically a user's device or software (softphone). It represents an end system and can function as both a client and a server. A UA has two logical sub-roles:
== SIP Architecture ==


* '''User Agent Client (UAC)''' - initiates requests
<kroki lang="plantuml">
* '''User Agent Server (UAS)''' - responds to requests
@startuml
title SIP Architecture Components
skinparam backgroundColor #ffffff
skinparam defaultFontColor #1e293b
skinparam ArrowColor #64748b
skinparam componentStyle rectangle


For example, if Alice's phone calls Bob's phone, Alice's UA acts as a UAC (sending an INVITE request) and Bob's UA acts as a UAS (receiving the INVITE and sending a response). Once a session is established, the roles can flip for each new transaction (e.g. Bob's phone sending a BYE will be UAC for that request and Alice's phone UAS to respond).
skinparam component {
    BackgroundColor #e0f4fc
    BorderColor #00A7E3
}


=== Proxy Server ===
skinparam database {
    BackgroundColor #fef3e2
    BorderColor #f78d1d
}


A SIP proxy is an intermediary that routes SIP requests and responses on behalf of UAs. When a UA sends a request to a SIP address, it typically goes to a proxy server in the domain, which then forwards it towards the destination. Proxies handle tasks like:
cloud "Internet / IP Network" as internet


* Routing logic (determining the next hop or target for a request)
component "User Agent\n(UAC/UAS)" as ua1
* Enforcing policies
component "User Agent\n(UAC/UAS)" as ua2
* Authentication
component "Proxy Server" as proxy
component "Registrar" as registrar
database "Location\nService" as location


A request may traverse multiple proxies in sequence. Each proxy may add or modify certain headers (like Via or Record-Route) before forwarding. Responses automatically follow the reverse path of the request through those proxies.
ua1 --> proxy : SIP Requests
proxy --> ua2 : SIP Requests
proxy <-- ua2 : SIP Responses
ua1 <-- proxy : SIP Responses


Proxies can be:
ua1 --> registrar : REGISTER
* '''Stateful''' - maintaining transaction state, allowing forks and smarter handling
registrar --> location : Store binding
* '''Stateless''' - simply forwarding messages and forgetting them
proxy --> location : Query user location
@enduml
</kroki>


=== Registrar ===
=== User Agent (UA) ===


A registrar is a server that handles user registration. UAs use the REGISTER method to sign in with a SIP service, providing their address and current location (IP address or forwarding address). The registrar accepts REGISTER requests and stores the information in a location service (a database of user addresses) for its domain. This allows proxies to later look up where a user is currently reachable. In essence, a registrar binds a user's permanent SIP URI (their Address-of-Record like <code>sip:alice@atlanta.com</code>) to the Contact address of their device.
An endpoint (softphone, IP phone) that initiates or receives calls. Has two roles:
* '''UAC (User Agent Client)''' - initiates requests (caller)
* '''UAS (User Agent Server)''' - responds to requests (callee)


=== Redirect Server ===
Roles flip depending on direction - BYE sender becomes UAC for that transaction.


A redirect server is a UAS that does not forward requests but instead sends back a special 3xx redirect response informing the UAC of a different route or address to try. For example, if a user has moved to a different domain, a redirect server might respond with "302 Moved Temporarily" and the new contact address. The UAC then sends a new request to that address.
=== Proxy Server ===


=== Back-to-Back User Agent (B2BUA) ===
Intermediary that routes SIP requests/responses on behalf of UAs. Performs routing logic, policy enforcement, authentication. Can be:
* '''Stateful''' - maintains transaction state, can fork requests to multiple destinations
* '''Stateless''' - simply forwards and forgets


A B2BUA is an entity that acts as a UA on both sides of a call - effectively terminating the SIP dialog on one side and creating a new one on the other side. Unlike a proxy, which passes messages along, a B2BUA maintains full state of the call and can perform deep packet inspection or modification. It behaves like a UAS to the caller and as a UAC to the callee, bridging the two call legs. This is used for scenarios like protocol interworking, media handling, or enforce policies where a proxy's limited role isn't enough.
Adds Via and optionally Record-Route headers before forwarding.


=== Addressing ===
=== Registrar ===


SIP addresses are in the form of Uniform Resource Identifiers (URI). A user's public address-of-record looks like an email (e.g. <code>sip:alice@atlanta.com</code>). This URI can be resolved to the user's current Contact address via the registrar's location service.
Handles REGISTER requests - stores user's current location (IP/port) in the Location Service database. Maps Address-of-Record (AOR) like <code>sip:alice@atlanta.com</code> to Contact address of device.


SIP URIs can also embed telephone numbers (e.g. <code>sip:1234567890@pstn.provider.net</code>) and may use a <code>tel:</code> URI scheme for phone numbers. There is also a secure form <code>sips:</code> (SIP Secure) which mandates that the request be sent over a secure transport (TLS) end-to-end.
=== Back-to-Back User Agent (B2BUA) ===


SIP relies on the DNS infrastructure for server location: the procedures in RFC 3263 define that the client will use DNS SRV records, NAPTR records, and A/AAAA records to find the SIP server for the target domain.
Acts as UAS to caller and UAC to callee, terminating one dialog and creating another. Common in PBX and SBC systems. Unlike proxies, maintains full call state and can modify signaling/media.


=== Transport and Network ===
=== Addressing ===


SIP messages can be transported over:
{| class="wikitable"
* '''UDP''' - most common for telephony
|-
* '''TCP'''
! URI Scheme !! Description !! Example
* '''TLS-encrypted TCP''' - for secure SIP
|-
* '''SCTP''' or '''WebSockets''' - e.g. SIP over WebSocket in web apps
| <code>sip:</code> || Standard SIP URI || <code>sip:alice@atlanta.com</code>
|-
| <code>sips:</code> || Secure SIP (TLS required) || <code>sips:alice@atlanta.com</code>
|-
| <code>tel:</code> || Telephone number ([https://datatracker.ietf.org/doc/html/rfc3966 RFC 3966]) || <code>tel:+1-555-123-4567</code>
|}


The protocol includes mechanisms to handle issues like fragmentation (large messages should use TCP) and network failures (via retransmission timers especially on UDP). NAT traversal can be challenging for SIP, because SIP messages and SDP often carry IP addresses and expect end-to-end connectivity. Extensions like rport (RFC 3581) and "outbound" (RFC 5626) address some of these issues.
SIP uses DNS SRV/NAPTR records ([https://datatracker.ietf.org/doc/html/rfc3263 RFC 3263]) to locate servers for a domain.


== SIP Messages: Requests and Responses ==
=== Transport ===


SIP is a text-based protocol that exchanges messages in a format similar to HTTP. There are two types of SIP messages:
{| class="wikitable"
|-
! Transport !! Port !! Notes
|-
| UDP || 5060 || Most common, requires retransmission handling
|-
| TCP || 5060 || For large messages, reliable delivery
|-
| TLS || 5061 || Encrypted signaling
|-
| WebSocket || 80/443 || For web applications ([https://datatracker.ietf.org/doc/html/rfc7118 RFC 7118])
|}


* '''Requests''' (methods) - sent by clients to initiate an action
== SIP Messages ==
* '''Responses''' - sent by servers (or UAs) to convey the result of that request


Each SIP message consists of a start line, zero or more header fields, a blank line, and an optional message body.
Two types: '''Requests''' (methods) and '''Responses''' (status codes). Format: start line, headers, blank line, optional body (usually SDP).


=== Core SIP Methods ===
=== Core SIP Methods ===
The core SIP specification (RFC 3261) defined six basic methods:


{| class="wikitable"
{| class="wikitable"
|-
|-
! Method !! Description
! Method !! Purpose !! Creates Dialog?
|-
|-
| '''INVITE''' || Establishes a session (initiate a call). Used to invite participants to a session with SDP for media setup.
| '''INVITE''' || Initiate session/call (carries SDP offer) || Yes
|-
|-
| '''ACK''' || Confirms receipt of a final response to an INVITE. Used only with INVITE.
| '''ACK''' || Confirm receipt of INVITE final response || No
|-
|-
| '''BYE''' || Terminates an established session (hangs up a call).
| '''BYE''' || Terminate established session || No (ends dialog)
|-
|-
| '''CANCEL''' || Cancels a pending request (typically used to cancel an unanswered INVITE).
| '''CANCEL''' || Cancel pending INVITE before answer || No
|-
|-
| '''REGISTER''' || Registers the UA's address with a SIP server.
| '''REGISTER''' || Register contact with server || No
|-
|-
| '''OPTIONS''' || Queries capabilities of a server or UA. Often used for keep-alive or diagnostics.
| '''OPTIONS''' || Query capabilities (ping/keepalive) || No
|}
|}


=== Extension Methods ===
=== Extension Methods ===
Several extension methods have been introduced by various RFCs:


{| class="wikitable"
{| class="wikitable"
|-
|-
! Method !! RFC !! Description
! Method !! RFC !! Purpose
|-
|-
| '''PRACK''' || RFC 3262 || Provisional Acknowledgment - acknowledges reliable provisional responses (1xx).
| '''PRACK''' || [https://datatracker.ietf.org/doc/html/rfc3262 3262] || Acknowledge reliable provisional responses
|-
|-
| '''SUBSCRIBE''' || RFC 3265 || Subscribes to an event on a server (presence, message waiting, etc.).
| '''SUBSCRIBE''' || [https://datatracker.ietf.org/doc/html/rfc3265 3265] || Subscribe to event notifications
|-
|-
| '''NOTIFY''' || RFC 3265 || Sends an event notification to a subscriber.
| '''NOTIFY''' || [https://datatracker.ietf.org/doc/html/rfc3265 3265] || Send event notification
|-
|-
| '''PUBLISH''' || RFC 3903 || Publishes event state (e.g., presence information) to a server.
| '''PUBLISH''' || [https://datatracker.ietf.org/doc/html/rfc3903 3903] || Publish event state (presence)
|-
|-
| '''INFO''' || RFC 2976 || Sends mid-session information (often DTMF tones).
| '''INFO''' || [https://datatracker.ietf.org/doc/html/rfc2976 2976] || Mid-session info (DTMF)
|-
|-
| '''REFER''' || RFC 3515 || Asks recipient to issue a new request (call transfer).
| '''REFER''' || [https://datatracker.ietf.org/doc/html/rfc3515 3515] || Request call transfer
|-
|-
| '''MESSAGE''' || RFC 3428 || Conveys instant message within or outside a dialog.
| '''MESSAGE''' || [https://datatracker.ietf.org/doc/html/rfc3428 3428] || Instant message
|-
|-
| '''UPDATE''' || RFC 3311 || Modifies session parameters before final INVITE response.
| '''UPDATE''' || [https://datatracker.ietf.org/doc/html/rfc3311 3311] || Modify session in early dialog
|}
|}


=== SIP Response Codes ===
=== SIP Response Codes ===
SIP responses are categorized by their class (hundreds digit):


{| class="wikitable"
{| class="wikitable"
|-
|-
! Class !! Type !! Description !! Examples
! Class !! Meaning !! Common Codes
|-
|-
| '''1xx''' || Informational || Provisional - request is being processed || 100 Trying, 180 Ringing, 183 Session Progress
| '''1xx''' || Provisional || 100 Trying, 180 Ringing, 183 Session Progress
|-
|-
| '''2xx''' || Success || Request succeeded || 200 OK
| '''2xx''' || Success || 200 OK, 202 Accepted
|-
|-
| '''3xx''' || Redirection || Try different location || 301 Moved Permanently, 302 Moved Temporarily
| '''3xx''' || Redirection || 301 Moved Permanently, 302 Moved Temporarily
|-
|-
| '''4xx''' || Client Error || Bad request or cannot fulfill || 400 Bad Request, 401 Unauthorized, 404 Not Found, 486 Busy Here
| '''4xx''' || Client Error || 400 Bad Request, 401 Unauthorized, 404 Not Found, 486 Busy, 487 Request Terminated
|-
|-
| '''5xx''' || Server Error || Server failed to fulfill valid request || 500 Server Internal Error, 503 Service Unavailable
| '''5xx''' || Server Error || 500 Internal Error, 503 Service Unavailable
|-
|-
| '''6xx''' || Global Error || Cannot be fulfilled anywhere || 603 Decline, 604 Does Not Exist Anywhere
| '''6xx''' || Global Failure || 603 Decline, 604 Does Not Exist Anywhere
|}
|}


Only final responses (2xx-6xx) terminate a SIP transaction. Provisional (1xx) responses are informative.
Only final responses (2xx-6xx) terminate a transaction. Provisional (1xx) are informative only.


== SIP Message Structure and Headers ==
== SIP Headers ==
 
SIP messages are structured like HTTP messages. After the start line, each message has header fields in "Name: value" format.
 
=== Key SIP Headers ===


{| class="wikitable"
{| class="wikitable"
|-
|-
! Header !! Description
! Header !! Purpose !! Example
|-
|-
| '''Via''' || Lists network path taken by request. Each proxy adds a Via header. Used to route responses back. Contains branch identifier for duplicate detection.
| '''Via''' || Route responses back; branch ID for matching || <code>Via: SIP/2.0/UDP host;branch=z9hG4bK...</code>
|-
|-
| '''From''' || Originator's identity (caller). Contains display name, SIP URI, and tag parameter.
| '''From''' || Caller identity + tag || <code>From: "Alice" <sip:alice@atlanta.com>;tag=1234</code>
|-
|-
| '''To''' || Intended recipient's identity (callee). Tag added by UAS in response.
| '''To''' || Callee identity + tag (added in response) || <code>To: "Bob" <sip:bob@biloxi.com>;tag=5678</code>
|-
|-
| '''Call-ID''' || Globally unique identifier for the call/session.
| '''Call-ID''' || Unique call identifier || <code>Call-ID: a84b4c76e66710@host</code>
|-
|-
| '''CSeq''' || Sequence number and method name for ordering requests.
| '''CSeq''' || Request sequence number + method || <code>CSeq: 314159 INVITE</code>
|-
|-
| '''Contact''' || Direct URI where UA wants to be reached for future requests.
| '''Contact''' || Direct reachable address || <code>Contact: <sip:alice@192.0.2.4:5060></code>
|-
|-
| '''Max-Forwards''' || Hop count limiter (similar to IP TTL). Default: 70.
| '''Max-Forwards''' || Hop limit (default 70) || <code>Max-Forwards: 70</code>
|-
|-
| '''Content-Type''' || MIME type of message body (usually <code>application/sdp</code>).
| '''Content-Type''' || Body MIME type || <code>Content-Type: application/sdp</code>
|-
|-
| '''Content-Length''' || Size of message body in bytes.
| '''Record-Route''' || Proxy stays in signaling path || <code>Record-Route: <sip:proxy;lr></code>
|-
| '''Authorization''' || Authentication credentials || <code>Authorization: Digest username="alice"...</code>
|}
|}


=== Additional Important Headers ===
=== Dialog Identification ===


* '''Record-Route / Route''' - Used by proxies to maintain themselves in the dialog path
A SIP dialog is uniquely identified by: '''Call-ID''' + '''From-tag''' + '''To-tag'''
* '''Authorization / WWW-Authenticate''' - HTTP Digest authentication (challenge-response)
* '''Supported / Require''' - Indicate supported or required SIP extensions


=== Message Body ===
=== Example: INVITE with SDP ===


The body is separated from headers by a blank line. In call setup, the body is usually an '''SDP (Session Description Protocol)''' offer or answer describing media streams (audio/video), codecs, IP addresses, and ports.
<pre>
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
 
v=0
o=alice 2890844526 2890844526 IN IP4 pc33.atlanta.com
s=Session SDP
c=IN IP4 pc33.atlanta.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
</pre>


The '''offer/answer model''' (RFC 3264) means one party offers media parameters in INVITE, and the other answers with their selection in 200 OK.
=== SDP Quick Reference ===
 
{| class="wikitable"
|-
! Line !! Meaning
|-
| <code>v=0</code> || SDP version (always 0)
|-
| <code>o=</code> || Origin: username, session-id, version, address
|-
| <code>c=</code> || Connection: where to send media (IP)
|-
| <code>m=audio 49172 RTP/AVP 0</code> || Media: type, port, protocol, payload types
|-
| <code>a=rtpmap:0 PCMU/8000</code> || Attribute: payload 0 = G.711 μ-law
|-
| <code>a=sendrecv</code> || Direction: bidirectional
|}


== SIP Call Flow Example ==
== SIP Call Flow Example ==
This example shows the "SIP trapezoid" - Alice calls Bob through their domain proxy servers.


<kroki lang="plantuml">
<kroki lang="plantuml">
@startuml
@startuml
title Basic SIP Call Flow (Trapezoid)
title Basic SIP Call Flow (Trapezoid)
 
skinparam backgroundColor #ffffff
skinparam backgroundColor #f8fafc
skinparam defaultFontColor #1e293b
skinparam defaultFontColor #1e293b
skinparam ArrowColor #64748b
skinparam ArrowColor #64748b
skinparam sequenceArrowThickness 2
skinparam sequenceArrowThickness 2
skinparam roundcorner 5
skinparam ParticipantPadding 20
skinparam ParticipantPadding 20


Line 200: Line 300:
}
}


participant "Alice's\nsoftphone" as Alice
participant "Alice" as Alice
participant "atlanta.com\nproxy" as Atlanta
participant "atlanta.com\nproxy" as Atlanta
participant "biloxi.com\nproxy" as Biloxi
participant "biloxi.com\nproxy" as Biloxi
participant "Bob's\nSIP phone" as Bob
participant "Bob" as Bob


Alice -> Atlanta : INVITE sip:bob@biloxi.com
Alice -> Atlanta : INVITE sip:bob@biloxi.com
Line 214: Line 314:
Alice <-- Atlanta : 180 Ringing
Alice <-- Atlanta : 180 Ringing
Biloxi <-- Bob : 200 OK (SDP answer)
Biloxi <-- Bob : 200 OK (SDP answer)
Atlanta <-- Biloxi : 200 OK (SDP answer)
Atlanta <-- Biloxi : 200 OK
Alice <-- Atlanta : 200 OK (SDP answer)
Alice <-- Atlanta : 200 OK
Alice -> Bob : ACK
Alice -> Bob : ACK
Alice <-> Bob : RTP media session established
Alice <-> Bob : RTP media session
Bob -> Alice : BYE
Bob -> Alice : BYE
Alice --> Bob : 200 OK (to BYE)
Alice --> Bob : 200 OK
 
@enduml
@enduml
</kroki>
</kroki>


=== Call Flow Steps ===
{| class="wikitable"
|-
! Step !! Message !! Purpose
|-
| 1 || INVITE || Initiate call (with SDP offer)
|-
| 2 || 100 Trying || Stop retransmissions (proxy-generated)
|-
| 3 || 180 Ringing || Callee alerting
|-
| 4 || 200 OK || Call answered (with SDP answer)
|-
| 5 || ACK || Confirm 200 OK receipt
|-
| 6 || RTP || Media session
|-
| 7 || BYE || End call
|-
| 8 || 200 OK || Confirm termination
|}


# '''INVITE''' - Alice's softphone sends INVITE to Bob's SIP URI through her proxy (atlanta.com). Includes SDP offer with proposed media parameters.
=== Canceling a Call ===


# '''Routing''' - Atlanta proxy forwards INVITE to biloxi.com after DNS lookup (RFC 3263). Adds Via and Record-Route headers.
<kroki lang="plantuml">
@startuml
title SIP CANCEL Flow
skinparam backgroundColor #ffffff
skinparam defaultFontColor #1e293b
skinparam ArrowColor #64748b
skinparam sequenceArrowThickness 2


# '''100 Trying''' - Proxies send this provisional response to stop retransmissions. Indicates "I got the INVITE, working on it."
skinparam participant {
    BackgroundColor #e0f4fc
    BorderColor #00A7E3
}


# '''Proxy to UAS''' - Biloxi proxy forwards INVITE to Bob's registered Contact address.
participant "Alice" as Alice
participant "Proxy" as Proxy
participant "Bob" as Bob


# '''180 Ringing''' - Bob's phone sends this when alerting (ringing). Travels back through proxies to Alice.
Alice -> Proxy : INVITE
Proxy -> Bob : INVITE
Alice <-- Proxy : 100 Trying
Proxy <-- Bob : 180 Ringing
Alice <-- Proxy : 180 Ringing


# '''200 OK''' - Bob answers. His phone sends 200 OK with SDP answer containing agreed media parameters. Dialog is established.
note over Alice: Decides to cancel


# '''ACK''' - Alice confirms receipt of 200 OK. Sent end-to-end (possibly through Record-Route path).
Alice -> Proxy : CANCEL
Proxy -> Bob : CANCEL
Alice <-- Proxy : 200 OK (for CANCEL)
Proxy <-- Bob : 200 OK (for CANCEL)
Proxy <-- Bob : 487 Request Terminated
Alice <-- Proxy : 487 Request Terminated
Alice -> Proxy : ACK (for 487)
Proxy -> Bob : ACK (for 487)
@enduml
</kroki>


# '''Media Session''' - RTP audio/video streams flow directly between endpoints.
CANCEL uses same Call-ID and CSeq number as the INVITE. Only effective before final response - ignored if 200 OK already sent.


# '''BYE''' - Bob hangs up. BYE sent within existing dialog (same Call-ID and tags) through the established path.
== Transactions, Dialogs, and Sessions ==


# '''200 OK (BYE)''' - Alice acknowledges termination. Call ends.
<kroki lang="plantuml">
@startuml
title SIP Call: Transactions within a Dialog
skinparam backgroundColor #ffffff
skinparam defaultFontColor #1e293b
skinparam ArrowColor #64748b


=== Canceling a Call ===
skinparam participant {
    BackgroundColor #e0f4fc
    BorderColor #00A7E3
}


If Alice hangs up before Bob answers, her UA sends a '''CANCEL''' request:
participant "Alice" as A
* Uses same Call-ID and CSeq (with method "CANCEL")
participant "Bob" as B
* Each proxy responds with 200 OK immediately
* Bob's UAS sends 487 Request Terminated for the original INVITE
* CANCEL only works before call is answered


== Transactions, Dialogs, and Sessions ==
== Dialog Established ==


=== Transaction ===
box "INVITE Transaction" #e0f4fc
A -> B : INVITE (CSeq: 1)
A <-- B : 100 Trying
A <-- B : 180 Ringing
A <-- B : 200 OK
end box


A '''transaction''' is a single request and all its responses. It's the fundamental unit of message handling:
box "ACK Transaction" #fef3e2
A -> B : ACK
end box


* Identified by CSeq, request method, and branch ID
|||
* Provisional responses (1xx) don't end transactions
note over A, B #f1f5f9: '''SESSION ACTIVE'''\n(RTP Media Flowing)
* Final responses (2xx-6xx) complete transactions
|||
* Handles retransmissions and timeouts


=== Dialog ===
box "BYE Transaction" #e0f4fc
B -> A : BYE (CSeq: 1)
B <-- A : 200 OK
end box


A '''dialog''' is a peer-to-peer relationship between two UAs that persists over time:
== Dialog Terminated ==
@enduml
</kroki>


* Created by successful INVITE transaction
{| class="wikitable"
* Identified by: Call-ID + From tag + To tag
|-
* Maintains: route set, remote target (Contact), sequence expectations
! Concept !! Scope !! Lifetime !! Identified By
* Lasts until BYE or termination
|-
* Allows in-dialog requests: BYE, re-INVITE, UPDATE, INFO, etc.
| '''Transaction''' || Single request/response || Seconds || Branch ID, CSeq, Method
|-
| '''Dialog''' || UA-to-UA relationship || Minutes-hours || Call-ID + From-tag + To-tag
|-
| '''Session''' || Media exchange || Duration of call || SDP negotiation
|}


=== Session ===
=== ACK Behavior ===


A '''session''' is the actual media session negotiated via SDP and carried via RTP. It's what users experience as "the call."
{| class="wikitable"
|-
! !! For 2xx Response !! For non-2xx Response
|-
| Part of INVITE transaction? || No (separate) || Yes (same)
|-
| UAS behavior if no ACK || Retransmits 200 OK || Retransmits error response
|-
| Routing || End-to-end via Route set || Hop-by-hop
|}
 
== Registration ==
 
<kroki lang="plantuml">
@startuml
title SIP Registration with Authentication
skinparam backgroundColor #ffffff
skinparam defaultFontColor #1e293b
skinparam ArrowColor #64748b
skinparam sequenceArrowThickness 2


== Registration and Location Service ==
skinparam participant {
    BackgroundColor #e0f4fc
    BorderColor #00A7E3
}


Before calls can be made, UAs typically register with their SIP server:
skinparam database {
    BackgroundColor #fef3e2
    BorderColor #f78d1d
}


<pre>
participant "Alice's UA" as Alice
REGISTER sip:atlanta.com SIP/2.0
participant "Registrar" as Registrar
To: sip:alice@atlanta.com
database "Location\nService" as Location
From: sip:alice@atlanta.com;tag=xyz
Contact: <sip:alice@192.0.2.4:5060>
Expires: 3600
</pre>


Key points:
Alice -> Registrar : REGISTER sip:atlanta.com
* Binds Address-of-Record (AOR) to Contact URI(s)
note right: To: sip:alice@atlanta.com\nContact: <sip:alice@192.0.2.4>
* Authentication via 401 challenge and Authorization header
* Registrations have limited lifetime (Expires header)
* Must be refreshed periodically
* Multiple devices can register for same AOR
* Location Service database stores these bindings


== SIP Extensions and Advanced Features ==
Registrar --> Alice : 401 Unauthorized
note right: WWW-Authenticate: Digest...


=== Reliability of Provisional Responses (RFC 3262) ===
Alice -> Registrar : REGISTER (with Authorization)
Registrar -> Location : Store binding
Registrar --> Alice : 200 OK
note right: Expires: 3600
@enduml
</kroki>


Adds '''PRACK''' method to acknowledge provisional responses reliably:
{| class="wikitable"
* UAS sends 1xx with <code>Require: 100rel</code> and RSeq header
|-
* UAC must respond with PRACK
! Action !! Expires Value !! Result
* Ensures important 180/183 responses aren't lost
|-
| Initial registration || e.g., 3600 || Binding created
|-
| Refresh registration || e.g., 3600 || Binding updated
|-
| Unregister || 0 || Binding removed
|}


=== Offer/Answer Model with SDP (RFC 3264) ===
Registration must be refreshed before expiration. Multiple devices can register same AOR - proxies fork INVITEs to all.


* One party offers media parameters (codecs, IPs, ports)
== SIP Extensions ==
* Other party answers with selection
* INVITE contains offer, 200 OK contains answer
* Or: INVITE without SDP, offer in 200 OK, answer in ACK
* re-INVITE or UPDATE can modify session later


=== Session Timer (RFC 4028) ===
=== Reliability of Provisional Responses (RFC 3262) ===


Keep-alive mechanism for dialogs:
Basic SIP sends 1xx responses unreliably. [https://datatracker.ietf.org/doc/html/rfc3262 RFC 3262] adds '''PRACK''' method to acknowledge provisional responses. UAS includes <code>Require: 100rel</code> and RSeq header; UAC responds with PRACK.
* Negotiated interval for session refresh
* Refresher sends periodic re-INVITE/UPDATE
* Cleans up zombie calls if one side crashes
* Uses Session-Expires header


=== UPDATE Method (RFC 3311) ===
=== Session Timer (RFC 4028) ===


Allows changing session parameters before INVITE completes:
Keep-alive mechanism for dialogs. Refresher sends periodic re-INVITE/UPDATE. If refresh fails, call terminates. Prevents zombie calls when one side crashes. Uses <code>Session-Expires</code> and <code>Min-SE</code> headers.
* Early media negotiations
* Codec changes during ringing
* Session timer refresh in early stage


=== REFER Method (RFC 3515) ===
=== REFER Method (RFC 3515) ===


Used for call transfer:
Used for call transfer. Alice sends Bob <code>REFER</code> with <code>Refer-To: carol@domain</code>. Bob initiates new INVITE to Carol. Transfer result reported via NOTIFY.
* Alice sends Bob REFER with Refer-To: Carol's URI
* Bob's UA initiates new INVITE to Carol
* Result reported via NOTIFY


=== NAT Traversal ===
=== NAT Traversal ===


==== rport (RFC 3581) ====
{| class="wikitable"
* UAC includes <code>Via: ...;rport</code>
|-
* Server sends response to source IP/port (not Via address)
! Extension !! RFC !! Purpose
* Helps responses get through NAT
|-
| '''rport''' || [https://datatracker.ietf.org/doc/html/rfc3581 3581] || Symmetric response routing (send to source IP:port, not Via address)
|-
| '''outbound''' || [https://datatracker.ietf.org/doc/html/rfc5626 5626] || Persistent flows, keep-alives for NAT bindings
|}
 
=== Quick Reference: Extensions ===
 
{| class="wikitable"
|-
! Extension !! RFC !! Key Headers/Methods
|-
| '''100rel''' || 3262 || PRACK, RSeq, RAck
|-
| '''timer''' || 4028 || Session-Expires, Min-SE
|-
| '''replaces''' || 3891 || Replaces header
|-
| '''outbound''' || 5626 || Instance-ID, reg-id
|-
| '''gruu''' || 5627 || Contact with gr parameter
|}
 
== Monitoring and Troubleshooting ==
 
=== What to Monitor ===
 
{| class="wikitable"
|-
! Layer !! What to Track !! Why
|-
| '''Signaling''' || INVITE/BYE timing, response codes, retransmissions || Identifies call setup failures, routing issues
|-
| '''Media (RTP)''' || Packet loss, jitter, latency, MOS || Actual voice quality
|-
| '''Registration''' || REGISTER success/failure || Endpoint reachability
|}
 
=== Common SIP Issues ===


==== Outbound (RFC 5626) ====
{| class="wikitable"
* Persistent connection for registration and incoming requests
|-
* Keep-alive messages (CRLF or STUN pings)
! Issue !! Symptoms !! Cause
* Instance-ID for device identification
|-
* Crucial for mobile devices and NAT-heavy environments
| '''One-way audio''' || Caller hears, callee doesn't (or vice versa) || NAT: SDP contains private IP
|-
| '''Call setup delays''' || Long wait before ringing || DNS problems, proxy timeouts
|-
| '''No ringback tone''' || Silence while waiting for answer || 180→183 conversion without RTP
|-
| '''Auth loops''' || Repeated 401/407 responses || Credential mismatch, realm error
|-
| '''Codec failure''' || 488 Not Acceptable || No common codecs
|}


=== Instant Messaging and Presence (SIP SIMPLE) ===
=== Ringback Tone Issue (180 vs 183) ===


* '''MESSAGE''' method for pager-mode IM
{| class="wikitable"
* '''SUBSCRIBE/NOTIFY''' for presence (RFC 3856)
|-
* '''PUBLISH''' for publishing presence state
! Response !! Behavior !! Audio Source
|-
| '''180 Ringing''' || Callee alerting || Caller generates local ringback
|-
| '''183 Session Progress''' || Early media || Network sends RTP audio
|}


=== Security Mechanisms ===
'''Problem:''' Device converts 180→183 but doesn't send RTP. Caller expects network audio but receives silence.


* '''TLS''' - Transport layer encryption (port 5061, SIPS URI)
'''Diagnosis:'''
* '''HTTP Digest Authentication''' - Challenge-response for registration/calls
# Check SIP History for 183 sent to caller
* '''STIR/SHAKEN''' - Caller ID authentication to prevent spoofing (RFC 8224)
# Check RTP tab for packets after 183
* '''SRTP''' - Secure media via SDES or DTLS-SRTP key exchange
# If RTP present but no ringback: caller device issue
# If no RTP: intermediate device issue - fix SBC/PBX config


== Key RFCs ==
=== Quality Metrics ===


{| class="wikitable"
{| class="wikitable"
|-
|-
! RFC !! Title
! Metric !! Good !! Acceptable !! Poor
|-
|-
| RFC 3261 || SIP: Session Initiation Protocol (core spec)
| '''MOS''' || > 4.0 || 3.5 - 4.0 || < 3.5
|-
|-
| RFC 3262 || Reliability of Provisional Responses (PRACK)
| '''Packet Loss''' || < 1% || 1% - 3% || > 3%
|-
|-
| RFC 3263 || Locating SIP Servers
| '''Jitter''' || < 20ms || 20-50ms || > 50ms
|-
|-
| RFC 3264 || Offer/Answer Model with SDP
| '''Latency''' || < 150ms || 150-300ms || > 300ms
|}
 
== Key RFCs ==
 
{| class="wikitable"
|-
|-
| RFC 3265 || Event Notification Framework (SUBSCRIBE/NOTIFY)
! RFC !! Title !! Category
|-
|-
| RFC 3311 || UPDATE Method
| [https://datatracker.ietf.org/doc/html/rfc3261 3261] || SIP: Session Initiation Protocol || Core
|-
|-
| RFC 3326 || Reason Header
| [https://datatracker.ietf.org/doc/html/rfc3262 3262] || Reliability of Provisional Responses (PRACK) || Reliability
|-
|-
| RFC 3428 || MESSAGE Method (Instant Messaging)
| [https://datatracker.ietf.org/doc/html/rfc3263 3263] || Locating SIP Servers || DNS/Routing
|-
|-
| RFC 3515 || REFER Method
| [https://datatracker.ietf.org/doc/html/rfc3264 3264] || An Offer/Answer Model with SDP || Media
|-
|-
| RFC 3581 || Symmetric Response Routing (rport)
| [https://datatracker.ietf.org/doc/html/rfc3265 3265] || SIP-Specific Event Notification || Events
|-
|-
| RFC 3903 || PUBLISH Method
| [https://datatracker.ietf.org/doc/html/rfc3515 3515] || The REFER Method || Transfer
|-
|-
| RFC 4028 || Session Timers
| [https://datatracker.ietf.org/doc/html/rfc3581 3581] || Symmetric Response Routing (rport) || NAT
|-
|-
| RFC 5411 || A Hitchhiker's Guide to SIP (RFC summary)
| [https://datatracker.ietf.org/doc/html/rfc4028 4028] || Session Timers in SIP || Keep-alive
|-
|-
| RFC 5626 || Managing Client-Initiated Connections (Outbound)
| [https://datatracker.ietf.org/doc/html/rfc5626 5626] || Client-Initiated Connections (Outbound) || NAT
|}
|}


== See Also ==
== See Also ==


* [[VoIP]]
* [[Comprehensive_Guide_to_VoIP_Voice_Quality|VoIP Voice Quality Guide]]
* [[RTP]] - Real-time Transport Protocol
* [[Call_Detail_Record_-_CDR|CDR Detail View]]
* [[SDP]] - Session Description Protocol
* [[Register|SIP Register Monitoring]]
* [[WebRTC]]
* [[Tls|TLS/SRTP Decryption]]
 
== AI Summary for RAG ==
 
'''Summary:''' Session Initiation Protocol (SIP) is an application-layer signaling protocol for establishing, modifying, and terminating multimedia sessions. Architecture includes User Agents (UAC/UAS), Proxy Servers (stateful/stateless routing), Registrars (store user locations), and B2BUAs (full call control). Core methods: INVITE (initiate), ACK (confirm), BYE (terminate), CANCEL (abort), REGISTER (location binding), OPTIONS (capabilities). Response classes: 1xx provisional, 2xx success, 3xx redirect, 4xx client error, 5xx server error, 6xx global failure. Key headers: Via (routing), From/To (identities with tags), Call-ID (unique identifier), CSeq (sequence), Contact (direct address), Record-Route (keep proxy in path). Dialog identified by Call-ID + From-tag + To-tag. Extensions include PRACK (reliable provisionals), session timers (keep-alive), REFER (transfer), rport/outbound (NAT traversal).
 
'''Keywords:''' SIP protocol, INVITE, ACK, BYE, CANCEL, REGISTER, OPTIONS, 180 Ringing, 183 Session Progress, early media, ringback tone, PRACK, dialog, session, transaction, SDP, Call-ID, CSeq, Via, From, To, Contact, Record-Route, rport, outbound, NAT traversal, session timer, REFER, transfer, proxy, registrar, B2BUA, response codes, 200 OK, 401 Unauthorized, 486 Busy, 487 Request Terminated
 
'''Key Questions:'''
* How does SIP establish a call between two endpoints?
* What is the difference between 180 Ringing and 183 Session Progress?
* Why does a caller hear silence instead of ringback tone?
* How do SIP headers like Via, Contact, and Record-Route work?
* What is a SIP dialog and how is it identified?
* What is the difference between transactions, dialogs, and sessions?
* How does SIP registration work?
* What are common SIP troubleshooting issues (one-way audio, auth failures)?
* What SIP extensions exist for NAT traversal?


[[Category:VoIP]]
[[Category:VoIP]]
[[Category:Protocols]]
[[Category:Protocols]]
[[Category:SIP]]
[[Category:SIP]]

Latest revision as of 16:49, 8 January 2026

Quick Navigation
Architecture & Basics Messages & Call Flow Advanced Topics

Core Components

Addressing & Transport

SIP Methods

Response Codes

Call Flows

Core Concepts

Registration

Extensions

Reference

Session Initiation Protocol (SIP) is an application-layer signaling protocol for creating, modifying, and terminating multimedia sessions over IP. SIP handles signaling; actual media uses RTP. Messages are text-based (like HTTP) using a request/response model with session descriptions in SDP.

Core specification: RFC 3261 (2002). Extended by numerous RFCs for reliability, events, IM, security, etc.

SIP Architecture

User Agent (UA)

An endpoint (softphone, IP phone) that initiates or receives calls. Has two roles:

  • UAC (User Agent Client) - initiates requests (caller)
  • UAS (User Agent Server) - responds to requests (callee)

Roles flip depending on direction - BYE sender becomes UAC for that transaction.

Proxy Server

Intermediary that routes SIP requests/responses on behalf of UAs. Performs routing logic, policy enforcement, authentication. Can be:

  • Stateful - maintains transaction state, can fork requests to multiple destinations
  • Stateless - simply forwards and forgets

Adds Via and optionally Record-Route headers before forwarding.

Registrar

Handles REGISTER requests - stores user's current location (IP/port) in the Location Service database. Maps Address-of-Record (AOR) like sip:alice@atlanta.com to Contact address of device.

Back-to-Back User Agent (B2BUA)

Acts as UAS to caller and UAC to callee, terminating one dialog and creating another. Common in PBX and SBC systems. Unlike proxies, maintains full call state and can modify signaling/media.

Addressing

URI Scheme Description Example
sip: Standard SIP URI sip:alice@atlanta.com
sips: Secure SIP (TLS required) sips:alice@atlanta.com
tel: Telephone number (RFC 3966) tel:+1-555-123-4567

SIP uses DNS SRV/NAPTR records (RFC 3263) to locate servers for a domain.

Transport

Transport Port Notes
UDP 5060 Most common, requires retransmission handling
TCP 5060 For large messages, reliable delivery
TLS 5061 Encrypted signaling
WebSocket 80/443 For web applications (RFC 7118)

SIP Messages

Two types: Requests (methods) and Responses (status codes). Format: start line, headers, blank line, optional body (usually SDP).

Core SIP Methods

Method Purpose Creates Dialog?
INVITE Initiate session/call (carries SDP offer) Yes
ACK Confirm receipt of INVITE final response No
BYE Terminate established session No (ends dialog)
CANCEL Cancel pending INVITE before answer No
REGISTER Register contact with server No
OPTIONS Query capabilities (ping/keepalive) No

Extension Methods

Method RFC Purpose
PRACK 3262 Acknowledge reliable provisional responses
SUBSCRIBE 3265 Subscribe to event notifications
NOTIFY 3265 Send event notification
PUBLISH 3903 Publish event state (presence)
INFO 2976 Mid-session info (DTMF)
REFER 3515 Request call transfer
MESSAGE 3428 Instant message
UPDATE 3311 Modify session in early dialog

SIP Response Codes

Class Meaning Common Codes
1xx Provisional 100 Trying, 180 Ringing, 183 Session Progress
2xx Success 200 OK, 202 Accepted
3xx Redirection 301 Moved Permanently, 302 Moved Temporarily
4xx Client Error 400 Bad Request, 401 Unauthorized, 404 Not Found, 486 Busy, 487 Request Terminated
5xx Server Error 500 Internal Error, 503 Service Unavailable
6xx Global Failure 603 Decline, 604 Does Not Exist Anywhere

Only final responses (2xx-6xx) terminate a transaction. Provisional (1xx) are informative only.

SIP Headers

Header Purpose Example
Via Route responses back; branch ID for matching Via: SIP/2.0/UDP host;branch=z9hG4bK...
From Caller identity + tag From: "Alice" <sip:alice@atlanta.com>;tag=1234
To Callee identity + tag (added in response) To: "Bob" <sip:bob@biloxi.com>;tag=5678
Call-ID Unique call identifier Call-ID: a84b4c76e66710@host
CSeq Request sequence number + method CSeq: 314159 INVITE
Contact Direct reachable address Contact: <sip:alice@192.0.2.4:5060>
Max-Forwards Hop limit (default 70) Max-Forwards: 70
Content-Type Body MIME type Content-Type: application/sdp
Record-Route Proxy stays in signaling path Record-Route: <sip:proxy;lr>
Authorization Authentication credentials Authorization: Digest username="alice"...

Dialog Identification

A SIP dialog is uniquely identified by: Call-ID + From-tag + To-tag

Example: INVITE with SDP

INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142

v=0
o=alice 2890844526 2890844526 IN IP4 pc33.atlanta.com
s=Session SDP
c=IN IP4 pc33.atlanta.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

SDP Quick Reference

Line Meaning
v=0 SDP version (always 0)
o= Origin: username, session-id, version, address
c= Connection: where to send media (IP)
m=audio 49172 RTP/AVP 0 Media: type, port, protocol, payload types
a=rtpmap:0 PCMU/8000 Attribute: payload 0 = G.711 μ-law
a=sendrecv Direction: bidirectional

SIP Call Flow Example

Step Message Purpose
1 INVITE Initiate call (with SDP offer)
2 100 Trying Stop retransmissions (proxy-generated)
3 180 Ringing Callee alerting
4 200 OK Call answered (with SDP answer)
5 ACK Confirm 200 OK receipt
6 RTP Media session
7 BYE End call
8 200 OK Confirm termination

Canceling a Call

CANCEL uses same Call-ID and CSeq number as the INVITE. Only effective before final response - ignored if 200 OK already sent.

Transactions, Dialogs, and Sessions

Concept Scope Lifetime Identified By
Transaction Single request/response Seconds Branch ID, CSeq, Method
Dialog UA-to-UA relationship Minutes-hours Call-ID + From-tag + To-tag
Session Media exchange Duration of call SDP negotiation

ACK Behavior

For 2xx Response For non-2xx Response
Part of INVITE transaction? No (separate) Yes (same)
UAS behavior if no ACK Retransmits 200 OK Retransmits error response
Routing End-to-end via Route set Hop-by-hop

Registration

Action Expires Value Result
Initial registration e.g., 3600 Binding created
Refresh registration e.g., 3600 Binding updated
Unregister 0 Binding removed

Registration must be refreshed before expiration. Multiple devices can register same AOR - proxies fork INVITEs to all.

SIP Extensions

Reliability of Provisional Responses (RFC 3262)

Basic SIP sends 1xx responses unreliably. RFC 3262 adds PRACK method to acknowledge provisional responses. UAS includes Require: 100rel and RSeq header; UAC responds with PRACK.

Session Timer (RFC 4028)

Keep-alive mechanism for dialogs. Refresher sends periodic re-INVITE/UPDATE. If refresh fails, call terminates. Prevents zombie calls when one side crashes. Uses Session-Expires and Min-SE headers.

REFER Method (RFC 3515)

Used for call transfer. Alice sends Bob REFER with Refer-To: carol@domain. Bob initiates new INVITE to Carol. Transfer result reported via NOTIFY.

NAT Traversal

Extension RFC Purpose
rport 3581 Symmetric response routing (send to source IP:port, not Via address)
outbound 5626 Persistent flows, keep-alives for NAT bindings

Quick Reference: Extensions

Extension RFC Key Headers/Methods
100rel 3262 PRACK, RSeq, RAck
timer 4028 Session-Expires, Min-SE
replaces 3891 Replaces header
outbound 5626 Instance-ID, reg-id
gruu 5627 Contact with gr parameter

Monitoring and Troubleshooting

What to Monitor

Layer What to Track Why
Signaling INVITE/BYE timing, response codes, retransmissions Identifies call setup failures, routing issues
Media (RTP) Packet loss, jitter, latency, MOS Actual voice quality
Registration REGISTER success/failure Endpoint reachability

Common SIP Issues

Issue Symptoms Cause
One-way audio Caller hears, callee doesn't (or vice versa) NAT: SDP contains private IP
Call setup delays Long wait before ringing DNS problems, proxy timeouts
No ringback tone Silence while waiting for answer 180→183 conversion without RTP
Auth loops Repeated 401/407 responses Credential mismatch, realm error
Codec failure 488 Not Acceptable No common codecs

Ringback Tone Issue (180 vs 183)

Response Behavior Audio Source
180 Ringing Callee alerting Caller generates local ringback
183 Session Progress Early media Network sends RTP audio

Problem: Device converts 180→183 but doesn't send RTP. Caller expects network audio but receives silence.

Diagnosis:

  1. Check SIP History for 183 sent to caller
  2. Check RTP tab for packets after 183
  3. If RTP present but no ringback: caller device issue
  4. If no RTP: intermediate device issue - fix SBC/PBX config

Quality Metrics

Metric Good Acceptable Poor
MOS > 4.0 3.5 - 4.0 < 3.5
Packet Loss < 1% 1% - 3% > 3%
Jitter < 20ms 20-50ms > 50ms
Latency < 150ms 150-300ms > 300ms

Key RFCs

RFC Title Category
3261 SIP: Session Initiation Protocol Core
3262 Reliability of Provisional Responses (PRACK) Reliability
3263 Locating SIP Servers DNS/Routing
3264 An Offer/Answer Model with SDP Media
3265 SIP-Specific Event Notification Events
3515 The REFER Method Transfer
3581 Symmetric Response Routing (rport) NAT
4028 Session Timers in SIP Keep-alive
5626 Client-Initiated Connections (Outbound) NAT

See Also

AI Summary for RAG

Summary: Session Initiation Protocol (SIP) is an application-layer signaling protocol for establishing, modifying, and terminating multimedia sessions. Architecture includes User Agents (UAC/UAS), Proxy Servers (stateful/stateless routing), Registrars (store user locations), and B2BUAs (full call control). Core methods: INVITE (initiate), ACK (confirm), BYE (terminate), CANCEL (abort), REGISTER (location binding), OPTIONS (capabilities). Response classes: 1xx provisional, 2xx success, 3xx redirect, 4xx client error, 5xx server error, 6xx global failure. Key headers: Via (routing), From/To (identities with tags), Call-ID (unique identifier), CSeq (sequence), Contact (direct address), Record-Route (keep proxy in path). Dialog identified by Call-ID + From-tag + To-tag. Extensions include PRACK (reliable provisionals), session timers (keep-alive), REFER (transfer), rport/outbound (NAT traversal).

Keywords: SIP protocol, INVITE, ACK, BYE, CANCEL, REGISTER, OPTIONS, 180 Ringing, 183 Session Progress, early media, ringback tone, PRACK, dialog, session, transaction, SDP, Call-ID, CSeq, Via, From, To, Contact, Record-Route, rport, outbound, NAT traversal, session timer, REFER, transfer, proxy, registrar, B2BUA, response codes, 200 OK, 401 Unauthorized, 486 Busy, 487 Request Terminated

Key Questions:

  • How does SIP establish a call between two endpoints?
  • What is the difference between 180 Ringing and 183 Session Progress?
  • Why does a caller hear silence instead of ringback tone?
  • How do SIP headers like Via, Contact, and Record-Route work?
  • What is a SIP dialog and how is it identified?
  • What is the difference between transactions, dialogs, and sessions?
  • How does SIP registration work?
  • What are common SIP troubleshooting issues (one-way audio, auth failures)?
  • What SIP extensions exist for NAT traversal?
Retrieved from "https://www.voipmonitor.org/doc/index.php?title=Understanding_the_SIP_Protocol&oldid=10165"