Skip to main content

Minutes IETF106: rum
minutes-106-rum-00

Meeting Minutes Relay User Machine (rum) WG
Date and time 2019-11-21 02:00
Title Minutes IETF106: rum
State Active
Other versions plain text
Last updated 2019-11-20

minutes-106-rum-00
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.