Subject: Re: [MMUSIC] 10 BUNDLE questions: Questions on the SDP restrictions

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Apr 2013 14:03:58 +0000

Hi,

>4. From 6.1, list 1 - are conditions 2, 5, 7 really necessary? (MUST use same c=, add rtcp-mux, same a=fingerprint)

There were some questions on why we have certain restrictions in list 1, as values can be "sorted out" in the second offer (where list 2 applies).

Regarding the same c=, if someone really sees a need for sending the first offer with different values, I guess we could discuss it. My suggestion is to keep the restriction in list 1. But, if someone OBJECTS to this, please indicate so.

Regarding "a=rtcp-mux", my suggestion is that we should mandate it for BUNDLE, and I have heard others saying the same. But, if someone OBJECTS to this, please indicate so.

Regarding "a=fingerprint", the opinion seems to be that there would be no idea using different values. But, if someone OBJECTS to this, please indicate so.

>5. From 6.1, list 2 - is condition 6 right? Why would we use different SDES keys for a single RTP session?

As people have indicated, it prevents a two-time pad attack, and that is also the only reason I can think of. My suggestion is to keep the restriction in list 1 and 2. But, if someone OBJECTS to this, please indicate so.

> 6. If you start with a m= line with one SDES config (e.g. 32-bit MAC), and then BUNDLE with another SDES line with a different (non overlapping) SDES config (e.g. 80-bit MAC), what happens? (assume fail)

People have indicated that this would be a failure, and I have seen no one indicate otherwise. But, if someone OBJECTS to this, please indicate so.

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Sat, 27 Apr 2013 14:56:50 -0700

I finally found something in all the noise.

> As people have indicated, it prevents a two-time pad attack, and that is also the only reason I can think of. My suggestion is to keep the restriction in list 1 and 2. But, if someone OBJECTS to th…

The two-time pad thing is bogus, unless you are using shim (so that
you can reuse SSRCs).

I think that I would like to OBJECT to this.  It is possible to
perform decrypt after demux, and there are no inherent problems.

I initially wasn't that concerned with people taking this position,
because I figured that it would be better to allow for some
flexibility in the order of operations.  However, it makes
multiplexing translators harder to build.

It's not a strong objection. After all, we are all in the business of
accelerating the heat death of the universe.

> People have indicated that this would be a failure, and I have seen no one indicate otherwise. But, if someone OBJECTS to this, please indicate so.

See above.