RUM WG Meeting [DRAFT]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): ChairsAgenda bashing
          and WG status updateNote Well presentedInteroperability
          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 issuesSingle stage dial-aroundBrian: 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 IPv6Brian:
          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 supportEugene: 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 compatibilityBrian: 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]