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

From: Bernard Aboba <[email-masked]>
Date: Tue, 21 Dec 2021 10:44:46 -0500

Sergio said:

"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 forwarding a screenshare video."

[BA] Yes, that it is the use case supported by TRANSPORT that would
not be permitted with IDENTICAL.  It seems that it can be supported by
the current API proposal.

Under the API proposal, the browser would never generate such an
Offer, but if RTCConfiguration.rtpHeaderEncryptionPolicy is set to
"negotiate" the browser could accept such an Offer.  I also believe it
would accept it as an Answer to an Offer containing "a=cryptex" on
every m-line (provided that each m-line in the bundle group had the
same setting).

In either case, the browser would only send cryptex on those m-lines
that the other peer indicated were able to receive it.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Dec 2021 19:37:40 +0000

Hi,

Note that the scope for a  mux category is a 5-tuple. So, if you have two m- lines that describe media to different media server endpoints (READ: different 5-tuples), IDENTICAL category SDP attributes in the m- lines can have different values.

Regards,

Christer

From: avt <[email-masked]> On Behalf Of Bernard Aboba
Sent: tiistai 21. joulukuuta 2021 17.45
To: IETF AVTCore WG <[email-masked]>
Subject: Re: [AVTCORE] CRYPTEX: Why TRANSPORT and not IDENTICAL?

Sergio said:

"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 forwarding a screenshare video."

[BA] Yes, that it is the use case supported by TRANSPORT that would not be permitted with IDENTICAL.  It seems that it can be supported by the current API proposal.

Under the API proposal, the browser would never generate such an Offer, but if RTCConfiguration.rtpHeaderEncryptionPolicy is set to "negotiate" the browser could accept such an Offer.  I also believe it would accept it as an Answer to an Offer containing "a=cryptex" on every m-line (provided that each m-line in the bundle group had the same setting).

In either case, the browser would only send cryptex on those m-lines that the other peer indicated were able to receive it.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 22 Dec 2021 13:32:09 +0100

Thank you for your feedback Christer, what is the DIfferent between
IDENTICAL and TRANSPORT then? In any case, this wouldn't affect the webrtc
api and the SDP O/A proposed handling on browsers, right?

Best regards
Sergio

El mar, 21 dic 2021 a las 20:40, Christer Holmberg (<christer.holmberg=
[email-masked]>) escribió:

> Hi,
>
>
>
> Note that the scope for a  mux category is a 5-tuple. So, if you have two
> m- lines that describe media to different media server endpoints (READ:
> different 5-tuples), IDENTICAL category SDP attributes in the m- lines can
> have different values.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* avt <[email-masked]> *On Behalf Of *Bernard Aboba
> *Sent:* tiistai 21. joulukuuta 2021 17.45
> *To:* IETF AVTCore WG <[email-masked]>
> *Subject:* Re: [AVTCORE] CRYPTEX: Why TRANSPORT and not IDENTICAL?
>
>
>
> Sergio said:
>
>
>
> each bundle group terminating in a different media server/endpoint?
>
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Dec 2021 19:32:31 +0000

Hi,

>Thank you for your feedback Christer, what is the DIfferent between IDENTICAL and TRANSPORT then?

It’s a while since I worked on this, but basically TRANSPORT allows you to give different attribute values in each m- line, but you will then use the value of the m- line that is used to describe the transport for the multiplex (in BUNDLE that m- line is referred to as “tagged m- line”).

When I take a quick look at the cryptex draft, I think it could be IDENTICAL, as the attribute does not have any value.

> In any case, this wouldn't affect the webrtc api and the SDP O/A proposed handling on browsers, right?

If you by “proposed handling” refer to what Bernard in the GitHub discussion suggests regarding RTCRtpTransceiver and RTCConfiguration, I can’t really comment on that. It’s too long since I looked at those :)

However, when looking at the GitHub discussion, I see the following statement from Bernard:

     “Discussion at December 14, 2021 Virtual Interim: Not clear why cryptex shouldn't be "IDENTICAL" (e.g. always on or off for all m-lines, not just bundle groups). Harald to raise issue on AVTCORE WG mailing list.”

Maybe I misunderstand what is meant by “not just bundle groups”, but the SDP category types only applies to bundled m- lines.

(Of course, there might be attributes that have to be identical for all m- lines for other reasons than multiplexing, but that is outside the scope of the mux category)

Regards,

Christer

El mar, 21 dic 2021 a las 20:40, Christer Holmberg (<christer.holmberg=[email-masked]<mailto:[email-masked]>>) escribió:
Hi,

Regards,

Christer

From: avt <[email-masked]<mailto:[email-masked]>> On Behalf Of Bernard Aboba
Sent: tiistai 21. joulukuuta 2021 17.45
To: IETF AVTCore WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [AVTCORE] CRYPTEX: Why TRANSPORT and not IDENTICAL?

Sergio said:

In either case, the browser would only send cryptex on those m-lines that the other peer indicated were able to receive it.
_______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/avt<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-cfa00aa7ddef0e6d&q=1&e=194f0c5f-d074-4437-95c3-24c5e5dfc661&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Favt>