Subject: [dhcwg] Emergency dial strings

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 23 Mar 2006 11:27:47 -0500

Here's a brief summary of the current proposal being discussed in ECRIT 
for obtaining dial strings and other location-based functions:

(1) End device obtains location information using, for example, DHCP, L2 
(LLDP-MED), GPS or via some L7 protocol. For dial strings, only 
country-level accuracy is needed, as contained, for example, in the 
dhcp-civic draft that's in the RFC editor's queue.

(2) The device then performs a mapping operation, mapping a service 
indicator and location information to one or more URLs that actually 
provide the service for that geographic region. The current protocol 
proposal is called LoST, described in draft-hardie-ecrit-lost-00 . It 
also returns the corresponding dial string for the service.

The service URN is described in draft-ietf-ecrit-service-urn-01.

It is likely that the LoST server would be located via DHCP, among other 
options.

Note that this works for services beyond emergency calling. You could 
use this for the local help desk, and it has been somewhat-facetiously 
for pizza delivery and towing services.

I believe that this is a better approach as it solves both problems. 
After all, a dial string itself isn't too useful if it can't be routed 
correctly. This also allows to separate the provision of services from 
the scope of the DHCP server. For example, at Columbia University, we 
split our facilities maintenance functionality into several areas, each 
spanning a group of buildings. A single (logical) DHCP server serves the 
whole campus. With the model above, I could easily map the location and 
the "repair" service to the right phone number or URL, without having to 
somehow encode civic or geospatial information into a service discovery 
options.

Henning

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg