Re: [dispatch] Request DISPATCH of RUM

Brian Rosen <> Fri, 01 February 2019 22:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 80C8A130ECE for <>; Fri, 1 Feb 2019 14:51:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.03
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kJUu4IycUWRh for <>; Fri, 1 Feb 2019 14:50:57 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 66F24130EBE for <>; Fri, 1 Feb 2019 14:50:57 -0800 (PST)
Received: by with SMTP id n32so9508569qte.11 for <>; Fri, 01 Feb 2019 14:50:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <> <> <> <> <>
In-Reply-To: <>
From: Brian Rosen <>
Date: Fri, 01 Feb 2019 17:50:45 -0500
Message-ID: <>
To: Christer Holmberg <>
Cc: DISPATCH list <>
Content-Type: multipart/alternative; boundary="000000000000d7f0e10580dcf991"
Archived-At: <>
Subject: Re: [dispatch] Request DISPATCH of RUM
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


On Fri, Feb 1, 2019 at 5:30 PM Christer Holmberg <> 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 <
>> 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 <
>> 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 <> on behalf of Brian Rosen <
> *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