Re: [Ecrit] country specific emergency URNs

John-Luc Bakker <jbakker@blackberry.com> Thu, 13 July 2017 18:22 UTC

Return-Path: <jbakker@blackberry.com>
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 1FB131318EC for <ecrit@ietfa.amsl.com>; Thu, 13 Jul 2017 11:22:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 KoSLAPO4Sdlo for <ecrit@ietfa.amsl.com>; Thu, 13 Jul 2017 11:22:26 -0700 (PDT)
Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BF9D1316A8 for <ecrit@ietf.org>; Thu, 13 Jul 2017 11:22:26 -0700 (PDT)
Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs211cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Jul 2017 14:22:25 -0400
Received: from XCT115CNC.rim.net (10.65.161.215) by XCT106CNC.rim.net (10.65.161.206) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 13 Jul 2017 14:22:25 -0400
Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT115CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Thu, 13 Jul 2017 14:22:24 -0400
From: John-Luc Bakker <jbakker@blackberry.com>
To: Paul Kyzivat <paul.kyzivat@comcast.net>, "ecrit@ietf.org" <ecrit@ietf.org>
Thread-Topic: [Ecrit] country specific emergency URNs
Thread-Index: AdL2ROp+GC2FwlYiRHWp8QRnly9MhQAeL5mAAEAq5AAAHB2PAAALhiIAAEj9UIAABsHgAAApl6CAAAYxyIAABIinAAASdB2AAB+YDoAAAFpNgAACM2kAAAFmhgAAKQqDAAACnkIgAAgVeAAABJqbYA==
Date: Thu, 13 Jul 2017 18:22:24 +0000
Message-ID: <155970D1DA8E174F9E46039E10E2AA35103A6679@XMB111CNC.rim.net>
References: <52809D5B0606C049903AD6AD07E033E10326EF8FFD@ATWIREMXSC0101.sv.ad.tmo> <CACgrgBY1Y_cT_F-eT-R50H81o5=9xgTjdLgRKS2x59Ar0M4gxw@mail.gmail.com> <52809D5B0606C049903AD6AD07E033E10327096BB1@ATWIREMXSC0101.sv.ad.tmo> <CACgrgBazRYu_XAu2S1t5-mEoMPYmRVFG+az71LLej_wTVFTiqw@mail.gmail.com> <52809D5B0606C049903AD6AD07E033E1032709747D@ATWIREMXSC0101.sv.ad.tmo> <CACgrgBYUs=CfyjuPM9BX9Z1u9o7Boqtpj4=viOMB0VjYu0Aq9w@mail.gmail.com> <52809D5B0606C049903AD6AD07E033E1032709783F@ATWIREMXSC0101.sv.ad.tmo> <CACgrgBY+d==tTbVCuwLcTP_M6saYZw0UpV4Mi66DL2ToCbVeeA@mail.gmail.com> <52809D5B0606C049903AD6AD07E033E10327178504@ATWIREMXSC0101.sv.ad.tmo> <1599E1B5-CBA4-43F9-90FC-FA8D4EBAC28F@brianrosen.net> <52809D5B0606C049903AD6AD07E033E103271785EB@ATWIREMXSC0101.sv.ad.tmo> <CACgrgBbTTBv0ZHShmsSyW3GS06t-MC3YnRqr-K2rD+_r-+PobA@mail.gmail.com> <52809D5B0606C049903AD6AD07E033E10327178B14@ATWIREMXSC0101.sv.ad.tmo> <155970D1DA8E174F9E46039E10E2AA35103A6468@XMB111CNC.rim.net> <fed5346b-da83-0474-3541-0be8a67b2466@comcast.net>
In-Reply-To: <fed5346b-da83-0474-3541-0be8a67b2466@comcast.net>
Accept-Language: en-US, en-CA
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.251]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/wuHmbg2NUyFBlhyGdEolfyz-6gY>
Subject: Re: [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, 13 Jul 2017 18:22:30 -0000

All though I don’t work for a regulator, I can imagine that service definition is not driven by the URN. Identifying the branch of government actually paying for the day-to-day operations is likely to have an influence. That's why even Europe's 112 may map to different URNs in the different countries of Europe.

I am not sure it is up to IETF to limit the types of emergency services countries may wish to develop or to further complicate defining these emergency services.

A limited set of emergency service types have been available via circuit switched (TS 22.101) [police, fire, ambulance, mountain, sea]. This restriction has not limited the creativity of regulators around the world. It has limited the applicability of the CS EMERGENCY SETUP message (the CS EMERGENCY SETUP message has to include one of the types above). It would seem that at a minimum the 5 types above need to be encoded in URNs (and RFC 5031 does that).

There is no global organization (not the UN) chartered to align emergency services. If experience on CS is a guide, leaving it up to regulators to define various country specific emergency services types (under the "sos" label) is a prudent way forward. I am not aware of a desire by regulators to align emergency service types globally.

-----Original Message-----
From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: Thursday, July 13, 2017 11:11 AM
To: ecrit@ietf.org
Subject: Re: [Ecrit] country specific emergency URNs

ISTM that one beneficial effect of creating this general
(non-nation-specific) enumeration of services is to provide a gentle way of encouraging countries to adopt consistent service definitions. Just the small effort of deciding whether one of the existing names will work for your service, or whether a new name is needed, can be a nudge toward consistency.

This seems important when people and their phones are roaming across countries.

	Thanks,
	Paul

On 7/13/17 10:47 AM, John-Luc Bakker wrote:
> Vasil makes a key point: countries determine the emergency services 
> provided within the country and the countries assign the number. *So 
> far, countries have not been required to consult with foreign
> organizations.* Countries may choose to allocate the same number 
> allocated by other countries, however calls may still be routed to 
> PSAPs offering primarily different emergency services: take for 
> example 112 in Europe. Some countries route calls to 112 to police, 
> while others route them to ambulance (in these countries a dedicated 
> emergency number for police may exist (which should bind to the police 
> URN)). Countries have full jurisdiction over their number plans and 
> rules that prescribe how calls to certain numbers shall be treated/routed.
> 
> The only policy they have in common is perhaps the  immediacy of the 
> response. This lines up with the “sos” label (RFC 5031):
> 
>     The 'sos' service type describes emergency services requiring an
> 
>     immediate response, typically offered by various branches of the
> 
>     government or other public institutions.
> 
> The binding of number to URN is country specific. Additional policies 
> beyond the immediacy of the response are country specific. The 
> specific list of services for which immediacy of the response is 
> required are country specific (some services treated as emergency in, 
> say Austria, are not required to be treated as emergency in many other countries).
> 
> Requiring regulators to engage in discussions on ECRIT or awareness of 
> IANA registration processes just for SIP emergency calls seems not 
> practical and confusing, at a minimum.
> 
> Since so much falls solely within the jurisdiction of 
> countries/regulators, this calls into question the need for having a 
> detailed/exhaustive registry beyond identifying some basic, more or 
> less universal services. Beyond this, it is really up to the needs of 
> the public in the country in question.
> 
> *From:*Ecrit [mailto:ecrit-bounces@ietf.org] *On Behalf Of *Aleksiev, 
> Vasil
> *Sent:* Thursday, July 13, 2017 6:05 AM
> *To:* Henning Schulzrinne <hgs@cs.columbia.edu>
> *Cc:* ecrit@ietf.org
> *Subject:* Re: [Ecrit] country specific emergency URNs
> 
> Henning,
> 
> In one country always there is a regulator commission which is 
> monitoring the telecom carriers. The regulator issues rules in written 
> form and monitors if all the carriers are following it. If the written 
> rules are not followed, the regulator issues the respective penalties.
> So every mobile or fixed operator looks into the written rules and 
> takes care of it. In this sense the telecom operators are only caring 
> what is the regulator definition of emergency calls. That is why we 
> have created a file with links to the respective documents, which are 
> issued by the regulators in the respective countries (in form of law). 
> In such document there is definition for emergency calls and list is 
> present with the numbers considered as emergency in the country. The 
> definition usually includes serving the calls with priority, providing 
> location of the subscribers, providing possibility for call back.
> 
> One operator uses such mechanisms only for numbers defined as 
> emergency by the law. Of course every organisation is free to define 
> its own emergency number for some reasons, but the operators do not 
> have an obligation to take care of this and route such numbers as normal calls.
> 
> I think there is no reason to search in google for every possible 
> emergency number which nobody is routing as emergency according to the 
> regulators requirements.
> 
> BR Vasil
> 
> *Von:*Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> *Gesendet:* Mittwoch, 12. Juli 2017 17:29
> *An:* Aleksiev, Vasil <Vasil.Aleksiev@t-mobile.at 
> <mailto:Vasil.Aleksiev@t-mobile.at>>
> *Cc:* Brian Rosen <br@brianrosen.net <mailto:br@brianrosen.net>>; 
> ecrit@ietf.org <mailto:ecrit@ietf.org>
> *Betreff:* Re: [Ecrit] country specific emergency URNs
> 
> Vasil,
> 
> the service URN does not prescribe any network priority treatment. 
> Indeed, at least in the US, landline 911 calls are treated exactly the 
> same as regular calls, e.g., during network congestion. (We have the 
> SIP RPH mechanism for prioritizing call treatment, but it's not used 
> for civilian emergency calls.)
> 
> I suspect this is try for many of the non-112 calls today. I very much 
> doubt that marine emergency calls in Finland or 1-800 calls to the 
> poison control center in the US (and the equivalent set of numbers in 
> Germany, say) receive any priority treatment in the network.
> 
> Again, I think it helps make progress if we do not overload labels 
> with policy.
> 
> Naturally, any country or carrier is free to use any label, including 
> the URN, to signify any treatment local law and regulation permits or 
> requires. But the label does not /require/ or imply such network treatment.
> 
> I admit I'm thoroughly confused by this discussion. Where did the 
> priority issue suddenly come from? It's not in any ECRIT document that 
> I'm aware of.
> 
> Henning
> 
> On Wed, Jul 12, 2017 at 10:49 AM, Aleksiev, Vasil 
> <Vasil.Aleksiev@t-mobile.at <mailto:Vasil.Aleksiev@t-mobile.at>> wrote:
> 
>     Hi Brian,
> 
>     A service URN with a top-level service type of "sos" is used only
>     when the user intends to establish an emergency call. The emergency
>     call will be treated with priority in the network. For non-emergency
>     numbers in one country sos shall not be used since priority there is
>     not needed.
> 
>     Best regards,
> 
>     Vasil
> 
>     *Von:*Brian Rosen [mailto:br@brianrosen.net <mailto:br@brianrosen.net>]
>     *Gesendet:* Mittwoch, 12. Juli 2017 15:46
>     *An:* Aleksiev, Vasil <Vasil.Aleksiev@t-mobile.at
>     <mailto:l.Aleksiev@t-mobile.at>>
>     *Cc:* Henning Schulzrinne <hgs@cs.columbia.edu
>     <mailto:hgs@cs.columbia.edu>>; ecrit@ietf.org <mailto:ecrit@ietf.org>
>     *Betreff:* Re: [Ecrit] country specific emergency URNs
> 
>     Vasil
> 
>     Once again, the name has no significance as long as it is unique. 
>     We use the names as suggestive for the service to aid the service
>     providers, regulators and public safety authorities in setting up
>     the systems, but the urn name is not used by anything other than
>     computer software during an emergency.
> 
>     If one country has a service for an ambulance service that is
>     considered an emergency service, but in another country it is not
>     considered an emergency service, we can, and should still use the
>     service in the sos tree for the non-emergency service.  On the other
>     hand, if there was a country that had two ambulance services, one
>     that was used for emergency transport and another that was used for
>     non-emergency transport, then we would need two URNs, because we
>     have distinct services and need different URNs.
> 
>     Brian
> 
> 
> ______________________________________________________________________
> ____________________
> 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.
> ______________________________________________________________________
> ____________________
> 
> 
> 
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
> 

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit