Subject: [dhcwg] Re: draft-polk-dhc-uri-00

From: "James M. Polk" <[email-masked]>
Date: Wed, 14 Sep 2005 16:38:54 -0500

At 08:48 AM 9/14/2005 -0400, Marc Linsner wrote:
>James,
>
>Would you please provide the basis for your text below regarding the timing
>of psap determination, I can't seem to match it up with any of the
>requirements within ecrit or geopriv.

When something is urgent, do you want to invoke more processing complexity 
or less processing complexity? More typically means "more prone to errors", 
less typically means "less prone to errors". Everyone hear is assuming that 
the UA providing location will get mapped to the appropriate PSAP within a 
reasonable call set-up timeframe.

This document suggests an optimization - to do the "mapping" before time is 
wasted doing the mapping just to set-up the call.

The ECRIT Charter says:

(item #1) "Successful delivery of an emergency service call within those 
systems requires both an association of the physical location of the 
originator with an appropriate emergency service center and call routing to 
deliver the call to the center."

and

(item #2) "Calls placed using Internet technologies do not use the same 
systems to achieve those goals, and the common use of overlay networks and 
tunnels (either as VPNs or for mobility) makes meeting them more 
challenging. There are, however, Internet technologies available to 
describe location and to manage call routing. This working group will 
describe when these may be appropriate and how they may be used."

and

(item #3)  "The group will show how the availability of location data and 
call routing information at different steps in session setup would enable 
communication between a user and a relevant emergency response center. "

Item # 1 talks the association of user location and the appropriate PSAP.
         - This ID describes this by using the same Link provider that 
knows the
         UA's location (and give the UA its location.

Item #2 talks about describing location and managing call routing - 
specifically "when" these may be appropriate.
         - This ID describes accomplishing this mapping before call set-up.
         - I don't remember reading a requirement in either WG that says
         "this mapping function MUST take place *only* during call set-up".

Item #3 talks about different information at different times in the session 
set-up.
         - This ID provides the Request-URI for the INVITE message, plus 
provides
         an alternate Request-URI, plus the URI of the ESGW and ESRP.

SIP Proxies will determine if a route is available or not, and reroute 
around any problems if there are any.  A URI is not an IP Address, of which 
there is one. The same URI can go to many difference locations in times of 
overload or error. Webservers have been doing this function for better than 
5 years now.

>"One example of this URI download would be one specifically for the SIP or
>SIPS URI of the appropriate Public Safety Answer Point (PSAP) for the client
>when the user of that client calls for emergency help (911 or 112-type of
>help).  This is not a transaction that should take place when a voice
>application wants to make such a critical call set-up.  It is more
>appropriate that this information be downloaded to the client when the voice
>(or other) application boots up in case it is needed at a later time."
>
>Thanks,
>
>-Marc-

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

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

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 15 Sep 2005 15:38:10 -0400

James,

Thanks for your answer.  My question was about the basis for your assertion
that it is 'more appropriate' to perform location to psap uri mapping at
host configuration setup time vs. emergency call setup time.  I derive from
your answer that your basis for this assertion is getting this task done
prior to call setup, making call setup faster and possibly more reliable.

More comments in-line....

> >Would you please provide the basis for your text below regarding the 
> >timing of psap determination, I can't seem to match it up 
> with any of 
> >the requirements within ecrit or geopriv.
> 
> When something is urgent, do you want to invoke more 
> processing complexity or less processing complexity? More 
> typically means "more prone to errors", less typically means 
> "less prone to errors".

No one can argue that simple is good, but there must be a balance with all
requirements.

> Everyone hear is assuming that the UA 
> providing location will get mapped to the appropriate PSAP 
> within a reasonable call set-up timeframe.

This assumption is based on years of experience, it's the way things have
work for 30+ years.  There is every expectation of success in duplicating a
like mechanism using Internet techologies.  If that wasn't possible, we
wouldn't be having this conversation as there would not be a PSTN-like
capability on the Internet.

> 
> This document suggests an optimization - to do the "mapping" 
> before time is wasted doing the mapping just to set-up the call.

It is not clear such optimization is necessary.  We don't have a 'failed'
mechanism (yet).

-Marc-

> 
> The ECRIT Charter says:
> 
> (item #1) "Successful delivery of an emergency service call 
> within those systems requires both an association of the 
> physical location of the originator with an appropriate 
> emergency service center and call routing to deliver the call 
> to the center."
> 
> and
> 
> (item #2) "Calls placed using Internet technologies do not 
> use the same systems to achieve those goals, and the common 
> use of overlay networks and tunnels (either as VPNs or for 
> mobility) makes meeting them more challenging. There are, 
> however, Internet technologies available to describe location 
> and to manage call routing. This working group will describe 
> when these may be appropriate and how they may be used."
> 
> and
> 
> (item #3)  "The group will show how the availability of 
> location data and call routing information at different steps 
> in session setup would enable communication between a user 
> and a relevant emergency response center. "
> 
>          - This ID describes this by using the same Link 
> provider that knows the
> Item #2 talks about describing location and managing call 
> routing - specifically "when" these may be appropriate.
> Item #3 talks about different information at different times 
> in the session set-up.
>          - This ID provides the Request-URI for the INVITE 
> message, plus provides
> SIP Proxies will determine if a route is available or not, 
> and reroute around any problems if there are any.  A URI is 
> not an IP Address, of which there is one. The same URI can go 
> to many difference locations in times of overload or error. 
> Webservers have been doing this function for better than
> 5 years now.
> 
> 
> >"One example of this URI download would be one specifically 
> for the SIP 
> >or SIPS URI of the appropriate Public Safety Answer Point (PSAP) for 
> >the client when the user of that client calls for emergency 
> help (911 
> >or 112-type of help).  This is not a transaction that should 
> take place 
> >when a voice application wants to make such a critical call 
> set-up.  It 
> >is more appropriate that this information be downloaded to 
> the client 
> >when the voice (or other) application boots up in case it is 
> needed at a later time."
> >
> >Thanks,
> >
> >-Marc-
> 
> 
> cheers,
> James
> 
>                                  *******************

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 14 Sep 2005 09:06:31 -0400

I've previously argued that while getting it when you boot (i.e. run DHCP)
is a good idea, it would be best if you did the mapping from location to URI
just before the call, because, due to failures or other disaster related
effects, the mapping may have changed.  It IS a transaction you want to do
when you want to make a call setup, because you want the most recent data.

You also want to make certain that you refresh this data periodically.
Daily is probably the minimum, and you know that some DHCP lease times are
on the order of weeks.

So, I would like this wording significantly changed.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Marc Linsner
Sent: Wednesday, September 14, 2005 8:48 AM
To: 'James M. Polk'
Cc: [email-masked]; 'ECRIT'
Subject: [Ecrit] draft-polk-dhc-uri-00

James,

Thanks,

-Marc-

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

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 14 Sep 2005 08:48:07 -0400

James,

Thanks,

-Marc-