rtp header encryption changes

[fippo]

as proposed in
https://www.w3.org/2026/06/16-webrtc-minutes.html#9a7b

(finally got around to doing it)

---

Preview | Diff

[youennf]

Is it clear how these dropped packets would appear on webrtc-stats? Will they even appear?

[fippo]

we don't have a SRTP unprotect failure counter so they would be dropped silently. Might be a useful thing to have regardless (I am looking at you error=9)

[youennf]

What happens in case the remote endpoint supports cryptex in that case?
Now that we have disable, I would think that the UA MUST send cryptex packets.
If it cannot be a MUST, a SHOULD would be good.

[fippo]

Good point. The current definition of disable leans towards "don't use it" but that needs text clarifying that it is supposed to ignore cryptex in the remote description too.
I'm generally in favor of "opportunistic cryptography" so :+1 for adding a "if the remote offers, you may use it"

If disable stays such a opt-out it might be good to mark it at risk upfront to make it clear we aim for more crypto.

(the case where the offerer is configured with disable and the answerer with require would break in both cases I think, it just depends how badly... don't shoot yourself in the foot)

[jan-ivar]

So something like this?

Suggested change

	clear.
	clear.
	If the remote endpoint indicates that it is capable of
	receiving RTP packets encrypted with cryptex, the
	user agent SHOULD apply cryptex.

[fippo]

I do not think we should narrow cryptex which says

Once each peer has verified that the other party supports receiving RTP packets encrypted with Cryptex, senders can unilaterally decide whether or not to use the Cryptex mechanism on a per-packet basis.

[youennf]

Overall looks good to me.

[jan-ivar]

So something like this?

Suggested change

	clear.
	clear.
	If the remote endpoint indicates that it is capable of
	receiving RTP packets encrypted with cryptex, the
	user agent SHOULD apply cryptex.

[jan-ivar]

We probably don't need to modify JSEP to add an additional restriction. Might it suffice to say:

Suggested change

	In setConfiguration in [[RTCWEB-JSEP]] section 4.1.18, replace
	"The bundle and RTCP-multiplexing policies MUST NOT be changed after the construction of the PeerConnection."
	with
	"The bundle policy, the RTCP-multiplexing policy and the RTP header encryption policy
	MUST NOT be changed after the construction of the PeerConnection."
	This spec adds the following restriction above and beyond what is described for
	setConfiguration in [[RTCWEB-JSEP]] section 4.1.18:
	"The RTP header encryption policy MUST NOT be changed after the construction of the PeerConnection."

Either way.

[fippo]

We always did however and also do in 15.3 - https://w3c.github.io/webrtc-extensions/#always-negotiating-datachannels-interface-extensions