112NG112.netNext generation emergency communications

NG112 reference

Emergency Service Urns

Structured NG112 reference page.

112 readiness

Policy, location, routing, and response quality connected in one operational model.

SIP and Emergency Signaling

Emergency Service URNs

Emergency calls start with local dial strings such as 112, but IP emergency routing benefits from a normalized service identifier. URNs allow systems to describe the requested service in a way that can survive national numbering differences and support service subtypes where implemented.

Dialed emergency number
->
Service URN
->
Location + service lookup
->
Routing target

What it does

Emergency service URNs identify emergency services logically, such as urn:service:sos, instead of relying only on dialed digits.

They identify the emergency service requested by the caller so routing can use both service and location.

How it works

  • Maps emergency intent to a standardized service identifier.
  • Combines with location for routing lookups.
  • Can distinguish emergency service categories where architecture supports it.

Key interfaces and protocols

  • IETF RFC 5031
  • SIP Request-URI concepts
  • LoST service field
  • Dial-plan normalization

Systems it interacts with

  • SIP
  • LoST
  • ECRF
  • ESRP
  • Originating networks

Common failure modes

  • Dial string is normalized incorrectly.
  • Service subtype unsupported downstream.
  • National special numbers are conflated with 112.
  • Test calls use a different service identifier.

Implementation considerations

  • Document emergency dial-string normalization.
  • Treat service identity separately from caller location.
  • Avoid inventing private service values without interop testing.

Standards

  • IETF RFC 5031
  • IETF RFC 5222
  • IETF RFC 6881

Related NG112 technologies

Related country deployments

No country deployments are listed here until independently verified against official or high-confidence sources.

Related articles

Sources

Advertisement