Subject: [Ecrit] draft-polk-dhc-emergency-dialstring-option

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 27 Feb 2006 09:30:44 -0500

Another quick comment: I'm glad to see this problem discussed, but I  
think we again need to ask ourselves how we can achieve economy of  
protocols. I think we should aim, overall, for the smallest number of  
distinct protocols, as that will greatly simplify interoperation,  
testing and in-field configuration.

I think the configuration problem is easily solved using existing  
mechanisms, without DHCP. In particular, there are two options:

(1) Using the mapping protocol: If the UA does a mapping protocol  
query, using either geo or civic, the response returns the  
dialstring. As shown in the LoST draft example, this is a one-line  
trivial addition to the protocol and has the advantage that the  
people who maintain the mapping database are in a much better  
position than anybody else to know 'their' dial strings.

(2) Using the SIP configuration mechanism: The user includes the  
location information in the configuration request (or the VSP gets  
the location) and gets the dial string along with all the other  
configuration information. The configuration server would presumably  
do the mapping query as in (1).

My concern with a DHCP solution is that it only works for residential  
users if all home routers (Linksys, etc.) are upgraded and, longer  
term, if we can trust local providers, including the coffee shop  
running their own AP, to track changes in dial strings. While this is  
not likely to be a major problem for 911 in the US, dial strings can  
and do change, particularly as local dial strings are replaced by  
region-wide strings, such as 112 in Europe or as new services, such  
as poison control, are introduced.

I think we had general agreement that we want to invent as few new  
protocols as possible, integrating emergency calling into more  
general frameworks where possible, such as device configuration for  
SIP devices. Thus, in my opinion, we should try to see first if  
existing mechanisms can address the problem, rather than adding to  
the protocol and mechanism proliferation.

Henning

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