Re: [dispatch] Request DISPATCH of RUM

Brian Rosen <br@brianrosen.net> Mon, 04 February 2019 15:34 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 66258130E78 for <dispatch@ietfa.amsl.com>; Mon, 4 Feb 2019 07:34:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.031
X-Spam-Level:
X-Spam-Status: No, score=-2.031 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] 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 7V3pJkx7J8cG for <dispatch@ietfa.amsl.com>; Mon, 4 Feb 2019 07:34:34 -0800 (PST)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 F0D4B130E0A for <dispatch@ietf.org>; Mon, 4 Feb 2019 07:34:33 -0800 (PST)
Received: by mail-qt1-x82e.google.com with SMTP id b15so277906qto.8 for <dispatch@ietf.org>; Mon, 04 Feb 2019 07:34:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=AFO4JWn9pTc+upJwsjk8d7Rypl0dKeRbiFaa+1QPqzE=; b=Cg8KTAtgw75kAJLgN1bJbPP5GO/tHGfhf9zH8s7PfILgGM3Oxyen8zzuQoYqhW2JAj DSd284nIEgnHC20amARELsb9ja0R/XDR00UI+IzhFc95pDpqRju19QgywIdXVoUFJA8u 2RyjpJmw2GtjEyDU0L/XrmABEPMf8maFKszi+HyD8eFgw2qsIPf76e3aq9nYMItlS/s9 ShJGHVDMhV38KIfyW3I9WItylZjtgX/RzxBXBo97GdOM4p6C/s3JUMXoDQMBZoFCftCy KBOrtdlYEezRJYhcuUljJy9m6YrqGwwFzqP62ILQgBoXeEx2zCcgNxa6LBpJh3rHP7sS 50Iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=AFO4JWn9pTc+upJwsjk8d7Rypl0dKeRbiFaa+1QPqzE=; b=Ud68qPmathCL5cARbSOI7kh8Ha/bVztaswjdyiZob4EvCOhSj9jgWPcluyWAsm3/j9 myHz+kRcKHN/6F/lRQdjIfUcXpnEGYY9p+HIH/9eYZU5FLuh3ccPnRR1zYn7ULU0ImZ8 K+KzNRzQxQtQh4VPwECZqGZdTvnWQxv52qbli6EPtUc/EJmLbanr9QF/reXS+LIFLaF4 d6RsHcdvZk0DOQkN3zMGmiqID4OIJUqdwswa5rd/4CfBYyhIMIwPeTxmQbfO8WWldk5I h2ebwu48km7egZ2JklIylkcnWQmHNSW8yCGUhtsbeLp1FLdubycKcWdvuMN/Z7bUUya5 1KTw==
X-Gm-Message-State: AJcUukd4xpNv9mtUK/C3r94NKb0fkepASm+dVvMqTQv8+/gklWmKufLA YAsw/BnVeRCQKaJ6bnFfhTYSMJU/14c=
X-Google-Smtp-Source: ALg8bN6qnaydYQ65jF1IgRqwjVqwkzEzkEqNTVpQppJar7pt5xodwsKskrFhMG8QL9+lmSvuCArxIw==
X-Received: by 2002:ac8:34b3:: with SMTP id w48mr51345358qtb.125.1549294472848; Mon, 04 Feb 2019 07:34:32 -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 c7sm15444526qkj.72.2019.02.04.07.34.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Feb 2019 07:34:32 -0800 (PST)
From: Brian Rosen <br@brianrosen.net>
Message-Id: <9C0BDD07-31D3-461E-BB4F-92CC3AA8C9DB@brianrosen.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D47F47F3-C296-4FC5-8659-7DE7686EB1FC"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Mon, 4 Feb 2019 10:34:31 -0500
In-Reply-To: <599ff1aa-80f3-b44f-5218-261242ae16a3@alum.mit.edu>
Cc: dispatch@ietf.org
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
References: <xw9ytkr6bmcobgbcfs69btor.1549147728175@email.android.com> <CAOPrzE28r9+BpoFc-n0spgHY2-BmV2=tbDmFzULN-=niVpwsvw@mail.gmail.com> <599ff1aa-80f3-b44f-5218-261242ae16a3@alum.mit.edu>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/0V_-AkJq4yZJ3Iv6mrMjpoboPsI>
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: Mon, 04 Feb 2019 15:34:39 -0000

The idea is that the providers implement the sever side of the interface to be defined by this work, and someone writes a device side that works with any provider.
The WebRTC idea is one way to build the device side.  A native SIP implementation is another, probably more common way.  The provider (server) side is all SIP all the time.  Although we could require the providers to implement both RFC4103 and a WebRTC data channel containing RTT, I think that’s a poor way to do it.  We are solving the problem at the moment, not defining the scope.  I will adjust the charter language to allow gateways (“minimize the need for gateways” perhaps).

> On Feb 2, 2019, at 8:29 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> 
> 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><mailto: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>
>>    <mailto: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> <mailto:br@brianrosen.net <mailto:br@brianrosen.net>>>
>>    Kopia: DISPATCH list <dispatch@ietf.org <mailto:dispatch@ietf.org> <mailto: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>
>>    <mailto: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>
>>>        <mailto: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>
>>>>        <mailto: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>
>>>>        <mailto:dispatch-bounces@ietf.org <mailto:dispatch-bounces@ietf.org>>> on behalf of Brian Rosen
>>>>        <br@brianrosen.net <mailto:br@brianrosen.net> <mailto: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> <mailto:dispatch@ietf.org <mailto:dispatch@ietf.org>>
>>>>        https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org <mailto:dispatch@ietf.org>
>> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org <mailto:dispatch@ietf.org>
> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>