Re: [Ecrit] country specific emergency URNs

Henning Schulzrinne <hgs@cs.columbia.edu> Thu, 13 July 2017 18:41 UTC

Return-Path: <hgs10@columbia.edu>
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 1C61613171B for <ecrit@ietfa.amsl.com>; Thu, 13 Jul 2017 11:41:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 ebCeoGeHwQly for <ecrit@ietfa.amsl.com>; Thu, 13 Jul 2017 11:41:27 -0700 (PDT)
Received: from outprodmail01.cc.columbia.edu (outprodmail01.cc.columbia.edu [128.59.72.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F99E131A6D for <ecrit@ietf.org>; Thu, 13 Jul 2017 11:41:27 -0700 (PDT)
Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by outprodmail01.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id v6DIfOqw058975 for <ecrit@ietf.org>; Thu, 13 Jul 2017 14:41:26 -0400
Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 69A35E3 for <ecrit@ietf.org>; Thu, 13 Jul 2017 14:41:26 -0400 (EDT)
Received: from sendprodmail03.cc.columbia.edu (sendprodmail03.cc.columbia.edu [128.59.72.15]) by hazelnut (Postfix) with ESMTP id 4A8DE90 for <ecrit@ietf.org>; Thu, 13 Jul 2017 14:40:56 -0400 (EDT)
Received: from mail-oi0-f70.google.com (mail-oi0-f70.google.com [209.85.218.70]) by sendprodmail03.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id v6DIet9x055357 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for <ecrit@ietf.org>; Thu, 13 Jul 2017 14:40:56 -0400
Received: by mail-oi0-f70.google.com with SMTP id i21so4756657oib.0 for <ecrit@ietf.org>; Thu, 13 Jul 2017 11:40:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+ijzMZUkb7YO/uq+x1zwRBsAK1S7tkbQURohDMedMAc=; b=fuJDkjJcePEblvANniqUkLiFaWPLc51DGYbmjJ0IwOc4WNgGLhKEBhNF5l8YK6IfC5 hSKUrJy8Y9/f5ItsbmU1nXqi65VH65yPiaVQEWbSpfOorcjSdt5IPhIyw3kMXTQK+Ti6 W+4MU1JNFpwSc6WvWnJEtbRpfIl5DuOO5O1spwpysWZGFfjL3lJgN9kROSRWbD3hrkQQ KXGk79JjeD3GjFk/d18GVn4X3Ph9AyxlCBop/eRfNMvKnr5Y+27xIdZH6oo4JEY/tJh3 0q09jh994uxqq3/XIithwpCimRzfy65IF+YIH/I4PMSijzY15aKx33yEtNePJgAoW8hK sLjw==
X-Gm-Message-State: AIVw112gcEuYq315n4I0phsa+v9VTslZmLT+BrHHP5xw6uP2H4m8Pchd XqzhUtyEr2IoEQYp86HdHnfTNXAfQLQB5OF/t2Bg8JmIfpGwiiiwRWWmDiuEO175brrDV2AEOCi y7HSiYYAJtUpHg4jiVlOt
X-Received: by 10.202.95.5 with SMTP id t5mr3854833oib.9.1499971254693; Thu, 13 Jul 2017 11:40:54 -0700 (PDT)
X-Received: by 10.202.95.5 with SMTP id t5mr3854821oib.9.1499971254362; Thu, 13 Jul 2017 11:40:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.116.34 with HTTP; Thu, 13 Jul 2017 11:40:33 -0700 (PDT)
In-Reply-To: <155970D1DA8E174F9E46039E10E2AA35103A6468@XMB111CNC.rim.net>
References: <52809D5B0606C049903AD6AD07E033E10326EF8FFD@ATWIREMXSC0101.sv.ad.tmo> <AF1BEB84-A0D2-44AD-9666-1C608B73BC68@brianrosen.net> <CACgrgBbgMqWn3ovUogw6o_pLPhJBpSOPZ+JgDcSfgzzChcUcAQ@mail.gmail.com> <DB5PR07MB14806FA9F5D0FA90DEF2E1E2F7AB0@DB5PR07MB1480.eurprd07.prod.outlook.com> <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>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Date: Thu, 13 Jul 2017 14:40:33 -0400
Message-ID: <CACgrgBZNpLSTU7ywMQE2E1e1D3JnuADVAf3d5R5uQRi7Bautfg@mail.gmail.com>
To: John-Luc Bakker <jbakker@blackberry.com>
Cc: "Aleksiev, Vasil" <Vasil.Aleksiev@t-mobile.at>, "ecrit@ietf.org" <ecrit@ietf.org>
Content-Type: multipart/alternative; boundary="001a113ce2b2ca3a620554374571"
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.78 on 128.59.72.15
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/wuUWhmQgu2Vkz_pBXi92gd0dAUs>
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:41:31 -0000

I don't expect this to change. Regulators and other entities say something
like "implement a national lost-children service using 116 000". They don't
specify protocols, URNs, IP addresses, port numbers or other details, and
don't need to. This is very similar to, say, mobile services, where a
regulator may auction spectrum and impose service conditions ("serve 95% of
the population within 5 years"). They don't show up at 3GPP defining the
radio access network modulation parameters or the protocol constants in
DIAMETER.

Thus, this requires no "negotiation".

This would be different if the IETF were to say "lost children services
need to use the phone number 123 and will get lower priority than 112
calls". Clearly, that steps into territory that regulators do care about
since it affects the user interface and experience. Service URNs, as we
have beaten to death on this thread, are not visible to users and do not
affect user experience. (Leaving aside fall-back corner cases.)

Henning

On Thu, Jul 13, 2017 at 10:47 AM, John-Luc Bakker <jbakker@blackberry.com>
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
> <hgs@cs.columbia.edu>]
> *Gesendet:* Mittwoch, 12. Juli 2017 17:29
> *An:* Aleksiev, Vasil <Vasil.Aleksiev@t-mobile.at>
> *Cc:* Brian Rosen <br@brianrosen.net>; 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> 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]
> *Gesendet:* Mittwoch, 12. Juli 2017 15:46
> *An:* Aleksiev, Vasil <Vasil.Aleksiev@t-mobile.at>
> *Cc:* Henning Schulzrinne <hgs@cs.columbia.edu>; 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.
> ____________________________________________________________
> ______________________________
>