Re: [Ecrit] country specific emergency URNs

["Drage, Keith (Nokia - GB)" <[e-mail]>]

I do not believe I quite agree.

The top level “sos” carries certain semantics including immediate response, which are quite distinct from “counselling”

So while a children’s service in one country may come under “sos” it will come under “counselling” in another.

Keith

From: Ecrit [mailto:[e-mail]] On Behalf Of Henning Schulzrinne
Sent: 08 July 2017 04:47
To: Brian Rosen <[e-mail]>
Cc: [e-mail]
Subject: Re: [Ecrit] country specific emergency URNs

Just to add to this: URNs are not meant to encode all kinds of policy by name, e.g., whether a service is legally considered an emergency service or not. They are protocol identifiers, not legal or human interface labels. The precise content, operator and status of well-known (including emergency) services sometimes change, without the number changing, so this isn't a particularly new issue.

The same basic service can function quite differently in different countries, as you know, but we still call it something similar or give it the same number. (For example, many emergency services that have separate numbers in European countries all use 911 in the US.)

Thus, the only real requirement is that, within a country or other appropriate jurisdiction, each distinct service has a unique name so that calls can be routed appropriately.

A secondary requirement is that a traveler should get a reasonably-close approximation of the service if it is mapped to the same URN. For example, it is probably better that somebody who has a speed dial button for children's services in Austria gets the rough equivalent in Germany or Italy, rather than having to look up the local number. In that case, a caller really does not care one bit that it is legally an emergency service in Austria, and not in Germany.

The notion of country-specific labels defeats this core portability design goal of the sos URN.

Similarly, if a single number serves two different purposes in one country, there is no harm in having two labels. Indeed, that's probably a good idea, just in case they get split later.

I think a helpful next step, which you have already started, is to enumerate the classes of emergency and related public services that currently do not have a suitable URN. We can then decide what the appropriate tree might be, recognizing that some may be a bit fuzzy (e.g., the child services you mentioned). The tree only matters in the case where a particular label does not exist in a country and labels are stripped. In some cases, the right approach may be to define related services in both the 'sos' and 'counseling' tree.

Henning

On Thu, Jul 6, 2017 at 5:09 PM, Brian Rosen <[e-mail]<mailto:[e-mail]>> wrote:
There seems to be a fundamental misunderstanding of what the values in the registry are supposed to be used for.

They are meant to be used to identify unique services.

It’s useful to try to not have a lot of services that really are the same service having different entries, but two services that are indeed different ought to have different entries.


Also, the routing of a service can be whatever is needed; no assumption about routing is made other than the implication that the routing element will have different service URNs for different services.

With that it mind, my suggestions for the cases you cited are inline:


On Jul 6, 2017, at 7:36 AM, Aleksiev, Vasil <[e-mail]<mailto:[e-mail]>> wrote:

Hello,
3GPP tried to register “sos.country-specific” sub-service type with IANA and got a comment back that “country-specific” is not an emergency service. There was a discussion on the last IETF meeting on this topic and as outcome 3 ways forward presented to 3GPP CT1 – change the registration process, create an exception in the registration process or use the current process.
There were discussions how to go forward with this topic in 3GPP CT1. With the help of some of the delegates list with emergency services was prepared in order to see what exactly problems we might have with registration. You can see the list attached.
Looking to the list there are some issues which I believe cannot be solved within the current registration process. I have tried to summarize the comments and the examples that we had during our discussions in 3GPP CT1 and to start a discussion in ECRIT mailing list regarding the possible registration of these specific emergency services. Meanwhile there is a process to make the list with the emergency services bigger.
There are some conclusions seen from the list:


  1.  Each emergency service needs to have unique emergency service URN. Handling in IMS can be different than handling in CS.

Example1:

In Czech republic, there is a "Municipal police" emergency service (156) and a "Police of the Czech Republic" emergency service (158) + other emergency services.

Within the CS domain it is possible to indicate the emergency service required, but in a limited set (3GPP TS 22.101) - there is only one bit for Police in the Emergency category Information Element.

An operator in Czech republic can provide to a UE via NAS a mapping of 158 and the Police bit in the Emergency category IE. Whenever the user dials 158 in Czech republic, this causes the UE to use a CS EMERGENCY SETUP with the Emergency category IE with the Police bit set or a UE-detectable IMS emergency call setup with the Request-URI set to the urn:service:sos.police, sent within emergency PDN connection. Either the MSC or the IMS network in Czech republic route the call to the PSAP providing the "Police of the Czech Republic" emergency service.

The operator in Czech republic canNOT provide to a UE via NAS a mapping of 156 and a bit in the Emergency category Information element since:
- the "Police" bit is taken for the "Police of the Czech Republic" emergency service (which is provided by a different PSAP than the PSAP providing the "Municipal police" emergency service);
- there is no other related bit; and
- providing no bit implies a generic emergency service (which is provided by a different PSAP than the PSAP providing the "Municipal police" emergency service).

Given that the UE is not configured with 156, whenever the user dials 156 in Czech republic, this causes the UE to use a CS SETUP for 156 or a non-emergency IMS call setup for tel:156;phone-context=<phone-context<tel:156;phone-context=%3cphone-context>>.
In CS, the MSC is always in the same country as the UE so the MSC just routes the non-emergency CS domain call for 156 to the PSAP providing the "Municipal police" emergency service.
In IMS, it is not so easy since inbound-roamer would have P-CSCF abroad.
                The P-CSCF abroad sends a 380 response to the UE to inform the UE that the UE dialed an emergency number. In the 380 response, there is a Contact header field indicating the "Municipal police" emergency service.
                Based on the 380 response, the UE determines that a call to an emergency number was attempted and the UE selects whether to attempt the emergency call in CS or in IMS.
                               If in IMS, the UE establishes an emergency PDN connection, and sets up a UE-detectable IMS emergency call and sets the Request-URI to the Contact of the 380 response, i.e. the Request-URI contains a sos URN identifying the "Municipal police" emergency service. Based on the Request-URI, the IMS network in Czech republic routes the call to the PSAP providing the "Municipal police" emergency service.
                               If in CS, since the the Contact of the 380 response does not match any of urn:service:sos, urn:service:sos.police, urn:service:sos.ambulance, urn:service:sos.fire, urn:service:sos.marine, urn:service:sos.mountain, the UE sends CS SETUP for 156.

The marked text above is one reason why each emergency service needs to have a unique emergency service URN (either country specific emergency URN or an emergency URN assigned by IANA and ECRIT).
There will be some form of “national.police” and some form of “local.police” or “municipal.police" registrations.   If needed, other police registrations can be made, but just using the two registrations for “national.police” and “local.police” and mapping 158 to “national.police’ and “156” to “local.police” would make sense here.  The routing element can still route a call marked “national.police” to the local PSAP or a call marked “national.police” to the local PSAP if it needs to.  Routing can be anything you need it to be; the name of the service doesn’t influence routing.  The system clearly can correctly route a 156 call and a 158 call on the ÇS or IMS networks, and it can clearly route a local.police and a national.police the same way.  The point here is that you have exactly two service codes (156 and 158) and you need exactly two service URNs, and there isn’t any reason at all that using “local.police” and “national.police” won’t work fine.



  1.  It is not possible to consolidate services which are in different nations.

Emergency service X might have a different meaning in different countries, e.g. X.A in country A and X.B in country B.
Furthermore, even if at the moment X.A and X.B would be identical, it cannot be guaranteed that national regulations of A and B would keep X.A and X.B in-line.
From this perspective it would make sense to allow national regulators to determine their national emergency service URNs in a way that is clearly indicated as country-specific.
I don’t agree.  While it may be the case that in some future time some country changes the generally accepted definition of a service, all that we care about is that there is a reasonable mapping available.  If we need to, when the new service is defined, it can get a new service urn if it is indeed a different service.


Assume there are several countries defining the following emergency service:
* 555 - religious/spiritual counselling
It might be difficult to ensure to people of different religious convictions that they end up with a counsellor of their need/expectation. Whilst this maybe could be solved by a designator for specific religion, the issue would for sure be seen by some countries as their decision to make (locally).
Like police, fire and ems, if we need a service URN for “spiritualCounseling” and in some country there is “christian.spiritualCounseling” and “moslem.spiritualCounseling” where in another country there is “Catholic.spiritualCounseling” and “easternOrthodox.spiritualCounseling” then we can make registrations for each of them, because they are actually different services.

EXAMPLE 2
142- Telefonseelsorge (Telefone soul care) is defined as emergency number in Austria and is served by the Catholic and Evangelistic Churches in Austria.
106 - Mental problems hotline in Belgium has nothing to do with the Church.
988 - Helpline (domestic violence/ suicides) in Poland.

It is not possible to consolidate these emergency numbers in 3 different countries under only one urn. They provide almost the same service, but have different ways to help. These 3 numbers cannot be referred to a single URN, since public and regulator expectations towards them are different.
I think those are separate services and would clearly qualify for separate registrations.    While one country might have a suicide prevention service and a separate domestic violence service, there could be a question of whether a combined service is a separate service.  I would think it would be, and would qualify for a registration.  It would clearly work if 988 in Poland used the “suicidePrevention” service URN even though it combines it with domestic violence.  However, I think it’s probably best to give it a separate service URN.


EXAMPLE 3
197- Terror Alert - Child Alert in France
114 - Child emergency in Italy
They cannot be under one URN since the number in France is also responsible for Terror Alert.
Same as above. I think France should have a separate registration, but it would work fine if they just used “childEmergency”.



  1.  In some countries some counselling services are considered as emergency and in other countries they are only counselling services.

EXAMPLE 4
In Austria:
-  147 - Notrufdienst für Kinder und Jugendliche is emergency number according to the regulators/ law. While in Germany [phone]<tel:+49%20800%201110333> Kinder- und Jugendtelefon is not emergency service.
So?  Do you want to map [phone]<tel:+49%20800%201110333> in Germany to “childEmergency” or not?  If it’s not mapped to the service URN, then there is no problem.  If it is, then the call is not an emergency call.  The service URN is designed to work with non-emergency services.  There is no restriction on sos:counseling that it can only be used for non-emergency calls.  If it makes sense in some country to treat it as an emergency call, do it.  Nothing will break somewhere else.


IANA have registered urn:service:sos for “emergency services” and urn:sos:counceling for non-emergency services. 147 has to be mapped under the “emergency services” tree to satisfy Austrian regulatory requirements, while [phone]<tel:+49%20800%201110333> has to remain under the “non-emergency services” tree. It is unclear how the ECRIT expert will handle these requests given the following description for the expert’s role in 4.3 of RFC 5031:
“The expert review should take into account whether these services are offered widely and in different countries, with approximately the same caller expectation in terms of services rendered.”
This is urn:service:sos.childEmergency (or something like it), not urn:service.sos or urn:sos:counceling.




  1.  The local regulator may want to have the routing urns in local language or may want to have a better translation to English that what is chosen in the time of the registration.

All the examples show that emergency services have its local peculiarities in different countries and consolidating them under respective sos sub-services is difficult. In some cases consolidation is possible (the sos urns which are already registered). But in other cases it is not possible to use the current registration process and to satisfy the regulatory requirements in different countries.
Once again, this is a urn, not a human readable tag.  It could be X4476 and work fine.

If there are distinct services, they should get distinct service urns.  Service urns are inexpensive and the process to get a new one is simple.  The fact that in some countries some unusual services, or service combinations exist doesn’t detract from the overall observation that in most countries, there is a common set of services that they all agree on.  Where there are distinct services, ask for a service urn and you will get one.

I believe the examples above give arguments to use “sos.country-specific”.
I don’t agree at all

Brian



_______________________________________________
Ecrit mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ecrit