Re: [dispatch] Request DISPATCH of RUM

Brian Rosen <br@brianrosen.net> Sat, 02 February 2019 23:18 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 09184130EC6 for <dispatch@ietfa.amsl.com>; Sat, 2 Feb 2019 15:18:33 -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 QhYZwMKCylEu for <dispatch@ietfa.amsl.com>; Sat, 2 Feb 2019 15:18:28 -0800 (PST)
Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 56CC3130EC5 for <dispatch@ietf.org>; Sat, 2 Feb 2019 15:18:28 -0800 (PST)
Received: by mail-qt1-x830.google.com with SMTP id k12so11854828qtf.7 for <dispatch@ietf.org>; Sat, 02 Feb 2019 15:18:28 -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=y4OmkrRXJ5VyyG0BF9D7RU8tvZmaaGeTVC/p8ChvPu4=; b=hNl5dBl0sPL9BZxS0JKyqzhCf9ZOlvDguM4r8bp8V0qJcfgN2YmN2ky4Am5oXRgpDE dzdV8biRJdnOS7IkELVUeHCXa089L2yKIq2JabzJLuIK8ZkTvUH2+7k5KtYpj8+69gBD 34eTMi6pI0UOb80UXOhFwUc9vAGreciZNj0xmuPGPDl/dHU8HB3YWWTIMDKRt5BROZDK /3TaBz47cNrfFWiBe0ekbA9xkQwY7I9JQtlUoKlM0ezNHGAleQ/HlqGBv4HNXIks6GX8 KvIH37PZUueUIziQz/vad4BQGxVsf4HcKyz9gdW9PDnh+kje4NuSREvSgrRnP7f2s9gX TMNQ==
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=y4OmkrRXJ5VyyG0BF9D7RU8tvZmaaGeTVC/p8ChvPu4=; b=ZzKPU9XO2YxdPW1hS7g7Bl16/K4ujSdU+xoDdwsmTFrx01gCzlacIBtSDEDPLyOL0X K8LyD1rkAbQBd1lhukf3MTFoh6X0PzXEbhH13uPR6V35KqpbkQV/0IwMUAdWniiGC0My t2KsRuZSX6Zz53a5vA4F5YqPgQuOrnMEOaZNIkyn9lD477pZ7sx/f4HaA/ACviCs252Y IeBK8+LQiGz0u6AqoPo9HkdnCzKZloLmKfPkueyOSuyvhiIDtJOLwoLOqXeKW/Np5UiB jtINtHeL5osKgBIRupG3IuxflMbCdsURLTOLg13hLwvzKDTxQnKMNzt6cgjYrSrfIpLz dbig==
X-Gm-Message-State: AJcUukfjj8pclqzi5E8D91Txrls3oDXKHaKZT04pFOEXZdq1N7apNTF+ qLfcEJMUKgYUP7PsotWF0Fy4V20UYFLRroy4Vclihw==
X-Google-Smtp-Source: ALg8bN5Sy2EaEZ3L9S6qs05punJisNJjqq8CpQDpg4s1R+NvfwUxTHPkDnjjpuI0WqieQi4Csc0fgGSmMF2GtjcEoYk=
X-Received: by 2002:a0c:dd81:: with SMTP id v1mr43346934qvk.71.1549149507098; Sat, 02 Feb 2019 15:18:27 -0800 (PST)
MIME-Version: 1.0
References: <xw9ytkr6bmcobgbcfs69btor.1549147728175@email.android.com>
In-Reply-To: <xw9ytkr6bmcobgbcfs69btor.1549147728175@email.android.com>
From: Brian Rosen <br@brianrosen.net>
Date: Sat, 2 Feb 2019 18:18:16 -0500
Message-ID: <CAOPrzE28r9+BpoFc-n0spgHY2-BmV2=tbDmFzULN-=niVpwsvw@mail.gmail.com>
To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= <gunnar.hellstrom@omnitor.se>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, DISPATCH list <dispatch@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000132eba0580f17a90"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/wXD8KKgBs1qyA42IU692JwastUk>
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: Sat, 02 Feb 2019 23:18:33 -0000

Hmmm, yeah, we really need to keep RTT in RTP.
We’ll have to use a gateway for that

Yes emergency calls are in scope.

Brian

On Sat, Feb 2, 2019 at 5:48 PM Gunnar Hellström <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>
> Datum: 2019-02-02 00:10 (GMT+01:00)
> Till: Brian Rosen <br@brianrosen.net>
> Kopia: DISPATCH list <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> 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
>
>
>