Re: [dispatch] Request DISPATCH of RUM

[Brian Rosen <[e-mail]>]

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 <[e-mail]> 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 <[e-mail] <mailto:[e-mail]><mailto:[e-mail] <mailto:[e-mail]>>> 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 <[e-mail] <mailto:[e-mail]>
>>    <mailto:[e-mail] <mailto:[e-mail]>>>
>>    Datum: 2019-02-02 00:10 (GMT+01:00)
>>    Till: Brian Rosen <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
>>    Kopia: DISPATCH list <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
>>    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
>>    <[e-mail] <mailto:[e-mail]>
>>    <mailto:[e-mail] <mailto:[e-mail]>>> 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
>>>        <[e-mail] <mailto:[e-mail]>
>>>        <mailto:[e-mail] <mailto:[e-mail]>>> 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
>>>>        <[e-mail] <mailto:[e-mail]>
>>>>        <mailto:[e-mail] <mailto:[e-mail]>>> 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 <[e-mail] <mailto:[e-mail]>
>>>>        <mailto:[e-mail] <mailto:[e-mail]>>> on behalf of Brian Rosen
>>>>        <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
>>>>        *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
>>>>        [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>>>>        https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>
>> _______________________________________________
>> dispatch mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>
> 
> _______________________________________________
> dispatch mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>