Re: [Ecrit] country specific emergency URNs

[Henning Schulzrinne <[e-mail]>]

I don't know what first-hand experience with regulators you've had, but
from having worked at a well-known one since 2010, this isn't quite mine.
>From my experience, at the staff level, they are well aware of the relevant
organizations (NENA in North America, EENA in Europe), know and are in
regular contact with many of the relevant standards organizations (e.g.,
ATIS in the US, 3GPP or IETF), they attend related meetings and staff are
happy to talk to outside experts. It does require some outreach,
particularly if there has been no prior contact in a particular topic area.
On the European side, I suspect that EENA would be happy to help with
making contact.

Thus, I find the argument that regulators are, to re-cast your argument a
bit, just too clueless and disconnected to care or be educated a bit
presumptuous. From what I can tell, most regulators haven't paid a whole
lot of attention to NG911/NG112 details since they haven't been actionable
until fairly recently.

You are essentially advocating to just use the (short code) numbers. If
that's all you want, there's no reason to bother with sos URNs at all.
Needless to say, I think that's a bad idea.

Henning

On Mon, Jul 24, 2017 at 7:54 AM, Ivo Sedlacek <[e-mail]>
wrote:

> Hello,
>
>
>
> my view:
>
>
>
> 1) an operator deploying a SIP based mobile network needs sos URNs for
> every emergency service defined in the country of the SIP based mobile
> network. Those SIP based mobile networks are being deployed today so the
> sos URNs are needed *NOW* as those sos URNs is used in those SIP based
> networks for internal routing (even if PSAPs are still using circuit
> switched technology).
>
>
>
> 2) it is regulator's decision on what emergency services are offered in a
> country.
>
>
>
> 3) if a service is defined as an emergency service by a regulator of a
> country, there has to be a unique (within the country) sos URN for it.
>
>
>
> 4) it is regulator's decision on what sos URN to use to indicate an
> emergency service.
>
>
>
>                 NOTE: without such decision, operator can guess an sos URN
> for a service. However, if guessing is incorrect, the operator will need to
> re-configure the SIP based mobile network (and that one reason for defining
> sos URNs relying solely on country identification and emergency number
> identification).
>
>
>
> 5) so far regulators are not used to make decisions described in 4).
>
>
>
> 6) it is decision of a regulator of a country A and a regulator of a
> country B, whether an emergency service X offered in country A is the same
> as an emergency service Y offered in country B.
>
>
>
> 7) so far regulators are not used to make decisions described in 6).
>
>
>
> 8) imagine that a number (e.g. 123) is specified by a regulator for a
> particular emergency service.
>
>                 Let's assume that someone would register a sos URN with a
> descriptive sublabel for this emergency service and this sos URN would be
> used in networks.
>
>                 Now what to do if the regulator extends the scope of the
> service associated with this number (i.e. 123)?
>
>                 Would someone need to register a new sos URN (with
> sublabel reflecting the extended scope) and the networks would need to be
> reconfigured to stop using the old sos URN and start using the new sos URN?
>
>
>
> So, I support Vasil's and Roberto's suggestion to specify a sos URN
> containing country identifier and emergency number (e.g.
> urn:service:sos.country-specific.<country ID>.<emergency number> or
> possibly urn:service:sos.country-specific-<country ID>-<emergency
> number>). Such sos URN will never be used by the UE (with exception of
> INVITE request triggered by 3xx response), only within the networks.
>
>
>
> All the above probably looks unreasonable or over-engineering from US
> perspective where 911 is the only emergency number. However, that's how it
> is in real world in other continents and technology needs to support the
> real world there too (and trying to force changes there will not be
> successful).
>
>
>
> Kind regards
>
>
>
> Ivo Sedlacek
>
>
>
> PS: Sorry for commenting late - I was enjoying holidays.
>
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
>
>