[dispatch] Request DISPATCH of RUM

Brian Rosen <br@brianrosen.net> Fri, 01 February 2019 20:51 UTC

Return-Path: <br@brianrosen.net>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80ED8124408 for <dispatch@ietfa.amsl.com>; Fri, 1 Feb 2019 12:51:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.032
X-Spam-Level:
X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 maLZgcfUNl3Q for <dispatch@ietfa.amsl.com>; Fri, 1 Feb 2019 12:50:56 -0800 (PST)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C1C01312F4 for <dispatch@ietf.org>; Fri, 1 Feb 2019 12:50:56 -0800 (PST)
Received: by mail-qt1-x82f.google.com with SMTP id y20so9123283qtm.13 for <dispatch@ietf.org>; Fri, 01 Feb 2019 12:50:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=Skxa4vo/C8K6pgE1Udzj+hZgbuY2qYhxZwdF+qtUidQ=; b=tsrMrIDc/AUIwpnrSFf3i+bGfnxBM427hKUT9gQHtipXgA4RJUK0AEoYySvVtiZC2a dkAW47oFIEy5cIGRCFbYbJwKHAGMEZAYdVgYgC8UZxDc99atA3fV1x7dvxYWtzu2YwjB YiciJmOusflj69SDq7MNKzYgoU4ZHiuwD+jWx/8P/AXDW7RMPqXPLBxmWluMpICKefef R9w4ZWqIJCWp9IiA1pdhgK8pQuK407Hg/B3YopjFJBMQZN8PjSdTYTKSy5XAYw+gnvXe rjss+Vy97pyF9VsRJHwfsYxVtplVcRKgQBoyApqBIQptD8c1a9xZsiu4LFx4pQGYzwqW wgew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=Skxa4vo/C8K6pgE1Udzj+hZgbuY2qYhxZwdF+qtUidQ=; b=axM9/kE17hFJS2bkxpVd1uZ/ybl5EmtUGeJA6mT72cMabrERHnbgR1h4jnWthZXuTC qEaxn+5wCx3p/gJr2oyRpdeYTewKlXqgYKUIClU6j/llC/prJEzXCRezLkL5DekrwykE UmenV3l6vVq1pnVJcOHtQNdmb8mBzxHOjD9EJR6D9+iq40Rrxz+lqGA8FlT66xDSsKVw NhVcnEBsto3TTfRyS1kmQTIjAlY5ki/K1rigkFThCJGNBjaW0YzB+rBCdjyyN2aQDyCr Y9tnKgW5awfumxFjOMiixLSSIP0toBCgfbulo66no+v+xo4B0tE9wpX03PXhGCJn1bBL 8cog==
X-Gm-Message-State: AJcUukcq4h138BDBHw3Oc2Qqy+ovug0K7pwyXNrd5N9SUKP4WI02iDYU j+jQx33D3tDvRzhBgeuyChKCH/kbSjI=
X-Google-Smtp-Source: ALg8bN5RgQrUhf0maDwIaerSNyprKnkDg9vR/EwWQ47Tb19A/hQ2JFWe+RsvQkS/PqYE01eTU4v+Og==
X-Received: by 2002:ac8:26b9:: with SMTP id 54mr40622152qto.301.1549054255142; Fri, 01 Feb 2019 12:50:55 -0800 (PST)
Received: from brians-mbp.lan (dynamic-acs-72-23-220-152.zoominternet.net. [72.23.220.152]) by smtp.gmail.com with ESMTPSA id t43sm18521162qtc.53.2019.02.01.12.50.54 for <dispatch@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Feb 2019 12:50:54 -0800 (PST)
From: Brian Rosen <br@brianrosen.net>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Message-Id: <36F81659-DF54-4688-88EE-C86170075072@brianrosen.net>
Date: Fri, 01 Feb 2019 15:50:53 -0500
To: DISPATCH list <dispatch@ietf.org>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/DulYa-smNK96RXGos_x_lEjeUw8>
Subject: [dispatch] Request DISPATCH of RUM
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Feb 2019 20:51:00 -0000

I would like dispatch to consider spinning up a mini-work group to create a sip device profile for use with Video Relay Services.  


The proposed charter is:

Relay User Machine (rum) Working Group Proposed Charter
ART Area
 
Many current instances of Video Relay Service (VRS), (sometimes called Video Interpretation Service.), use the Session Initiation Protocol (SIP) and other IETF multimedia protocols. VRSwhich is used bya service that deaf and hard- of- hearing persons and person with speech impairments use to communicate with hearing persons.  The deaf, hard- of- hearing or speech-impaired person (D-HOH-SI) uses a SIP- based video phone to connect with an interpreter, and the interpreter places a phone call on the PSTN to the hearing person. The hearing person can also reach D-HOH-SI individuals by in the same manner as calling any other phone number.  The D-HOH-SI person uses sign language and possibly real-time text with the interpreter and the interpreter uses spoken language with the hearing person, providing on- line, real- time, two- way communication.  VRS services are often government- supported.  In some countries, private companies provide the interpreters, and compete with one another.  Often these companies use proprietary implementations for user devices as a means of vendor lock in.  

Having a standard interface between the end- user device and the VRS provider allows vendors and open-source developers to build devices that work with multiple service providers; devices can also be retained when changing providers.  In this instance, “device” could be a purpose-built videophone or could be downloadable software on a general purpose computing platform or mobile phone.  The SIP protocol is complex enough that some form of profiling is needed to achieve interoperability between devices and providers. To ensure interoperability of the key features of this service, certain aspects (e.g., codecs, media transport, and SIP features) must be specified as mandatory-to-implement for SIP-based VRS devices. These specified features effectively form a profile for SIP and the media it negotiates.
 
This working group will produce a single document: a profile of SIP and media features for use with video relay services (which includes video, real time text, and audio), and other similar interpretation services that require multimedia.  It will reference the IETF’s current thinking on multimedia communicationsuch devices, including references to work beyond SIP (e.g., WebRTC and SLIM).  No protocol changes are anticipated by this work.
 
While WebRTC could be used to implement a RUM, the group’s work will focusis on the device-to-provider interface.  A WebRTC- based RUM couldwould create a SIP interface (using, e.g., SIP over WebSockets) towards the provider that conformed to the document RUMrum will produce.  Such an implementation should be possible, ideally without requiring a media gateway.
 
The scope of the work includes mechanisms to provision the user’s device with common features such as speed dial lists, provider to contact, videomail service interface point and similar items.  These features allow users to more easily switch providers temporarily (a feature known as “dial around”) or permanently, while retaining their data.

Devices used in VRS can be used to place point- to- point calls, i.e., where both communicating parties use sign language.  When used for point-to-point calling where the participants are not served by the same VRS provider, or when one provider provides the originating multimedia transport environment, but another provides the interpreter (“dial-around call”), the call traverses two providers.  Both of these uses impose additional requirements on a RUMrum device and are in scope for this work.  

Although the interface between providers also requires standardization to enable multi-provider point-to-point calls, that  interface has already been defined in a SIP Forum document and is thus out of scope for RUM.