RUM WG Meeting

IETF 111 - Virtual
Thursday, July 29, 2021, 4:30 - 5:30 PM PDT
Chairs: Brian Rosen, Paul Kyzivat
Notetakers: Jonathan Lennox, Jim Malloy

[Both Jim and Jonathan took notes. I (Paul) merged them and edited slightly to produce this.]

Introduction [0:10): Chairs

Agenda bashing and WG status update

Note Well presented

Interoperability Profile for Relay User Equipment [0:45]: Brian Rosen (https://datatracker.ietf.org/doc/html/draft-ietf-rum-rue-05)

Version -06 submitted this morning, by rules need to use -05 for this discussion.

Remaining open issues

Single stage dial-around

Brian: All calls go to the default provider. Removed ROUTE header from example. Routing to dial around provider based on domain in R-URI.

Dropping of IPv6

Brian: This is not happening. IETF effectively requires it. Will add “if used for signaling, must be used for media".

Eugene Christensen: The RUE must support both v4 and v6; if I as a provider only support one, an my NAPTR record reflects that, will it be okay?

Brian: I believe it requires v6 (for both media and signaling)

Paul: RUE may be on a device that doesn’t have a V4 address. It's reasonable to assume provider can get both; but the RUE may be on a device that doesn't have a v4 address.

Brian: Spec says implementations MUST support

Eugene: But the document is for the RUE.

Paul/Brian: It's both sides, unless specified otherwise.

Brian: There are networks where you can't get a v4 address anymore.

Paul: Could say that you use the same IP version for media as you use for signaling. Or if you use ICE, include candidates of the flavor of your signaling (but could offer both).

Brian: Currently only says the former, but could allow both.

Brian: will tweak the wording.

Contact sync as is:

Brian: jCard could be changed xCard, but JSON seems better.

Isaac Roach: I like newer stuff, so I'm all for JSON, but it's not such a simple change, and we already have everything working for xCard, and it's all the same data, so why require implementors to do a bunch of work for the thing they already have?

Brian: Do you use it for contact export?

Isaac: Yes, it's required by the FCC.

Paul: The rules don't cover sync, do they? Just transport?

Brian: Yes, but if you're going to do it one way for one, do it the same for everything. So I'm willing to make it xCard. Does anyone feel strongly that it should be jCard?

Brian: We'll take it to the list, but it sounds like xCard is better.

WebRTC compatibility

Brian: Not supporting webRTC, just media requirements for compatibility with webRTC clients using a gateway for signaling conversion.

Isaac: Can you clarify that?

Brian: Any WebRTC implementation that meets the requirements of the RFCs can generate media that a RUE-supporting VRS provider can consume, without decoding and re-encoding audio and video. (RTT would still need to be decoded and re-encoded, since WebRTC uses the data channel, whereas RUE uses RFC 4103.)

Isaac: So we have to support a WebRTC-based RUE client?

Brian: You have to support someone else doing a conversion between WebRTC and RUE. You aren't responsible for dealing with WebRTC yourself.

Isaac: It has requirements like, you MUST use DTLS for security, and NACK, etc.; it's not as simple as just sending media.

Brian: Yes, but it's still an offer/answer. It supports more than a typical VRS system does (e.g., multiple video streams). But only if the server negotiates it.

Paul: Codec parameters, too.

Paul: If you have explicit issues, let us know.

Brian: There was a STRONG suggestion when we created this WG that these codecs should be included. These codecs [OPUS] are the best recommendations based on IETF. If there was an issue that made implementation too hard or impossible, we could argue otherwise. We are obligated to attempt this, in the charter.

Paul: Not many comments on the mailing list, please write concerns down in explicit language.

Isaac: Will provide that detail. Raised issue on list almost a year ago. Should reference and adhere to VRS Provider Profile.

Brian: As Chair, repeat‚ we need specifics of why this is a problem. "We don’t do it that way today" probably doesn’t fly. Should support current best practices. Charter says “should” - if there is a technical problem, we can talk.

Jonathan Lennox: I think the goal was that it be possible to write a RUE in WebRTC; I think this has been achieved. It shouldn't impose new requirements on other providers.

Brian: There are things that would have to be supported beyond current provider requirements, including OPUS. Offer/Answer, minimum set [???]

Paul: Interoperability end-to-end with legacy devices, problem?

Brian: recognize this as a problem.

Brian. Required that you support the media. Specific about what has to be supported.

Isaac: there are some media mechanisms that are harder to support including OPUS, flow control, packet loss mechanisms. We will get that list.


Paul: If you can detail where you see interop issues, let us know. Then we'll have something tangible to focus on.

Brian: If a RUE is connecting to a legacy device, there could be restrictions. If you're RUE-to-RUE, hopefully there are no problems.

Isaac: on IPv6, are you saying we have to support both? E.g., on iOS you have to be IPv6-only, and there are complexities like an IPv6 address is really v4. NAT64, DNS64, etc.

Paul: Those complexities are if you need to talk to v4; if you can support v6 all the way you don't need to worry about it.

Isaac: I think we need to dig into this a bit more.

Brian: Please do.

Paul: You've clearly got some real-life experience here, so please share it if you can.

MWI support is required.

Isaac: It's an optional feature from the FCC.

Paul: But don't all providers provide it?

Isaac: But not specifically a specific protocol.

Brian: The only requirement is that there's a mechanism to indicate a light, that's it.

Paul: There's a URI to get your mail.

Brian: Possibly we need a better mechanism for a RUE to know what to with that.

Isaac: We use push notifications on iOS, because it works better.

Brian: I'm willing to say if you don't implement videomail, you don't have to implement MWI.

Paul: But it doesn't work to say you implement a proprietary videomail, but not the standard one, that defeats the purpose of RUE.

Brian: I'm happy to say you support an https browser experience for it. But there needs to be a way to notify that mail is waiting. I don't care what the interface is, whether SIP or HTTP.

Isaac: On iOS, you pretty much have to use a push notification for it.

Paul: The push notification for SIP is in the spec.

Isaac: That's for a call.

Brian: I think it should work for push notifications too, but I'll double-check that.

Paul: I think we should start Last Call.

Brian: This isn't "we're done", it gives you a deadline to get your comments in.

Alex Ospina: We can put some suggestions together on the items that were listed as "not done".

Brian: That'd be great.

[Discussion of WGLC vs. IETF Last Call]