Re: [dispatch] Request DISPATCH of RUM

[Paul Kyzivat <[e-mail]>]

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