[dhcwg] RE: [Ecrit] RE: draft-polk-dhc-uri-00

["Stastny Richard" <Richard.Stastny at oefeg.at>]

Is there a possibility to get this question back to facts:
what will the average call setup delay be for lets say one
additional DNS query to the x queries required to do the call-setup
from the client to the PSAP, eventually via an ESRP and a ESGW
in the first place?

Richard


________________________________

Von: ecrit-bounces at ietf.org im Auftrag von Marc Linsner
Gesendet: Do 15.09.2005 21:38
An: 'James M. Polk'
Cc: dhcwg at ietf.org; 'ECRIT'
Betreff: [Ecrit] RE: draft-polk-dhc-uri-00



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....

> 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".

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. "
>
> 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.
>

_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit



_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg