Draft Minutes from the IETF 105 RUM meeting Scribe: "A. Jean Mahoney" 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? ------------------------------------------------------------------------ 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: 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 - 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: Henning - Original charter at SIPForum. slide 10: 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 gateway-able 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 - 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]