Re: [dispatch] Fwd: Request DISPATCH of RUM

[Adam Roach <[e-mail]>]

Thanks. Seeing no objections and significant support, I have initiated 
the chartering process.

/a

On 2/15/19 11:45 AM, Mary Barnes wrote:
> Hi all,
>
> Chairs and ADs think this is ready to move forward, but we'd like to 
> give the WG a final chance to provide any feedback before forwarding 
> to the IESG for official chartering.  Please post any additional 
> comments or concerns by February 22, 2019 CoB
>
> Regards,
> Mary
> DISPATCH WG co-chair
>
>
>
> ---------- Forwarded message ---------
> From: *Brian Rosen* <[e-mail] <mailto:[e-mail]>>
> Date: Thu, Feb 7, 2019 at 4:21 PM
> Subject: Re: [dispatch] Request DISPATCH of RUM
> To: DISPATCH list <[e-mail] <mailto:[e-mail]>>
>
>
> I’ve made the changes requested.  Since this seems to have sufficient 
> interest, and we have bashed the charter fairly well, I would like to 
> request DISPATCH prior to Prague if that is possible.
>
> 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. VRS is used by deaf and 
> hard-of-hearing persons and person with speech impairments 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 
> to the hearing person. The hearing person can also reach D-HOH-SI 
> individuals in the same manner as calling any hearing user. 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.
>
> 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. To ensure 
> interoperability of the key features of this service, certain aspects 
> (e.g., codecs, media transport, addressing 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 communication, including references to 
> work beyond SIP (e.g., WebRTC and SLIM). No protocol changes are 
> anticipated by this work.
>
> Often, the hearing user is on the PSTN, and RUM will include 
> interoperability specifications for that use, including the use of 
> telephone numbers.  RUM will not assume hearing users are on the PSTN.
>
> While WebRTC could be used to implement a RUM, the group’s work will 
> focus on the device-to-provider interface.  The working group will 
> consider ways for WebRTC based services to interwork with a RUM 
> compliant provider, but is not required to make such interwork possible.
>
> RUM devices will be expected to be able to place emergency calls 
> conforming to the current IETF emergency call recommendations.
>
> 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 RUM device and are in scope 
> for this work.
>
> Although the interface between providers also requires standardization 
> to enable multi-provider point-to-point and dial-around calls, that 
>  interface has already been defined in a SIP Forum document and is 
> thus out of scope for RUM.
>
>> On Feb 6, 2019, at 2:19 AM, Gunnar Hellström 
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>> Good,
>>
>> The WebRTC discussion is much more understandable now.
>>
>> There are some mainly editorial issues left.
>>
>> 1. Insert the title again. Without it, RUM is not defined.
>>
>> 2. Far down in first paragraph, "by in" s.b. "in" .
>>
>> 3. You did not delete mentioning PSTN. I suggest that you do, because 
>> it is already said to be gone in some countries. This is a way:
>> 3.1 In first paragraph, delete "on the PSTN"
>>
>> 3.2 Replace "any PSTN user" with "any voice communication user"
>>
>> However, these changes 3.1 and 3.2 may leave it too wide open for 
>> which addressing systems it will work. Interoperability between the 
>> voice communication user and the VRS provider managing the RUM is 
>> required, either directly or through the inter-provider interface. 
>> Please try to insert that scope limitation.
>>
>> Regards
>>
>> Gunnar
>>
>>
>>
>> -------- Originalmeddelande --------
>> Från: Brian Rosen <[e-mail] <mailto:[e-mail]>>
>> Datum: 2019-02-04 21:22 (GMT+01:00)
>> Till: Gunnar Hellström <[e-mail] 
>> <mailto:[e-mail]>>
>> Kopia: Paul Kyzivat <[e-mail] 
>> <mailto:[e-mail]>>, [e-mail] 
>> <mailto:[e-mail]>
>> Rubrik: Re: [dispatch] Request DISPATCH of RUM
>>
>> Here is a new charter text proposal, hopefully addressing all issues 
>> raised so far.  I dialed back the WebRTC stuff, making it a “consider 
>> but not required” thing and removing detail.
>>
>> Many current instances of Video Relay Service (VRS), sometimes called 
>> Video Interpretation Service. use the Session Initiation Protocol 
>> (SIP) and other IETF multimedia protocols. VRS is used by deaf and 
>> hard-of-hearing persons and person with speech impairments 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 PSTN user.  
>> 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.
>>
>> 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. To ensure 
>> interoperability of the key features of this service, certain aspects 
>> (e.g., codecs, media transport, addressing 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 communication, 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 
>> focus on the device-to-provider interface.  The working group will 
>> consider ways for WebRTC based services to interwork with a RUM 
>> compliant provider, but is not required to make such interwork possible.
>>
>> RUM devices will be expected to be able to place emergency calls 
>> conforming to the current IETF emergency call recommendations.
>> 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 RUM device and 
>> are in scope for this work.
>>
>> Although the interface between providers also requires 
>> standardization to enable multi-provider point-to-point and 
>> dial-around calls, that  interface has already been defined in a SIP 
>> Forum document and is thus out of scope for RUM.
>>
>>> On Feb 4, 2019, at 2:32 PM, Gunnar Hellström 
>>> <[e-mail] <mailto:[e-mail]>> 
>>> 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.
>>> Your conclusion is sufficient. Good.
>>>
>>> What wording do you propose for the emergency service support?
>>>
>>> Regards
>>>
>>> Gunnar
>>>
>>>
>>>
>>> Gunnar Hellström
>>> [e-mail] <mailto:[e-mail]>
>>> [phone]
>>>
>>>
>>> -------- Originalmeddelande --------
>>> Från: Brian Rosen <[e-mail] <mailto:[e-mail]>>
>>> Datum: 2019-02-04 16:46 (GMT+01:00)
>>> Till: Gunnar Hellström <[e-mail] 
>>> <mailto:[e-mail]>>
>>> Kopia: Paul Kyzivat <[e-mail] 
>>> <mailto:[e-mail]>>, [e-mail] 
>>> <mailto:[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
>>>
>>
>
> _______________________________________________
> dispatch mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dispatch