Re: [dispatch] Request DISPATCH of RUM

[Brian Rosen <[e-mail]>]

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