3.1 SIP Signaling Architecture & Call Flows

3.1 SIP Signaling Architecture & Call Flows

The Session Initiation Protocol (SIP), standardized under RFC 3261, serves as the foundational signaling protocol across enterprise collaboration ecosystems. SIP is an application-layer, text-based control protocol modeled heavily on HTTP and SMTP. It is designed to create, modify, and terminate multimedia sessions including voice over IP (VoIP), video conferencing, and presence.

---

1. Architectural Entities in SIP

SIP defines several functional components that participate in session routing and state management:

User Agent Client (UAC) and User Agent Server (UAS)

• User Agent Client (UAC): The client application that initiates a SIP request (for example, generating an INVITE when an IP phone goes off-hook and dials digits).
• User Agent Server (UAS): The server application that contacts the user upon receiving a SIP request and returns a response on the user's behalf (such as generating 180 Ringing and 200 OK).
• In practice, every SIP endpoint—including Cisco IP Phones, Cisco Unified Border Element (CUBE), and Cisco Unified Communications Manager (CUCM)—is a User Agent (UA) capable of acting as both a UAC and a UAS depending on the transaction direction.

SIP Proxy Server

An intermediary entity that acts as both a server and a client for the purpose of making requests on behalf of other clients. Proxies route requests toward the destination UA:

• Stateless Proxy: Forwards messages independently without maintaining dialog state or transaction timers. Highly scalable, but cannot handle retransmissions or advanced call routing logic.
• Stateful Proxy: Maintains transaction state during the lifetime of a request and response transaction. It can perform parallel or sequential forking and handle transport layer protocol conversion.
• Critical distinction: A proxy does not terminate media streams and does not alter the message body (such as SDP).

SIP Registrar and Location Service

• Registrar: A server that accepts REGISTER requests and places the information it receives (the binding between an Address of Record [AoR] like sip:1001@collab.local and a physical Contact URI like sip:1001@10.1.1.50:5060) into a location database.
• Location Service: Queried by proxy servers and redirect servers to determine the current network contact addresses for a destination user.

Back-to-Back User Agent (B2BUA)

A B2BUA is a logical entity that terminates a SIP dialog on one side (acting as a UAS) and initiates a completely independent SIP dialog on the other side (acting as a UAC).

• Both CUCM and CUBE function as B2BUAs.
• Because a B2BUA terminates both call legs, it maintains full call state, can rewrite SIP headers, can modify or transcode SDP parameters (e.g., converting codecs or bridging IP addresses), and can police media streams. This distinguishes enterprise call managers and session border controllers from simple SIP proxies.

---

2. Core SIP Request Methods

SIP defines a suite of client request methods that govern session setup, maintenance, and teardown:

---

3. SIP Response Code Hierarchy

SIP responses use a 3-digit integer format categorized into six classes:

1xx: Informational — Request received, continuing to process (e.g., 100 Trying, 180 Ringing, 183 Session Progress)
2xx: Success       — Action was successfully received, understood, and accepted (e.g., 200 OK, 202 Accepted)
3xx: Redirection   — Further action needed to complete the request (e.g., 301 Moved Permanently, 302 Moved Temporarily)
4xx: Client Error  — Request contains bad syntax or cannot be fulfilled at this server (e.g., 401 Unauthorized, 404 Not Found)
5xx: Server Error  — Server failed to fulfill an apparently valid request (e.g., 500 Server Internal Error, 503 Service Unavailable)
6xx: Global Failure— Request cannot be fulfilled at any server (e.g., 603 Decline, 604 Does Not Exist Anywhere)

Critical Status Codes Tested in Enterprise Troubleshooting

• 100 Trying: Hop-by-hop informational response sent immediately to quench retransmission timers (Timer A / Timer T1) while the downstream proxy or server processes digit analysis.
• 180 Ringing: Indicates the destination UA is alerting the user. The originating UA typically generates local ringback tone (ring-back tone generator).
• 183 Session Progress: Used when early media must be cut through prior to call answer. It carries an SDP body so the originating UA can play in-band ringback, network intercept messages, or carrier call progress tones.
• 401 Unauthorized: Sent by a registrar or UAS challenging the client for credentials via HTTP digest authentication (WWW-Authenticate header).
• 403 Forbidden: The server understood the request but refuses to fulfill it. Typical causes are a registrar refusing a device it does not recognize, a peer rejecting an untrusted source (CUBE's toll-fraud check rejects untrusted INVITEs with cause 21, signaled as 403), or a deliberate policy block. Digits that match no pattern in the caller's CSS normally produce 404 Not Found (Q.931 cause 1) instead.
• 404 Not Found: The dialed user or URI does not exist within the server's directory or dial plan routing tables.
• 486 Busy Here: The called endpoint is currently engaged on another call and has no available line appearances or call-forwarding targets.
• 488 Not Acceptable Here: The session description (SDP) is unacceptable. This occurs during codec mismatches (e.g., one side offers G.729 only, but the remote endpoint supports only G.711u) or unsupported crypto suites in SRTP.
• 503 Service Unavailable: The server is temporarily unable to process the request due to resource exhaustion, Call Admission Control (CAC) bandwidth limits, or downstream gateway trunk failures.

---

4. SIP Header Structure & Dissection

A standard SIP INVITE message exhibits key headers critical for call tracking and troubleshooting:

INVITE sip:2002@10.1.1.20:5060 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.10:5060;branch=z9hG4bK1a2b3c4d
From: "Alice Smith" <sip:1001@10.1.1.10>;tag=987654321
To: <sip:2002@10.1.1.20>
Call-ID: c0a8010a-00001234-56789abc@10.1.1.10
CSeq: 101 INVITE
Contact: <sip:1001@10.1.1.10:5060;transport=udp>
Max-Forwards: 70
Supported: 100rel, timer, replaces
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK
Content-Type: application/sdp
Content-Length: 238

• Via: Identifies the network transport protocol, IP address, and port where the response must be sent. The branch parameter uniquely identifies the transaction and always begins with the magic cookie z9hG4bK per RFC 3261.
• From: Indicates the logical identity of the caller and includes a unique tag parameter generated by the UAC.
• To: Specifies the intended recipient. The UAS adds a tag parameter to the To header in non-100 responses, forming the complete SIP dialog identifier: (Call-ID, From-tag, To-tag).
• Call-ID: A globally unique identifier for this specific call session, persistent across all transactions within the dialog.
• CSeq (Command Sequence): A traditional 32-bit unsigned integer counter and method name (e.g., 101 INVITE). Retransmissions retain the same CSeq number; new transactions increment the number.
• Contact: The direct IP address and port where subsequent mid-dialog requests (such as re-INVITE, BYE, ACK) must be sent, bypassing intermediary proxies if permitted.

---

5. Mid-Call Signaling: Hold, Resume & Transfer

Call Hold & Resume (re-INVITE)

When a user places an active call on hold:

1. The holding party issues a re-INVITE within the existing dialog (same Call-ID, matching tags, incremented CSeq).
2. The SDP sets the media direction to a=sendonly (the holder may still send media but will not receive it) or a=inactive, or, in the legacy RFC 2543 style, c=0.0.0.0. In a CUCM call, CUCM itself manages hold and connects the held party to a Music on Hold (MOH) source.
3. The held party responds with 200 OK containing an SDP attribute of a=recvonly.
4. When the user resumes the call, the holding party transmits another re-INVITE with a=sendrecv. The held party responds with 200 OK containing a=sendrecv, and bidirectional two-way conversation RTP resumes.

Consultation Call Transfer

An attended or consultative transfer involves three endpoints: the Transferee (Party A), the Transferor (Party B), and the Transfer Target (Party C):

1. A and B are connected: Normal bidirectional RTP session.
2. B puts A on hold: Party B sends re-INVITE with a=sendonly to Party A.
3. B calls C: Party B initiates a second, independent dialog to Party C via a new INVITE.
4. B completes the transfer: Party B sends a REFER request to Party A. The REFER contains a Refer-To header specifying Party C's URI and embeds a Replaces parameter identifying the B-to-C dialog:

   REFER sip:PartyA@10.1.1.50 SIP/2.0
   Refer-To: <sip:PartyC@10.1.1.60?Replaces=b-c-call-id%3Bto-tag%3Dctag%3Bfrom-tag%3Dbtag>
   Referred-By: <sip:PartyB@10.1.1.55>
   

5. A accepts the transfer: Party A responds to B with 202 Accepted and sends a NOTIFY with body SIP/2.0 100 Trying.
6. A invites C: Party A issues an INVITE directly to Party C containing the Replaces header. Party C matches the header to its active call with B and joins Party A.
7. Teardown: Party A sends a final NOTIFY with body SIP/2.0 200 OK to Party B, and Party B sends BYE to Party A to clear the original dialog. Party C, having accepted the INVITE with Replaces, sends BYE to Party B to clear the replaced consultation dialog.