[Rum] Notes from the IETF 105 RUM meeting

"A. Jean Mahoney" <mahoney@nostrum.com> Tue, 23 July 2019 21:59 UTC

Return-Path: <mahoney@nostrum.com>
X-Original-To: rum@ietfa.amsl.com
Delivered-To: rum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40AD12001B for <rum@ietfa.amsl.com>; Tue, 23 Jul 2019 14:59:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEy__luG6cwg for <rum@ietfa.amsl.com>; Tue, 23 Jul 2019 14:59:11 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06F91209A0 for <rum@ietf.org>; Tue, 23 Jul 2019 14:59:11 -0700 (PDT)
Received: from dhcp-9ab9.meeting.ietf.org ([IPv6:2001:67c:1232:144:ad94:7b0b:cb29:fa61]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x6NLx9kZ053194 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <rum@ietf.org>; Tue, 23 Jul 2019 16:59:10 -0500 (CDT) (envelope-from mahoney@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1563919151; bh=JZMs5q/KMuaXlQfPm2QIRz1Ye9z9tvMIZw3GMZ936y0=; h=To:From:Subject:Date; b=NY0z2KfdxNqxQtJw9hfrERjzbv0k4hu6hfaD5eAe2HsS4HYM12zTHHZqp6Ad/peAj +jp27bj3Zzkg6mfDN5nk/86+Yngi3MdVjg9w92wRClqDSOJicMKSfsAPdbwieCWtuV 74U26E1hTiifwed3F515SZ6MBUbxR7zRDWwMSldE=
X-Authentication-Warning: raven.nostrum.com: Host [IPv6:2001:67c:1232:144:ad94:7b0b:cb29:fa61] claimed to be dhcp-9ab9.meeting.ietf.org
To: rum@ietf.org
From: "A. Jean Mahoney" <mahoney@nostrum.com>
Message-ID: <3ee04a2f-b70f-0275-9fb5-08168cbff01e@nostrum.com>
Date: Tue, 23 Jul 2019 17:59:09 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/g3PHcJPX0RC1C2dgiVCY_W6GLUM>
Subject: [Rum] Notes from the IETF 105 RUM meeting
X-BeenThere: rum@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Relay User Machine <rum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rum>, <mailto:rum-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rum/>
List-Post: <mailto:rum@ietf.org>
List-Help: <mailto:rum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rum>, <mailto:rum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jul 2019 21:59:24 -0000

See below. I marked things that I missed with ...

Corrections/additions welcome!

Jean

========================================================================

RUM WG Meeting
IETF 105 - Montreal
Tuesday, July 23, 2019, 1520 - 1650
Chairs: Brian Rosen, Paul Kyzivat

------------------------------------------------------------------------
Introduction [0:10]
Chairs
https://datatracker.ietf.org/meeting/105/materials/slides-105-rum-chair-slides-00

Note taker - Jean Mahoney
Jabber scribe - Jonathan Lennox

No changes to the agenda.

------------------------------------------------------------------------
Goal review - why we need and are ready for a standard: [0:15]
Eric Burger
https://datatracker.ietf.org/meeting/105/materials/slides-105-rum-rum-goal-review-00

Eric - How the IETF and governments can work together. Video 
interpretation for deaf users. The video phones are proprietary - either 
HW and/or SW. The time is right to create a globally standard interface 
- this is not limited to the US. We have the tools - the vendors may 
consider SRTP. Looking forward to refinements and help on coming up with 
a standard.

The FCC runs (through a contractor) an interoperability event. We can 
make sure the profile we create works.

Any questions?

<no questions>

------------------------------------------------------------------------
Document History: [0:15]
Henning Schulzrinne
https://datatracker.ietf.org/meeting/105/materials/slides-105-rum-rum-history-background-00

slide 1: Title

slide 2: What is a Video Relay Service Call?

Henning - The solution has been around for a long time. Started with 
H323 and TV sets, now looks like modern video conferencing.

slide 3: Databases

Henning - ENUM database is used to establish eligibility of users, binds 
a TN to a Tel URL and management and eligibility info.

slide 4: All relay services are just media combinations

Henning - The largest user of VRS is for communication between deaf 
individuals - p2p, but relay services should inform our discussions.

slide 5: <sequence diagram>

slide 6: What are the recurring problems?

Henning - There is difficulty with making calls between providers. One 
provider has 85% market share. Had been difficult getting good quality 
connection between two different providers. That problem is mainly 
solved. The remaining problem is device/SW porting. 300k users of VRS - 
small market.

<Henning was disconnected>

Henning - Want to support additional platforms beyond Apple or Windows - 
in-home platforms for instance. Users want to switch providers when 
calls drop or there are long waits.

slide 7: The full interoperability cake

Henning - In the IETF we never managed to get configuration retrieval 
standardized and used. Cherry on top is voice & video mail, address book 
porting

slide 8: Incomplete timeline

Henning - We have tried for the last 7 years to work on this. MITRE's 
initial release VATRP is Windows only. There are a lot of people that 
are not eligible - can sign ASL but are friends, or teachers, or 
corporations or governments that want to hire ASL signers and use the 
service. MITRE's been working on it.

slide 9: <email>

Henning - Original charter at SIPForum.

slide 10: <SIPForum Video Relay Service document>

Henning - What we do in the working group should be compatible with this.

slide 11: VRS interoperability events

slide 12: Other related efforts

Henning - RCS has fleshed out the specs. It will be helpful to consider 
them. It would be good to create a bridge between RUM and RCS, if they 
are gatewayable without media gateways.

Paul Kyzivat - In full disclosure. I've been the editor of the VRS 
Profile. The new version will have SRTP.

------------------------------------------------------------------------
Interoperability Profile for Relay User Equipment [0:30]
Brian Rosen
https://tools.ietf.org/html/draft-rosen-rue-00
https://datatracker.ietf.org/meeting/105/materials/slides-105-rum-draft-rosen-rue-00

slide 1: Title

Brian - I'm working on an update to the draft. I'm going to incorporate 
Olle's feedback, and I appreciate his feedback. If others could read the 
draft and provide input, that would be great.

slide 2: Table of Contents

Brian -  The media section will reference WebRTC media specs in next 
version.

slide 3: SIP Signaling

Brian - the VRS-specific case here is dial-round, and short-circuit 
signaling for that.

slide 4: Media

slide 5: SRTP

Brian - This section will be impacted by the WebRTC specs.

slide 6: Contacts

slide 7: Provisioning

slide 8: What's next?

Brian - If the WG decides to adopt the draft, we'll decide which 
sections we want to keep or change. The next version will include Olle's 
feedback and WebRTC specs, before the end of this week hopefully. I will 
appreciate any reviews.

Jonathon Lennox - a tricky thing - WebRTC doesn't include real-time text.

Brian - Yes, but if we use the data channel - there's issue with 
backward compatibility. Realtime text is not a high bitrate... Solve 
this in the standard SIP-based way.

Paul - Has anyone implemented realtime text over datachannel?

Adam Roach - I don't know. It's something an application would 
implement, not the browser. It's simple, but you don't want to push it 
into terminals that don't implement the datachannel stack. Use the SIP 
related one. Maybe after we deploy this we could add it on.

Brian - There are some university groups that code these kind of apps. 
Maybe we can get a group together - this is a student-sized project. See 
if we can get a group interested in an open source environment.

Bernard Aboba - ORTCweb (sp?) - there's an open source project.

Brian - Send me an email on that.

ACTION: Bernard to send Brian email regarding the open source project 
that Bernard mentioned.

Chris Wendt - Authentication, giving out SIP credentials... MD5 hash. 
Are there thoughts about expanding that?

Brian - It's not secure enough. We need to change that. What's in the 
draft won't fly in the IETF - get that in the notes.

Henning - <garbled>

Brian - Henning is talking about user configuration - current solution 
is username and password stored in files. Need to change that. Current 
doc has a standard method for configuration - a json object. Hope to 
refine that.

Jonathan for James Hamlin - Can we clarify that RUM is a user endpoint 
interface whereas access from call centers and other video platforms is 
a network to network interface. Sorry for delayed interruption.

Brian - this is the UNI interface, not an NNI interface. Not provider to 
provider.

Paul - The stuff MITRE is doing - they act like a provider. Interface 
NNI - connect to users who are not deaf.

Brian - the FCC has contracted MITRE to do interop testing. VATRP - they 
test it through their own provider interface. They make another call to 
another provider endpoint. VATRP is based on winphone - just does a user 
device.

Paul - To James' point - If you have a call center that has employees 
that can sign and want to communicate to deaf people, you have to 
connect to one of the existent providers. There are no regulations for 
that. Or need support for the NNI interface.

Brian - NNI interface is out of scope. MITRE has an interface like that 
- uses WebRTC. Scope is user device to provider.

Eric - is there source code available?

Brian - There's a release process with the standard lawyer problem. I'll 
post it to the list.

Henning - January 2019 in GitHub, for Windows. It's in the links of my 
presentation.

Jim Malloy in chat room - v1.0 (Jan 2019) is here 
https://github.com/mitrefccace/fcc-vatrp

Jonathan Lennox - Is it a goal that it should be implementable in a 
browser in WebRTC?

Brian - During the bashing the charter, earlier versions said desirable, 
now there is less emphasis. As an individual, I would like to see that. 
Build a WebRTC server with a SIP backend to meet the spec. Interop with 
VRS endpoint. I would appreciate your help in doing that.

Chris Wendt - That should be possible.

Paul - need to get the media right.

Chris - Do we take on security in provisioning?

Brian - If we can't do that, then shouldn't be in the draft. I welcome 
suggestions on how to do that. IETF has tried to do provisioning. Not 
implementable. You have to get security right or it won't get implemented.

Jonathan for Meetecho - That sounds like something Janus can help with 
:) https://janus.conf.meetecho.com.  It's open source, and has a 
controllable SIP gatewaying functionality in the server.

Gunner Hellstrom - This is a good action. I heard from Eric he wants it 
to be global. In Europe we haven't discussed security provisioning. We 
have an ETSI standard for VRS, but it does not cover security or 
provisioning. I don't know how to handle contacts. Maybe move it into 
another spec. The hope I hear from Henning, GSMA interoperability is in 
conflict with the hope to have WebRTC interoperability. WebRTC is not 
IMS. Need to specify which way to go.

Brian - We can split the doc into multiple drafts. I would like to find 
the problem we can't solve quickly. Hope the contact will .... security 
issues that don't have obvious answers. Personally, I want to see the 
WebRTC specs. IR-94 - proper subset. .... we'll check out.

Henning - IR94 - I would like to see gatewaying relatively 
straightforward. plain SIP on one side, IMS on the other side. On 
provisioning, one of the differences that makes it tractable - it's a 
2-stage provisioning model. Users have identities with providers. Stores 
with public key/private key. Non-visible bootstrapping that you can use. 
Maybe it  looks like a cloud, ssh kind of model. Or strings that you 
copy into a SIP registrar.

Brian - Or could do it with oauth. Have a primary that stores the info. 
We can explore.

Chris - oauth is something to look at. Sometimes terminals don't have 
the capabilities to enter that information though.

Brian - we'll have to decide how far down the rat hole we want to go 
down. Devices have gotten better, but there are still devices that have 
issues.

Lennox - I didn't find in the draft, how do you specify multiple 
possible sign languages?

Brian - lang tags in the INVITE. I thought I had it in there, but maybe 
not.

Paul - With regard for call to adopt, more than half dozen have read it --

Brian - I'll put the new version out, and then we'll do a call of the 
adoption on -01 on list.


[End of meeting]