Re: [Ecrit] URN: for people with hearing loss

"Drage, Keith (Nokia - GB)" <keith.drage@nokia.com> Wed, 19 July 2017 23:56 UTC

Return-Path: <keith.drage@nokia.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 36222126BF3 for <ecrit@ietfa.amsl.com>; Wed, 19 Jul 2017 16:56:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.91
X-Spam-Level:
X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
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 orgTKnpZqNYE for <ecrit@ietfa.amsl.com>; Wed, 19 Jul 2017 16:56:06 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0138.outbound.protection.outlook.com [104.47.0.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8338F128BA2 for <ecrit@ietf.org>; Wed, 19 Jul 2017 16:56:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8nON89ASmi9v9AMw0hO8mI5eZsWIsvQGSieNLltYhgg=; b=WMFgCFPhtR8o+ROSaP2REZGVYAYyIgXd8tk7YJPuGJLNvMM4T735CCJ7JfbdvTel6OVSdXsH5s9bct+dxLK5hY3k+n4OsMskihuiKvl7M5f71tOyukJ8TbJE9WPDA5aj6TyaSs8htbyhb6iVM3kYs1eywerALvZmul/r2Y0qzig=
Received: from DB5PR07MB1480.eurprd07.prod.outlook.com (10.165.212.10) by DB5PR07MB1687.eurprd07.prod.outlook.com (10.166.13.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Wed, 19 Jul 2017 23:56:01 +0000
Received: from DB5PR07MB1480.eurprd07.prod.outlook.com ([fe80::f4d7:1b83:cbeb:be99]) by DB5PR07MB1480.eurprd07.prod.outlook.com ([fe80::f4d7:1b83:cbeb:be99%14]) with mapi id 15.01.1282.011; Wed, 19 Jul 2017 23:56:01 +0000
From: "Drage, Keith (Nokia - GB)" <keith.drage@nokia.com>
To: Henning Schulzrinne <hgs@cs.columbia.edu>, Gunnar Hellström <gunnar.hellstrom@omnitor.se>
CC: ECRIT <ecrit@ietf.org>
Thread-Topic: [Ecrit] URN: for people with hearing loss
Thread-Index: AQHS+pZPj1HU07DS40Whp8HTmgJv9aJPudMAgACRA4CAADx+AIAAAuKAgAtRHeA=
Date: Wed, 19 Jul 2017 23:56:01 +0000
Message-ID: <DB5PR07MB1480D183FEDE9AF52F0FE10EF7A60@DB5PR07MB1480.eurprd07.prod.outlook.com>
References: <CACgrgBaAVY7CJ4XWy8f4P83=HayYjqGQo_M7S_x0hSiRqHQuVQ@mail.gmail.com> <f8a9688f-ca56-3a1a-4c7e-dc871144f901@omnitor.se> <CACgrgBbj9Rmnjf3sLhgbpDtRkmVr2XcFwVqrGshrvF9pSxM+vw@mail.gmail.com> <c9b4f82d-0418-f971-a29b-b06b7b58a0f5@omnitor.se> <CACgrgBZS_xVj1keHYONN3DNyom0QPLJgzRje2uRuPz7FthAqZA@mail.gmail.com>
In-Reply-To: <CACgrgBZS_xVj1keHYONN3DNyom0QPLJgzRje2uRuPz7FthAqZA@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: cs.columbia.edu; dkim=none (message not signed) header.d=none;cs.columbia.edu; dmarc=none action=none header.from=nokia.com;
x-originating-ip: [135.245.212.8]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB5PR07MB1687; 7:qQI2KE5wGoQKMzozTJOIaKBsbfV3c+IjphHRWfM+Wh+pOEE+5H2mW1MAoQyjrvCP3FLYPsiROK+ChmUaD69pShyeJvSL3WPI1oqzQeAJSnazS5fm4E6uaoLAbmxF7Xf1zAy7gCZkOMfsX08Tu8PqsGnH2LXsKINXPRAZibBucRWOwdYUkVWdy5hUXImZ2JCt0GC14cPb1sjyJ8KhRFM5F1I1J+8/T90HKbRNmfQhiE9w+aCss4tP8l4Hp2ID0vsQC8DvbQGZRNlp2KJSc4K7BsYpEOIu91S+6LEBFApic1Om8vaPpCbpsEvzxxjeH5JsJdo4xJGTCJdLz57LoybeJiivElkRQK20XyZNsl5PyI3kduVRP1zsNbU/e/hc+qlpL3dg1FURDMN09WKqVVKQkUQd4j4g9KY69rVfoZq+eHIG4Qufxc8abwSt7dY/mIhVN40wjB+XaGFeZk7UOPGtwjYuGQDVuU/c77JwYaLl6BtoF/bSz0M+odVTWRBJ5eFoln/8g4e5OE5JyHfSYcz/mUwfUqv4MFnBKjkzbyf+OzQGhURTH8w/fPvUjZjccyPftEsvxm5hT+uX0SfAcCuASA53HXD5gBBz+oetiSgPjpdDK+B5ayxybyXjukE+Sp7r8dLywLL4j4ZNR1lad1LxnZVwyNOL7L1H8pHRdSlDF+mvMEeA1fGwG9b7xwXePclxwpQcTDjtpnpE0ViLYXpm7dJbvYCF9xvZDY/LAFq8/HrlRS6zsWkjpZ3dD4bnx3Iutdaq9IaQp+DL/r2HqUe2QTBfLWluRKxp02AqL4gU0qs=
x-ms-office365-filtering-correlation-id: c363c6fe-0e5a-41c1-aad7-08d4cf01b5b8
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB5PR07MB1687;
x-ms-traffictypediagnostic: DB5PR07MB1687:
x-exchange-antispam-report-test: UriScan:(151999592597050)(26388249023172)(236129657087228)(148574349560750)(21748063052155)(247924648384137);
x-microsoft-antispam-prvs: <DB5PR07MB16870A51414687A3C782AEBCF7A60@DB5PR07MB1687.eurprd07.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(2017060910075)(5005006)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB5PR07MB1687; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB5PR07MB1687;
x-forefront-prvs: 0373D94D15
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(39860400002)(39840400002)(39450400003)(39850400002)(39410400002)(39400400002)(377454003)(24454002)(74316002)(86362001)(99286003)(55016002)(6506006)(6436002)(966005)(66066001)(14454004)(53546010)(8676002)(8936002)(478600001)(81166006)(189998001)(7736002)(2906002)(4326008)(50986999)(76176999)(54356999)(2900100001)(7696004)(93886004)(229853002)(33656002)(2950100002)(3280700002)(102836003)(5250100002)(6116002)(6246003)(790700001)(3846002)(5660300001)(3660700001)(606006)(53936002)(54896002)(6306002)(25786009)(2171002)(38730400002)(9686003)(236005)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1687; H:DB5PR07MB1480.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB5PR07MB1480D183FEDE9AF52F0FE10EF7A60DB5PR07MB1480eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2017 23:56:01.6309 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1687
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/SczNLT4fKySTOSVdCLb8Bax7Qo0>
Subject: Re: [Ecrit] URN: for people with hearing loss
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: Wed, 19 Jul 2017 23:56:09 -0000

Replying to the thread as a whole, rather than just to the last message.

Firstly I think we should ignore SMS from a solution based on service URN for a number of reasons.

It has been specified by the regulator as an emergency service in the UK, but imposes no requirements on the mobile operators to treat it any different to a normal SMS, therefore it is formally still a store and forward service. My understanding is that this is regarded as a means to an end, rather than an ideal solution, and ultimately real time text would be the preferred solution.

3GPP does not define an emergency form of SMS, and SMS does not meet the service requirements for emergency call, primarily the need for an interactive communication.

In regard to obtaining a real time text service, surely there are two issues here – do I require routeing to a specialist endpoint, and how do I indicate to the remote endpoint that real time text is required. Surely we only require routeing to a specialist endpoint if either the technology at a normal endpoint cannot handle the service, or a specialist user is required. My understanding of the UK perspective on this is that when a move is made to IP PSAPs, the intention is that all 1st level PSAPs will be capable of handling real time text (in my understanding not a particularly expensive requirement), and that all PSAP attendants will be trained to handle such calls. If that is the case, then there is no special routeing requirement. In terms of indicating the need to the endpoint, then SDP is sufficient. Thus from the UK perspective, I am not understanding the need for anything beyond the existing SOS URN.

I would add that in adding .msg as a subtype, there would be considerable confusion as to its precedence with other subtypes, such as fire. Is sos.msg.fire the same as sos.fire.msg? Assuming those combinations are defined as legal in the first place. Note that if sos.fire.msg was used, and the responder did not understand .fire, then the result would only be understood as sos, and not as sos.msg. Therefore I see major issues of reuse of the URN to indicate this requirement.

Keith

From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Henning Schulzrinne
Sent: 12 July 2017 19:50
To: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
Cc: ECRIT <ecrit@ietf.org>
Subject: Re: [Ecrit] URN: for people with hearing loss

Gunnar,

I found another case that's a bad idea, but reality: Australia uses 106 for TTY (not SMS, no fax) calls. I'll still group it as sos.message, but it shows the range of legacy solutions.

However, there do seem to be other options that are probably more attractive, even if not completely integrated ("ask for 000"):

http://relayservice.gov.au/making-a-call/emergency-calls/

Henning

On Wed, Jul 12, 2017 at 2:39 PM, Gunnar Hellström <gunnar.hellstrom@omnitor.se<mailto:gunnar.hellstrom@omnitor.se>> wrote:
Henning,

Yes, I agree that for the limited application you describe, when a country has a separate number for SMS and/or fax, and handle these calls in a separate PSAP, then they likely currently act as relays when the emergency case is for coastguard or any of the other subservices.

Under such circumstances sos.message would do.

It is just sad that it is not just one number for all emergencies because people cannot learn more than one and remember it in an emergency situation. But that is another story.

Gunnar