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, 01 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 > > >
- Re: [dispatch] Request DISPATCH of RUM Christer Holmberg
- [dispatch] Request DISPATCH of RUM Brian Rosen
- Re: [dispatch] Request DISPATCH of RUM Brian Rosen
- Re: [dispatch] Request DISPATCH of RUM Christer Holmberg
- Re: [dispatch] Request DISPATCH of RUM Richard Shockey
- Re: [dispatch] Request DISPATCH of RUM Brian Rosen
- Re: [dispatch] Request DISPATCH of RUM Brian Rosen
- Re: [dispatch] Request DISPATCH of RUM Christer Holmberg
- Re: [dispatch] Request DISPATCH of RUM Brian Rosen
- Re: [dispatch] Request DISPATCH of RUM Christer Holmberg
- Re: [dispatch] Request DISPATCH of RUM Gunnar Hellström
- Re: [dispatch] Request DISPATCH of RUM Brian Rosen
- Re: [dispatch] Request DISPATCH of RUM Paul Kyzivat
- Re: [dispatch] Request DISPATCH of RUM Gunnar Hellström
- Re: [dispatch] Request DISPATCH of RUM Brian Rosen
- Re: [dispatch] Request DISPATCH of RUM Brian Rosen
- Re: [dispatch] Request DISPATCH of RUM Brian Rosen
- Re: [dispatch] Request DISPATCH of RUM Gunnar Hellström
- Re: [dispatch] Request DISPATCH of RUM Paul Kyzivat
- Re: [dispatch] Request DISPATCH of RUM Brian Rosen
- Re: [dispatch] Request DISPATCH of RUM Paul Kyzivat
- Re: [dispatch] Request DISPATCH of RUM Brian Rosen
- Re: [dispatch] Request DISPATCH of RUM Gunnar Hellström
- Re: [dispatch] Request DISPATCH of RUM Gunnar Hellström
- Re: [dispatch] Request DISPATCH of RUM Brian Rosen
- [dispatch] Fwd: Request DISPATCH of RUM Mary Barnes
- Re: [dispatch] Fwd: Request DISPATCH of RUM Eric Burger
- Re: [dispatch] Fwd: Request DISPATCH of RUM Paul Kyzivat
- Re: [dispatch] Fwd: Request DISPATCH of RUM Roni Even (A)
- [dispatch] DISPATCH of JCS Anders Rundgren
- Re: [dispatch] DISPATCH of JCS Dale R. Worley
- Re: [dispatch] DISPATCH of JCS Anders Rundgren
- Re: [dispatch] DISPATCH of JCS Dale R. Worley
- Re: [dispatch] Fwd: Request DISPATCH of RUM Adam Roach
- Re: [dispatch] Request DISPATCH of RUM Brian Rosen