[email protected]
[Top] [All Lists]

RE: [Ecrit] RE: draft-polk-dhc-uri-00: mixed goals

Subject: RE: [Ecrit] RE: draft-polk-dhc-uri-00: mixed goals
From: "Stastny Richard"
Date: Sat, 17 Sep 2005 01:13:42 +0200
Hi James

Sorry for the "date" problem, I meant data, but the explanation
was not very well formulated anyway. It was a bit late

Ok, it is late now again, but lets try

I will start with your last remark:
>remember, this is **NOT** an ECRIT Architecture ID, it is a DHC ID that
>doesn't need to get into all the architecture stuff of emergency
>communications. Another ECRIT (or two) ID could/should explain how these
>purposes are used, including message flows.

Ok, but we are discussing this on the ecrit list.
So in ecrit we must define how the data are distributed
to the DHCP servers. One method could be that the
DHCP servers are querying periodically the mapping
database, because this is IMHO the ONLY authoritative
source for the location to PSAP URI mapping

Any other means would end up in a complete mess (one
cannot expect thousands of DHCP servers updated
properly if a PSAP URI changes)
So the PSAP URI may be retrieved in that way, but
I did not see in any of the proposals of the mapping
database a datafield indicating a destinction between
a PSAP URI or a ESRP URI, and I also did not
see an ESGW URI
So where are these DATA coming from?

The only data in the mapping database up
to now is a SIP URI. We would propose
to provide IN ADDITION to the PSAP
URI (which may also be an ESRP URI -who cares)
a TEL URI. This TEL URI may either be used
by the ESRP to access an ESGW or maybe
by any network knowing or owning a gateway
and also knowing the (national) context.


Von: James M. Polk [mailto:[email protected]]
Gesendet: Sa 17.09.2005 00:44
An: Stastny Richard; Thomson, Martin; [email protected]
Betreff: RE: [Ecrit] RE: draft-polk-dhc-uri-00: mixed goals

comments in line

At 10:34 AM 9/15/2005 +0200, Stastny Richard wrote:
>Sorry for jumping in into this discussion a bit late
>but I had no time up to now to read the draft completely
>I also apologize if I re-query some issues already discussed
>In principle I consider it as a good idea to have a vehicle
>to provide such information to a client.
>Having said this, I would like to discuss the purpose list
>in detail.
>Purpose = 1  (Primary PSAP URI)
>    Purpose = 2  (Secondary PSAP URI)
>    Purpose = 3  (Location By-Reference of Client)
>    Purpose = 4  (ESGW URI of Client)
>    Purpose = 5  (ESRP URI of Client)
>    Purpose = 6  (Location Providing Location for Client)
>    Purpose = 7  (URI of Geocoding/Reverse Geocoding)
>    Purpose = 8  (Primary URI of Geo Mapping Service)
>    Purpose = 9  (Secondary URI of Geo Mapping Service)
>    Purpose = 10 (Primary URI of Civic Mapping Service)
>    Purpose = 11 (Secondary URI of Civic Mapping Service)
>General remark 1 (this was already discussed):
>There needs to be a requirement in ecrit req I-D defining
>the TTL of such information and therefore the minimum lease time


>Also the concern of Brian regarding short time changes has to by taken
>account, which may render the transmissinon of the URI of the Mapping
>service and the PSAP useless, because then they always need to be
>queried at
>emergency call setup.

Why "at" call set-up? Why not "before" call set-up?

>General remark 2:
>Is it necessary to provide secondaries in general? Especially
>for SIP URIs (PSAP) this can be done with other means (e.g. SRV RR)

I thought I'd include them now and see what the WGs said about the reliance
on one or two

>Remark ESRP
>If you query the mapping service, you get back a SIP URI. You do
>not care if this is a PSAP direct or a ESRP.

The client might not, but it might be stored in a server differently.
Further, the client could get 3 URIs, Pri and Sec PSAP URIs and the ESRP as
another fallback.

>As far as I know there
>is no distinction within the proposed protocols. So why put
>this distinction here.

Because we don't know every possible instance of how URIs will be used, and
there may be a difference somewhere.

>If you have a distinction, you need first
>to get the date.

the date? I don't understand this.

>Since the provider of this date may (Must?) derive
>this data from the mapping service anyway, how can he make the

again - I don't understand this "date"

>So IMHO this purpose is not needed.
>Remark ESGW:
>Now here I have a serious problem
>It is stated in the draft
>    "This purpose=4 URI is for the Emergency Services Gateway that an IP
>    client would contact when setting up an emergency call with a PSAP
>    that is not IP enabled.  Having this information locally in the
>    client will allow it to contact the ESGW directly and not have to
>    rely on an intermediary to determine which ESGW is the right one for
>    this client, and possibly fail the call set-up during that
>    determination."
>We are planning to use ESGW, but these may accessed only via
>the ESRPs.

Is that true for every enterprise network?

>The ESGW are basically PoIs to the PSTN. If you access
>the ESGW with a SIP URI, you are basically accessing a SIP proxy
>and then it is a ESRP.

You may be telling a call server which GW to direct the call set-up
towards. I believe this applies more to the smaller networks than the open

>We are planning to access the ESGW with tel URIs via the ESRP.

I believe a tel:uri will be converted to a SIP uri that is then sent to the
ESGW, but I could be wrong

>It is the task of the ESRP to map the location (via the mapping service
>or via a local DB to the NATIONAL routing numbers required to access
>the national emergency service network. This mapping is very national
>specific (it may not use E.164 numbers).

yes - but an ESRP is not always necessary.

If the UA has the IP destination URI (be it PSAP or ESGW), there doesn't
need to be an ESRP to do the mapping that has already been done.

>Since the client is not able in most case to access the ESGW directly
>this purpose should not be there.

"in most cases" means not all the time, so there are instances in which
this can be used, maybe not many

>What I am missing in the I-D is a way to provide the client eventually
>with the local emergency identifiers

remember, this is **NOT** an ECRIT Architecture ID, it is a DHC ID that
doesn't need to get into all the architecture stuff of emergency
communications. Another ECRIT (or two) ID could/should explain how these
purposes are used, including message flows.



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

Ecrit mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>