What SIP is: history, role in VoIP architecture, RFC 3261 and applications

In the previous course, you learned how live human speech is digitized into G.711, AMR, or Opus codec samples and transmitted across an IP network inside RTP packets every 20 milliseconds. Yet before the very first RTP voice packet can leave a phone, two endpoints on opposite sides of the planet must locate each other, discover their current IP addresses, check whether the called party is free to talk, agree on a common audio codec, and cleanly release network resources when the conversation ends. This entire orchestration is performed by the SIP (Session Initiation Protocol). In this lesson, we explore what SIP is, why it replaced complex legacy telecom protocols, how signaling is strictly separated from the media stream, and where SIP operates today.

Goal and prerequisites

After this lesson, you will be able to:

• define the purpose of the SIP protocol and list its five core session management facets under RFC 3261;
• explain the fundamental separation between the signaling control plane (SIP + SDP) and the media user plane (RTP / RTCP);
• trace the classic SIP Trapezoid (why signaling traverses domain servers while RTP audio flows directly between endpoints);
• compare the SIP architecture (IETF RFC 2543 / RFC 3261) against the legacy ITU-T H.323 suite and identify key SIP deployment domains.

What you need to know in advance: lessons From microphone to IP packets and back (the end-to-end VoIP voice chain), RTP header and packet fields (real-time media delivery over UDP), as well as ipnet lessons covering the TCP/IP stack, UDP/TCP ports, DNS domain resolution, and TLS security.

A real-life task

An enterprise has just migrated its office telephony to VoIP: employees have desk IP phones on the local subnet 192.168.10.0/24, while the corporate PBX signaling server is hosted in a secure cloud data center at 198.51.100.10. The security administrator opened firewall rules allowing all office phones to reach only the cloud server IP 198.51.100.10 on standard port UDP 5060. During a test call between two neighboring desks, both phones ring normaal, caller ID appears on the display, and the call timer starts counting — yet both handsets remain completely silent. To understand why call setup succeeds while audio fails, an engineer must know the exact boundary of SIP responsibility: what signaling handles, and how RTP voice packets travel afterward.

What SIP is and its five core facets

SIP (Session Initiation Protocol) is an application-layer signaling protocol (control plane) designed for creating, modifying, and terminating multimedia sessions between two or more participants over IP networks. A session can be a two-party voice call, a video call, a multiparty conference, or an instant messaging exchange.

By everyday analogy, SIP acts like an executive assistant organizing a meeting: it locates the right participant, rings them to check if they are available, negotiates the language to be spoken and the meeting room number, steps aside while the participants converse directly, and finally records the end of the meeting when everyone hangs up.

According to the core specification IETF RFC 3261 (Section 2), SIP provides five distinct facets for establishing and terminating multimedia communications:

1. User Location: determining the current IP address and port of the end system to be used for communication (since a user might log in from an office desk phone, a home laptop, or a mobile app).
2. User Availability: determining the willingness of the called party to engage in communications (whether the user is free, busy on another call, or away from the phone).
3. User Capabilities: determining the media and media parameters to be used (audio-only vs. audio+video, and agreeing on a shared codec such as G.711, G.722, AMR, or Opus along with UDP ports).
4. Session Setup: "ringing" the called party and establishing session parameters at both the calling and called endpoints.
5. Session Management: including transfer and termination of sessions, modifying session parameters mid-call (such as placing a call on hold or adding video), and invoking services.

Separating signaling and media: why SIP is not "all of VoIP"

The foundational design principle built into SIP by IETF engineers is modularity and strict separation between the control plane (signaling) and the user plane (media). SIP never carries encoded voice samples or video frames inside its own messages. Instead, it operates in concert with dedicated companion protocols:

• SIP (RFC 3261) — the signaling envelope and negotiation state machine: who is calling, who is being called, which servers route the request, and whether the call is accepted. By default, SIP uses port 5060 (for UDP and TCP) and port 5061 (for encrypted TLS).
• SDP (Session Description Protocol, RFC 8866) — a plain-text "media specification sheet" carried inside the body of SIP messages. In the SDP body, an endpoint declares its media IP address, UDP port number, and supported codecs (covered in detail in Section 7 of this course).
• RTP / RTCP (RFC 3550) and SRTP (RFC 3711) — real-time transport protocols that carry the actual voice and video packets directly between endpoints over even-numbered dynamic UDP ports (typically in the 10000–20000 or 16384–32767 range) once SIP negotiation completes.
• DNS (RFC 3263) — the Domain Name System used by phones and proxies to locate a remote domain's signaling server and select the transport protocol.

The SIP Trapezoid

Because signaling and media are decoupled, their packets almost always follow different network paths. This classic routing topology is known as the SIP Trapezoid.

When alice@atlanta.com calls bob@biloxi.com, Alice's phone does not initially know the current IP address of Bob's phone. Therefore, SIP signaling messages travel up the left leg of the trapezoid to the atlanta.com server, across to the biloxi.com server, and down to Bob's phone (steps 1 → 2 → 3). However, as soon as both phones exchange SDP descriptions and learn each other's media IP addresses and ports, the RTP voice stream (step 4, the bottom base of the trapezoid) flows directly between Phone A and Phone B, completely bypassing the signaling servers! This keeps gigabits of audio traffic off the signaling servers and minimizes mouth-to-ear latency.

Worked example breakdown: signaling server load vs media path traffic

Let us calculate the exact byte volume of a two-minute call to see why separating SIP and RTP allows a single compact signaling server to handle tens of thousands of simultaneous calls:

=== Signaling (SIP) vs Media (RTP) Traffic Comparison (1 call, 120 s) ===
1. Control Plane (SIP, port 5060):
   Total messages for entire call:  ~6-8 packets (setup and teardown)
   Average SIP message size:        ~600 bytes
   Total SIP volume over 2 minutes: 7 * 600 = 4,200 bytes (~4.2 KB)
   SIP bandwidth during active talk: 0 bps (SIP is silent during conversation!)

2. User / Media Plane (RTP, G.711 codec, ptime = 20 ms):
   Packet rate per direction:       50 pps (100 pps full duplex)
   Ethernet voice frame size:       218 bytes (160 B audio + 58 B headers)
   Total RTP packets in 120 s:      100 pps * 120 s = 12,000 packets
   Total RTP volume over 2 minutes: 12,000 * 218 = 2,616,000 bytes (~2.62 MB)
   Ratio of RTP volume to SIP:      2,616,000 / 4,200 = 622.8x (623 times larger!)

During an active two-minute call, the signaling server processes only around 4.2 KB of data at call start and call end, whereas 2.62 MB of RTP audio packets flow directly between the two endpoints.

History and evolution: from H.323 and RFC 2543 to RFC 3261

In the mid-1990s, the first VoIP signaling standard was the ITU-T H.323 suite (1996). Rooted in traditional ISDN (Q.931) telephony, H.323 encoded messages in complex binary ASN.1 PER, required opening multiple parallel TCP connections (H.225.0, H.245) for a single call, spanned thousands of pages, and integrated poorly with Internet web services.

In 1996, within the IETF MMUSIC (Multiparty Multimedia Session Control) working group, Henning Schulzrinne and Mark Handley proposed a radically simpler philosophy: design telephony signaling as a human-readable text protocol modeled after HTTP and SMTP.

The standardization of SIP reached two historic milestones:

• March 1999 — RFC 2543: the first official specification of SIP version 2.0 (SIP/2.0), authored by H. Schulzrinne, M. Handley, E. Schooler, and J. Rosenberg. The protocol rapidly gained traction among IP phone vendors and service providers.
• June 2002 — RFC 3261: a comprehensive revision and clarification (authored by J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler) that formally obsoleted RFC 2543. Crucially, to preserve backward compatibility with deployed equipment, the protocol version string inside messages remained SIP/2.0.

Today, SIP is the universal signaling standard across three major telecom domains:

1. Enterprise Telephony (IP-PBX / Unified Communications): connecting desk IP phones, softphones, and video endpoints to corporate call servers (Asterisk, FreeSWITCH, Cisco CUCM).
2. Carrier and Enterprise Interconnects (SIP Trunking): connecting enterprise PBXs to telecom operators and interconnecting carriers, replacing legacy E1 ISDN PRI trunks and SS7 links.
3. 4G and 5G Mobile Core Networks: 3GPP adopted SIP as the core signaling protocol for the IMS (IP Multimedia Subsystem) (covered in a dedicated course in this track), which powers VoLTE in 4G, VoWiFi, and VoNR in 5G networks.

What can go wrong and how to find it

⚠️ Never confuse the SIP signaling path with the RTP media path. Just because two phones can reach the PBX signaling server on port 5060 does not guarantee that those two phones in different subnets or behind NAT can exchange RTP voice packets directly!

Practice

1. Predict. An enterprise has 50 IP phones in subnet 10.10.1.0/24 and 50 IP phones in branch subnet 10.10.2.0/24. Both branches can reach the central SIP proxy 10.10.0.10, but direct routing between 10.10.1.0/24 and 10.10.2.0/24 is blocked by an ACL. What will happen when a user in Branch 1 calls Branch 2 (assuming a classic SIP trapezoid)?
2. Verify. Review the mapping of protocols, planes, and default ports in a standard VoIP call:

=== Protocol Stack in a SIP Call ===
Role / Function           Protocol & Standard   Default Transport and Ports
------------------------  --------------------  ------------------------------
Server discovery          DNS (RFC 3263)        UDP / TCP port 53
Session signaling         SIP (RFC 3261)        UDP / TCP port 5060, TLS 5061
Media capability sheet    SDP (RFC 8866)        Carried inside SIP message body
Voice and video stream    RTP / SRTP (RFC 3550) UDP even ports (10000-20000)
Media quality reports     RTCP (RFC 3550)       UDP odd port (RTP + 1)

3. Explain. Why did the authors of RFC 3261 in June 2002 keep the version string SIP/2.0 instead of incrementing it to SIP/3.0?
4. Modify. Calculate how many bytes of RTP voice traffic (G.711 codec, 218-byte Ethernet frame every 20 ms in each direction) pass through the SIP signaling proxy itself during a 5-minute call when media follows the classic SIP trapezoid directly between phones.
5. Do it yourself ⭐. A telecom carrier handles 1,000 concurrent G.711 calls (each full-duplex RTP call consumes 174.4 kbps at the Ethernet layer). Calculate how much bandwidth the carrier's central SIP signaling server saves because RTP media streams flow directly between border media gateways instead of passing through the signaling server.

Self-check

Question 1. What five core facets of session establishment and management does SIP provide according to RFC 3261 Section 2?

Explanation. SIP provides: 1) User Location (resolving the endpoint's current IP address); 2) User Availability (checking whether the called party is willing/free to talk); 3) User Capabilities (negotiating media types and codecs via SDP); 4) Session Setup (ringing the callee and establishing call parameters); and 5) Session Management (modifying parameters mid-call, transferring, and terminating the session).

Question 2. Which protocol carries the actual digitized voice samples once SIP sets up a call, and what are the default ports for SIP?

Explanation.

Control Plane (Signaling):
  Protocol: SIP (RFC 3261) carrying an SDP (RFC 8866) body
  Default ports: 5060 (UDP and TCP), 5061 (TLS)

User / Media Plane (Voice & Video):
  Protocol: RTP (RFC 3550) or encrypted SRTP (RFC 3711)
  Ports: dynamic even UDP ports negotiated inside the SDP body

Answers to practice:

=== Practice Exercise Solutions ===
Item 1: SIP signaling succeeds via server 10.10.0.10 (both phones ring and connect),
        but once answered there is complete silence because direct RTP between
        10.10.1.0/24 and 10.10.2.0/24 is blocked by the ACL.
Item 3: The version string remained SIP/2.0 to maintain backward compatibility with
        millions of deployed RFC 2543 devices, introducing new features via extensions.
Item 4: 0 bytes! In the classic SIP trapezoid, RTP voice traffic flows directly
        between the endpoints and never traverses the SIP signaling proxy.
Item 5: 1,000 calls * 174.4 kbps = 174,400 kbps = 174.4 Mbps of continuous media
        traffic is offloaded from the central SIP signaling server.

Review and the criterion for moving on

Move on to the next lesson if, without looking at the notes, you can:

• list the five core facets of SIP defined in RFC 3261;
• clearly separate the roles of SIP, SDP, and RTP/RTCP, and state default ports 5060 and 5061;
• sketch the SIP Trapezoid and explain why a call can ring and connect yet have no audio.

Standards and sources

• IETF RFC 3261 (June 2002) — SIP: Session Initiation Protocol (§1–§2, Overview of Operation).
• IETF RFC 2543 (March 1999) — SIP: Session Initiation Protocol (first historical SIP/2.0 specification).
• IETF RFC 8866 (January 2021) — SDP: Session Description Protocol.
• IETF RFC 3550 (July 2003) — RTP: A Transport Protocol for Real-Time Applications.