Subject: Re: [MMUSIC] New Version Notification for draft-dawkins-avtcore-sdp-rtp-quic-00.txt

From: Justin Uberti <[email-masked]>
Date: Wed, 2 Feb 2022 15:48:43 -0800

Spencer, thanks for writing this up. Having some signaling written down
lets us understand some of the next-level questions here.

RTP Profile
=========
I think the security aspects discussed in Section 1.5 are a good example of
this. At first glance, QUIC/RTP/SAVPF feels a lot like the
UDP/TLS/RTP/SAVPF defined in https://www.rfc-editor.org/rfc/rfc5764.html,
but the semantics are much different, namely:
1) The SRTP encryption process is not used, and instead QUIC's encryption
and encapsulation process is used.
2) The SAVPF profile is meant to be a hint to downstream consumers, per
Section 1.5, rather than a difference in the wire format.

I think it would be good to align with the precedent set in
https://www.rfc-editor.org/rfc/rfc7850.html, which indicates that the right
profile in all cases would be QUIC/RTP/AVPF. Any behaviors required of the
middlebox seem like they should be indicated by some other explicit
attribute given the ambiguity associated with overloading the profile.

tls-id
====
It would probably be a good idea for the SDP to include a=tls-id, defined
in https://datatracker.ietf.org/doc/html/rfc8842, to ensure endpoints can
tell when the security handshake is being restarted, as discussed in the
cited RFC. This would probably obivate the need for a=connection:new as
well (which is not typically used in DTLS-SRTP).

c2s vs p2p
========
For c2s use, the SDP you have outlined should work well. For p2p usage, we
should include the a=fingerprint mechanism used in
https://datatracker.ietf.org/doc/html/rfc5763 to allow validation of
self-signed peer certs.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 3 Feb 2022 09:32:06 -0600

Hi, Justin,

> lets us understand some of the next-level questions here.

Thanks for the quick feedback! I'll create issues for each of these in
https://github.com/SpencerDawkins/sdp-rtp-quic.

And then start working on PRs, of course ... 😉

Best,

Spencer

> RTP Profile
> =========
> I think the security aspects discussed in Section 1.5 are a good example
> of this. At first glance, QUIC/RTP/SAVPF feels a lot like the
> https://www.rfc-editor.org/rfc/rfc7850.html, which indicates that the
> right profile in all cases would be QUIC/RTP/AVPF. Any behaviors required
> of the middlebox seem like they should be indicated by some other explicit