Transcript Framework-PhoneBCP

Status Update – IETF ecrit
-framework and -phonebcp
Brian Rosen
Neustar
draft-ietf-ecrit-framework

Purpose: Describe the big picture of how emergency calls work

Endpoint gets location (or reference) from access network

Phone detects local (or home) dialstring to recognize
emergency call

Emergency call marked with urn:service:sos

Routed to correct PSAP with LoST

Location included with call (-conveyance) + callback URIs

Informational – no normative text

References lots of other documents
draft-ietf-ecrit-framework
 Current State: Nearing completion
 All the known relevant areas are covered at about the
right depth
 Needs significantly more review
 Will track –phonebcp for a while (will last call –
phonebcp and –framework at the same time)
 Anticipate IESG approval before end of CY2007
draft-ietf-ecrit-phonebcp
 Purpose: Best Current Practice for phone (endpoint)
and carrier (proxy server) to implement IETF ecrit
emergency phone architecture
 Expect ALL sip (or xmpp) multimedia session
management endpoints to conform
 Expect ALL carriers to conform
 As a consequence, defines the interface from the
Internet to Emergency Services IP networks
 Single international standard, works for all devices,
home, roaming and nomadic
Location Processing

Phone gets location (or a reference) from a Location
Configuration Protocol

-phonebcp specifies 3 of them (DHCP, LLDP-MED. HELD)

Phones implement all of them

Access networks implement one of them

If it’s not on the list, better have iron-clad control on the
specs of EVERY device (directly or indirectly) connected to
the net

Phone uses LoST to obtain a mapping to PSAP URI on boot,
caches it for possible later use

Location is included in signaling via –conveyance

Includes mechanisms for location update
LoST Mapping
 Specifies that endpoints map from location to URI
 Important because can’t depend on availability of LoST
server in disasters at call time
 Mapping is done at boot, periodically thereafter, and at
time of call
 If it doesn’t work, use latest cached value
 Of course, get location update at the same time 
 This means endpoint recognizes emergency dialstring,
pushes urn:service:sos into Route header, and puts
PSAP URI in Request URI
-phonebcp allows some network
centric options
 Location and mapping CAN be done by a proxy if it
knows, unambiguosly where the device is and
therefore what it’s local dialstring is
 This means proxy must track location changes and
update the LoST mapping to discover the local
dialstring if the proxy can serve a nomadic or
roaming user outside the domain of the local proxy
 Proxy can add Geolocation header, and a Route
header
 Of course, proxy normally routes towards the PSAP
URI and probably has a private IP connection to the
ESInet
Other regular stuff in there
 Describes details of minimal SIP header and feature
sets required
 Some “interesting” things here, please pay attention,
like “no via hiding”
 Disabling of certain features (Call waiting, …)
 Minimal codecs for voice, video, text
Test Procedures
 Defines a mechanism to test emergency call
mechanisms without actually placing a call
 Depends on implementation of the mechanism at the
PSAP
 Signalled with “;test” on the urn:service:sos
 Auto “answer” at PSAP
 Media loopback
 Errors returned if headers, location, etc is missing or
bad
 Ensures call is routed to PSAP that serves the location
supplied
Status
 Nearing completion
 All the known relevant areas are covered at about the
right depth
 Needs significantly more review
 Will track –framework for a while (will last call –
phonebcp and –framework at the same time)
 Anticipate IESG approval before end of CY2007