Skip to main content

Session Initiation Protocol

Session Initiation Protocol (SIP) is a signaling protocol that establishes, modifies, and terminates real-time communication sessions over IP networks, including voice, video, messaging, and related multimedia interactions.

Expanded Explanation

1. Technical Function and Core Characteristics

SIP is an application-layer control protocol that manages the setup, change, and teardown of sessions between endpoints over IP networks. It defines messages, procedures, and header fields for initiating, routing, and managing communication sessions. It operates independently of the underlying transport and media, and commonly uses Session Description Protocol (SDP) to negotiate media characteristics and Real-time Transport Protocol (RTP) to carry the actual media streams.

The protocol uses a text-based request and response model similar to Hypertext Transfer Protocol (HTTP), with defined methods such as INVITE, ACK, BYE, REGISTER, OPTIONS, CANCEL, and responses grouped by status codes. It supports user location, user availability, user capabilities, and call handling features such as forking, redirection, and proxying through registrars, proxies, and redirect servers.

2. Enterprise Usage and Architectural Context

Enterprises use SIP as the control plane for IP telephony, unified communications, contact centers, and conferencing services. It underpins many private branch exchange systems, Session Border Controllers, and carrier interconnects for voice over IP services.

In architecture diagrams, SIP typically operates between user agents, enterprise call control platforms, SIP trunks, and service providers, while separate protocols handle media and quality control. Security teams often integrate Transport Layer Security (TLS) for SIP signaling, along with authentication, topology hiding, and policy enforcement through SBCs and firewalls.

3. Related or Adjacent Technologies

SIP commonly works with the RTP for media transport, the SDP for media negotiation, and Diameter or RADIUS for Authentication, Authorization, and Accounting (AAA). It coexists with legacy SS7 and ISDN signaling through gateways that perform protocol interworking.

Related application-layer protocols include H.323 for multimedia conferencing and WebRTC, which uses JavaScript APIs and underlying signaling mechanisms that often interoperate with existing SIP infrastructures. In carrier and enterprise networks, SIP interacts with Domain Name System (DNS), ENUM, and various management and monitoring tools for routing, number resolution, and service assurance.

4. Business and Operational Significance

SIP enables enterprises to consolidate voice and video communications onto IP infrastructure, which supports centralized management, interoperability across vendors, and integration with collaboration and business applications. It provides a standardized framework that service providers and enterprises can use for interconnection and service delivery.

From an operational standpoint, SIP affects network design, security policy, Quality of Service (QoS) planning, and regulatory compliance for voice recording and lawful intercept. It also factors into migration strategies from time-division multiplexing telephony to IP-based voice and collaboration platforms.

Related Perspectives

CISA issues update on missing IPsec integrity for Verizon IMS SIP signaling

June 2, 2026

Overview VoLTE deployments on Verizon’s IMS network have historically lacked IPsec-based integrity protection for SIP signaling, contravening well-established requirements in 3GPP TS 33.203 and GSMA IR.92. As a result, SIP messages—including registration (REGISTER), call setup (INVITE), and messaging (MESSAGE)—were transmitted in plaintext without cryptographic guarantees of integrity or authenticity. Passive analysis of live traffic over multiple months confirmed the consistent absence of SIP Security Agreement headers and ESP traffic, indicating a systematic configuration decision rather than an isolated anomaly. In response to repeated follow-up inquiries, Verizon stated on [insert date] that integrity support is “currently available at their request” and will be extended to all UEs “starting later this year.” Separately, the researchers recently observed that Apple’s iOS 26.5 carrier bundle (released May 11, 2026) includes IMS IPsec-related configuration entries—an indication that device-side support may now be active or enabled in newer software. While this change is promising, its real-world impact remains uncertain: there is no evidence yet that Verizon has modified its network to enforce IPsec, that the configuration is being activated per session, or that integrity is functionally operational in production deployments. Absent explicit verification (e.g., captured ESP traffic or official confirmation), this may reflect preparatory software changes rather than an end-to-end security upgrade. The vulnerability remains active for the vast majority of Verizon VoLTE users during the unprotected period, and until network-level enforcement is observed and confirmed, the risk of on-path signaling manipulation endures. Description CVE-2026-10629 SIP signaling stack in Verizon IMS (unspecified version) implements SIP signaling without IPsec integrity protection (missing Security-Client/Security-Server headers and ESP traffic), which allows an on-path attacker to compromise confidentiality, integrity, and authenticity of VoLTE signaling via passive monitoring and active manipulation of unsecured SIP messages over the radio and core network. According to 3GPP TS 33.203 and GSMA IR.92, SIP signaling between the UE and P-CSCF in IMS networks must be protected using IPsec ESP with mandatory integrity following IMS AKA authentication. This protection is negotiated via SIP Security Agreement headers (Security-Client, Security-Server, Security-Verify) during registration and results in integrity-protected ESP traffic for all subsequent signaling messages. However, observations conducted over several weeks on Verizon’s network showed no such headers in use. The REGISTER exchange lacked any security negotiation, and post-registration SIP traffic—including INVITE, MESSAGE, BYE, and UPDATE—traversed the network in plaintext over standard UDP/TCP, with no ESP encapsulation. This pattern was consistent across device models and network conditions, indicating a systemic configuration decision rather than a transient issue. The absence of integrity checking means any modification to SIP messages—including redirection of emergency calls or injection of fake message payloads—would go undetected by both the UE and the IMS core. No technical justification for this deviation from globally adopted security practices has been provided by Verizon, and prior engagement failed to elicit a substantive response beyond the recent, non-binding commitment to future deployment. Impact The lack of IPsec integrity protection enables on-path attackers—including those controlling femtocells, compromised base stations, or IMS intermediaries—to intercept, modify, replay, or inject SIP messages without detection. These capabilities permit call hijacking, spoofing of SMS-over-IMS, denial-of-service through forged BYE or CANCEL, and manipulation of emergency call routing—without requiring compromise of the UE, SIM, or backend infrastructure. Because SIP signaling lacks cryptographic integrity, all such modifications go unnoticed by both the UE and the IMS core, undermining core security assumptions of VoLTE. While the recently observed iOS 26.5 configuration change may signal progress toward a more secure implementation, its operational impact is yet to be demonstrated; until then, the risk remains real and unmitigated for users on unprotected deployments. Solution Until the vulnerability is fully mitigated by Verizon, users and enterprises should continue to assume VoLTE signaling is untrusted for high-assurance operations. Acknowledgements Thanks to DongWon Lee, Jeongmin Choi, and CheolJun Park from Kyung Hee University for their thorough technical report, persistent follow-up efforts, and the additional observation regarding iOS 26.5. Their work has significantly advanced the understanding of this issue and helped keep the discussion grounded in observable behavior. This AI-assisted document was written by Timur Snoke.