Subject: Re: [dispatch] Request DISPATCH of RUM

From: Gunnar Hellström <[email-masked]>
Date: Wed, 06 Feb 2019 08:19:18 +0100

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. RegardsGunnar

-------- Originalmeddelande --------
Från: Brian Rosen <[email-masked]> 
Datum: 2019-02-04  21:22  (GMT+01:00) 
Till: Gunnar Hellström <[email-masked]> 
Kopia: Paul Kyzivat <[email-masked]>, [email-masked] 
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 <[email-masked]> 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?RegardsGunnarGunnar [email-masked]+46 708 204 288-------- Originalmeddelande --------Från: Brian Rosen <[email-masked]> Datum: 2019-02-04  16:46  (GMT+01:00) Till: Gunnar Hellström <[email-masked]> Kopia: Paul Kyzivat <[email-masked]>, [email-masked] Rubrik: Re: [dispatch] Request DISPATCH of RUM InlineOn Feb 3, 2019, at 5:12 PM, Gunnar Hellström <[email-masked]> wrote:Brian,A. About technology and WebRTCAt 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 callingI 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 wordingD.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 versionRegardsGunnar-------- Originalmeddelande --------Från: Paul Kyzivat <[email-masked]> Datum: 2019-02-03 02:29 (GMT+01:00) Till: [email-masked] 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 thatIn 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 > <[email-masked] <mailto:[email-masked]>> 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 <[email-masked]>     <mailto:[email-masked]>>>     Datum: 2019-02-02 00:10 (GMT+01:00)>     Till: Brian Rosen <[email-masked] <mailto:[email-masked]>>>     Kopia: DISPATCH list <[email-masked] <mailto:[email-masked]>>>     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>     <[email-masked]>     <mailto:[email-masked]>> 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>>         <[email-masked]>>         <mailto:[email-masked]>> 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>>>         <[email-masked]>>>         <mailto:[email-masked]>> 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 <[email-masked]>>>         <mailto:[email-masked]>> on behalf of Brian Rosen>>>         <[email-masked] <mailto:[email-masked]>>>>>         *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>>>         [email-masked] <mailto:[email-masked]>>>>         https://www.ietf.org/mailman/listinfo/dispatch> > > _______________________________________________> dispatch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/dispatch> _______________________________________________dispatch mailing [email-masked]://www.ietf.org/mailman/listinfo/dispatch_______________________________________________dispatch mailing [email-masked]://www.ietf.org/mailman/listinfo/dispatch

---

From: Brian Rosen <[email-masked]>
Date: Thu, 7 Feb 2019 17:21:10 -0500

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 <[email-masked]> 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
> 
> 
> 
> 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 <[email-masked] <mailto:[email-masked]>> 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
>> [email-masked] <mailto:[email-masked]>
>> +46 708 204 288
>> 
>> 
>> Från: Brian Rosen <[email-masked] <mailto:[email-masked]>> 
>> Datum: 2019-02-04 16:46 (GMT+01:00) 
>> Till: Gunnar Hellström <[email-masked] <mailto:[email-masked]>> 
>> Kopia: Paul Kyzivat <[email-masked] <mailto:[email-masked]>>, [email-masked] <mailto:[email-masked]> 
>> Inline
>>> On Feb 3, 2019, at 5:12 PM, Gunnar Hellström <[email-masked] <mailto:[email-masked]>> 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
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Från: Paul Kyzivat <[email-masked] <mailto:[email-masked]>> 
>>> Datum: 2019-02-03 02:29 (GMT+01:00) 
>>> Till: [email-masked] <mailto:[email-masked]> 
>>> 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 
>>> > <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> 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
>>> > 
>>> > 
>>> > 
>>> >     Från: Christer Holmberg <[email-masked] <mailto:[email-masked]>
>>> >     <mailto:[email-masked] <mailto:[email-masked]>>>
>>> >     Datum: 2019-02-02 00:10 (GMT+01:00)
>>> >     Till: Brian Rosen <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>>> >     Kopia: DISPATCH list <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>>> >     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
>>> >     <[email-masked] <mailto:[email-masked]>
>>> >     <mailto:[email-masked] <mailto:[email-masked]>>> 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
>>> >>         <[email-masked] <mailto:[email-masked]>
>>> >>         <mailto:[email-masked] <mailto:[email-masked]>>> 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
>>> >>>         <[email-masked] <mailto:[email-masked]>
>>> >>>         <mailto:[email-masked] <mailto:[email-masked]>>> 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 <[email-masked] <mailto:[email-masked]>
>>> >>>         <mailto:[email-masked] <mailto:[email-masked]>>> on behalf of Brian Rosen
>>> >>>         <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>>> >>>         *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
>>> >>>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>> >>>         https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>
>>> > 
>>> > 
>>> > _______________________________________________
>>> > dispatch mailing list
>>> > [email-masked] <mailto:[email-masked]>
>>> > https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>
>>> > 
>>> 
>>> _______________________________________________
>>> dispatch mailing list
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>
>>> _______________________________________________
>>> dispatch mailing list
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>
>

---

From: Mary Barnes <[email-masked]>
Date: Fri, 15 Feb 2019 11:45:32 -0600

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 <[email-masked]>
Date: Thu, Feb 7, 2019 at 4:21 PM
Subject: Re: [dispatch] Request DISPATCH of RUM
To: DISPATCH list <[email-masked]>

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.

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 <[email-masked]>
wrote:

Good,

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"

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 <[email-masked]>
Datum: 2019-02-04 21:22 (GMT+01:00)
Till: Gunnar Hellström <[email-masked]>
Kopia: Paul Kyzivat <[email-masked]>, [email-masked]
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 <[email-masked]>
wrote:

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.

Regards

Gunnar

Gunnar Hellström
[email-masked]
+46 708 204 288

-------- Originalmeddelande --------
Från: Brian Rosen <[email-masked]>
Datum: 2019-02-04 16:46 (GMT+01:00)
Till: Gunnar Hellström <[email-masked]>
Kopia: Paul Kyzivat <[email-masked]>, [email-masked]
Rubrik: Re: [dispatch] Request DISPATCH of RUM

Inline

On Feb 3, 2019, at 5:12 PM, Gunnar Hellström <[email-masked]>
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)

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.

Regards

Gunnar

-------- Originalmeddelande --------
Från: Paul Kyzivat <[email-masked]>
Datum: 2019-02-03 02:29 (GMT+01:00)
Till: [email-masked]
Rubrik: Re: [dispatch] Request DISPATCH of RUM

Thanks,
Paul

> <[email-masked] <mailto:[email-masked]
<[email-masked]>>> wrote:
>     Från: Christer Holmberg <[email-masked]
>     <mailto:[email-masked]
<[email-masked]>>>
>     Till: Brian Rosen <[email-masked] <mailto:[email-masked]
<[email-masked]>>>
>     Kopia: DISPATCH list <[email-masked] <mailto:[email-masked]
<[email-masked]>>>
>     <[email-masked]
>     <mailto:[email-masked]
<[email-masked]>>> wrote:
>>         <[email-masked]
>>         <mailto:[email-masked]
<[email-masked]>>> wrote:
>>>         <[email-masked]
>>>         <mailto:[email-masked]
>>>         *From:*dispatch <[email-masked]
>>>         <mailto:[email-masked] <[email-masked]>>>
on behalf of Brian Rosen
>>>         <[email-masked] <mailto:[email-masked] <[email-masked]>
>>
>>>         [email-masked] <mailto:[email-masked] <[email-masked]>>
>>>         https://www.ietf.org/mailman/listinfo/dispatch
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Feb 2019 15:30:37 -0500

I'm in favor and hope to participate.

	Thanks,
	Paul

On 2/15/19 12:45 PM, 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

---

From: "Roni Even (A)" <[email-masked]>
Date: Sun, 17 Feb 2019 06:23:44 +0000

Hi,
I support and will participate
Roni Even

From: dispatch [mailto:[email-masked]] On Behalf Of Mary Barnes
Sent: Friday, February 15, 2019 7:46 PM
To: DISPATCH
Cc: ART ADs; dispatch chairs
Subject: [dispatch] Fwd: Request DISPATCH of RUM

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 <[email-masked]<mailto:[email-masked]>>
Date: Thu, Feb 7, 2019 at 4:21 PM
Subject: Re: [dispatch] Request DISPATCH of RUM
To: DISPATCH list <[email-masked]<mailto:[email-masked]>>

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.

On Feb 6, 2019, at 2:19 AM, Gunnar Hellström <[email-masked]<mailto:[email-masked]>> wrote:

Good,

Regards

Gunnar

-------- Originalmeddelande --------
Från: Brian Rosen <[email-masked]<mailto:[email-masked]>>
Datum: 2019-02-04 21:22 (GMT+01:00)
Till: Gunnar Hellström <[email-masked]<mailto:[email-masked]>>
Kopia: Paul Kyzivat <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>
Rubrik: Re: [dispatch] Request DISPATCH of RUM

On Feb 4, 2019, at 2:32 PM, Gunnar Hellström <[email-masked]<mailto:[email-masked]>> wrote:

Regards

Gunnar

Gunnar Hellström
[email-masked]<mailto:[email-masked]>
+46 708 204 288

-------- Originalmeddelande --------
Från: Brian Rosen <[email-masked]<mailto:[email-masked]>>
Datum: 2019-02-04 16:46 (GMT+01:00)
Till: Gunnar Hellström <[email-masked]<mailto:[email-masked]>>
Kopia: Paul Kyzivat <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>
Rubrik: Re: [dispatch] Request DISPATCH of RUM

Inline

On Feb 3, 2019, at 5:12 PM, Gunnar Hellström <[email-masked]<mailto:[email-masked]>> wrote:

Brian,

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.."

Regards

Gunnar

-------- Originalmeddelande --------
Från: Paul Kyzivat <[email-masked]<mailto:[email-masked]>>
Datum: 2019-02-03 02:29 (GMT+01:00)
Till: [email-masked]<mailto:[email-masked]>
Rubrik: Re: [dispatch] Request DISPATCH of RUM

Thanks,
Paul

> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>
>     Från: Christer Holmberg <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]>>
>     Till: Brian Rosen <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
>     Kopia: DISPATCH list <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
>     <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]>> wrote:
>
>         Hi,
>
>>         <[email-masked]<mailto:[email-masked]>
>>         <mailto:[email-masked]>> wrote:
>>
>>
>>         Hi,
>>
>>>         <[email-masked]<mailto:[email-masked]>
>>>         <mailto:[email-masked]>> wrote:
>>>
>>>         Hi,
>>>
>>>         *From:*dispatch <[email-masked]<mailto:[email-masked]>
>>>         <mailto:[email-masked]>> on behalf of Brian Rosen
>>>         <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
>>>         [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
dispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
dispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dispatch

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 17 Feb 2019 07:30:58 +0100

Hi,
Since our BoF request for IETF-104 apparently was rejected, I hope that our request for DISPATCH processing of 2018-02-13 will be considered.

Recently updated I-D:
https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-05

Thanx,
Anders

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 18 Feb 2019 17:16:13 -0500

> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-05

The value of having a JSON canonicalization is clear to me.  But I note
that the abstract doesn't seem to actually *say* that the document
defines a JSON canonicalization, but leaves the reader to infer from the
name, "JSON Canonicalization Scheme", what JCS does...

Dale

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 19 Feb 2019 05:26:45 +0100

> name, "JSON Canonicalization Scheme", what JCS does...

    Cryptographic operations like hashing and signing requires that the
    original data does not change during serialization or parsing.  One
    way addressing this issue is creating a canonical form of the data.
    The JSON Canonicalization Scheme (JCS) performs this task on data
    provided in JSON [RFC8259] format.  JCS achieves this by building
    on the strict serialization formats for JSON primitives defined by
    ECMAScript [ES6], constraining JSON data to the I-JSON [RFC7493]
    subset, and through a platform independent property sorting scheme.

Better?

Anders

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 19 Feb 2019 22:31:28 -0500

>     Cryptographic operations like hashing and signing requires that the
s/requires/require/
>     way addressing this issue is creating a canonical form of the data.
---------^
"of" is missing here
>     provided in JSON [RFC8259] format.  JCS achieves this by building
You might want to omit "provided".
>     subset, and through a platform independent property sorting scheme.
I think this is "platform-independent property-sorting scheme", but
you'd better check with the Editor.

Yes, that clarifies it.

Dale

---

From: Adam Roach <[email-masked]>
Date: Mon, 25 Feb 2019 17:47:38 -0600

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

/a

On 2/15/19 11:45 AM, Mary Barnes wrote:
> 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
>
>
>
> From: *Brian Rosen* <[email-masked] <mailto:[email-masked]>>
> To: DISPATCH list <[email-masked] <mailto:[email-masked]>>
>
>
> 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 
> 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 
> 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 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Good,
>>
>> 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:
>> 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
>>
>>
>>
>> Kopia: Paul Kyzivat <[email-masked] 
>> <mailto:[email-masked]>>, [email-masked] 
>> <mailto:[email-masked]>
>> 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.
>>
>> 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 
>> 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.
>>
>> standardization to enable multi-provider point-to-point and 
>> dial-around calls, that  interface has already been defined in a SIP 
>>> On Feb 4, 2019, at 2:32 PM, Gunnar Hellström 
>>> <[email-masked] <mailto:[email-masked]>> 
>>> wrote:
>>>
>>> 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.
>>> Kopia: Paul Kyzivat <[email-masked] 
>>> <mailto:[email-masked]>>, [email-masked] 
>>> <mailto:[email-masked]>
>>>> On Feb 3, 2019, at 5:12 PM, Gunnar Hellström 
>>>> <[email-masked] <mailto:[email-masked]>> 
>>>> wrote:
>>>>
>>>> Brian,
>>>>
>>>> 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).
>>> 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.
>>>>
>>>> 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.
>>>
>>>>
>>>> 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.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)
>>>> 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.
>>>> Till:[email-masked] <mailto:[email-masked]>
>>>> > <[email-masked] 
>>>> <mailto:[email-masked]><mailto:[email-masked]>> 
>>>> wrote:
>>>> >
>>>> <mailto:[email-masked]>
>>>> >    Till: Brian Rosen <[email-masked] 
>>>> <mailto:[email-masked]><mailto:[email-masked]>>
>>>> >    Kopia: DISPATCH list <[email-masked] 
>>>> <mailto:[email-masked]><mailto:[email-masked]>>
>>>> <mailto:[email-masked]>
>>>> >>>        <[email-masked] 
>>>> <mailto:[email-masked]><mailto:[email-masked]>>
>>>> >>>        [email-masked] <mailto:[email-masked]><mailto:[email-masked]>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 26 Feb 2019 17:44:04 -0500

We don’t have a mailing list yet.  It can wait, but we need it.

Brian

> On Feb 25, 2019, at 6:47 PM, Adam Roach <[email-masked]> wrote:
> 
> Thanks. Seeing no objections and significant support, I have initiated the chartering process.
> 
> /a
> 
>> From: Brian Rosen <[email-masked] <mailto:[email-masked]>>
>>> On Feb 6, 2019, at 2:19 AM, Gunnar Hellström <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Good,
>>>