Subject: [AVTCORE] CRYPTEX: Why TRANSPORT and not IDENTICAL?

From: Harald Alvestrand <[email-masked]>
Date: Thu, 16 Dec 2021 15:39:19 +0100

The W3C WEBRTC WG discussed how we could accomodate Cryptex in the 
WebRTC API.

An issue that came up is documented here: 
https://github.com/w3c/webrtc-extensions/issues/47#issuecomment-995847241

Basically - the spec claims that it's possilbe (by virtue of declaring 
cryptex TRANSPORT) to have SDP of the form:

a=group:a b

a=group:c d

m=audio

a=mid:a

m=video

a=mid:b

m=audio

a=cryptex

a=mid:c

m=video

a=cryptex

a=mid:d

ie we have one bundle supporting cryptex and another bundle not 
supporting it.

This raises a number of issues - the proposed API for webrtc wouldn't 
produce such a thing, since we're proposing to have just one flag for 
controlling it, but if it is allowed by the cryptex spec, we have to 
define how it is handled.

Is there a compelling use case where mixed cryptex/non-cryptex is really 
needed, or can we simplify this?

Harald

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 16 Dec 2021 16:30:54 +0100

Correct me if I am wrong, wouldn't it be possible to send an SDP with each
bundle group terminating in a different media server/endpoint?

In this case, one could support cryptex and the other one not. Not saying
it is a desirable use case, but I have done it in the past for connecting a
webrtc browser simultaneously with a pstn gateway and media server
frowarding a screenshare video.

Best regards
Sergio

El jue, 16 dic 2021 a las 15:40, Harald Alvestrand (<[email-masked]>)
escribió:

> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 16 Dec 2021 11:50:44 -0500

Sergio (in https://github.com/w3c/webrtc-extensions/issues/47) said:

"This is my understanding:

   - browsers will support receiving cryptex on all m-lines, so they will
   add the cryptex attribute on all m-lines of all bundles.
   - browsers will always try to send cryptex if the other end supports
   cryptex (there is no api for controlling this).
   - browsers will throw an exception on setRemoteDescription if the
   RTCConfiguration.rtpHeaderEncryptionPolicy is require and the other end
   does not support cryptex on any bundle."

[BA]  So it is OK for a browser to reject the Offer in Harald's example if
rtpHeaderEncryptionPolicy is "require"?   Doesn't this mean that browsers
would implement IDENTICAL rather than TRANSPORT?

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 16 Dec 2021 18:31:58 +0100

El jue, 16 dic 2021 a las 17:50, Bernard Aboba (<[email-masked]>)
escribió:

>    RTCConfiguration.rtpHeaderEncryptionPolicy is require and the other
>    end does not support cryptex on any bundle."
>
>

But the answer would be "rejected" even if all m-lines didn't contain the
cryptex attribute and the policy is "require", so not sure if this is about
IDENTICAL vs TRANSPORT at all. The topic is that the rejection proposed in
webrtc would be to throw an exception, so the remote SDP would not be even
set at all.

 If the "rejection" was instead about rejecting the m-lines belonging to
the non-cryptex bundle transport, that could be still possible with the
TRANSPORT attribute.

What would be the defined behavior of webrtc if it receives an SDP with
two bundles, one with DTLS and another with plain RTP ? (which would be a
"valid" SDP according to bundle, right?)

Best regards
Sergio