Re: [dispatch] Request DISPATCH of RUM

Brian Rosen <br@brianrosen.net> Fri, 01 February 2019 22: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 80C8A130ECE for <dispatch@ietfa.amsl.com>; Fri, 1 Feb 2019 14:51:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.03
X-Spam-Level:
X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 kJUu4IycUWRh for <dispatch@ietfa.amsl.com>; Fri, 1 Feb 2019 14:50:57 -0800 (PST)
Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 66F24130EBE for <dispatch@ietf.org>; Fri, 1 Feb 2019 14:50:57 -0800 (PST)
Received: by mail-qt1-x82b.google.com with SMTP id n32so9508569qte.11 for <dispatch@ietf.org>; Fri, 01 Feb 2019 14:50:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kuFFfI5HPIeYSzNWZ5+ifVMU6uT7deylAGVjaarJI7U=; b=tkT/BS+9Fwg/3U6BaeEl3nSOUCioDbqfwDAafnceWO/XWCVOOXZ8F/TdCEgAy1bsod w22CRHtK/jRaa/pmhQNU3TIeMTGaHpzvKrcYz/mI9V0AkZN3M2eqCHtG5m7OT4u0Qy5l KynN+f9sn3xppZP/jw+6n+IhY1+F/7NyCqddxpLMhKRYZFdMLbSumWNA0NPrkJuG8uBp 2PQ+w3l3MFW8wm3BBXatQlWyC54a55iouUDZHQKmg81+F17NKXDT9WO53+bzIoxeSmpK RArn5cw6SPlOWj7y6/nBYYNoKSMEoOru206Pkh/eigZM2VuHiIjXj5DvfapZHBeh6Ne/ seEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kuFFfI5HPIeYSzNWZ5+ifVMU6uT7deylAGVjaarJI7U=; b=ijVkSA6HuPyDX6ijkSATw1lMS5Y/1oa8WSORM59pGh/cdG9fE09wg3HZK2ad4t6wZO Vy7oGioMNIk7QTU0rmCD7RL2kmqHt8dsi81bToxM/fu310WEXb3WpIQiop4QgLVi9agu 2/WDczWKWCoJmZhT5edhp4TjpXWelV5fp/Nz+Y+mIm4zS2B3fZ8VO7IpmciKaMe1k93F cyMGBLCUJvV0ORF23mFXY8WPR/2v0MylJofqYKP9P/BBhKAvK7hgujy86g0KdccvcCBp glAg1w/juhbCQ1fSzg67KvHXm/I4eeiYMkxy6rIFgwmWGmg+grx1qlTXC1c+QLkHOa3S rvxg==
X-Gm-Message-State: AJcUukfFaQV7kuumcgrV6rk0bvXE1DhnHjsC7QQGPi6JP/S5fnDgHCBn ATrRwbJS6tPL/bfXYkVFcGbE6ayxJB0gVLOuHq1qSQ==
X-Google-Smtp-Source: ALg8bN4ggZcnBpuxNM/zE4cnGURm6xhSqXh+n3z3Yiy9baqIElA67MnyIaIbXDtkBy2ALeaBS2TxnoNZwVofd2NFKxs=
X-Received: by 2002:ac8:42c1:: with SMTP id g1mr41285017qtm.118.1549061456387; Fri, 01 Feb 2019 14:50:56 -0800 (PST)
MIME-Version: 1.0
References: <36F81659-DF54-4688-88EE-C86170075072@brianrosen.net> <HE1PR07MB3161E8F2D9398D7D83BC862393920@HE1PR07MB3161.eurprd07.prod.outlook.com> <9C380026-3420-4D56-AA55-BE620558377D@brianrosen.net> <HE1PR07MB3161AC1DA7071C6FD964830D93920@HE1PR07MB3161.eurprd07.prod.outlook.com> <59099553-2629-46AE-BEF3-F551F1073A46@brianrosen.net> <HE1PR07MB3161E331C66C205D59C144E193920@HE1PR07MB3161.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR07MB3161E331C66C205D59C144E193920@HE1PR07MB3161.eurprd07.prod.outlook.com>
From: Brian Rosen <br@brianrosen.net>
Date: Fri, 1 Feb 2019 17:50:45 -0500
Message-ID: <CAOPrzE2+56CXDFHCrAYRA+9AOHijht3bXtZECphgOuWgZevToQ@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: DISPATCH list <dispatch@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d7f0e10580dcf991"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/a3c3s91sRzc_U0f0XLTx-iydr_E>
Subject: Re: [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 22:51:01 -0000

Yes, that’s the idea.  I will work on some wording. I don’t want the
charter to have a list of such features.

Brian

On Fri, Feb 1, 2019 at 5:30 PM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
>
> >Can you suggest a wording change?
>
> Not at the moment, I first want to understand exactly what the scope and
> purpose is.
>
> >It now says "A WebRTC- based RUM could create a SIP interface (using,
> e.g., SIP over
> > WebSockets) towards the provider that conformed to the document RUM will
> produce.  Such >an implementation should be possible, ideally without
> requiring a media gateway.”  That >seems to me to be clear that the wg
> won’t do any work beyond making sure it’s possible to >create a WebRTC
> based RUM without a media gateway.
>
> If the WG is going to "make sure" that it works without a media gateway,
> does that mean that you would also mandate e.g., ICE, continuous consent,
> DTLS, and whatever other media level features might be mandated to support
> by WebRTC? If so, I think it needs to be very clear.
>
> Regards,
>
> Christer
>
>
> Brian
>
>
>
> On Feb 1, 2019, at 4:57 PM, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
>
> Hi,
>
> >We want to make sure the mechanisms interact reasonably.  We suspect this
> is mostly codec
> >choices, etc.
>
> Then you should say that a goal is interoperability with WebRTC when it
> comes to codecs etc.
>
> The way I read the text now is that the WG is about writing WebRTC SIP
> clients, which I assume is outside the scope 😊
>
> Regards,
>
> Christer
>
>
> On Feb 1, 2019, at 4:11 PM, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
> Hi,
>
> If the purpose of the WG is to define a SIP profile, I assume it does not
> matter if the SIP UAs are implemented using WebRTC or something else, so
> why does the charter need to talk about WebRTC?
>
> If you want to look at some of the specific network technologies used by
> WebRTC, e.g., the data channel, I think should talk about that instead.
>
> Regards,
>
> Christer
>
>
> ------------------------------
>
> *From:* dispatch <dispatch-bounces@ietf.org> on behalf of Brian Rosen <
> br@brianrosen.net>
> *Sent:* Friday, February 1, 2019 10:50:53 PM
> *To:* DISPATCH list
> *Subject:* [dispatch] Request DISPATCH of RUM
>
> 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.
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
>
>