Re: [Ecrit] country specific emergency URNs

[Henning Schulzrinne <[e-mail]>]

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]> 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]>
> 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
> <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]
> <+49%20800%201110333> Kinder- und Jugendtelefon is not emergency service.
>
> So?  Do you want to map [phone] <+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] <+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]
> https://www.ietf.org/mailman/listinfo/ecrit
>
>