Subject: [Rum] Release announcement: WebRTC VATRP v1.0

From: Matthew H Garber <[email-masked]>
Date: Thu, 26 Aug 2021 12:38:40 +0000

Good morning all,

Note: This is a second notice of the WebRTC VATRP v1.0 release and is intended for a broader audience than the previous email

MITRE has released the 1.0 version of a WebRTC based RUE client to the public ACE Github, located at https://github.com/mitrefccace/fcc-vatrp-webrtc . This client has a communications driver for using the Janus Media Server from Meetecho as a gateway to convert WebRTC-based messages to RTP/SRTP. It will also communicate with a SIP server configured to receive WebRTC messages directly.

The release notes for this application are at https://github.com/mitrefccace/fcc-vatrp-webrtc/blob/main/docs/FCC_TRS_WebRTC_VATRPv1-0_PR_21-1891.docx . There are known defects that prevent full RUE compliance outlined in the release notes, but MITRE is planning follow-on releases to address these and any other discrepancies with future revisions to the working draft. Our intent is to deliver an open source client that is 100% compliant with the final RUM-RUE language.

A release build is available for Windows and Mac at https://github.com/mitrefccace/fcc-vatrp-webrtc/releases/tag/v1.0.

We are actively looking for partners for testing interoperability with this client – if you have an implementation you’d like to try out, please don’t hesitate to reach out to me and we’ll work out a timeframe.

Thanks,

Matt Garber
Group Lead/Lead Software Engineer
L178 Collaboration and Social Computing
571-326-7167
MITRE | Solving Problems for a Safer World™

---

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

Matt,

Welcome to the RUM WG! (I don't recall seeing you post here before.)

On 8/26/21 8:38 AM, Matthew H Garber wrote:
> Good morning all,
> 
> Note: This is a second notice of the WebRTC VATRP v1.0 release and is 
> intended for a broader audience than the previous email

Thank you for publicizing this. "Running Code" is huge in building 
support for publishing an RFC. Also, implementina a spec almost always 
ferrets out issues.

> MITRE has released the 1.0 version of a WebRTC based RUE client to the 
> public ACE Github, located 
> athttps://github.com/mitrefccace/fcc-vatrp-webrtc 
> <https://github.com/mitrefccace/fcc-vatrp-webrtc>. This client has a 
> communications driver for using the Janus Media Server from Meetecho as 
> a gateway to convert WebRTC-based messages to RTP/SRTP. It will also 
> communicate with a SIP server configured to receive WebRTC messages 
> directly.
> 
> The release notes for this application are 
> athttps://github.com/mitrefccace/fcc-vatrp-webrtc/blob/main/docs/FCC_TRS_WebRTC_VATRPv1-0_PR_21-1891.docx 
> <https://github.com/mitrefccace/fcc-vatrp-webrtc/blob/main/docs/FCC_TRS_WebRTC_VATRPv1-0_PR_21-1891.docx>. 
> There are known defects that prevent full RUE compliance outlined in the 
> release notes,butMITRE isplanningfollow-on releases to address these and 
> any other discrepancies with future revisions to the working draft. Our 
> intent is to deliver an open source client that is 100% compliant with 
> the final RUM-RUE language.

While building this implementation have you come across any places where 
you think changes to the spec would be advantageous?

I see that the RTT presents difficulties. Do you have any thoughts on 
how to ease that?

> A release build is available 
> forWindowsandMacathttps://github.com/mitrefccace/fcc-vatrp-webrtc/releases/tag/v1.0 
> <https://github.com/mitrefccace/fcc-vatrp-webrtc/releases/tag/v1.0>.
> 
> We are actively looking for partners for testing interoperability with 
> this client – if you have an implementation you’d like to try out, 
> please don’t hesitate to reach out to me and we’ll work out a timeframe.

I'm guessing that you can't yet interoperate with the existing US VRS 
providers production networks. Have you built your own provider server 
that accepts calls from your RUE? Can it connect to and interoperate 
with real providers?

	Thanks,
	Paul

---

From: Matthew H Garber <[email-masked]>
Date: Thu, 26 Aug 2021 20:04:10 +0000

>you think changes to the spec would be advantageous?

MITRE is committed to supporting the spec however it comes out, so we’ll work to the final language, wherever it ends up.

As an individual who is primarily a web developer/data engineer, I think allowing direct WebRTC connections would be very forward looking w.r.t. extant library support and the kind of software engineering talent available to hire in the future, but I understand this group has reasons for not wanting to do that at this time.

>I see that the RTT presents difficulties. Do you have any thoughts on

This is due to our technology choice – web applications generally don’t know how to, nor need to, speak T.140; most folks would pick up a library like socket.io to handle this unless they had a specific use case not to. The reason we selected the Janus gateway is that it’s the only fully open source server side component to attempt to currently support it (Asterisk deprecated this when they changed SIP libraries). Any solution I have personally would involve moving the transcoding to the data center, which I think is outside the scope here – but that would allow more compatibility with current web technology stacks. Other than that, a specialist in this could try adding features to a websocket library and/or create a transcoding library, but those are both fairly heavy lifts.

>that accepts calls from your RUE? Can it connect to and interoperate

We have a SIP server we’ve used for interoperability in the past with our Windows client, which has some inherited design choices that make full RUE compliance difficult. We’ve used this to make calls with the WebRTC client, though we have to work at reverse engineering Google’s intentional decision to exclude the proprietary H.264 codec from Electron due to licensing concerns before we can expect a call to succeed (which should be fine for non-commercial purposes, or we can try the openH264 codec and see how compatible it is). Calls with the optional VP8 client :should: work, though we’d have to try it to see if that was the case.

-Matt

From: Rum <[email-masked]> on behalf of Paul Kyzivat <[email-masked]>
Date: Thursday, August 26, 2021 at 12:18 PM
To: [email-masked] <[email-masked]>
Subject: [EXT] Re: [Rum] Release announcement: WebRTC VATRP v1.0
Matt,

        Thanks,
        Paul

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

---

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

Far be it from me to try to interpret licensing issues, but I believe there is an available zero cost license for H.264 when used with WebRTC media.  

But Google made a choice, and you have to deal with it.

Brian

> On Aug 26, 2021, at 4:04 PM, Matthew H Garber <[email-masked]> wrote:
> 
> This is due to our technology choice – web applications generally don’t know how to, nor need to, speak T.140; most folks would pick up a library like socket.io <http://socket.io/> to handle this unless they had a specific use case not to. The reason we selected the Janus gateway is that it’s the only fully open source server side component to attempt to currently support it (Asterisk deprecated this when they changed SIP libraries). Any solution I have personally would involve moving the transcoding to the data center, which I think is outside the scope here – but that would allow more compatibility with current web technology stacks. Other than that, a specialist in this could try adding features to a websocket library and/or create a transcoding library, but those are both fairly heavy lifts.
>  
> From: Rum <[email-masked] <mailto:[email-masked]>> on behalf of Paul Kyzivat <[email-masked] <mailto:[email-masked]>>
> To: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
> > athttps://github.com/mitrefccace/fcc-vatrp-webrtc <athttps://github.com/mitrefccace/fcc-vatrp-webrtc> 
> > <https://github.com/mitrefccace/fcc-vatrp-webrtc <https://github.com/mitrefccace/fcc-vatrp-webrtc>>. This client has a 
> > athttps://github.com/mitrefccace/fcc-vatrp-webrtc/blob/main/docs/FCC_TRS_WebRTC_VATRPv1-0_PR_21-1891.docx <athttps://github.com/mitrefccace/fcc-vatrp-webrtc/blob/main/docs/FCC_TRS_WebRTC_VATRPv1-0_PR_21-1891.docx> 
> > <https://github.com/mitrefccace/fcc-vatrp-webrtc/blob/main/docs/FCC_TRS_WebRTC_VATRPv1-0_PR_21-1891.docx <https://github.com/mitrefccace/fcc-vatrp-webrtc/blob/main/docs/FCC_TRS_WebRTC_VATRPv1-0_PR_21-1891.docx>>. 
> > forWindowsandMacathttps://github.com/mitrefccace/fcc-vatrp-webrtc/releases/tag/v1.0 <forwindowsandmacathttps://github.com/mitrefccace/fcc-vatrp-webrtc/releases/tag/v1.0> 
> > <https://github.com/mitrefccace/fcc-vatrp-webrtc/releases/tag/v1.0 <https://github.com/mitrefccace/fcc-vatrp-webrtc/releases/tag/v1.0>>.
> > 
> [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>

---

From: Matthew H Garber <[email-masked]>
Date: Thu, 26 Aug 2021 20:22:51 +0000

Yeah, we know and are. It’s our #1 priority for the next release.

From: Brian Rosen <[email-masked]>
Date: Thursday, August 26, 2021 at 4:20 PM
To: Matthew H Garber <[email-masked]>
Cc: Kyzivat, Paul <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [Rum] [EXT] Re: Release announcement: WebRTC VATRP v1.0
Far be it from me to try to interpret licensing issues, but I believe there is an available zero cost license for H.264 when used with WebRTC media.

Brian

On Aug 26, 2021, at 4:04 PM, Matthew H Garber <[email-masked]<mailto:[email-masked]>> wrote:

>I see that the RTT presents difficulties. Do you have any thoughts on

This is due to our technology choice – web applications generally don’t know how to, nor need to, speak T.140; most folks would pick up a library like socket.io<http://socket.io/> to handle this unless they had a specific use case not to. The reason we selected the Janus gateway is that it’s the only fully open source server side component to attempt to currently support it (Asterisk deprecated this when they changed SIP libraries). Any solution I have personally would involve moving the transcoding to the data center, which I think is outside the scope here – but that would allow more compatibility with current web technology stacks. Other than that, a specialist in this could try adding features to a websocket library and/or create a transcoding library, but those are both fairly heavy lifts.

-Matt

From: Rum <[email-masked]<mailto:[email-masked]>> on behalf of Paul Kyzivat <[email-masked]<mailto:[email-masked]>>
Date: Thursday, August 26, 2021 at 12:18 PM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: [EXT] Re: [Rum] Release announcement: WebRTC VATRP v1.0
Matt,

> forWindowsandMacathttps://github.com/mitrefccace/fcc-vatrp-webrtc/releases/tag/v1.0<forwindowsandmacathttps://github.com/mitrefccace/fcc-vatrp-webrtc/releases/tag/v1.0>

        Thanks,
        Paul

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

---

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

I am reminded that there is no licensing costs for less than 100,000 licenses per licensor per year.

Doesn’t fix what is in the library, but there is no licensing costs for all instances we can think of for this spec.

Brian

> On Aug 26, 2021, at 4:22 PM, Matthew H Garber <[email-masked]> wrote:
> 
> On Aug 26, 2021, at 4:04 PM, Matthew H Garber <[email-masked] <mailto:[email-masked]>> wrote:
>