Re: [rtcweb] Possible New Cases - Emergency Services Call & Text

Harald Alvestrand <harald@alvestrand.no> Sun, 31 July 2011 12:31 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C982D21F8593 for <rtcweb@ietfa.amsl.com>; Sun, 31 Jul 2011 05:31:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+k2VbSM2kxr for <rtcweb@ietfa.amsl.com>; Sun, 31 Jul 2011 05:31:42 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2E45621F8588 for <rtcweb@ietf.org>; Sun, 31 Jul 2011 05:31:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E098F39E0FA for <rtcweb@ietf.org>; Sun, 31 Jul 2011 14:30:32 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okAomQHS531B for <rtcweb@ietf.org>; Sun, 31 Jul 2011 14:30:32 +0200 (CEST)
Received: from [172.16.1.228] (173-167-136-97-illinois.hfc.comcastbusiness.net [173.167.136.97]) by eikenes.alvestrand.no (Postfix) with ESMTPS id B90FB39E0F5 for <rtcweb@ietf.org>; Sun, 31 Jul 2011 14:30:31 +0200 (CEST)
Message-ID: <4E354B2C.2040505@alvestrand.no>
Date: Sun, 31 Jul 2011 08:31:40 -0400
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <9EF49A9D-7F17-4E92-AECA-55BC7ABC7339@gmail.com>
In-Reply-To: <9EF49A9D-7F17-4E92-AECA-55BC7ABC7339@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Possible New Cases - Emergency Services Call & Text
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 Jul 2011 12:31:42 -0000

On 07/30/11 07:03, Paul Beaumont wrote:
> This was mentioned is the initial RTCWeb session at IETF 81 but just to make sure it has been captured and understood.
>
> (1) Please can a separate use case be added for an Emergency Services telephony call (eg 999 in UK, 112 in EU, 911 in NA, etc).
I am skeptical to adding this use case. The most important issues and 
complications that ES brings to the table are with call setup, which I 
believe is outside of what RTCWEB should be focusing on. As long as 
there is nothing special about the media plane issues here, I would 
prefer not to take it on.
> (2) Please can a further separate use case be added for an Emergency Services real time text (eg 18000 in UK, via TextDirect operator to ES operator for hearing impaired persons). FYI today this is a low speed in-band voice band data call on the text leg. Presumably the replacement would be some kind of Presence/Messaging replacement with assured delivery or similar.
>
> Please note these are treated differently today in current networks and I would suggest we aim to preserve the capabilities - subject to discussion in the community, in the right WG - eg ECRIT. These are, using legacy terminology ...
>
> A). Prioritisation in processing of Emergency Services calls above Ordinary Calls, particularly when server in overload.
Are you talking about prioritization in the control plane (out of scope) 
in the media plane, or both? Note that the media plane doesn't 
necessarily have any servers in it.
> B). Marking of Emergency Services calls to a specific A-/Calling Party Category to allow them to be identified downstream.
Same question here.
> C). Release control modified to B-/Called Party Control with changed RTCWeb browser client behaviour along with indication as to "Off Hook" and "On Hook".
Does the "hook" map to anything we currently have in our APIs or concepts?
> Paul
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>