3.3 SIP Signaling in NG911 (RFC 3261) & Emergency Call Flow

3.3 SIP Signaling in NG911 (RFC 3261) & Emergency Call Flow

Quick Answer: In Next Generation 9-1-1 (NG911), Session Initiation Protocol (SIP - IETF RFC 3261) replaces legacy CAMA and SS7/ISUP signaling as the foundational protocol for session establishment, control, and teardown. Originating networks direct emergency calls to the universal Service URN urn:service:sos, embedding caller geolocation in a PIDF-LO object and negotiating media parameters via Session Description Protocol (SDP - RFC 4566). Audio and video streams flow over Real-time Transport Protocol (RTP) or Secure RTP (SRTP - RFC 3711), with G.711 mu-law serving as the mandatory universal audio codec and G.722 providing wideband HD voice. If a PSAP cannot accept a call, SIP failure codes (such as 486 Busy Here or 503 Service Unavailable) trigger automated policy routing failover at the Emergency Service Routing Proxy (ESRP).

---

The Shift to SIP Signaling in NG911

Legacy 9-1-1 emergency call delivery relied on Centralized Automatic Message Accounting (CAMA) multi-frequency (MF) signaling or SS7 ISDN User Part (ISUP) trunk signaling. CAMA signaling suffered severe operational limitations: in-band MF pulsing added call setup delay, it was limited to a 7- or 10-digit telephone number transmission, could not natively transmit location coordinates, and was entirely incapable of supporting modern media such as text, high-definition voice, or video.

Under NENA-STA-010, NG911 completely replaces these legacy protocols with Session Initiation Protocol (SIP - IETF RFC 3261). SIP is an application-layer, text-based, client-server signaling protocol modeled after HTTP. In public safety, SIP provides:

• Rapid Session Setup: Typical call setup times drop from 10-15 seconds in legacy networks to under 500 to 1,500 milliseconds in an ESInet.
• Extensible Headers: Carries rich metadata, including caller identities, priority indicators, device capabilities, and cryptographic authentication tokens (STIR/SHAKEN PASSporT).
• Native Location Conveyance: Conveys Presence Information Data Format Location Objects (PIDF-LO) with the call. The SIP Geolocation header (RFC 6442) either references a PIDF-LO carried in the message body (a cid: URI, location by value) or supplies a URI to dereference (location by reference).
• Multimedia Negotiation: Coordinates simultaneous two-way audio, interactive video, Real-Time Text (RTT), and supplemental telematics data within a single unified session.

---

SIP Emergency Call Setup Message Exchange

The establishment, alerting, answering, and teardown of an emergency call across an ESInet follows a standardized, deterministic SIP message sequence:

Caller / LNG                 BCF / Ingress Proxy               ESRP                      PSAP CHE Console
    |                                |                          |                               |
    |--- [1] INVITE (urn:service:sos) ->|                          |                               |
    |    (SDP Offer, PIDF-LO)        |--- [2] INVITE ---------->|                               |
    |                                |                          |--- [3] INVITE (Routes to PSAP)->|
    |<-- [4] 100 Trying -------------|<-- [5] 100 Trying -------|                               |
    |                                |                          |<-- [6] 180 Ringing -----------|
    |<-- [7] 180 Ringing ------------|<-- [8] 180 Ringing ------|                               |
    |                                |                          |<-- [9] 200 OK (Call Answered)-|
    |                                |                          |    (SDP Answer)               |
    |<-- [10] 200 OK ----------------|<-- [11] 200 OK ----------|                               |
    |--- [12] ACK ------------------>|--- [13] ACK ------------>|--- [14] ACK ----------------->|
    |                                |                          |                               |
    |<==================== [15] TWO-WAY RTP / SRTP MEDIA STREAM ===============================>|
    |                                |                          |                               |
    |--- [16] BYE (Disconnect) ----->|--- [17] BYE ------------>|--- [18] BYE ----------------->|
    |<-- [19] 200 OK (Teardown Conf)-|<-- [20] 200 OK ----------|<-- [21] 200 OK ---------------|

Step-by-Step Call Setup Analysis

1. INVITE Request: The originating endpoint (or Legacy Network Gateway) initiates the call by transmitting a SIP INVITE. Crucially, the Request-URI does not contain a standard dialed phone number; instead, it is addressed to urn:service:sos. The INVITE contains:
   • From Header: Identifies the caller (e.g., sip:+15551234567@carrier.com).
   • To Header: The dialed entity (sip:911@carrier.com or urn:service:sos).
   • Geolocation Header (RFC 6442): Points to the caller's location, either a cid: reference to a PIDF-LO body part (RFC 4119, using RFC 5491 geodetic shapes or RFC 5139 civic elements) or a dereferencing URI.
   • SDP Body (Session Description Protocol): Declares the caller's supported audio/video codecs, IP address, and listening media port.
2. 100 Trying (Provisional Response): Transmitted immediately by intermediate hops (BCF, ESRP) back to the sender. This suppresses SIP retransmission timers and signals that the server is actively processing routing logic (such as querying the ECRF).
3. 180 Ringing (Provisional Response): Sent by the terminating PSAP Call Handling Equipment (CHE) once the call arrives in an answering queue or alerts at a telecommunicator console. This generates ringback audio to the caller.
4. 200 OK (Success Response): Sent when the telecommunicator answers the call ("goes off-hook"). The 200 OK contains the terminating system's SDP answer, confirming the negotiated codec and media IP/port.
5. ACK (Acknowledgment): Transmitted by the originating client to confirm receipt of the 200 OK. The three-way handshake (INVITE -> 200 OK -> ACK) is now complete, establishing the active dialog.
6. Two-Way RTP / SRTP Media: Real-time voice, video, or RTT packets flow directly between negotiated endpoints (or anchored through the BCF).
7. BYE & 200 OK (Teardown): When either party disconnects, a BYE request terminates the dialog. The receiving party responds with 200 OK, and all network resources and firewall pinholes are released.

---

SIP URIs & Emergency Service URNs

In standard commercial VoIP networks, SIP routing targets static phone numbers formatted as Tel URIs (tel:+15551234567) or SIP URIs (sip:user@domain.com). In NG911, emergency routing relies on Service Uniform Resource Names (Service URNs) as specified in IETF RFC 5031.

Originating Service Providers must populate the SIP Request-URI with the root emergency URN: $\text{urn:service:sos}$

When specialized dispatch services are required, RFC 5031 defines standardized sub-services:

• urn:service:sos.police — Directs routing exclusively to law enforcement dispatch.
• urn:service:sos.fire — Directs routing to fire and rescue dispatch.
• urn:service:sos.ambulance — Directs routing to emergency medical services (EMS).
• urn:service:sos.marine — Directs routing to maritime rescue authorities (e.g., U.S. Coast Guard).
• urn:service:sos.mountain — Directs routing to specialized mountain search-and-rescue teams.

The Emergency Call Routing Function (ECRF) receives the urn:service:sos and the caller's geographic coordinates, querying GIS boundary layers to resolve the URN into a routable SIP URI pointing to the correct PSAP (e.g., sip:psap-dispatch@state-esinet.gov).

---

Session Description Protocol (SDP) Media Negotiation

SIP does not transport voice or video media directly; it manages the signaling dialog. Media transport parameters are negotiated using Session Description Protocol (SDP - IETF RFC 4566) embedded within the SIP message body.

An SDP payload contains critical session descriptors:

v=0
o=OriginatingGateway 10293847 1 IN IP4 198.51.100.25
s=NG911 Emergency Call
c=IN IP4 198.51.100.25
t=0 0
m=audio 49170 RTP/SAVP 0 9 101
a=rtpmap:0 PCMU/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv

• c= (Connection Data): Specifies the network type, address type, and IP address sending the media.
• m= (Media Announcement): Declares media type (audio), transport port (49170), profile (RTP/SAVP for Secure RTP), and supported payload formats (0 for G.711 PCMU, 9 for G.722).
• a= (Attribute Lines): Defines codec sampling rates, telephony DTMF event mapping (RFC 4733), and stream directionality (sendrecv).

Mandatory and Supported Codecs in NENA i3

Exam Trap: While G.722 wideband audio provides superior speech intelligibility, G.711 mu-law remains the mandatory baseline codec in North American NG911. Every PSAP CHE, gateway, and core element must support G.711 to ensure that calls originating from legacy landlines or basic wireless networks can connect without requiring resource-intensive transcoding.

---

RTP and Secure RTP (SRTP) Media Transport

Once negotiated via SDP, real-time media packets flow using the Real-time Transport Protocol (RTP - RFC 3550). RTP packets encapsulate 20 milliseconds of audio payload, accompanied by:

• Sequence Numbers: Detects lost or out-of-order packets.
• Timestamps: Enables jitter buffers to reconstruct proper audio playback timing.
• Payload Type: Confirms the active codec format.

In compliance with NENA i3 security requirements, all media traversing the ESInet should be protected via Secure Real-time Transport Protocol (SRTP - RFC 3711):

• Confidentiality: Encrypts media payloads using Advanced Encryption Standard (AES) in Counter (CTR) mode (typically AES-128 or AES-256), preventing unauthorized wiretapping of emergency citizen communications.
• Integrity & Authentication: Appends an HMAC-SHA1 message authentication code to each packet, guaranteeing the audio/video has not been intercepted, tampered with, or injected by an attacker.
• Key Exchange: Cryptographic master keys are negotiated with DTLS-SRTP (RFC 5764): the DTLS handshake runs on the media path and is bound to certificate fingerprints exchanged in SDP, so keys never travel in the signaling itself.

---

SIP Response Status Code Classes

SIP status codes are three-digit integers grouped into six functional classes:

[ 1xx: Informational ] --> Request received; processing continues (e.g., 100 Trying, 180 Ringing)
[ 2xx: Success       ] --> Action successfully received, understood, and accepted (e.g., 200 OK)
[ 3xx: Redirection   ] --> Further action needed; client must query alternate URI (e.g., 302 Moved)
[ 4xx: Client Error  ] --> Request invalid or cannot be fulfilled by server (e.g., 404 Not Found)
[ 5xx: Server Error  ] --> Server failed to fulfill valid request (e.g., 503 Service Unavailable)
[ 6xx: Global Failure] --> Request cannot be fulfilled at any server anywhere (e.g., 603 Decline)

---

Critical Failure Codes & Automated Policy Routing Failover

In public safety communications, a call cannot simply be dropped when an error occurs. The Emergency Service Routing Proxy (ESRP) monitors SIP response codes and applies automated Policy Routing Function (PRF) contingency rules:

1. Handling 486 Busy Here (Queue Saturation)

When an incoming emergency call arrives at a PSAP where all call-taker consoles are engaged and the local ACD queue capacity is exceeded, the PSAP gateway returns a 486 Busy Here.

• The ESRP intercepts the 486 code.
• Instead of disconnecting the caller, the ESRP's PRF rules immediately trigger overflow rerouting.
• The ESRP sends a new INVITE to a designated secondary PSAP, a regional backup facility, or an automated rollover queue, ensuring the caller is answered.

2. Handling 488 Not Acceptable Here (Media Negotiation Failure)

If a caller attempts a high-definition video call to a PSAP whose call handling equipment only supports voice, the PSAP returns 488 Not Acceptable Here with an SDP payload indicating acceptable parameters.

• The ingress BCF or originating network intercepts the 488.
• The client immediately issues an updated INVITE with media parameters downgraded to standard G.711 audio, allowing the emergency voice call to connect without requiring caller intervention.

3. Handling 503 Service Unavailable (Catastrophic Facility Outage)

If a backhoe severs the local fiber connection to a PSAP or the primary call-taking server experiences a total hardware failure, the PSAP edge gateway (or BCF health probe) responds with 503 Service Unavailable (or fails to respond, causing an RFC 3261 Timer B timeout).

• The upstream ESRP immediately identifies the primary route failure.
• The PRF executes pre-programmed disaster recovery failover, redirecting all pending and subsequent emergency calls to the designated alternate PSAP or cloud-hosted disaster recovery position within milliseconds.