Re: [dispatch] Request DISPATCH of RUM

Paul Kyzivat <pkyzivat@alum.mit.edu> Sun, 03 February 2019 01:29 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 B8EB3130EDE for <dispatch@ietfa.amsl.com>; Sat, 2 Feb 2019 17:29:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 qKZjiqem0jHi for <dispatch@ietfa.amsl.com>; Sat, 2 Feb 2019 17:29:13 -0800 (PST)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6170130E2B for <dispatch@ietf.org>; Sat, 2 Feb 2019 17:29:12 -0800 (PST)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x131T9aq019454 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <dispatch@ietf.org>; Sat, 2 Feb 2019 20:29:10 -0500
To: dispatch@ietf.org
References: <xw9ytkr6bmcobgbcfs69btor.1549147728175@email.android.com> <CAOPrzE28r9+BpoFc-n0spgHY2-BmV2=tbDmFzULN-=niVpwsvw@mail.gmail.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <599ff1aa-80f3-b44f-5218-261242ae16a3@alum.mit.edu>
Date: Sat, 2 Feb 2019 20:29:09 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <CAOPrzE28r9+BpoFc-n0spgHY2-BmV2=tbDmFzULN-=niVpwsvw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/PPipEuLSLv7WSSYChpSP2cX7BAg>
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: Sun, 03 Feb 2019 01:29:16 -0000

On 2/2/19 6:18 PM, Brian Rosen wrote:
> Hmmm, yeah, we really need to keep RTT in RTP.
> We’ll have to use a gateway for that

In the case of a call with an interpreter the provider can provide the 
gateway, or provide the interpreter with native text over data channel 
support. For a p2p call with another WebRTC user a gateway won't be 
needed. The only special case is a p2p call with one WebRTC endpoint and 
one native SIP endpoint.

	Thanks,
	Paul

> Yes emergency calls are in scope.
> 
> Brian
> 
> On Sat, Feb 2, 2019 at 5:48 PM Gunnar Hellström 
> <gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>> wrote:
> 
>     So far, in tradiitional SIP based VRS, real-time text has been
>     implemented with RTP, while in WebRTC it is supposed to use the data
>     channel. How would you specify that interop without a media gateway?
> 
> 
>     Another issue: should possibility to interop with emergency services
>     be mentioned in the charter? I assume that such calls need to pass
>     through the provider, and can be gatewayed ther, but there is a
>     desire that all media is conveyed between the emergency service and
>     the RUM and  there might therefore be a need to consider this
>     requirement when specifying the RUM interface.
> 
> 
>     Regards
>     Gunnar
> 
> 
> 
>     -------- Originalmeddelande --------
>     Från: Christer Holmberg <christer.holmberg@ericsson.com
>     <mailto:christer.holmberg@ericsson.com>>
>     Datum: 2019-02-02 00:10 (GMT+01:00)
>     Till: Brian Rosen <br@brianrosen.net <mailto:br@brianrosen.net>>
>     Kopia: DISPATCH list <dispatch@ietf.org <mailto:dispatch@ietf.org>>
>     Rubrik: Re: [dispatch] Request DISPATCH of RUM
> 
> 
>     Hi,
> 
>      >Yes, that’s the idea.  I will work on some wording. I don’t want
>     the charter to have a
>      >list of such features.
> 
>     You could say that the profile will mandate all features needed in
>     order to interoperate with WebRTC without having to use a media
>     gateway, or something like that.
> 
>     Regards,
> 
>     Christer
> 
> 
> 
>     Brian
> 
>     On Fri, Feb 1, 2019 at 5:30 PM Christer Holmberg
>     <christer.holmberg@ericsson.com
>     <mailto: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
>>         <mailto: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
>>>         <mailto: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
>>>         <mailto:dispatch-bounces@ietf.org>> on behalf of Brian Rosen
>>>         <br@brianrosen.net <mailto: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 <mailto:dispatch@ietf.org>
>>>         https://www.ietf.org/mailman/listinfo/dispatch
> 
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>