Re: [dispatch] Request DISPATCH of RUM

Brian Rosen <> Mon, 04 February 2019 15:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66258130E78 for <>; Mon, 4 Feb 2019 07:34:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.031
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7V3pJkx7J8cG for <>; Mon, 4 Feb 2019 07:34:34 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F0D4B130E0A for <>; Mon, 4 Feb 2019 07:34:33 -0800 (PST)
Received: by with SMTP id b15so277906qto.8 for <>; Mon, 04 Feb 2019 07:34:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 ( []) by with ESMTPSA id c7sm15444526qkj.72.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Feb 2019 07:34:32 -0800 (PST)
From: Brian Rosen <>
Message-Id: <>
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, 04 Feb 2019 10:34:31 -0500
In-Reply-To: <>
To: Paul Kyzivat <>
References: <> <> <>
X-Mailer: Apple Mail (2.3445.102.3)
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: 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 <> 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 < <>< <>>> 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 < <>
>>    < <>>>
>>    Datum: 2019-02-02 00:10 (GMT+01:00)
>>    Till: Brian Rosen < <> < <>>>
>>    Kopia: DISPATCH list < <> < <>>>
>>    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
>>    < <>
>>    < <>>> 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
>>>> <> < <>>
>>>> <>
>> _______________________________________________
>> dispatch mailing list
>> <>
>> <>
> _______________________________________________
> dispatch mailing list
> <>
> <>