* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Rum Status Pages

Relay User Machine (Active WG)
Art Area: Barry Leiba, Adam Roach, Alexey Melnikov | 2019-Apr-12 —  

IETF-105 rum minutes

Session 2019-07-23 1520-1650: Notre Dame - rum chatroom


minutes-105-rum-00 minute

          Draft Minutes from the IETF 105 RUM meeting
          Scribe: "A. Jean Mahoney"
          I marked things that I missed with ...
          Corrections/additions welcome!
          RUM WG Meeting
          IETF 105 - Montreal
          Tuesday, July 23, 2019, 1520 - 1650
          Chairs: Brian Rosen, Paul Kyzivat
          Introduction [0:10]
          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
          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
          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
          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
          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
          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
          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
          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
          Jim Malloy in chat room - v1.0 (Jan 2019) is here
          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
          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
          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]

Generated from PyHt script /wg/rum/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -