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
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
emergency call setup.
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)
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. As far as I know there
is no distinction within the proposed protocols. So why put
this distinction here. If you have a distinction, you need first
to get the date. Since the provider of this date may (Must?) derive
this data from the mapping service anyway, how can he make the
So IMHO this purpose is not needed.
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
We are planning to use ESGW, but these may accessed only via
the ESRPs. 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.
We are planning to access the ESGW with tel URIs via the ESRP.
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).
Since the client is not able in most case to access the ESGW directly
this purpose should not be there.
Side remark: there are discussions here in Europe to provide
access to PSAPs (at least to a national default PSAP), as an
solution for VSPs having no national gateway and if, they may need to
the national practice, but I do not consider this as a good idea. In
case you may provide this TEL URI in the purpose.
First, this is not generally available (some countries do not provide
access to PSAPs via international calls) and second, it is only a
the more straightforward solution using a national ESRP with access to
a national ESGW.
One possible solution here is to store in the mapping service in
to the SIP URI to the ESRP (which is used by the clients) also a TEL URI
with local context (which is then used only by the ESRP). The local
indicated that the TEL URI can only be interpreted by the specific
ESRP to provide the ESGW with the necessary routing information.
Now one may consider to store this tel URI in the ESGW purpose, but
since this information is useless to the client, I need not be there
What I am missing in the I-D is a way to provide the client eventually
with the local emergency identifiers
Ecrit mailing list