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

[Justin Uberti <[e-mail]>]

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.