Subject: [Rum] Action Items from RUM session at IETF 111

From: Paul Kyzivat <[email-masked]>
Date: Thu, 19 Aug 2021 12:03:51 -0400

The minutes from the RUM session include a number of action items. 
Specifically, the following people made commitments:

Brian Rosen
Isaac Roach
Alex Ospina

Brian is working on an updated version, but it won't include the 
concerns of the others above if we don't hear from you. Rather than try 
to summarize those I refer you back to the minutes. You can find them at:
https://datatracker.ietf.org/doc/minutes-111-rum/

I plan to issue WGLC on the document soon. I will wait one week (until 
Aug 26). If there hasn't been any followup by then I will ask Brian to 
issue a version that we can advance to WGLC.

	Thanks,
	Paul

---

From: Eugene Christensen <[email-masked]>
Date: Wed, 25 Aug 2021 18:58:52 +0000

Brian, Paul thank you for considering the changes that have been brought up to this point.  Leaving things alone with the X-Card, the inclusion of the instance-id for location, additions to support notification services for mobile, etc. are all appreciated.
 
It is my opinion that we should not include requirements for the following in the new RUM document.  Here are the reasons that I believe this way.
 
WebRTC
 
* While there is an RFC for WebRTC, it doesn't appear that all browsers are following it.  For example, TMMBR is required for WebRTC but Chrome does not signal it.
* WebRTC is an audio first implementation.  For VRS, video is the most important media stream.  It means everything to the deaf or hard of hearing user.  If video is suffering first in a lossy network, that is a problem for VRS.
* Some of the VRS providers do not currently support the following items.  This could pose a significant impact on the VRS providers to get this implemented.
o Encryption (DTLS)
o ICE
o RTP/RTCP Muxing
 
IPv6 
* For those VRS providers whose current implementations do not support IPv6, this can be a big jump to get their solution to support both IPv4 as well as IPv6.  Granted, it does not require being dual stacked but rather could be two separate servers, each supporting their respective version of IP.  This could be a big undertaking just to get IPv6 into the mix.  
* Another solution could be an IPv4 to IPv6 gateway but that doesn't work flawlessly.  For example, the gateway can forward the IPv6 SIP message to the proper address on the IPv4 network, however, how does it resolve the embedded IPv6 addresses signaled in the SDP?  So, for example, consider two RUEs, one legacy RUE that is using IPv4 and one that is IPv6; the signaling is possible for both once the servers for each support that or provide a IP gateway between the two.  How is the media going to work?  Each of the RUEs is going to provide an IP address in their SDP, one will be IPv4 and the other IPv6.  How is this going to work without having to anchor all the media somewhere?
* Are there issues that we need to resolve with NAT64 and/or DNS64?  
* As I understand it, some mobile devices are already IPv6 but do not follow the RFC for embedding an IPv4 address into an IPv6 address.  This is going to require special handling to get this to work with such devices on vendors that do not follow the RFC in this regard.
 
Message Waiting Indicator
* Some, if not all, of the current implementations of RUE by VRS providers, already include means to record video messages and are not all created the same way.  Proprietary methods have been used.  The document states that MWI is optional but if the ability to leave a message is provided then MWI is to be implemented.  Since there are proprietary solutions, it seems appropriate to me that this should be changed so that proprietary solutions and indications can continue to be utilized.

I don't believe I have enumerated all the reasons for not including requirements for the above but I believe the examples given are sufficient to consider.

Regards,
Eugene Christensen

CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential and proprietary information. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail at [email-masked] or by telephone at +1 (801) 287-9419, and destroy the original transmission and its attachments without reading them or saving them to disk.

-----Original Message-----
From: Rum <[email-masked]> On Behalf Of Paul Kyzivat
Sent: Thursday, August 19, 2021 10:04 AM
To: [email-masked]
Cc: Alexander Ospina <[email-masked]>; Isaac Roach <[email-masked]>; Brian Rosen <[email-masked]>
Subject: [Rum] Action Items from RUM session at IETF 111

[EXTERNAL] 

Brian Rosen
Isaac Roach
Alex Ospina

	Thanks,
	Paul

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Aug 2021 15:09:53 -0400

Eugene,

Thank you for following up. I will respond to your comments, but I first 
want to see what others have to say.

It would be good to hear the other providers view on these things too.

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 26 Aug 2021 13:16:04 +0200

Friends,
This is the IETF after all. 

We can’t let any documents be published without IPv6. The problems you outline here are surely solved in existing implementations of SIP, propably since many years ago. If not, we have work to do.

In addition, RUM services without SRTP/DTLS will be used over any network, including the Internet, and it is a very bad solution that feels like something we sold in the SIP world a long time ago. The world has moved since then.

I strongly urge that the RUM specs has to require mandatory IPv6 support as well as SRTP/DTLS encryption.

I would personally go as far as to say that SRTP/DTLS is a MUST and nothing else is ok, very much like WebRTC.

In regards to proprietary vs open standards, this is again the IETF. We produce open standards and a RUM specification has to point to a SIP SUBSCRIBE/NOTIFY package for MWI. 

Remember that what I’m talking about is documents as specified by the IETF. Industry profiles and various services may go other ways, but the IETF standards has to be up to date with best current practise.

Cheers,
/O

> On 25 Aug 2021, at 20:58, Eugene Christensen <[email-masked]> wrote:
>

---

From: Roger Slusser <[email-masked]>
Date: Thu, 26 Aug 2021 10:17:04 -0400

Hello all,
First off these are personal comments and not as a spokesperson for the VRS
provider I work for.

I have to agree right down the line with Eugene Christensen. I have been a
part of this from day one and have been directly involved in the setup and
execution of the bi-annual Interop conferences and development of the
Provider Interoperability Profile.

It is obvious to me that this RUM RFC will be picked up by the FCC as the
new spec for the VATRP. So let's not kid ourselves or mince words about
implementations, industry profiles and various services. This endpoint spec
will be terminated by a VRS provider Interpreter station or proprietary
endpoint in 99% of the use cases. By mandating via "MUSTs" in this RFC, and
there are many, it will force the VRS providers to abandon current project
plans and business goals to turn attention to implementing things in this
RFC that have very little value to the Deaf and HH end users we support.
Every provider already has a notification scheme for message waiting, most
of which is much more elaborate and sophisticated than MWI, yet this RFC
will force less desirable services... why? This is just an example that has
been objected to since day one and yet it still has stuck like glue. Let's
not lose focus of the driving force here, the betterment of the endpoint
experience for the Deaf and HH user base.

I understand this is IETF. I understand this must have the latest and
greatest tech the industry has to offer, but I think the driving committee
members of this RFC also need to understand the realities of implementation
and the hardship this can and will bring to providers with the "MUSTs". The
FCC denies funding for non compliance, the reality is these "MUSTs" could
put providers out of business.

I know there are heavy hitters in the IETF community on this project. But
there are also founding members of the VRS industry who have offered
comments with reasonable explanations that have been dismissed. After 18
year I believe we know our customer base. The Deaf employees in our
companies in marketing and sales collectively drive our product offerings
to best suit their needs because we eat our own dog food.. I would urge
this committee to take long and hard consideration of the experience that
in my opinion is being dismissed offhandedly for the sake of new tech that
has very little to do with our customers needs or wants.

Thanks for your consideration,
Roger Slusser

On Thu, Aug 26, 2021 at 7:16 AM Olle E. Johansson <[email-masked]> wrote:

> We can’t let any documents be published without IPv6. The problems you
> outline here are surely solved in existing implementations of SIP, propably
> since many years ago. If not, we have work to do.
>
> In addition, RUM services without SRTP/DTLS will be used over any network,
> including the Internet, and it is a very bad solution that feels like
> something we sold in the SIP world a long time ago. The world has moved
> since then.
>
> I would personally go as far as to say that SRTP/DTLS is a MUST and
> nothing else is ok, very much like WebRTC.
>
> In regards to proprietary vs open standards, this is again the IETF. We
> produce open standards and a RUM specification has to point to a SIP
> SUBSCRIBE/NOTIFY package for MWI.
>
> Remember that what I’m talking about is documents as specified by the
> IETF. Industry profiles and various services may go other ways, but the
> IETF standards has to be up to date with best current practise.
>
> Cheers,
> /O
>
> > Brian, Paul thank you for considering the changes that have been brought
> up to this point.  Leaving things alone with the X-Card, the inclusion of
> the instance-id for location, additions to support notification services
> for mobile, etc. are all appreciated.
> >
> > It is my opinion that we should not include requirements for the
> following in the new RUM document.  Here are the reasons that I believe
> this way.
> >
> > WebRTC
> >
> > * While there is an RFC for WebRTC, it doesn't appear that all browsers
> are following it.  For example, TMMBR is required for WebRTC but Chrome
> does not signal it.
> > * WebRTC is an audio first implementation.  For VRS, video is the most
> important media stream.  It means everything to the deaf or hard of hearing
> user.  If video is suffering first in a lossy network, that is a problem
> for VRS.
> > * Some of the VRS providers do not currently support the following
> items.  This could pose a significant impact on the VRS providers to get
> this implemented.
> > o Encryption (DTLS)
> > o ICE
> > o RTP/RTCP Muxing
> >
> > IPv6
> > * For those VRS providers whose current implementations do not support
> IPv6, this can be a big jump to get their solution to support both IPv4 as
> well as IPv6.  Granted, it does not require being dual stacked but rather
> could be two separate servers, each supporting their respective version of
> IP.  This could be a big undertaking just to get IPv6 into the mix.
> > * Another solution could be an IPv4 to IPv6 gateway but that doesn't
> work flawlessly.  For example, the gateway can forward the IPv6 SIP message
> to the proper address on the IPv4 network, however, how does it resolve the
> embedded IPv6 addresses signaled in the SDP?  So, for example, consider two
> RUEs, one legacy RUE that is using IPv4 and one that is IPv6; the signaling
> is possible for both once the servers for each support that or provide a IP
> gateway between the two.  How is the media going to work?  Each of the RUEs
> is going to provide an IP address in their SDP, one will be IPv4 and the
> other IPv6.  How is this going to work without having to anchor all the
> media somewhere?
> > * As I understand it, some mobile devices are already IPv6 but do not
> follow the RFC for embedding an IPv4 address into an IPv6 address.  This is
> going to require special handling to get this to work with such devices on
> vendors that do not follow the RFC in this regard.
> >
> > * Some, if not all, of the current implementations of RUE by VRS
> providers, already include means to record video messages and are not all
> created the same way.  Proprietary methods have been used.  The document
> states that MWI is optional but if the ability to leave a message is
> provided then MWI is to be implemented.  Since there are proprietary
> solutions, it seems appropriate to me that this should be changed so that
> proprietary solutions and indications can continue to be utilized.
> >
> >
> > I don't believe I have enumerated all the reasons for not including
> requirements for the above but I believe the examples given are sufficient
> to consider.
> >
> > Regards,
> > Eugene Christensen
> >
> > CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents,
> files or previous e-mail messages attached to it, may contain confidential
> and proprietary information. If you are not the intended recipient, or a
> person responsible for delivering it to the intended recipient, you are
> hereby notified that any disclosure, copying, distribution or use of any of
> the information contained in or attached to this message is STRICTLY
> PROHIBITED. If you have received this transmission in error, please
> immediately notify me by reply e-mail at [email-masked] or by
> telephone at +1 (801) 287-9419, and destroy the original transmission and
> its attachments without reading them or saving them to disk.
> >
> > Cc: Alexander Ospina <[email-masked]>; Isaac Roach <
> [email-masked]>; Brian Rosen <[email-masked]>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 26 Aug 2021 16:31:05 +0200

> On 26 Aug 2021, at 16:17, Roger Slusser <[email-masked]> wrote:
> 
> Hello all,
> First off these are personal comments and not as a spokesperson for the VRS provider I work for. 
> 
> I have to agree right down the line with Eugene Christensen. I have been a part of this from day one and have been directly involved in the setup and execution of the bi-annual Interop conferences and development of the Provider Interoperability Profile.  
> 
> It is obvious to me that this RUM RFC will be picked up by the FCC as the new spec for the VATRP.
Roger,
With all respect. There is a world outside the USA. RFCs are written with global scope, not limited to a specific market or group of vendors.

> So let's not kid ourselves or mince words about implementations, industry profiles and various services. This endpoint spec will be terminated by a VRS provider Interpreter station or proprietary endpoint in 99% of the use cases. By mandating via "MUSTs" in this RFC, and there are many, it will force the VRS providers to abandon current project plans and business goals to turn attention to implementing things in this RFC that have very little value to the Deaf and HH end users we support. Every provider already has a notification scheme for message waiting, most of which is much more elaborate and sophisticated than MWI, yet this RFC will force less desirable services... why? This is just an example that has been objected to since day one and yet it still has stuck like glue. Let's not lose focus of the driving force here, the betterment of the endpoint experience for the Deaf and HH user base. 
I think being able to get privacy and be able to use all networks, including the old IPv4 networks, is a good experience.
>  
> 
> I understand this is IETF. I understand this must have the latest and greatest tech the industry has to offer, but I think the driving committee members of this RFC also need to understand the realities of implementation and the hardship this can and will bring to providers with the "MUSTs". The FCC denies funding for non compliance, the reality is these "MUSTs" could put providers out of business.  
A MUST in an RFC points to an implementation. It doesn’t provide a profile for a service. If a service provider only provides IPv4 that’s ok (depending on the customer requirements of course). But to be RFC compliant and interoperable, an implementation has to be able to support what’s specified as MUSTs.
> 
> I know there are heavy hitters in the IETF community on this project. But there are also founding members of the VRS industry who have offered comments with reasonable explanations that have been dismissed. After 18 year I believe we know our customer base. The Deaf employees in our companies in marketing and sales collectively drive our product offerings to best suit their needs because we eat our own dog food.. I would urge this committee to take long and hard consideration of the experience that in my opinion is being dismissed offhandedly for the sake of new tech that has very little to do with our customers needs or wants.
IPv6 is not new tech at this point. SRTP/DTLS is implemented in millions of web browsers out there, with many implementations in Open Source. It’s not new tech, not at all. In fact I would be surprised if the US FCC does not require IPv6.

I have been working with social care alarms as well as telephony for deaf and hearing impaired. The users don’t deserve old technology or a lack of privacy. If you ask them it would be assumed that you work on all kind of networks - mobile, wifi, fixed and they trust you to give them privacy. They won’t specify that in technichal terms, it’s just assumed.

/O
> On Thu, Aug 26, 2021 at 7:16 AM Olle E. Johansson <[email-masked] <mailto:[email-masked]>> wrote:
> Friends,
> > On 25 Aug 2021, at 20:58, Eugene Christensen <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential and proprietary information. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail at [email-masked] <mailto:[email-masked]> or by telephone at +1 (801) 287-9419, and destroy the original transmission and its attachments without reading them or saving them to disk.
> > 
> > From: Rum <[email-masked] <mailto:[email-masked]>> On Behalf Of Paul Kyzivat
> > To: [email-masked] <mailto:[email-masked]>
> > Cc: Alexander Ospina <[email-masked] <mailto:[email-masked]>>; Isaac Roach <[email-masked] <mailto:[email-masked]>>; Brian Rosen <[email-masked] <mailto:[email-masked]>>
> > https://datatracker.ietf.org/doc/minutes-111-rum/ <https://datatracker.ietf.org/doc/minutes-111-rum/>
> > 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>
> > 
> > -- 
> > Rum mailing list
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>
> 
> -- 
> Rum mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>
> -- 
> Rum mailing list
> [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Aug 2021 11:47:42 -0400

I want to split off MWI as different from the other issues you have 
raised. If I understand, your point is that each provider has a 
proprietary way of indicating video mail is waiting and retrieving it, 
so there is no need to do something different. (Please correct me if I 
have gotten this wrong.)

The problem with this is that it means for a RUE to be able to access 
video mail it needs to support the proprietary mechanism of each 
provider it aims to work with. But interoperability of the RUE with 
multiple providers is an explicit goal of this work group. So we need a 
mechanism that the RUE can implement that will work with any provider.

In principle this mechanism need not use the MWI mechanism, but coming 
up with some other, presumably purpose built, mechanism will be a hard sell.

IMO proposals that fail to address this need for interoperability are 
out of scope. (To go there would require a change to the charter.)

So, please frame video mail and MWI issues with interoperability as a 
requirement.

	Thanks,
	Paul (With my RUM WG Chair hat ON)

On 8/25/21 2:58 PM, Eugene Christensen wrote:
> Brian, Paul thank you for considering the changes that haved been brought up to this point.  Leaving things alone with the X-Card, the inclusion of the instance-id for location, additions to support notification services for mobile, etc. are all appreciated.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Aug 2021 12:48:20 -0400

On 8/26/21 10:31 AM, Olle E. Johansson wrote:
> 
> 
>> On 26 Aug 2021, at 16:17, Roger Slusser <[email-masked] 
>> <mailto:[email-masked]>> wrote:

...

>> the new spec for the VATRP. 

...

>> greatest tech the industry has to offer, but I think the driving 
>> committee members of this RFC also need to understand the realities of 
>> implementation and the hardship this can and will bring to providers 
>> with the "MUSTs". The FCC denies funding for non compliance, the 
>> reality is these "MUSTs" could put providers out of business. 
> A MUST in an RFC points to an implementation. It doesn’t provide a 
> profile for a service. If a service provider only provides IPv4 that’s 
> ok (depending on the customer requirements of course). But to be RFC 
> compliant and interoperable, an implementation has to be able to support 
> what’s specified as MUSTs.
>>
>> I know there are heavy hitters in the IETF community on this project. 
>> But there are also founding members of the VRS industry who have 
>> offered comments with reasonable explanations that have been 
>> dismissed. After 18 year I believe we know our customer base. The Deaf 
>> employees in our companies in marketing and sales collectively 
>> drive our product offerings to best suit their needs because we eat 
>> our own dog food.. I would urge this committee to take long and hard 
>> consideration of the experience that in my opinion is being dismissed 
>> offhandedly for the sake of new tech that has very little to do with 
>> our customers needs or wants.
> IPv6 is not new tech at this point. SRTP/DTLS is implemented in millions 
> of web browsers out there, with many implementations in Open Source. 
> It’s not new tech, not at all. In fact I would be surprised if the US 
> FCC does not require IPv6.

ISTM the keys to a path forward are lurking in the above.

Certainly in the US it will be the FCC that decides what it wants to 
require. While it could require full conformance to the RFC that comes 
out of RUM it can also choose to only require a profile. And it can 
adjust the profile it requires over time as a way to ease migration.

I know the FCC prefers refer to specs generated by standards bodies 
rather than creating specs itself. If there is need of a profile it is 
certainly possible that such work could be done in the SIP Forum, 
potentially as an extension to the VRS Provider Profile.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Thu, 26 Aug 2021 13:09:34 -0400

Could we look at this using the easy target: IPv6?

All implementations of just about any internet service is going to have to support IPv6 in the future.  We can argue about how far out it is, but, increasingly, there are IPv6 only networks.  IPv4 will be with us with work arounds for some time, but we have to acknowledge that it’s not optional any more.  Implementation can be delayed, but it can’t be dismissed.  If you are supporting mobile clients, it’s getting much harder over time to support IPv4 only.  There are current work arounds, but it’s getting harder.  

When I was asked to start this effort, and venue was discussed, we understood that whatever venue we did the work would impose some sort effective constraints on what we did.  When we discussed doing it in the IETF, I was the one that pointed out that we would absolutely encounter the sorts of things we are discussing now.  I think I even mentioned IPv6 as emblematic of the consequences of doing the work here.  We have to accept that wherever we tried to create a spec like this, the organizations biases affect the outcome.  We’re not going to be able to get this doc through the IETF without IPv6.

When we discussed chartering this effort, the discussion on WebRTC occurred.  The charter says we should do what we ended up doing.  That was because the people who looked at the work proposed pointed out that we had just finished a rather difficult consensus gathering on what best practice for real time multimedia over the Internet should be, and no one wanted to start another discussion on what best practice was.  We decided, with a WHOLE lot of expert advice and opinions, and the people who drove the charter language wanted to make sure that we used the prior work as best we could.  I think we have done that.  I think you will find that you will want to go the direction we have in this doc.  As an example, everyone else is moving away from video bridges, and using SFUs.  There are substantial advantages to VRS for using SFUs instead of bridges.  Yes, it’s a change, but it’s a change that is good for users.  Our doc doesn’t require either end to support SFUs, but it gives you the basis for doing it.  The same is true of OPUS.  Users who have some hearing ability see large advantages to wideband codecs and OPUS is free, universal, and high quality.

Brian

> On Aug 26, 2021, at 10:17 AM, Roger Slusser <[email-masked]> wrote:
> 
> Hello all,
> It is obvious to me that this RUM RFC will be picked up by the FCC as the new spec for the VATRP. So let's not kid ourselves or mince words about implementations, industry profiles and various services. This endpoint spec will be terminated by a VRS provider Interpreter station or proprietary endpoint in 99% of the use cases. By mandating via "MUSTs" in this RFC, and there are many, it will force the VRS providers to abandon current project plans and business goals to turn attention to implementing things in this RFC that have very little value to the Deaf and HH end users we support. Every provider already has a notification scheme for message waiting, most of which is much more elaborate and sophisticated than MWI, yet this RFC will force less desirable services... why? This is just an example that has been objected to since day one and yet it still has stuck like glue. Let's not lose focus of the driving force here, the betterment of the endpoint experience for the Deaf and HH user base.  
>

---

From: Ed Sayers <[email-masked]>
Date: Thu, 26 Aug 2021 17:15:18 +0000

Hi Paul,

The issue of MWI is far more the just mechanism of notifying the user. Whether that be push, email, SMS or anything else Provider can already support.
In addition, VRS Providers each solved the SIP PUSH problem 10+ years ago - long before the RFC  was created - Following the needs of our customers and because RFCs like RFC8599 didn't exist, or because RFC-3482 was insufficient and there were no other adequate alternatives.

Providers also currently use their own RESTful APIs to stream and/or download Video messages to the client for playback.
This cannot be supported by RFC-3482. Even if it were possible using the RFC-2822 message headers, section 3.5 states "Message headers MUST NOT be included in an initial NOTIFY, as new messages could be essentially unbounded in size". This means that MWI cannot provide streaming URIs for any old or initial new messages, and leaves a historical 'dial-up' mechanism as the only complete option when using this RFC.

Providers would thus need to go and re-implement that "old tech" that was thrown away years ago and provides a much poorer user experience; A call to a Video IVR, to be navigated by DTMF tones. If nothing else, this requires a customer to be online every single time they want to view a message (And potentially incur data charges every time). Whereas any streamed message could be cached and still be viewed when offline.

We completely understand that there is no RFC that can currently support the way we provider video mail notifications and messages. We knew that a long time ago.

However, it needs to be made clear that this is a deficiency of the currently available RFCs, not one that VRS Providers are currently constrained by.
However, the creation of the RUM specification will constrain the way that Providers can provide features such as this, stifle innovation, and in cases such as this certainly be a limiting and retrograde step.

Many thanks,

Ed Sayers
Endpoint SDK Team Lead
Purple, a Division of ZP Better Together, LLC
purplevrs.com

The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.

-----Original Message-----
From: Rum <[email-masked]> On Behalf Of Paul Kyzivat
Sent: 26 August 2021 16:48
To: Eugene Christensen <[email-masked]>; [email-masked]; Brian Rosen <[email-masked]>
Cc: Isaac Roach <[email-masked]>; Alexander Ospina <[email-masked]>
Subject: [Rum] VRS Provider issues - MWI

I want to split off MWI as different from the other issues you have raised. If I understand, your point is that each provider has a proprietary way of indicating video mail is waiting and retrieving it, so there is no need to do something different. (Please correct me if I have gotten this wrong.)

The problem with this is that it means for a RUE to be able to access video mail it needs to support the proprietary mechanism of each provider it aims to work with. But interoperability of the RUE with multiple providers is an explicit goal of this work group. So we need a mechanism that the RUE can implement that will work with any provider.

In principle this mechanism need not use the MWI mechanism, but coming up with some other, presumably purpose built, mechanism will be a hard sell.

IMO proposals that fail to address this need for interoperability are out of scope. (To go there would require a change to the charter.)

So, please frame video mail and MWI issues with interoperability as a requirement.

	Thanks,

On 8/25/21 2:58 PM, Eugene Christensen wrote:
> Cc: Alexander Ospina <[email-masked]>; Isaac Roach 
> <[email-masked]>; Brian Rosen <[email-masked]>
> concerns of the others above if we don't hear from you. Rather than 
> try to summarize those I refer you back to the minutes. You can find them at:

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Aug 2021 13:19:57 -0400

Changing the subject to ease following the discussion.

-------- Forwarded Message --------
Subject: 	Re: [Rum] Action Items from RUM session at IETF 111
Resent-From: 	[email-masked]
Date: 	Thu, 26 Aug 2021 13:09:34 -0400
From: 	Brian Rosen <[email-masked]>
To: 	Roger Slusser <[email-masked]>
CC: 	Olle E. Johansson <[email-masked]>, Eugene Christensen 
<[email-masked]>, [email-masked] <[email-masked]>, Alexander 
Ospina <[email-masked]>, Isaac Roach <[email-masked]>, 
Paul Kyzivat <[email-masked]>

All implementations of just about any internet service is going to have 
to support IPv6 in the future.  We can argue about how far out it is, 
but, increasingly, there are IPv6 only networks.  IPv4 will be with us 
with work arounds for some time, but we have to acknowledge that it’s 
not optional any more.  Implementation can be delayed, but it can’t be 
dismissed.  If you are supporting mobile clients, it’s getting much 
harder over time to support IPv4 only.  There are current work arounds, 
but it’s getting harder.

When I was asked to start this effort, and venue was discussed, we 
understood that whatever venue we did the work would impose some sort 
effective constraints on what we did.  When we discussed doing it in the 
IETF, I was the one that pointed out that we would absolutely encounter 
the sorts of things we are discussing now.  I think I even mentioned 
IPv6 as emblematic of the consequences of doing the work here.  We have 
to accept that wherever we tried to create a spec like this, the 
organizations biases affect the outcome.  We’re not going to be able to 
get this doc through the IETF without IPv6.

When we discussed chartering this effort, the discussion on WebRTC 
occurred.  The charter says we should do what we ended up doing.  That 
was because the people who looked at the work proposed pointed out that 
we had just finished a rather difficult consensus gathering on what best 
practice for real time multimedia over the Internet should be, and no 
one wanted to start another discussion on what best practice was.  We 
decided, with a WHOLE lot of expert advice and opinions, and the people 
who drove the charter language wanted to make sure that we used the 
prior work as best we could.  I think we have done that.  I think you 
will find that you will want to go the direction we have in this doc. 
  As an example, everyone else is moving away from video bridges, and 
using SFUs.  There are substantial advantages to VRS for using SFUs 
instead of bridges.  Yes, it’s a change, but it’s a change that is good 
for users.  Our doc doesn’t require either end to support SFUs, but it 
gives you the basis for doing it.  The same is true of OPUS.  Users who 
have some hearing ability see large advantages to wideband codecs and 
OPUS is free, universal, and high quality.

Brian

> On Aug 26, 2021, at 10:17 AM, Roger Slusser <[email-masked] 
> I have to agree right down the line with Eugene Christensen. I have 
> been a part of this from day one and have been directly involved in 
> the setup and execution of the bi-annual Interop conferences and 
> development of the Provider Interoperability Profile.
>
> It is obvious to me that this RUM RFC will be picked up by the FCC as 
> the new spec for the VATRP. So let's not kid ourselves or mince words 
> about implementations, industry profiles and various services. This 
> endpoint spec will be terminated by a VRS provider Interpreter station 
> or proprietary endpoint in 99% of the use cases. By mandating via 
> "MUSTs" in this RFC, and there are many, it will force the VRS 
> providers to abandon current project plans and business goals to turn 
> attention to implementing things in this RFC that have very little 
> value to the Deaf and HH end users we support. Every provider already 
> has a notification scheme for message waiting, most of which is much 
> more elaborate and sophisticated than MWI, yet this RFC will 
> force less desirable services... why? This is just an example that has 
> been objected to since day one and yet it still has stuck like glue. 
> Let's not lose focus of the driving force here, the betterment of the 
> endpoint experience for the Deaf and HH user base.
>
>     We can’t let any documents be published without IPv6. The problems
>     you outline here are surely solved in existing implementations of
>     SIP, propably since many years ago. If not, we have work to do.
>
>     In addition, RUM services without SRTP/DTLS will be used over any
>     network, including the Internet, and it is a very bad solution
>     that feels like something we sold in the SIP world a long time
>     ago. The world has moved since then.
>
>     I would personally go as far as to say that SRTP/DTLS is a MUST
>     and nothing else is ok, very much like WebRTC.
>
>     In regards to proprietary vs open standards, this is again the
>     IETF. We produce open standards and a RUM specification has to
>     point to a SIP SUBSCRIBE/NOTIFY package for MWI.
>
>     Remember that what I’m talking about is documents as specified by
>     the IETF. Industry profiles and various services may go other
>     ways, but the IETF standards has to be up to date with best
>     current practise.
>
>     Cheers,
>     /O
>
>     > On 25 Aug 2021, at 20:58, Eugene Christensen
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     > Brian, Paul thank you for considering the changes that have been
>     brought up to this point.  Leaving things alone with the X-Card,
>     the inclusion of the instance-id for location, additions to
>     support notification services for mobile, etc. are all appreciated.
>     >
>     following in the new RUM document.  Here are the reasons that I
>     believe this way.
>     >
>     > WebRTC
>     >
>     > * While there is an RFC for WebRTC, it doesn't appear that all
>     browsers are following it.  For example, TMMBR is required for
>     WebRTC but Chrome does not signal it.
>     > * WebRTC is an audio first implementation.  For VRS, video is
>     the most important media stream.  It means everything to the deaf
>     or hard of hearing user.  If video is suffering first in a lossy
>     network, that is a problem for VRS.
>     > * Some of the VRS providers do not currently support the
>     following items.  This could pose a significant impact on the VRS
>     providers to get this implemented.
>     > o Encryption (DTLS)
>     > o ICE
>     > o RTP/RTCP Muxing
>     >
>     > IPv6
>     > * For those VRS providers whose current implementations do not
>     support IPv6, this can be a big jump to get their solution to
>     support both IPv4 as well as IPv6.  Granted, it does not require
>     being dual stacked but rather could be two separate servers, each
>     supporting their respective version of IP.  This could be a big
>     undertaking just to get IPv6 into the mix.
>     > * Another solution could be an IPv4 to IPv6 gateway but that
>     doesn't work flawlessly.  For example, the gateway can forward the
>     IPv6 SIP message to the proper address on the IPv4 network,
>     however, how does it resolve the embedded IPv6 addresses signaled
>     in the SDP?  So, for example, consider two RUEs, one legacy RUE
>     that is using IPv4 and one that is IPv6; the signaling is possible
>     for both once the servers for each support that or provide a IP
>     gateway between the two.  How is the media going to work?  Each of
>     the RUEs is going to provide an IP address in their SDP, one will
>     be IPv4 and the other IPv6.  How is this going to work without
>     having to anchor all the media somewhere?
>     > * As I understand it, some mobile devices are already IPv6 but
>     do not follow the RFC for embedding an IPv4 address into an IPv6
>     address.  This is going to require special handling to get this to
>     work with such devices on vendors that do not follow the RFC in
>     this regard.
>     >
>     providers, already include means to record video messages and are
>     not all created the same way.  Proprietary methods have been
>     used.  The document states that MWI is optional but if the ability
>     to leave a message is provided then MWI is to be implemented. 
>     Since there are proprietary solutions, it seems appropriate to me
>     that this should be changed so that proprietary solutions and
>     indications can continue to be utilized.
>     >
>     >
>     > I don't believe I have enumerated all the reasons for not
>     including requirements for the above but I believe the examples
>     given are sufficient to consider.
>     >
>     > Regards,
>     > Eugene Christensen
>     >
>     > CONFIDENTIALITY NOTICE. This e-mail transmission, and any
>     documents, files or previous e-mail messages attached to it, may
>     contain confidential and proprietary information. If you are not
>     the intended recipient, or a person responsible for delivering it
>     to the intended recipient, you are hereby notified that any
>     disclosure, copying, distribution or use of any of the information
>     contained in or attached to this message is STRICTLY PROHIBITED.
>     If you have received this transmission in error, please
>     immediately notify me by reply e-mail at [email-masked]
>     <mailto:[email-masked]> or by telephone at +1 (801)
>     287-9419, and destroy the original transmission and its
>     attachments without reading them or saving them to disk.
>     >
>     > Cc: Alexander Ospina <[email-masked]
>     <mailto:[email-masked]>>; Isaac Roach
>     <[email-masked] <mailto:[email-masked]>>; Brian Rosen
>     <[email-masked] <mailto:[email-masked]>>
>     <https://datatracker.ietf.org/doc/minutes-111-rum/>
>     >
>     <https://www.ietf.org/mailman/listinfo/rum>
>     >
>     > --
>     > Rum mailing list
>     <https://www.ietf.org/mailman/listinfo/rum>
>
>     -- 
>     Rum mailing list
>     <https://www.ietf.org/mailman/listinfo/rum>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Aug 2021 13:31:53 -0400

Ed,

One takeaway from your comments below is that the current spec doesn't 
say much about *retrieval* of video mail.

Is there something we can specify that the RUE could use with all 
providers to retrieve video mail? E.g., could that simply be a https URL 
that will bring up a web page that the user will use to choose, play, 
and delete video mail?

Once we find a standard way to retrieve video mail then we can revisit 
how to deliver a notification.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Thu, 26 Aug 2021 13:33:23 -0400

I think this is not correct in most respects.

This is a standard that allows a client conforming to the standard to connect to a provider conforming to the standard (and, for a point to point call, another client conforming to the standard.  Anything that is proprietary would not be acceptable, regardless of how it works.  It has to be standardized, or a client couldn’t be created that worked with any conforming provider.  

The doc only requires MWI, which is the notification of messages waiting.  It does not assume any specific mechanism to retrieve messages.  Only the notification to the user that there are messages waiting to be retrieved.  So discussion of how messages are streamed is out of scope.

The fact that each provider solved SIP PUSH is irrelevant: they each solved it in a different way.  Their proprietary clients can use that, but a generic client couldn’t.  

RFC3842 predates any SIP client created by VRS providers by many years.  They chose not to use the standards mechanism  that existed years before their implementation in favor of proprietary systems.  There is no deficiency of RFCs.  You can imagine improvements on what 3842 does.  For example, you could want the number of outstanding messages.  But the fundamental, everyone needs it, indication that there is at least one message available is universal, and needs a solution specified one way or another in our document.  I’m not aware of any other standard for MWI.  No one proposed an alternative to 3842, you have only requested that this be proprietary, which is contrary to the basic goals of the spec.

Brian

> On Aug 26, 2021, at 1:15 PM, Ed Sayers <[email-masked]> wrote:
> 
> Hi Paul,
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Aug 2021 14:59:47 -0400

> The doc only requires MWI, which is the notification of messages waiting.  It does not assume any specific mechanism to retrieve messages.  Only the notification to the user that there are messages…

I don't think that makes sense. An interoperable RUE is a failure if the 
user still needs a proprietary mechanism to retrieve the video mail.

The traditional SIP mechanism for voicemail is that the user establishes 
a sip dialog through which the user receives saved up voice mail. As Ed 
notes, it is archaic in that it typically doesn't provide a way to pick 
and choose what you want to hear. (Potentially it can, via some 
interaction over a media stream established by the call as long as the 
device doesn't have to do anything special.)

I was thinking that there was an extension to RFC3842 that included an 
enumeration of individual messages with a URL to access each. But I 
haven't been able to find such so I may have been imagining it.

I think we could allow configuration of either a SIP or an HTTPS URL for 
use in retrieving video mail. The HTTPS would provide a way to offer a 
provider-specific GUI for managing the video mail that can be accessed 
by a RUE that has no proprietary parts.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Thu, 26 Aug 2021 15:01:16 -0400

I’m certainly willing to add a URL for retrieval to the config data.

Brian

> On Aug 26, 2021, at 2:59 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> I don't think that makes sense. An interoperable RUE is a failure if the user still needs a proprietary mechanism to retrieve the video mail.
> 
> The traditional SIP mechanism for voicemail is that the user establishes a sip dialog through which the user receives saved up voice mail. As Ed notes, it is archaic in that it typically doesn't provide a way to pick and choose what you want to hear. (Potentially it can, via some interaction over a media stream established by the call as long as the device doesn't have to do anything special.)
> 
> I was thinking that there was an extension to RFC3842 that included an enumeration of individual messages with a URL to access each. But I haven't been able to find such so I may have been imagining it.
> 
> I think we could allow configuration of either a SIP or an HTTPS URL for use in retrieving video mail. The HTTPS would provide a way to offer a provider-specific GUI for managing the video mail that can be accessed by a RUE that has no proprietary parts.
> 
> 	Thanks,
> 	Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Aug 2021 15:11:52 -0400

Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Aug 2021 15:16:36 -0400

> I’m certainly willing to add a URL for retrieval to the config data.

There probably should be a section on retrieval/management of video mail 
- basically what the RUE is supposed to do with the URL. We need to see 
that the user will be able to fully manage video mail from the RUE 
without any proprietary implementation.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Thu, 26 Aug 2021 15:18:44 -0400

Absolutely willing to do that.

It wouldn’t be much text.  

Brian

> On Aug 26, 2021, at 3:16 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> There probably should be a section on retrieval/management of video mail - basically what the RUE is supposed to do with the URL. We need to see that the user will be able to fully manage video mail from the RUE without any proprietary implementation.
> 
> 	Thanks,
> 	Paul
> 
>> Brian

---

From: Roger Slusser <[email-masked]>
Date: Thu, 26 Aug 2021 15:30:13 -0400

On Thu, Aug 26, 2021 at 10:31 AM Olle E. Johansson <[email-masked]> wrote:

> new spec for the VATRP.
> With all respect. There is a world outside the USA. RFCs are written with
> global scope, not limited to a specific market or group of vendors.
>
Olle,
I think you may have missed my point about this targeting a specific
industry, namely the VRS industry in the US. Also when the FCC mandates
support of an RFC they do not specify custom profiles especially in this
case. There may be other uses for this out there but none that are directly
or possibly adversely affected.

>
> So let's not kid ourselves or mince words about implementations, industry
> profiles and various services. This endpoint spec will be terminated by a
> VRS provider Interpreter station or proprietary endpoint in 99% of the use
> cases. By mandating via "MUSTs" in this RFC, and there are many, it will
> force the VRS providers to abandon current project plans and business goals
> to turn attention to implementing things in this RFC that have very little
> value to the Deaf and HH end users we support. Every provider already has a
> notification scheme for message waiting, most of which is much more
> elaborate and sophisticated than MWI, yet this RFC will force less
> desirable services... why? This is just an example that has been objected
> to since day one and yet it still has stuck like glue. Let's not lose focus
> of the driving force here, the betterment of the endpoint experience for
> the Deaf and HH user base.
>
> I think being able to get privacy and be able to use all networks,
> including the old IPv4 networks, is a good experience.
>

Most providers already support encryption and IPV6 on a limited scope, not
necessarily the way it is defined in RUM spec. Mandating compliance using
MUST requires providers to discard sometimes huge amounts of development to
change over to what RUM is specifying. The push back is not about doing
these things it is about the loss of time, effort and money to do them in
the way RUM mandates with MUSTs.

> A MUST in an RFC points to an implementation. It doesn’t provide a profile
> for a service. If a service provider only provides IPv4 that’s ok
> (depending on the customer requirements of course). But to be RFC compliant
> and interoperable, an implementation has to be able to support what’s
> specified as MUSTs.
>
>
> of web browsers out there, with many implementations in Open Source. It’s
> not new tech, not at all. In fact I would be surprised if the US FCC does
> not require IPv6.
>

> I have been working with social care alarms as well as telephony for deaf
> and hearing impaired. The users don’t deserve old technology or a lack of
> privacy. If you ask them it would be assumed that you work on all kind of
> networks - mobile, wifi, fixed and they trust you to give them privacy.
> They won’t specify that in technichal terms, it’s just assumed.
>
> /O
>

I already addressed this earlier. It is not that we don't provide
encryption, we have settled on other methods. We have been supporting IPv6
for some time now on a limited basis.

>> network, including the Internet, and it is a very bad solution that feels
>> like something we sold in the SIP world a long time ago. The world has
>> moved since then.
>>
>> brought up to this point.  Leaving things alone with the X-Card, the
>> inclusion of the instance-id for location, additions to support
>> notification services for mobile, etc. are all appreciated.
>> >

---

From: Brian Rosen <[email-masked]>
Date: Thu, 26 Aug 2021 15:40:16 -0400

Roger

The WHOLE IDEA of rum is a provider independent client.

If we can’t build a client that works across any conforming provider, then the whole project is a failure.

That means that any proprietary way of doing something isn’t acceptable.  The spec has to specify a way to build a client that every server supports.  

Any standard that arrives when some pre-standard implementations exist faces this problem.  Of course it means changes to those implementations.  We choose to standardize for good reasons, but there are costs to existing implementations.  We shouldn’t make choices that just make busy work for existing implementations.  If it was the case that all existing implementations did it one way, and the spec requires another way, we have to have a good technical argument on why we made a different choice.  But when there is no common choice and every implementation is different from every other one, then we can’t do that. 

Also, there are several participants on this list that are anticipating uses beyond USA VRS.  We’ll agree that is the impetus to start the work, but the goal is a global standard.  

Brian

> On Aug 26, 2021, at 3:30 PM, Roger Slusser <[email-masked]> wrote:
> 
> 
> 
> On Thu, Aug 26, 2021 at 10:31 AM Olle E. Johansson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On 26 Aug 2021, at 16:17, Roger Slusser <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hello all,
> I think you may have missed my point about this targeting a specific industry, namely the VRS industry in the US. Also when the FCC mandates support of an RFC they do not specify custom profiles especially in this case. There may be other uses for this out there but none that are directly or possibly adversely affected.
> 
> Most providers already support encryption and IPV6 on a limited scope, not necessarily the way it is defined in RUM spec. Mandating compliance using MUST requires providers to discard sometimes huge amounts of development to change over to what RUM is specifying. The push back is not about doing these things it is about the loss of time, effort and money to do them in the way RUM mandates with MUSTs.   
>>  
>> 
> I already addressed this earlier. It is not that we don't provide encryption, we have settled on other methods. We have been supporting IPv6 for some time now on a limited basis.  
>>

---

From: Joe Gruessing <[email-masked]>
Date: Thu, 26 Aug 2021 21:20:20 +0000

For what it’s worth, the NTL routinely interacts with the community (including academia) to get feedback and we bring students from the community in to perform testing with us on a regular basis. For this particular issue, the feedback from users of the existing VRS ecosystem is consistent and repeated: there is a lack of message notification, or of consistent notification from within the client app. Implementation varies from Provider to Provider and from client to client currently.

The existing language and the proposal to add a provider-based retrieval URL for a RUE makes a lot of sense!

----------
Joe Gruessing
Infrastructure Engineering, Principal
Group Leader, L114

Office: (703) 983-2075
Mobile: (703) 347-2402

 [LinkedIn] <https://www.linkedin.com/company/mitre>  [Twitter] <https://twitter.com/MITREcorp>  [YouTube] <https://www.youtube.com/user/mitrecorp>  [Facebook] <https://www.facebook.com/MITREcorp>  [Instagram] <https://www.instagram.com/mitre.corp/?hl=en>

[MITRE | Solving Problems for a Safer World]

From: Brian Rosen <[email-masked]>
Sent: Thursday, August 26, 2021 3:19 PM
To: Kyzivat, Paul <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rum] VRS Provider issues - MWI

Brian

On Aug 26, 2021, at 3:16 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

               Thanks,
               Paul

Brian

On Aug 26, 2021, at 2:59 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

  Thanks,
       Paul

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Aug 2021 17:40:01 -0400

Roger,

On 8/26/21 3:30 PM, Roger Slusser wrote:

> Most providers already support encryption and IPV6 on a limited scope, 
> not necessarily the way it is defined in RUM spec. Mandating compliance 
> using MUST requires providers to discard sometimes huge amounts of 
> development to change over to what RUM is specifying. The push back is 
> not about doing these things it is about the loss of time, effort and 
> money to do them in the way RUM mandates with MUSTs.

Do you think there is something else we could write in this spec that 
covers encryption and IPv6 in a way that is less burdensome for 
providers while remaining interoperable with all providers?

If so, can you please spell it out?

	Thanks,
	Paul

---

From: Joe Gruessing <[email-masked]>
Date: Thu, 26 Aug 2021 21:43:15 +0000

Isn’t it correct that the motivation of this document ( i.e.  to create with best practice the “right” type of client guidelines through consensus and current art) is distinct from what the FCC decides to do with the written product (whole or in part) and how it relates to existing industry tech? Shouldn’t the question at this point be focused on whether this document properly captures the IETF global  interpretation of how a RUE ought to be implemented today and not whether the government agency will enforce mandates and how?  Those are related but separate initiatives in my opinion.

----------
Joe Gruessing

Office: (703) 983-2075
Mobile: (703) 347-2402

From: Roger Slusser <[email-masked]>
Sent: Thursday, August 26, 2021 3:30 PM
To: Olle E. Johansson <[email-masked]>
Cc: Christensen, Eugene <[email-masked]>; [email-masked]; Kyzivat, Paul <[email-masked]>; Alexander Ospina <[email-masked]>; Roach, Isaac <[email-masked]>; Brian Rosen <[email-masked]>
Subject: Re: [Rum] Action Items from RUM session at IETF 111

On Thu, Aug 26, 2021 at 10:31 AM Olle E. Johansson <[email-masked]<mailto:[email-masked]>> wrote:

On 26 Aug 2021, at 16:17, Roger Slusser <[email-masked]<mailto:[email-masked]>> wrote:

Hello all,

/O

On Thu, Aug 26, 2021 at 7:16 AM Olle E. Johansson <[email-masked]<mailto:[email-masked]>> wrote:
Friends,
This is the IETF after all.

Cheers,
/O

> On 25 Aug 2021, at 20:58, Eugene Christensen <[email-masked]<mailto:[email-masked]>> wrote:
>
> CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential and proprietary information. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail at [email-masked]<mailto:[email-masked]> or by telephone at +1 (801) 287-9419, and destroy the original transmission and its attachments without reading them or saving them to disk.
>
> From: Rum <[email-masked]<mailto:[email-masked]>> On Behalf Of Paul Kyzivat
> To: [email-masked]<mailto:[email-masked]>
> Cc: Alexander Ospina <[email-masked]<mailto:[email-masked]>>; Isaac Roach <[email-masked]<mailto:[email-masked]>>; Brian Rosen <[email-masked]<mailto:[email-masked]>>

---

From: Joe Gruessing <[email-masked]>
Date: Thu, 26 Aug 2021 21:59:38 +0000

The providers have already agreed that encryption is important... that's why it's described for the server-server leg in the Providers Profile last year. That protects the server infrastructure. Great.

The RUE closes the gap so that client-server and ultimately end-to-end privacy is established. The entire world expects this now. What is so unreasonable about this requirement? Reword it if it needs to be.  If I had to pick just one requirement as mandatory, this would be it without a doubt!

Joe

----------
Joe Gruessing

Office: (703) 983-2075
Mobile: (703) 347-2402

-----Original Message-----
From: Paul Kyzivat <[email-masked]> 
Sent: Thursday, August 26, 2021 5:40 PM
To: Roger Slusser <[email-masked]>
Cc: [email-masked]
Subject: [Rum] IPv6 and encryption

Roger,

On 8/26/21 3:30 PM, Roger Slusser wrote:

> not necessarily the way it is defined in RUM spec. Mandating 
> compliance using MUST requires providers to discard sometimes huge 
> amounts of development to change over to what RUM is specifying. The 
> push back is not about doing these things it is about the loss of 
> time, effort and money to do them in the way RUM mandates with MUSTs.

Do you think there is something else we could write in this spec that covers encryption and IPv6 in a way that is less burdensome for providers while remaining interoperable with all providers?

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 27 Aug 2021 08:01:43 +0200

> 26 aug. 2021 kl. 19:31 skrev Paul Kyzivat <[email-masked]>:
> 
> Ed,
> 
> One takeaway from your comments below is that the current spec doesn't say much about *retrieval* of video mail.
> 
> Is there something we can specify that the RUE could use with all providers to retrieve video mail? E.g., could that simply be a https URL that will bring up a web page that the user will use to choose, play, and delete video mail?
Defining an extended subscribe/notify implementation with a list of URI’s in addition to voicemail status seems fairly simple. You could even ad an optional URI for a thumbnail of the video to help the UI a bit. As well as the caller ID. All provided we have a secure connection.

/O
> 
> Once we find a standard way to retrieve video mail then we can revisit how to deliver a notification.
> 
> 	Thanks,
> 	Paul
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 27 Aug 2021 08:09:30 +0200

> 26 aug. 2021 kl. 23:59 skrev Joe Gruessing <[email-masked]>:
> 
> 
> The RUE closes the gap so that client-server and ultimately end-to-end privacy is established.th
There is no standard in SIP for end-to-end privacy. It’s hop-by-hop. It’s a gaping hole that we have to solve. This means that any SIP messaging and possibly also audio will be in the clear on the provider’s server.

Yes, there’s S/MIME in RFC 3261 but during all my years with SIP I so far haven’t seen any interoperable implementations.

> The entire world expects this now. What is so unreasonable about this requirement? Reword it if it needs to be.  If I had to pick just one requirement as mandatory, this would be it without a doubt!
Even without full end-to-end, protecting the first hop is important and a big step forward.

/O

---

From: Ed Sayers <[email-masked]>
Date: Fri, 27 Aug 2021 09:37:40 +0000

Hi Brian,

To clarify some of your points below..

We were using SIP for VRS as long as 15 years ago - just not in-between US VRS Providers (It was still ITU-T H.323, as was mandated by the FCC at the time).

We did also implement and support the MWI RFC in around 2006. But, in the following years as Smartphones, Tablets, laptops and Wireless communication moved on and so did Videomail notification and retrieval.

To answer Paul's question at this point; Providers have Account Portals where users can manage their accounts, call history, contacts and view their messages.

I had thought I was clear, we are not proposing the inclusion of anything proprietary into this RFC. (Although if such a mechanism were defined in an RFC, surely it stops being proprietary?).

As I already highlighted RFC-3842 does provide a mechanism for additional headers to be included in the NOTIFY body that are specific to each message, in section 3.5. Examples being 'From', 'To' headers.
However, the limitations on use that I quoted means that the notifications cannot solely be used to list messages with thumbnails and streaming URLs and results in the inferior dial-up experience that we have all left behind.

Whilst it might be possible to include an update to the MWI RFC, I'd argue that the existing mechanisms already provided are sufficient. (E.g. email with attached message or SMS).
For a Provider that can supply these alternative standard mechanisms, it seems that MWI should be optional for the provider.

Cheers,

Ed Sayers
Endpoint SDK Team Lead

-----Original Message-----
From: Brian Rosen <[email-masked]> 
Sent: 26 August 2021 18:33
To: Ed Sayers <[email-masked]>
Cc: Paul Kyzivat <[email-masked]>; Eugene Christensen <[email-masked]>; [email-masked]; Isaac Roach <[email-masked]>; Alexander Ospina <[email-masked]>
Subject: Re: [Rum] VRS Provider issues - MWI

Brian

> Purple, a Division of ZP Better Together, LLC purplevrs.com
> 
>> I plan to issue WGLC on the document soon. I will wait one week 
>> (until Aug 26). If there hasn't been any followup by then I will ask 
>> Brian to issue a version that we can advance to WGLC.
>> 
>> 	Thanks,
>> 	Paul
>> 
> 
> --
> Rum mailing list
> [email-masked]

---

From: Ed Sayers <[email-masked]>
Date: Fri, 27 Aug 2021 10:52:28 +0000

Hi Joe,

The proposal to use SIP PUSH and WMI defines standards that echo the proprietary mechanisms that US Providers are already using.

What this specification _does_not_ do is somehow make message notifications more consistent or timely in and of itself, because it is using equivalent technologies.
We would also tend not to agree that notification problems are endemic. That is not the feedback we get from our Deaf employees, community, analytics or the regular testing we perform above and beyond the regular US VRS InterOp conferences.
The quality, reliability and inter-operability of our services is something we have all always very seriously.

Cheers,

Ed Sayers
Endpoint SDK Team Lead
Purple, a Division of ZP Better Together, LLC
purplevrs.com<https://purplevrs.com/>

[Purple is DEI certified!]
The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.

From: Rum <[email-masked]> On Behalf Of Joe Gruessing
Sent: 26 August 2021 22:20
To: Brian Rosen <[email-masked]>; Kyzivat, Paul <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rum] VRS Provider issues - MWI

----------
Joe Gruessing

Office: (703) 983-2075
Mobile: (703) 347-2402

From: Brian Rosen <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, August 26, 2021 3:19 PM
To: Kyzivat, Paul <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Rum] VRS Provider issues - MWI

Brian

               Thanks,
               Paul

Brian

  Thanks,
       Paul

---

From: Roger Slusser <[email-masked]>
Date: Fri, 27 Aug 2021 09:39:35 -0400

Joe,
In a pure and perfect world yes this would be the case, we have been at
this long enough to know this is not the reality of how this will play out.
I have read ahead, I see that Ed Sayers addressed this much better than I
could.
Roger

On Thu, Aug 26, 2021 at 5:48 PM Joe Gruessing <[email-masked]> wrote:

>
>
> Isn’t it correct that the motivation of this document ( i.e.  to create
> with best practice the “right” type of client guidelines through consensus
> and current art) is distinct from what the FCC decides to do with the
> written product (whole or in part) and how it relates to existing industry
> tech? Shouldn’t the question at this point be focused on whether this
> document properly captures the IETF global  interpretation of how a RUE
> ought to be implemented today and not whether the government agency will
> enforce mandates and how?  Those are related but separate initiatives in my
> opinion.
>
>
>
> *----------*
>
> *Joe Gruessing*
>
>   <https://www.linkedin.com/company/mitre> [image:
> Twitter] <https://twitter.com/MITREcorp> 
> <https://www.youtube.com/user/mitrecorp> 
> <https://www.facebook.com/MITREcorp> 
> <https://www.instagram.com/mitre.corp/?hl=en>
>
>
>
>
>
> *From:* Roger Slusser <[email-masked]>
> *Sent:* Thursday, August 26, 2021 3:30 PM
> *To:* Olle E. Johansson <[email-masked]>
> *Cc:* Christensen, Eugene <[email-masked]>; [email-masked];
> Kyzivat, Paul <[email-masked]>; Alexander Ospina <
> [email-masked]>; Roach, Isaac <[email-masked]>; Brian Rosen
> <[email-masked]>
> *Subject:* Re: [Rum] Action Items from RUM session at IETF 111
>
>
>
>
>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Aug 2021 16:15:49 -0400

Providers,

My request below to Roger should have been broader. You all seem to have 
the same issue. I encourage any/all of you to make an alternative 
proposal here. Just saying "we don't like what is there" isn't helpful 
without an alternative.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Aug 2021 17:06:50 -0400

Chad,

Welcome to the RUM WG!

On 8/30/21 11:51 AM, Chad Leeper wrote:
> - While WebRTC w/ SRTP/DTLS (encryption) is an excellent idea going 
> forward, it can't be a "MUST" requirement.  I agree with Roger Slusser 
> that mandating compliance using MUST requires providers to implement 
> significant development to change over to what RUM is specifying.

The requirements in this doc will apply only to devices that claim to 
conform to it. Presumably you could continue to support your existing 
devices using whatever mechanisms they currently use. So the 
implementation burden is only on the server side, not the legacy device 
side. (Of course the FCC will have a say in this.)

One motivation for the webrtc requirement is so that a RUE can be built 
on top of WebRTC. E.g., it can be a server that supports deaf users 
using any device with a browser. Such a server is effectively just 
signaling gateway that can establish a p2p link between the browser and 
the VRS provider server. (It does have to transcode RTT, but that is 
less of a burden.)

When defining a specification for an interface that is to be implemented 
by independent parties it is necessary for essential functions to have 
at least one mandatory to implement mechanism. Currently there are no 
standards for connecting a RUE to a provider, so we need to pick 
*something* to be mandatory to implement. If you have an alternative for 
the media you would prefer, then please make a specific proposal.

> - We should keep any new privacy requirements very minimal at this 
> time.  While companies in the EU have already created their systems in 
> compliance with the GDPR, most of the world hasn't created an equivalent 
> yet.  So what may look like an easy change to EU implementers may be a 
> dramatic change for others.

I don't think we have said much about privacy of retained data. But we 
are concerned that the media and signaling be private between the RUE 
and the provider. That is a low bar these days. It is unlikely that 
anything less could be approved. I expect the FCC will agree.

If you have an alternate proposal that achieves that then make a 
proposal we can discuss.

	Thanks,
	Paul

> On Fri, Aug 27, 2021 at 3:16 PM Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Providers,
>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 30 Aug 2021 17:24:11 -0400

I don’t think there are ANY alternatives to SRTP.  There are alternatives to DTLS-SRTP.  There are moves within the IETF to deprecate SDES, specifically.  There is push back on that, but it’s an ongoing discussion because SDES isn’t secure enough.   Since all providers I know about anchor media, this only affects the initial hop.  Users really want to hear that their media is protected end to end (at least hop by hop) but our document doesn’t require that.  Again, we need a STANDARDS based solution, and we have to live within the constraints the IETF has for new standards with respect to security.  Like nearly every organization, the IETF is much more security conscious than it was, and won’t tolerate bad security although it often recognizes the necessity for backwards compatibility as long as it’s not to a known insecure mechanism.  

I really think this is a “step up to the bar” thing.  We’ve spent lots of time and cycles implementing things that turn out not to be secure enough, and we have to move forward on things that are.  DTLS-SRTP is one of those things, as is IPv6.

Brian

> On Aug 30, 2021, at 5:06 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> Chad,
> 
> Welcome to the RUM WG!
> 
>> - While WebRTC w/ SRTP/DTLS (encryption) is an excellent idea going forward, it can't be a "MUST" requirement.  I agree with Roger Slusser that mandating compliance using MUST requires providers to implement significant development to change over to what RUM is specifying.
> 
> The requirements in this doc will apply only to devices that claim to conform to it. Presumably you could continue to support your existing devices using whatever mechanisms they currently use. So the implementation burden is only on the server side, not the legacy device side. (Of course the FCC will have a say in this.)
> 
> One motivation for the webrtc requirement is so that a RUE can be built on top of WebRTC. E.g., it can be a server that supports deaf users using any device with a browser. Such a server is effectively just signaling gateway that can establish a p2p link between the browser and the VRS provider server. (It does have to transcode RTT, but that is less of a burden.)
> 
> When defining a specification for an interface that is to be implemented by independent parties it is necessary for essential functions to have at least one mandatory to implement mechanism. Currently there are no standards for connecting a RUE to a provider, so we need to pick *something* to be mandatory to implement. If you have an alternative for the media you would prefer, then please make a specific proposal.
> 
>> - We should keep any new privacy requirements very minimal at this time.  While companies in the EU have already created their systems in compliance with the GDPR, most of the world hasn't created an equivalent yet.  So what may look like an easy change to EU implementers may be a dramatic change for others.
> 
> I don't think we have said much about privacy of retained data. But we are concerned that the media and signaling be private between the RUE and the provider. That is a low bar these days. It is unlikely that anything less could be approved. I expect the FCC will agree.
> 
> If you have an alternate proposal that achieves that then make a proposal we can discuss.
> 
> 	Thanks,
> 	Paul
> 
>> On Fri, Aug 27, 2021 at 3:16 PM Paul Kyzivat <[email-masked] <mailto:[email-masked]>> wrote:
>>    Providers,
>>    --     Rum mailing list