[Ecrit] country specific emergency URNs

"Aleksiev, Vasil" <Vasil.Aleksiev@t-mobile.at> Thu, 06 July 2017 11:37 UTC

Return-Path: <Vasil.Aleksiev@t-mobile.at>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4DC129AF3 for <ecrit@ietfa.amsl.com>; Thu, 6 Jul 2017 04:37:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wg7TJ51qwQFy for <ecrit@ietfa.amsl.com>; Thu, 6 Jul 2017 04:37:01 -0700 (PDT)
Received: from shmail05.t-systems.at (shmail05.t-systems.at [212.31.88.92]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CCD8126E64 for <ecrit@ietf.org>; Thu, 6 Jul 2017 04:36:59 -0700 (PDT)
X-IronPort-RemoteIP: 213.162.65.68
X-IronPort-MID: 7633510
X-IronPort-Reputation: None
X-IronPort-Listener: DefaultListener
X-IronPort-SenderGroup: TMA_Relay
X-IronPort-MailFlowPolicy: $RELAY
X-HAT: Sender Group TMA_Relay, Policy $RELAY applied.
X-ExtLoop1: 1
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2HmAwB6H15Z/0RBotVGFoMfIRwtUxCBELV1ghEHARyFeAIjgwE/GAEBAQEBAQEBAQEBAmgdC4IzIhBGWAEBAQEBASMCCIEGEBwWDAMdATMCCwEGCTAUEgEEEwgGC4gOAYIIA7N7gUWJfwEBAQEGAQEBAQEUD4MngTGCHGd5ghiFPRUmCg4SCgmDBIIxBYldhzOGHodbBgKBAIIcgQuCHYIMgjqDRIdCGYFMji2VOB85gQoegTWDAIITHIFpdIYzgj8BAQE
X-IronPort-AV: E=Sophos;i="5.40,317,1496095200"; d="xml'?xlsx'72,48?scan'72,48,208,217,72,48?bin'72,48,208,217,72,48?rels'72,48,208,217,72,48"; a="7633510"
X-Spam-Processed: mailint1.t-mobile.at, Thu, 06 Jul 2017 13:37:33 +0200 (not processed: message from trusted or authenticated source)
X-MDHelo: ATWIREHUBV0001.sv.ad.tmo
X-MDArrival-Date: Thu, 06 Jul 2017 13:37:33 +0200
X-Return-Path: Vasil.Aleksiev@t-mobile.at
X-Envelope-From: Vasil.Aleksiev@t-mobile.at
X-MDaemon-Deliver-To: ecrit@ietf.org
From: "Aleksiev, Vasil" <Vasil.Aleksiev@t-mobile.at>
To: "ecrit@ietf.org" <ecrit@ietf.org>
Date: Thu, 06 Jul 2017 13:36:44 +0200
Thread-Topic: country specific emergency URNs
Thread-Index: AdL2ROp+GC2FwlYiRHWp8QRnly9MhQ==
Message-ID: <52809D5B0606C049903AD6AD07E033E10326EF8FFD@ATWIREMXSC0101.sv.ad.tmo>
Accept-Language: en-US, de-AT
Content-Language: de-DE
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US, de-AT
Content-Type: multipart/mixed; boundary="_004_52809D5B0606C049903AD6AD07E033E10326EF8FFDATWIREMXSC010_"
MIME-Version: 1.0
X-TMADISCLAIMER: MAILINT1
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/DcOCc7lMUOOGBroTxHpE0dXEcOw>
Subject: [Ecrit] country specific emergency URNs
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jul 2017 11:37:05 -0000

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).





 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.

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).



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.



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.



 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 +49 800 1110333 Kinder- und Jugendtelefon is not emergency service.


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 +49 800 1110333 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."



 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.
I believe the examples above give arguments to use "sos.country-specific".

Best regards,
Vasil

T-Mobile International Austria GmbH
Vasil Aleksiev
SIM - Standardization & IPR Management

Rennweg 97-99, A-1030 Wien
Mobile: +43 676 8200 5145
E-Mail: vasil.aleksiev@t-mobile.at<mailto:stefanie.simon@t-mobile.at>
www.t-mobile.at<http://www.t-mobile.at>

LIFE IS FOR SHARING



__________________________________________________________________________________________
Notice: This e-mail and any attachments are confidential and may be privileged.
If you are not the intended recipient, notify the sender immediately, destroy all
copies from your system and do not disclose or use the information for any purpose.
Diese E-Mail inklusive aller Anhaenge ist vertraulich und koennte bevorrechtigtem
Schutz unterliegen. Wenn Sie nicht der beabsichtigte Adressat sind, informieren Sie
bitte den Absender unverzueglich, loeschen Sie alle Kopien von Ihrem System und
veroeffentlichen Sie oder nutzen Sie die Information keinesfalls, gleich zu welchem Zweck.

Think before you print!

T-Mobile Austria GmbH
Geschaeftsfuehrung: Dr. Andreas Bierwirth (Vorsitzender), Aufsichtsrat: Dr. Rolf Nafziger (Vorsitzender)
Firmenbuch: Handelsgericht Wien, Sitz Wien, FN 171112k, UID ATU 45011703, DVR 0898295
Konto: UniCredit Bank Austria AG IBAN: AT93 1200 0528 4407 2301, BIC: BKAUATWW

T-Mobile - Das verbindet uns.
__________________________________________________________________________________________