Re: [dispatch] Request DISPATCH of RUM

[Paul Kyzivat <[e-mail]>]

On 2/4/19 2:32 PM, Gunnar Hellström wrote:
> Thanks, I think all your answers are good.
> About the WebRTC issue, some clarification in wording seems to be needed.
> 
> About the addressing issue, I also think your response is good.
> 
> You started that topic with "To my knowledge, there are no Video 
> Interpretation Services that provide interpreters for telephone calls 
> that do not use E.164s as the address."
> That is right. My request for support of other addressing forms was 
> rather from the observation that an enormous amount of calls nowadays 
> are set up with other addressing forms than E.164 numbers. With such 
> calls lacking VRS support we are seeing a rapidly decreasing 
> accessibility level in the communication area and a need for improvements.

I have been thinking for a long time that it would be good to define a 
new interface for VRS provision, that only provides the interpretation 
services, not the telephony origination/termination service. Anybody who 
wanted to provide audio/video connectivity (regardless of the form of 
addressing) could then "bridge" in the VRS service when it is needed.

	Thanks,
	Paul

> Your conclusion is sufficient. Good.
> 
> What wording do you propose for the emergency service support?
> 
> Regards
> 
> Gunnar
> 
> 
> 
> Gunnar Hellström
> [e-mail]
> [phone]
> 
> 
> -------- Originalmeddelande --------
> Från: Brian Rosen <[e-mail]>
> Datum: 2019-02-04 16:46 (GMT+01:00)
> Till: Gunnar Hellström <[e-mail]>
> Kopia: Paul Kyzivat <[e-mail]>, [e-mail]
> Rubrik: Re: [dispatch] Request DISPATCH of RUM
> 
> Inline
> 
>> On Feb 3, 2019, at 5:12 PM, Gunnar Hellström 
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>> Brian,
>>
>> A. About technology and WebRTC
>> At the moment it seems most important to get the scope clear. And for 
>> that, the issue if this is about a WebRTC RUM interface or a native 
>> SIP RUM interface or both. Another implementation environment could be 
>> 3GPP IMS RUM. Is that also in scope? Is it really realistic to write a 
>> RUM spec that fulfilles the goal to allow the users to move a device 
>> between providers regardless if they use native SIP or WebRTC (or even 
>> IMS )?  ( if that is what is meant by the section about WebRTC).
>> Maybe a list of supported call cases is needed to make us understand 
>> and accept an intended scope.
> I proposed scope that defined a SIP interface where it would be possible 
> to build a WebRTC implementation that ultimately provided the client 
> side of that interface. That means that the WebRTC server created the 
> client side SIP interface towards the provider.
> 
> I would like it to be possible to do that, but I don’t think that is the 
> design center.  I do think re-using the media specs from WebRTC is the 
> right set of choices to make for this profile, independent of whether 
> the user has a WebRTC client or a native SIP client.
>>
>> B. About Paul's call cases:
>> The statement: "For a p2p call with another WebRTC user a gateway 
>> won't be
>> needed." is in conflict with a statement by the end of the charter 
>> saying: "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."
>> If the users are registered by WebRTC to different providers, and want 
>> to set up a p2p call, then the charter says that the providers would 
>> use the provider-to-provider interface specified by SIP Forum. But 
>> that is a native SIP interface and requires gateways from any WebRTC 
>> RUM. So it must be decided, are we specifying for WebRTC, and do we 
>> support multi-provider WebRTC calls and do we assume the 
>> provider-to-provider interface to be the SIP FORUM spec?
> We are specifying a native SIP interface.  It may be possible to 
> interwork some other client to that interface.
> 
>>
>> C. Number calling and other forms of calling
>> I think the scope regarding addressing should be clarified in the 
>> charter. Only one sentence mentions addressing: "The hearing person 
>> can also reach D-HOH-SI individuals by in the same manner as calling 
>> any other phone number."
>> Nowadays a large portion of calls are made with other addressing than 
>> phone numbers, and we must prepare to enable VRS use also in such 
>> calls. It would be best if the RUM spec is agnostic to what kind of 
>> addressing is used. That may be possible, because the number handling 
>> and conversion between numbers and SIP URI is handled elsewhere. I 
>> think anyway that the scope of addressing variants is worth a 
>> paragraph in the charter. 
> 
> To my knowledge, there are no Video Interpretation Services that provide 
> interpreters for telephone calls that do not use E.164s as the address. 
>   While the actual address of the SIP device is a SIP URI, and we could 
> say that we support that, the interwork for dialing needs to be 
> explicit, so that whenever telephone numbers are used, the device 
> interface uses them consistently.    I’ll propose language that allows 
> SIP URIs for the device address.
>>
>> Proposal: Delete the mentioning of number, and include the following 
>> paragraph: "Addressing of participants in the calls are supposed to be 
>> based on general addressing conventions in SIP. Any conversion needed 
>> between this form and other addressing forms (e.g. phone numbers) 
>> required for completion of the calls are assumed to take place in 
>> other parts of the networks."
>>
>> D: Do you also want to discuss minor edits in the charter? If so, here 
>> are a couple of hints:
>>
>> D.1. This phrase: "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." should be changed. PSTN is fading away. The call 
>> might also be automated. Maybe it is sufficient to modify it to:  "The 
>> deaf, hard- of- hearing or speech-impaired person (D-HOH-SI) uses a 
>> SIP-based video phone to connect with a provider, and the provider 
>> conveyes the call to the hearing person and includes an interpreter in 
>> the call."
>>
>> (this wording would also support the implementation when the 
>> interpreter actually is involved in placing the leg of the call to the 
>> hearing person)
> I will adjust the wording
>>
>> D.2. There are a number of places where it is obvious that the wording 
>> is copied from a  document with changemarks, and both the original and 
>> the modification happened to be included in the charter. The first 
>> example of this kind is on line 4, where "VRSwhich" has apparently 
>> history in a modification from "which" to "VRS" and should be just  
>> "VRS". I can help to sort them out if you want.
> Yes, sorry, I didn’t notice that.  I will fix it in the next version
> 
>>
>>
>> Regards
>>
>> Gunnar
>>
>>
>>
>>
>>
>>
>> -------- Originalmeddelande --------
>> Från: Paul Kyzivat <[e-mail] <mailto:[e-mail]>>
>> Datum: 2019-02-03 02:29 (GMT+01:00)
>> Till:[e-mail] <mailto:[e-mail]>
>> Rubrik: Re: [dispatch] Request DISPATCH of RUM
>>
>> 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]>> 
>> 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]>>
>> >     Datum: 2019-02-02 00:10 (GMT+01:00)
>> >     Till: Brian Rosen <[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>
>> >     Kopia: DISPATCH list <[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]>> 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]>> 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]>> 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]>> on behalf of Brian Rosen
>> >>>         <[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]>
>> >>>        https://www.ietf.org/mailman/listinfo/dispatch
>> >
>> >
>> > _______________________________________________
>> > dispatch mailing list
>> >[e-mail] <mailto:[e-mail]>
>> >https://www.ietf.org/mailman/listinfo/dispatch
>> >
>>
>> _______________________________________________
>> dispatch mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/dispatch
>> _______________________________________________
>> dispatch mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/dispatch
>