Rum Status PagesRelay User Machine (Active WG)
Art Area: Barry Leiba, Adam Roach, Alexey Melnikov | 2019-Apr-12 —Chairs:
IETF-106 rum minutes
Session 2019-11-21 1000-1200: VIP A - Audio stream - rum chatroom
IETF 106 rum meeting Thursday, Nov 21, 10:00 VIP-A Co-Chairs Brian Rosen, Paul Kyzivat (remote) Many more remote participants than in person participants! Brian Rosen presented draft-ietf-rum-rue-01 1. Media Still some concern on OPUS as MTI, especially if older devices must be upgraded. It was pointed out that OPUS has very low compute requirements, and it would be difficult to get a document through the IETF without it, as it is considered best current practice. There was a request to clarify that G.711 may be needed in circumstances other than PSTN interconnect, e.g. to connect to older devices. Request by Brian to review WebRTC video specs we reference and suggest any other requirements. Confirmed that WebRTC mandates support for Mode 4. Discussion of eliminating most occurrences of differentiation between rue and provider, in favor of discussing only what happens across the interface. Editor will do this, but the WG may decide to revert the change if it doesn't come out right. Will keep the provisioning capability, but add text clarifying how the mechanism works. Long discussion of contacts. Current text requires upload/download from a URI and CardDAV. There seemed to be confusion between the data format of a contact (JCard) and the transport (URI based upload/download and CardDav). It was noted that JCard is extensible, including proprietary extensions, which should cover all known enhancements providers typically offer. There was some skepticism of sync actually working, although several participants cited multivendor sync working for them. Request by Brian to bring up other areas that need work. Emergency calling was cited. Need more text on how location is handled and how existing "E911" support is provided. "Additional Data" reference and explanatory text is needed. Discussion of certificates. Text currently provides a client cert for mutual auth, but It seems what providers want is identity of the code/implementation, not the user. There was skepticism that this was possible, but list discussion will be held to figure out if there are some things we can do. Objection to "With the understanding that" wording. Editor to rework. It was suggested we follow new work on multiparty RTT because some end device support may be needed.