Subject: [Perc] Request for decision review

From: Emil Ivov <[email-masked]>
Date: Mon, 16 May 2016 14:42:36 -0500

Hey all,

The parallel thread that we had going on the subject might have become 
too hairy so I assume not everyone is following, so I am spinning off 
this one:

I would officially like to ask the PERC WG to review the decision for 
immutable SSRCs.

At this point, after the many conversations on the topic, it sounds like 
no one would really have a problem with SSRCs being mutable. We also 
have at least some (if not many) implementers ranting that lacking the 
possibility to change SSRCs would make things *very* complicated for them.

So all in all it sounds like we'd have a net positive if we reviewed 
that decision.

Could we please do that?

Emil

-- 
https://jitsi.org

---

From: Adam Roach <[email-masked]>
Date: Mon, 16 May 2016 16:01:08 -0500

On 5/16/16 14:42, Emil Ivov wrote:
> At this point, after the many conversations on the topic, it sounds 
> like no one would really have a problem with SSRCs being mutable.

Cullen's message on May 10th called out some specific, hard problems in 
the PERC system -- problems that don't arise in non-PERC systems, like 
ensuring the focus doesn't engage in intentional misattribution. Keeping 
the SSRCs immutable prevents these problems.

If you would like to engage in a discussion of allowing SSRCs to change, 
it seems that it is first necessary for someone to figure out alternate 
means of solving those problems.

The people who don't agree with the need to allow the focus to change 
SSRCs aren't going to be very motivated to come up with those solutions, 
so it would seem that those people insisting that they be mutable -- 
i.e., you -- are on the hook for coming up with something viable. What 
do you propose?

/a

---

From: Emil Ivov <[email-masked]>
Date: Mon, 16 May 2016 16:18:57 -0500

> i.e., you -- are on the hook for coming up with something viable. What

That makes sense.

Cullen's mail asks about how we handle RTCP. I already answered this: 
it's always terminated. I am not sure I see where the problem lies here.

The second problem mentioned by Cullen on May 10 is the one about 
splicing that's also described here:
https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01#section-7.2.4

This can be resolved by simply having an rtp-hdrext attached and signed 
by the sender that carries the original SSRC. That part will not be 
allowed to change and needs to be copied over by the MDD/SFU together 
with the rests of the immutable parts.

If we need the same thing in RTCP, we add a similar extension there.

How does that work for everyone?

Emil

-- 
https://jitsi.org

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 16 May 2016 21:47:52 +0000

Emil,

>with the rests of the immutable parts.

I don't think there is even an additional signing process required.  The 
sender of the packet will encrypt the packet containing the original 
SSRC value, with the authentication including that SSRC field.  If the 
MDD preserves that value in the OHB (described in the "double" draft), 
then the receiving endpoint could restore the original SSRC value in the 
packet header before attempting to decrypt.  If the wrong SSRC is 
provided, the packet will fail authentication.

Having two SSRC numbering spaces that can overlap is unfortunate, 
though.  Using libraries like libsrtp, we would need to have an E2E 
context and a HBH context.  That is, we have to initialize the library 
twice, because every SSRC and related cryptograhic parameters, replay 
database, etc. expects a single number space.  Thus, to decrypt a packet 
we would have to do this:

     srtp_unprotect(hbh_context, packet);
     do_perc_stuff(packet);  // Such as dealing with the OHB field
     srtp_unprotect(e2e_context, packet);
We could hide that extra step by having the library create the second 
context under-the-covers or creating a wrapper layer around libsrtp (or 
whatever SRTP library is employed).  If we did not create overlapping 
number spaces, this could be avoided.

I personally think having overlapping number spaces is messy.  And for 
what?  I still fail to see how performing a 1:1 mapping of an SSRC value 
does anything to make building the MDD any easier.  In fact, I see it as 
just more complexity.  And, it's more complexity for the endpoint (as I 
note above), juggling E2E and HBH SSRC values.

Paul

---

From: Emil Ivov <[email-masked]>
Date: Mon, 16 May 2016 20:50:45 -0500

Hey Paul,

On 16.05.16 г. 16:47, Paul E. Jones wrote:
>> This can be resolved by simply having an rtp-hdrext attached and
>> signed by the sender that carries the original SSRC. That part will
>> not be allowed to change and needs to be copied over by the MDD/SFU
>> together with the rests of the immutable parts.
>
> I don't think there is even an additional signing process required.

No of course not. I just meant that it would be part of the data that is 
signed E2E.

> The

So ... I admit I haven't fully wrapped my head around the OBH thing just 
yet. Specifically I don't understand the wording about how it should be 
placed after the original header extensions and why that even matters 
given that it's removed before verification ...

I also don't understand exactly how it allows for changing other fields, 
such as the timestamp, or whether it is meant to allow for changing of 
(which) header extensions.

That said, I agree that if we tweak these definitions then using the OBH 
could work.

> number spaces, this could be avoided.

I don't get it. Given your sample above, it sounds to me that this issue 
is bound to happen exactly when you are not changing the SSRC because 
you have two crypto contexts for the same SSRC.

You are actually avoiding that issue if you can be certain of using 
different SSRCs in HBH and E2E, which you can't anyway in either of the 
solutions we are discussing.

What am I missing?

> does anything to make building the MDD any easier.

I am not sure if my previous explanations were unclear or unconvincing 
so I am just going to try and explain again:

The way simulcast is being implemented in SFUs today is by having all 
the logic at the sender and at the SFU. There is never any of it in the 
receiver. This essentially means that the sender feeds two or three 
SSRCs to the SFU. The SFU then makes sure that what goes out on the 
other side is one single and coherent RTP flow with a single SSRC. This 
allows it to handle all the logic of layer switching including things 
like requesting keyframes, detecting layer drops, detecting keyframes 
during layer switches, timestamp uplifts and others.

The receiver in this picture lives with the impression that it only ever 
gets a single video stream that simply happens to change its resolution 
every now and again.

This makes things much simpler and quicker than trying to have the 
receiver detect and juggle with layers, request keyframes and such ...

No receiver does that today and PERC would be a much tougher sell if you 
tried to get people to not only implement a new SRTP layer but also 
force them into adopting receiver side simulcast support which virtually 
no one does today.

> In fact, I see it as

I really fail to understand how immutable SSRCs would fix your issue 
above (and again, I am probably the one missing something here) but even 
with that I can assure you that having one extra libsrtp call is 
incomparably simpler than trying to get a receiver to handle simulcast 
layer switching.

Emil

-- 
https://jitsi.org

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 17 May 2016 02:29:23 +0000

Emil,

>I don't get it. Given your sample above, it sounds to me that this 
>issue is bound to happen exactly when you are not changing the SSRC 
>because you have two crypto contexts for the same SSRC.
>

So you see the example code I have above?  It won't work, is the 
problem.  Let's say Alice uses SSRC 1 and Carol uses SSRC 1.  Let's say 
the MDD remaps those to 101 and 102, respectively.  We can then do 
srtp_unprotect() on the HBH packet, but then when we call 
srtp_unprotect() for the E2E version (following the perc stuff), the 
SRTP library will not be able to find the right crypto context, because 
there are two SSRCs in the system that have the same value "1".  That's 
not valid.

So, we'd have to program around this.  It's doable, but it makes 
everything more complicated.  Maybe we initialize the SRTP library once 
for every HBH SSRC (really ugly, IMO) or we pass to the "unprotect" call 
the HBH SSRC so that we then can look for some "extended" SSRC value 
(some 64-bit value vs. 32-bit value).

Anyway, I know what we'd need to do to handle the HBH/E2E number 
overlapping problem, but it would be a heck of a lot easier if we just 
avoid it to start with.  If there is a conference-wide number space, we 
don't have to jump through hoops to support this in the SRTP libraries.  
(There would still be work, but it's simpler and would require less code 
change.  And, we could just use two SRTP instances as I showed above as 
the laziest approach.)

>so I am just going to try and explain again:

I was unconvinced. :)

>The receiver in this picture lives with the impression that it only 
>ever gets a single video stream that simply happens to change its 
>resolution every now and again.
>
>No receiver does that today and PERC would be a much tougher sell if 
>you tried to get people to not only implement a new SRTP layer but also 
>force them into adopting receiver side simulcast support which 
>virtually no one does today.

I have assumed that the receiver would receive different media flows and 
perform local composition.  The receiver would know that the video 
resolution changed, but it would know why: because now it is receiving 
PT=98 (360p) rather than PT=97 (1080p) and those are mapped to different 
simulcast flows in SDP (on the same m= line).

Also, I had assumed that the sender will always send out 97 and 98 since 
it does not know when it will be the active speaker.  It sends out both 
flows and the MDD decides which of the two to forward to receivers (if 
any at all).  I think on this point, we have the same idea.  Are you 
assuming the same SSRC would be used for both flows in line with the 
simulcast signaling spec?

Thus, the difference might be in MDD behavior.  Are you changing PTs 
when the image size changes or using the same PT?  I had assumed the PT 
value will change.

If you agree with that last paragraph on PT changing, then I'm left 
wondering exactly what the difference is in the receiver.  If the 
receiver is expecting to get either 97 or 98, which is one size video 
vs. another, then why would it care about the SSRC value.  Either would 
use same SSRC.

Let's drill in on this a little, because maybe this is where we have the 
disconnect.

>above (and again, I am probably the one missing something here) but 
>even with that I can assure you that having one extra libsrtp call is 

Having immutable SSRCs does not fix an issue, because there isn't one.  
Having mutable SSRCs, though, creates a problem where one did not exist 
before.  I suspect you have not encountered this, because you have a 
single SSRC number space and you're doing one one decryption step at the 
receiver.  With PERC doing both a HBH and E2E decryption step, having 
potentially overlapping number spaces with collisions is a headache I'd 
like to avoid.

Paul

---

From: Emil Ivov <[email-masked]>
Date: Mon, 16 May 2016 22:22:22 -0500

Hey Paul,

On Mon, May 16, 2016 at 9:29 PM, Paul E. Jones <[email-masked]> wrote:
>> is bound to happen exactly when you are not changing the SSRC because you
>> have two crypto contexts for the same SSRC.
>>
> So you see the example code I have above?  It won't work, is the problem.
> Let's say Alice uses SSRC 1 and Carol uses SSRC 1.  Let's say the MDD remaps
> those to 101 and 102, respectively.
>  We can then do srtp_unprotect() on the
> HBH packet, but then when we call srtp_unprotect() for the E2E version
> (following the perc stuff), the SRTP library will not be able to find the
> right crypto context, because there are two SSRCs in the system that have
> the same value "1".  That's not valid.

If you are concerned about that, you could have simply chosen to have
the SSRC collision obvious to Alice or Carol.

> So, we'd have to program around this.  It's doable, but it makes everything
> more complicated.  Maybe we initialize the SRTP library once for every HBH
> SSRC (really ugly, IMO)
> or we pass to the "unprotect" call the HBH SSRC so
> that we then can look for some "extended" SSRC value (some 64-bit value vs.
> 32-bit value).
> Anyway, I know what we'd need to do to handle the HBH/E2E number overlapping
> problem, but it would be a heck of a lot easier if we just avoid it to start
> with.  If there is a conference-wide number space, we don't have to jump
> through hoops to support this in the SRTP libraries.  (There would still be
> work, but it's simpler and would require less code change.  And, we could
> just use two SRTP instances as I showed above as the laziest approach.)

OK. There are two things that are wrong with this argument.

First:  There is absolutely nothing that prevents you from keeping a
single SSRC space. This is exactly what we do. SSRC rewriting does not
in any way imply creating a new context for every SSRC. In fact it may
very often mean simply reducing the number of SSRCs that are visible
to receivers.

Second: There is absolutely nothing that requires your MDD to actually
do SSRC rewriting. If you don't like it: don't do it.

>> I am not sure if my previous explanations were unclear or unconvincing so
>> I am just going to try and explain again:
>
> I was unconvinced. :)
>
>
>> The way simulcast is being implemented in SFUs today is by having all the
>> logic at the sender and at the SFU. There is never any of it in the
>> receiver. This essentially means that the sender feeds two or three SSRCs to
>> the SFU. The SFU then makes sure that what goes out on the other side is one
>> single and coherent RTP flow with a single SSRC. This allows it to handle
>> all the logic of layer switching including things like requesting keyframes,
>> detecting layer drops, detecting keyframes during layer switches, timestamp
>> uplifts and others.
>>
>> tried to get people to not only implement a new SRTP layer but also force
>> them into adopting receiver side simulcast support which virtually no one
>> does today.
>
> perform local composition.
>
> The receiver would know that the video
> resolution changed, but it would know why: because now it is receiving PT=98
> (360p) rather than PT=97 (1080p) and those are mapped to different simulcast
> flows in SDP (on the same m= line).

That is not how most of the popular SFUs work today.

> Also, I had assumed that the sender will always send out 97 and 98 since it
> does not know when it will be the active speaker.  It sends out both flows
> and the MDD decides which of the two to forward to receivers (if any at
> all).  I think on this point, we have the same idea.

We don't. There is no reason for the sender to use different payload
types, as long as it uses different SSRCs.

> Are you assuming the
> same SSRC would be used for both flows in line with the simulcast signaling
> spec?
>
> Thus, the difference might be in MDD behavior.  Are you changing PTs when
> the image size changes or using the same PT?  I had assumed the PT value
> will change.

It will not. Regardless of whether the PT changes at the sender, the
receiver will always get a single continuous and coherent RTP stream
with the same SSRC, the same PT, continuous seq. nums and continuous
timestamps.

> wondering exactly what the difference is in the receiver.  If the receiver
> is expecting to get either 97 or 98, which is one size video vs. another,
> then why would it care about the SSRC value.  Either would use same SSRC.
>

I hope this clarifies things.

>> I really fail to understand how immutable SSRCs would fix your issue above
>> (and again, I am probably the one missing something here) but even with that
>> I can assure you that having one extra libsrtp call is incomparably simpler
>> than trying to get a receiver to handle simulcast layer switching.
>
>

And there is no reason why you would need to have one with SSRC
rewriting. If your worry is only about conflict detection then let's
just require a single SSRC space per conference as part of PERC. I
would have no problem with that.

> before. I suspect you have not encountered this, because you have a single
> SSRC number space and you're doing one one decryption step at the receiver.
> With PERC doing both a HBH and E2E decryption step, having potentially
> overlapping number spaces with collisions is a headache I'd like to avoid.

Again, I think that issue is far smaller than reimplementing simulcast
but if we have consensus on trying to avoid it then let's just work on
that and avoid throwing the baby with the bath water.

Emil

-- 
https://jitsi.org

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 17 May 2016 05:28:45 +0000

Emil,
>>problem.

It would be unfortunate to have to statically assign SSRCs to endpoints 
and m= lines.

>>everything
>>overlapping

I can do that by not mapping SSRCs.

If we map SSRCs, we then create the complex problem of ensuring that 
every entity uses an SSRC that no other entity is using.  That gets 
really complex when there are cascaded MDDs and lots of endpoints 
hanging off each one.

>do SSRC rewriting. If you don't like it: don't do it.

It's far less of an MDD issue than an endpoint issue.  The endpoint will 
be responsible for decrypting the packet using HBH authenticated 
encryption.  Then, it needs to modify the RTP headers to put the 
original packet back into the buffer.  Then it needs to decrypt using 
the E2E cipher.  This is where it gets messy.  It needs to look up this 
context.  It could use the HBH context, and have data hanging off of 
that for E2E.  That would work.  But, the normal SRTP processing would 
want to do replay protection.  We'd have to disable that to avoid the 
stack getting confused over the fact there is "1" from Alice and "1" 
from Carol.  The challenge we face here is on the receiver when there 
are collisions in the E2E numbering space.

Again, if we don't re-write, we don't have this problem.

>>>...
>>>you
>>>force

Isn't that how the current I-Ds specify it?  Are you describing a 
proprietary transmission logic?

>types, as long as it uses different SSRCs.

You're suggesting the same media source use different SSRCs? Why? It 
seems like this is just one more place where things can get complex and 
not be within the spirit of RFC 3550.  (And I'll ignore that big ol' 
statement in RFC 3550 that says audio and video should not be 
multiplexed in the same RTP session, since WebRTC clearly violates that 
and everybody thought that was just fine. :P ).

>>when

Now add to that an SSRC from the sender and one from the MDD, and do 
authenticated encryption on each one.  It's doable, but complicated.

With the current PERC proposal, the SSRCs would be constant, so not an 
issue.  PT value would change for multicast per the current I-Ds, 
otherwise PT values are constant.  Sequence numbers can change to 
produce sequential numbers per RFC 3550.

So, it appears it's still an difference of opinion about how the 
receiver is to deal with overlapping SSRC number spaces.  With PERC the 
group agreed to have one number space.  With what you're proposing, 
there are two number spaces: the original source SSRC space and the MDD 
space.

>>receiver

I think so, but I do feel changing the SSRC is making things complex.

>>single

I think an important revelation that arose from this dialog is that the 
decision to change the SSRC or not will have an impact on the receiving 
terminal.  Significantly, this is true regardless of whether PERC exists 
or not.  If we follow the current I-Ds on simulcast, then receivers you 
describe that do not properly deal with switching based on PT values 
will not work right.  With the specs being driven in the IETF, SSRCs do 
not change.  PERC is consistent with that approach.  Importantly, the 
PERC and IETF simulcast approach also appears consistent with RFC 3550.

If we allow SSRC values to change, there is an incompatibility with the 
current simulcast specs.  And for PERC, it presents a challenge in 
effectively performing HBH and E2E decryption.  The HBH part is easy, 
but then we have to deal with potential collisions in the SSRC number 
space for E2E.

Paul

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 17 May 2016 08:11:32 -0700

On May 16, 2016, at 18:50, Emil Ivov <[email-masked]> wrote:
> 
> No receiver does that today and PERC would be a much tougher sell if you tried to get people to not only implement a new SRTP layer but also force them into adopting receiver side simulcast support which virtually no one does today.

[BA] It is worse than that. WebRTC 1.0 API does not support simulcast reception (only sending). ORTC does support reception, but only ORTC Lib implements this in a general way (non-codec specific) and doing so adds quite a bit of complexity so it is not clear that feature is worth keeping.

---

From: Emil Ivov <[email-masked]>
Date: Tue, 17 May 2016 13:22:21 -0500

Hey Paul,

> It would be unfortunate to have to statically assign SSRCs to endpoints

I have no idea what you mean and why we are talking about static SSRCs. 
What I meant was that if you want to use the native SSRC collision 
mechanism then you can and we should just state that as a constraint. 
There is nothing that justifies the jump from there to "DO NOT OVERWRITE"

It is up to implementers to decide how to enforce it and the native 3550 
mechanism is very much still workable.

In other words: do not assume that SSRC overwriting necessarily implies 
new SSRCs.

> every entity uses an SSRC that no other entity is using.

That is not correct as I stated above.

> That gets

It really doesn't. Of courses there are cases where it might but just 
the fact that you are overwriting some SSRCs doesn't mean that you are 
automatically in one of those cases.

> Again, if we don't re-write, we don't have this problem.

Again: I don't think you need to do these things just because you are 
re-writing. Even if you did though you are still looking at a much 
lesser effort than the one you are facing if you ask people to do 
simulcast your way.

> proprietary transmission logic?

The current simulcast I-Ds have had their faire share of controversy so 
I wouldn't rely too much on them as the only compatibility threshold to 
pass. If http only allowed and in fact required a single form of 
"standard" html, then the world would be a very different place today.

> You're suggesting the same media source use different SSRCs?

Difference SSRCs for the same physical device yes.

> Why?

I find that "Why should we use different PTs for the same payload" is a 
more appropriate question. We have different sources in all ways that 
matter. They may (and often do) have different timestamp bases, 
different sequence numbering ...

> It
> not be within the spirit of RFC 3550.

Huh? Aside from the complexity comment being completely subjective here 
(certainly entirely contrary to our experience) how the heck does that 
contradict 3550???

> (And I'll ignore that big ol'

Wait, what??? How did we even get audio involved here? I fail to see the 
relevance that this has to ... anything.

> authenticated encryption on each one.  It's doable, but complicated.

Completely lost you. Why would I be adding SSRCs? For what reason? Just 
to make your arguments work?

The whole point of what I am describing is that the receiver only sees 
one SSRC for one stream.

> there are two number spaces: the original source SSRC space and the MDD

Please do not say that again. I explained multiple times already why 
this is not true. Please stop misrepresenting.

> I think so, but I do feel changing the SSRC is making things complex.

Again, I am inviting you to look at how WebRTC SFUs do that. I am happy 
to get on a call with you and walk you through it.

> terminal.
> Significantly, this is true regardless of whether PERC exists

The conclusion here is simply wrong and the only revelation I see is 
that the reasoning for avoiding SSRC modifications have much more to do 
with subjective preferences than with rational arguments.

Emil

-- 
https://jitsi.org

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 17 May 2016 13:30:50 -0700

[BA] It seems to me that PERC is making some assumptions about the RTP
topology which need to be made explicit.  For example, is PERC assuming an
RTP translator topology?   Since few (any?) existing SFUs support the RTP
translator topology, that is going to limit applicability.

In a topology where the SFU is the RTP/RTCP endpoint (and modifies SSRCs), RTCP
SDES/BYE messages are typically modified as well so that SSRC collisions
can only occur between the endpoint and the SFU,

On Tue, May 17, 2016 at 11:22 AM, Emil Ivov <[email-masked]> wrote:

> mechanism then you can and we should just state that as a constraint. There
> is nothing that justifies the jump from there to "DO NOT OVERWRITE"
>
> It really doesn't. Of courses there are cases where it might but just the
> fact that you are overwriting some SSRCs doesn't mean that you are
> re-writing. Even if you did though you are still looking at a much lesser
> effort than the one you are facing if you ask people to do simulcast your
> way.
>
> ...
> The current simulcast I-Ds have had their faire share of controversy so I
> wouldn't rely too much on them as the only compatibility threshold to pass.
> If http only allowed and in fact required a single form of "standard" html,
> then the world would be a very different place today.
>
> matter. They may (and often do) have different timestamp bases, different
> sequence numbering ...
>
> It
> Completely lost you. Why would I be adding SSRCs? For what reason? Just to
> make your arguments work?
>
> The whole point of what I am describing is that the receiver only sees one
> SSRC for one stream.
>
> Please do not say that again. I explained multiple times already why this
> is not true. Please stop misrepresenting.
>
> Again, I am inviting you to look at how WebRTC SFUs do that. I am happy to
> get on a call with you and walk you through it.
>
> The conclusion here is simply wrong and the only revelation I see is that
> the reasoning for avoiding SSRC modifications have much more to do with
> subjective preferences than with rational arguments.
>
>
> Emil
>
> --
> https://jitsi.org
>
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc
>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 23 May 2016 10:03:24 -0700

> On May 16, 2016, at 12:42 PM, Emil Ivov <[email-masked]> wrote:
> 
> At this point, after the many conversations on the topic, it sounds like no one would really have a problem with SSRCs being mutable. 

I don’t think that is true - lots of people just can’t be bothered to repeat what they said at the previous meetings.  If there was a proposal on the table that was easy for existing DTLS-SRTP endpoints to implement, it would be easier to discuss. 

Clearly we  need a solution that does not require for terminating all the RTCP at the  MDD for people that don’t want to do that. 

I’m still not clear on what problem mutable SSRC solves.

---

From: Emil Ivov <[email-masked]>
Date: Mon, 23 May 2016 13:21:13 -0500

On Mon, May 23, 2016 at 12:03 PM, Cullen Jennings <[email-masked]> wrote:
> > At this point, after the many conversations on the topic, it sounds like no
> > one would really have a problem with SSRCs being mutable.
>
>
> I don’t think that is true - lots of people just can’t be bothered to repeat
> what they said at the previous meetings.

Well luckily, if whatever they said is to be given any consideration
at all, it would have been on this list, so I am happy to be pointed
to those argumentations.

The only technical argument I've heard thus far is Paul saying that
mutable SSRCs would make it a bit harder for PERC to be implemented as
two SRTP-compatible operations on top of each other.

As he also agreed though, things are still implementable that way.

> If there was a proposal on the
> table that was easy for existing DTLS-SRTP endpoints to implement, it would
> be easier to discuss.

I doubt that but there isn't one anyway so we are where we are.

> Clearly we  need a solution that does not require for terminating all the
> RTCP at the  MDD for people that don’t want to do that.

Now, if you want to sell a worthless SFU that doesn't terminate RTCP,
then you should really not worry: nothing I ever suggested would
prevent that (neither conserving the original SSRC nor coming up with
a new PERC ID). So, please go ahead.

What I am asking for is that we don't prevent existing SFUs from doing PERC.

> I’m still not clear on what problem mutable SSRC solves.

OK, then I will also pretend that you actually do want to understand
and explain it again :)

It is not possible for WebRTC compatible browsers today to support
incoming simulcast unless it is completely transparent to them. All
layers need to come in as part of the same flow.

RID awareness would in theory make this better except that this is far
from being done. It is not implemented today and it is not part of
WebRTC 1.0. It may become implemented at some point in the future but
we are not there yet.

So in other words: there is NO running code in browsers today that
would support the architecture this group has currently chosen for
anything but the most basic scenarios.

Presence and absence of running code used to matter around here ...
but obviously we are somehow unconcerned about it in this working
group.

Emil

-- 
https://jitsi.org

---

From: Adam Roach <[email-masked]>
Date: Mon, 23 May 2016 13:54:40 -0500

> WebRTC 1.0. It may become implemented at some point in the future but

You are working from erroneous assumptions and incorrect data. Let's 
clear that up.

 1. The RID work is far ahead of PERC; in fact, the baseline spec is
    halfway through WGLC in AVTEXT:
    <https://mailarchive.ietf.org/arch/msg/avtext/eRsaN0zMHNfUxr1lFYSrQr8lmqY>

 2. RID is in the WebRTC 1.0 specs:
    <http://w3c.github.io/webrtc-pc/#idl-def-rtcrtpencodingparameters>

 3. Firefox has RID support. It landed in Firefox 46, which is already
    in release:
    <https://bugzilla.mozilla.org/showdependencytree.cgi?id=1192390&hide_resolved=0>

The only *other* argument I've found so far is "some implementors have 
historically done it another way," which is relevant, but not as 
compelling as the countervailing argument of "it will make the crypto 
properties of this system harder to think about and harder to implement."

/a

---

From: Emil Ivov <[email-masked]>
Date: Mon, 23 May 2016 15:39:27 -0500

On 23.05.16 г. 13:54, Adam Roach wrote:
> You are working from erroneous assumptions and incorrect data.

You might have missed some aspects of the discussion.

> Let's clear that up.

Let's indeed.

>  1. The RID work is far ahead of PERC;

Maybe ... but that's not saying much.

> in fact, the baseline spec is

True, however in order for RID to be "done" it would take a lot more 
than just taking the syntax for the rtp extension out the door.

We still need to work out the congestion control side of things, the 
expectations for sender and receiver behaviour as well as the 
signalling, especially for the WebRTC case.

So no, not close to being done.

>     <http://w3c.github.io/webrtc-pc/#idl-def-rtcrtpencodingparameters>

Except that receiver-side simulcast isn't. There is nothing in JSEP that 
allows a WebRTC receiver to configure itself for receiving multiple layers.

Are you implying that the single ID in the encoding params should 
somehow suffice?

>     <https://bugzilla.mozilla.org/showdependencytree.cgi?id=1192390&hide_resolved=0>

So just to be clear ... because this is sort of a biggie: you are 
claiming that Firefox 46 has support for receiving and demultiplexing 
based on RID. Right?

One of us is obviously confused so could you please point me to the 
demux code in the mozilla repos?

> properties of this system harder to think about and harder to implement."

Another biggie: please explain to me what crypto properties will be 
harder to think about and harder to implement if we were to just relay 
the original SSRC as either the early versions of double were proposing 
or as a separate extension?

Emil

-- 
https://jitsi.org

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 23 May 2016 21:42:25 +0000

Emil,

>or as a separate extension?

If we keep the SSRC value unchanged, this simplifies the logic in the 
SRTP code since we avoid the possibility of having both Alice and Carol 
using the same E2E SSRC value.  SSRCs are what is used to identify the 
media stream and related cryptographic parameters (per section 3.2.3 of 
RFC 3711). If E2E SSRC values can potentially conflict, it would mean 
we'd need to use a new identifier (e.g., SSRC_HBH || SSRC_E2E) that is 
"new" to SRTP or prehaps an "instance" of a SRTP library per media flow 
(which would be terribly unfortunate).

Paul

---

From: Emil Ivov <[email-masked]>
Date: Mon, 23 May 2016 16:54:21 -0500

On Mon, May 23, 2016 at 4:42 PM, Paul E. Jones <[email-masked]> wrote:
>> Another biggie: please explain to me what crypto properties will be harder
>> to think about and harder to implement if we were to just relay the original
>> SSRC as either the early versions of double were proposing or as a separate
>> extension?
>
>
> If we keep the SSRC value unchanged, this simplifies the logic in the SRTP
> code since we avoid the possibility of having both Alice and Carol using the
> same E2E SSRC value.

As I have mentioned at least twice already :) ... this is not
necessarily true. Simulcast rewriting often reuses one of the original
SSRCs without introducing new ones, so conflict resolution could still
work as per 3550. Anyways, I think we shouldn't rely on that, but we
need to be accurate.

> SSRCs are what is used to identify the media stream
> and related cryptographic parameters (per section 3.2.3 of RFC 3711). If E2E
> SSRC values can potentially conflict, it would mean we'd need to use a new
> identifier (e.g., SSRC_HBH || SSRC_E2E) that is "new" to SRTP or prehaps an
> "instance" of a SRTP library per media flow (which would be terribly
> unfortunate).

PERC will rely on SRTP for HBH. Nothing I ever said challenges that.
Relying on stock unmodified SRTP primitives to handle E2E is a goal
that comes out of nowhere. It would be neat, sure, but not doing so
does not in any compromise the crypto properties of PERC. It is just
an implementation detail with a relatively low (aesthetic) cost at the
SRTP side and a huge gain on the SFU side.

Emil

-- 
https://jitsi.org

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 24 May 2016 00:19:54 +0200

Emil,

The whole point of PERC is E2E encryption. And, if Alice and Carol chose the same SSRC value, the MDD can't change that. It can only rewrite it and preserve the original value, as that original value is needed for E2E decryption.  And that's where we run into the number space conflict.

Paul

-------- Original Message --------
From: Emil Ivov <[email-masked]>
Sent: May 23, 2016 11:54:21 PM GMT+02:00
To: "Paul E. Jones" <[email-masked]>
Cc: Adam Roach <[email-masked]>, Cullen Jennings <[email-masked]>, [email-masked]
Subject: Re: [Perc] Request for decision review

Emil

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Mon, 23 May 2016 21:36:22 -0500

Hey Paul,

On Mon, May 23, 2016 at 5:19 PM, Paul E. Jones <[email-masked]> wrote:
> Emil,
>
> The whole point of PERC is E2E encryption.

Yup ... I think we are on the same page there :)

> And, if Alice and Carol chose the
> same SSRC value, the MDD can't change that. It can only rewrite it and
> preserve the original value, as that original value is needed for E2E
> decryption.

 ... I won't re-explain this a sixth time :). Please read any of my
five previous explanations about this is not true.

> And that's where we run into the number space conflict.

Even if we do go for full rewriting preserving the original SSRC is
trivial and, as per your words, is only a matter of using 64bit
identifiers (the concatenation of the two SSRCs) at the receiving end
in order to get it to work with the double srtp unprotect.

Where is the problem with that.

Emil

>>> harder
>>>  SS!
>>>  RC as
>>> either the early versions of double were proposing or as a separate
>>>  extension?
>>
>>
>>
>> SRTP

-- 
https://jitsi.org

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 24 May 2016 09:24:33 +0200

Emil,

Since we are not enforcing a requirement that endpoints select a distinct SSRC per media flow, there is a potential conflict in the number space used E2E.  The 64 bit identifier is just a hack to work around that problem. If the problem didn't exist, we could use SSRC values to look up the context as it was I intended in SRTP.

The problem with using a 64 bit value is that any existing SRTP library would have to change to associate the context that way. Further, if we wish to break up the PERC processing into two steps, that HBH SSRC would have to be extracted and passed in by the application. While I think the intent with Double is for this to be an autonomous operation, it might not be implemented that way for two reasons:
1) If there is a desire to do HBH FEC, the process might be to encrypt E2E -> FEC -> HBH. So the second call to the SRTP library would need that HBH SSRC passed in when doing these steps in reverse to introduce that 64-bit context ID.
2) It might be desirable to implement the PERC logic by just having a two-step wrapper around the existing SRTP library to avoid making changes to the core library.  (I'd prefer built-in support for Double, but I can appreciate how some might prefer to not change an otherwise working library.)

Paul

-------- Original Message --------
From: Emil Ivov <[email-masked]>
Sent: May 24, 2016 4:36:22 AM GMT+02:00
To: "Paul E. Jones" <[email-masked]>
Cc: Adam Roach <[email-masked]>, Cullen Jennings <[email-masked]>, [email-masked]
Subject: Re: [Perc] Request for decision review

Hey Paul,

Emil

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Tue, 24 May 2016 12:37:25 -0500

On 24.05.16 г. 2:24, Paul E. Jones wrote:
> Emil,
>
> Since we are not enforcing a requirement that endpoints select a
> distinct SSRC per media flow, there is a potential conflict in the
> number space used E2E.

As I have been insisting many times already: We have the option to 
mandate that SFUs preserve the SSRC space. That's not hard to implement. 
It's not a great option but it is a possibility.

We can also say that whether or not SFUs do that rewrite is a feature 
that has to be signalled so clients can choose whether to support it or 
not. This should address your concern.

> The 64 bit identifier is just a hack to work
> around that problem. If the problem didn't exist, we could use SSRC
> values to look up the context as it was I intended in SRTP.

E2E PERC is NOT SRTP. We may choose to make it look like it is and I see 
why that is appealing but not doing it is by no means "a hack".

Again, signalling whether rewrites are done should address your concern.

> The problem with using a 64 bit value is that any existing SRTP library
> would have to change to associate the context that way.

So just to be clear ... we are lamenting about changing an int to a long?

> Further, if we
> wish to break up the PERC processing into two steps, that HBH SSRC would
> have to be extracted and passed in by the application. While I think the
> intent with Double is for this to be an autonomous operation, it might
> not be implemented that way for two reasons:
> 1) If there is a desire to do HBH FEC, the process might be to encrypt
> E2E -> FEC -> HBH. So the second call to the SRTP library would need
> that HBH SSRC passed in when doing these steps in reverse to introduce
> that 64-bit context ID.

Em ... you'd have to explain this in a bit more detail because I fail to 
see how FEC is any different than regular media. As you say it yourself, 
it all just works out properly as long as you do your FEC after E2E and 
before HBH as that way the SFU would be able to de- or re-FEC.

> 2) It might be desirable to implement the PERC logic by just having a
> two-step wrapper around the existing SRTP library to avoid making
> changes to the core library. (I'd prefer built-in support for Double,
> but I can appreciate how some might prefer to not change an otherwise
> working library.)

As I said, being able to reuse SRTP libraries with no change is a great 
optimization if we get it but I really don't think the alternative is 
anywhere near the complexity that would justify banning SSRC re-writing.

Emil
>
> Paul
>
> ------------------------------------------------------------------------
> *From:* Emil Ivov <[email-masked]>
> *Sent:* May 24, 2016 4:36:22 AM GMT+02:00
> *To:* "Paul E. Jones" <[email-masked]>
> *Cc:* Adam Roach <[email-masked]>, Cullen Jennings <[email-masked]>,
> [email-masked]
> *Subject:* Re: [Perc] Request for decision review
>
> Hey Paul,
>
>                 properties of this system harder to think about and
>                 harder to
>                 implement."
>
>
>
>
>             to think about and harder to implement if we were to just
>             relay the
>             original
>             SS!
>             RC as
>             extensi! on?
>         code since we avoid the possibility of having both Alice and
>         Carol using
>         the
>         same E2E SSRC value.
>
>
>
>         and related cryptographic parameters (per section 3.2.3 of RFC
>         3711). If
>         E2E
>         SSRC values can potentially conflict, it would mean we'd need to
>         use a
>         new
>
>         identifier (e.g., SSRC_HBH || SSR! C_E2E) that is "new" to SRTP
>         or prehaps
>         an

-- 
https://jitsi.org

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 25 May 2016 12:22:36 +0000

Emil,

>mandate that SFUs preserve the SSRC space. That's not hard to 
>implement. It's not a great option but it is a possibility.
>

The SFU has nothing to do with the E2E SSRC collision problem.  When an 
endpoints sends out an RTP packet and it goes though an SFU that changes 
the SSRC, there is a HBH SSRC and an E2E SSRC.  I fully agree that the 
SFU can ensure that the HBH SSRCs do not collide, but it cannot control 
the fact that the E2E SSRCs collide.

>E2E PERC is NOT SRTP. We may choose to make it look like it is and I 
>see why that is appealing but not doing it is by no means "a hack".

Of course it's SRTP.  It just happens to be two passes of SRTP, but it's 
nonetheless SRTP.  What PERC is adding are some additional steps between 
each pass for HBH authentication of packets at the sender (and the 
reverse at the receiver).  The MDD doesn't have two steps: it just does 
one normal SRTP decryption for the packet received and one SRTP 
encryption step sending the packet.  The only special requirement PERC 
introduces is that if the MDD changes either the PT field or sequence 
number, the original values have to be added to the packet inside an RTP 
header extension called OHB (if not already present).

>So just to be clear ... we are lamenting about changing an int to a 

No, lamenting that this would not align with what RFC 3711 says to use 
to identify the context.

>Em ... you'd have to explain this in a bit more detail because I fail 
>to see how FEC is any different than regular media. As you say it 
>yourself, it all just works out properly as long as you do your FEC 
>after E2E and before HBH as that way the SFU would be able to de- or 
>re-FEC.

Historically, there were two options for FEC.  Either we do FEC first 
and then SRTP, or SRTP first then FEC.  The order has to match at both 
the sender and receiver.  Either way, it generally makes very little 
difference.

An MDD might want to be a good citizen and reconstruct lost packets 
before sending a stream to a receiver.  In order to do that, the sender 
will either need to do SRTP (both passes) then FEC or it could do the 
first SRTP pass (the E2E encryption pass) then FEC then SRTP for the 
HBH.  It really depends on what we want that FEC flow to look like.  Do 
we want it to be FEC over a bunch of E2E+HBH encrypted packets or just 
over the E2E packets.  (The latter would be parallel to the current FEC 
order of "FEC then SRTP".

So, thinking of how this might be implemented in an SRTP library, if we 
allow the SRTP(E2E)+FEC+SRTP(HBH) option for FEC order, then when the 
application encrypts the packet, it would pass the packet into the SRTP 
libtary once to encrypt HBH.  It then does whatever FEC processing it 
wants, then it calls into the SRTP library again to encrypt the second 
pass (HBH pass).  It could be two entirely instances of the SRTP library 
that handles each pass.  On the MDD, it decrypts the flow and does 
whatevever FEC magic it wants to do.  There is only one SRTP operation 
at the MDD, so no problem.  At the receiver, it decrypts the packet 
received using HBH decryption. It then does whatever FEC processing it 
needs to do.  Next, it would call into the SRTP library to decrypt for 
E2E.  If the SSRCs never change, this works fine.  One could implement 
this using two instances of an SRTP library today.  If a single library 
is used, then the only requirement is to ensure the second call into the 
library does not encounter issues with the replay database (since it 
might otherwise think it's a replayed packet).  In either case, the 
crypto context would be looked up as per RFC 3711 using SSRC.  If, 
however, the SSRC value is allowed to change, then the second call into 
the SRTP library (same or different instance of the library) would be a 
problem since Alice and Bob both used SSRC 1.  The collision is going to 
prevent the library from working properly.

If we take the approach of using a 64-bit identifier (in contradiction 
to RFC 3711) to identify the crypto context, then we would need to pass 
that identifier into the SRTP library when attempting to decrypt the 
packet, because it could not simply discover it by looking at the packet 
(which it could do normally since the SSRC value is right there in the 
packet).  It would be necessary to make a call like 
srtp_unprotect(context, packet, stream_identifiier) (where 
stream_identifier is something that identifies the stream other than the 
SSRC per 3711, like E2E_SSRC || HBH_SSRC).

A beautiful thing about SRTP today is the library can operate on streams 
without the application having to pass in such identifiers.  The stream 
is self-identifying.  But, we lose that elegance when we modify the SSRC 
in the MDD when we break the operation into two passes to handle this 
FEC order.

>anywhere near the complexity that would justify banning SSRC 

At least we agree that it would be a good goal to find an approach that 
would eliminate or minimize changes to the SRTP logic. :)

Now to the complexity part... that's in the thread you're having with 
Cullen which, as I understand, is an expression of a concern that 
receiving endpoints are not going to properly handle multiple simulcast 
streams coming toward them.

Since I don't work for a browser vendor, I cannot speak to their plans.  
I can only assume that proper handling of received simulcast flows would 
be implemented per the current drafts.  And if that's the case, then I 
don't think changing the SSRC would be needed.  If receiving endpoints 
fail to do that, then you're right that this could be a problem.

Paul

---

From: Emil Ivov <[email-masked]>
Date: Wed, 25 May 2016 13:23:43 -0500

Paul,

I have answered your points below but we did gloss over the suggestion I 
made and I consider it important:

We can allow SSRC rewriting and make it negotiable by signalling. This 
way SFUs can state they support rewriting/immutability/both and 
endpoints can choose to use what's available or reject the session as 
unsupported.

I believe this should address the concerns that have been expressed so far.

Now for the rest of the points:

On 25.05.16 г. 7:22, Paul E. Jones wrote:
>> that has to be signalled so clients can choose whether to support it
>> or not. This should address your concern.
>

The SFU has everytihng to do with the E2E collision problem and it's 
potential solutions. What you describe is one way to handle things. 
Another one would be to just make SSRC conflicts obvious to senders so 
that they would apply 3550 resolution. That's pretty easy to implement.

> nonetheless SRTP.

Exactly! And two passes of SRTP happen to NOT be SRTP as in: no stock 
SRTP endpoint would do anything meaningful with them. So what you are 
looking is to just optimize implementations, which is relevant but not 
the primary concern.

> What PERC is adding are some additional steps between

Again, 3711 applies to HBH. We are trying to reuse as much of it for E2E 
as possible and that's admirable but it's not a reason why we should 
significantly disrupt existing implementations.

> libtary once to encrypt HBH.

You mean E2E here.

>  It then does whatever FEC processing it

I still fail to see how FEC changes any of this (for better or worse). 
The problem you describe here is exactly the same with or without FEC 
and it's what we are having the argument about.

> to RFC 3711)

:) ... It is NOT in contradiction with 3711 because layers of 
encryptions are not part of 3711. We simply need to set the expectations 
right for implementers.

>  to identify the crypto context, then we would need to pass
> A beautiful thing about SRTP today

You mean PERC here and not SRTP (even if PERC does simply apply a second 
srtp unprotect it is still not stock 3711).

> is the library can operate on streams

So we have an aesthetic concern because we have to change int-s to 
long-s and that's why we are having a 100 mail thread. I am speechless.

>> As I said, being able to reuse SRTP libraries with no change is a
>> great optimization if we get it but I really don't think the
>> alternative is anywhere near the complexity that would justify banning
>> SSRC re-writing.
>

Let's be clear on this. There is absolutely nothing wrong or standard 
breaking in the way browsers handle simulcast reception today. They are 
simply not simulcast aware and the SFU hides it from them.

There is no reason why that would be labelled a bad practice even when 
RID does go through all of the IETF process.

Also, the availability of this option (simulcast unaware receivers) and 
its existence today make the motivation for RID support on the receiving 
end pretty low. It does not give you anything extra in terms of 
functionality. There are no substantial benefits from doing it (and no 
it doesn't allow for significantly simpler SFUs ... those would still 
have to keep 95% of their existing logic). We can decide to make PERC 
dependent on it and hope that this would sway all browser vendors ... or 
we could also try to lower the burden on PERC adoption.

Again, as stated in the beginning of this mail: it sounds like a 
compromise may lie in the option for PERC to allow an SSRC rewriting 
mode combined with the option for endpoints to not support it. In other 
words we can have part of the PERC signalling indicate whether the 
client and the server support these modes and whether they use them. 
This is not beautiful (by any means) but it wouldn't prevent either of 
us to do things their way.

Emil
-- 
https://jitsi.org

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 25 May 2016 20:20:19 +0000

Emil,

You are saying that endpoints would negotiate via signaling which SSRC 
value(s) to use before actually joining the conference?

That doesn't strike me as terribly appealing, honestly.  Between that 
and the pain of dealing with conflicting SSRCs, I might favor the 
latter.  What I'd prefer most, though, is neither and just let endpoints 
do their thing.

I'd still like to hear confirmation that receiving browsers will 
definitely be doing the right thing w.r.t. receiving simulcast streams.  
Adam seemed to suggest Firefox will be doing the right thing (probably 
before PERC is done). What about popular browsers?

Paul

------ Original Message ------
From: "Emil Ivov" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>
Cc: "Adam Roach" <[email-masked]>; "Cullen Jennings" <[email-masked]>; 
[email-masked]
Sent: 5/25/2016 2:23:43 PM
Subject: Re: [Perc] Request for decision review

>Paul,
>
>I have answered your points below but we did gloss over the suggestion 
>I made and I consider it important:
>
>Again, 3711 applies to HBH. We are trying to reuse as much of it for 
>E2E as possible and that's admirable but it's not a reason why we 
>should significantly disrupt existing implementations.
>
>>>>Further, if we
>encryptions are not part of 3711. We simply need to set the 
>expectations right for implementers.
>
>You mean PERC here and not SRTP (even if PERC does simply apply a 
>second srtp unprotect it is still not stock 3711).
>
>its existence today make the motivation for RID support on the 
>receiving end pretty low. It does not give you anything extra in terms 
>of functionality. There are no substantial benefits from doing it (and 
>no it doesn't allow for significantly simpler SFUs ... those would 
>still have to keep 95% of their existing logic). We can decide to make 
>PERC dependent on it and hope that this would sway all browser vendors 
>... or we could also try to lower the burden on PERC adoption.
>
>-- https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Wed, 25 May 2016 15:43:47 -0500

> value(s) to use before actually joining the conference?

It's awesome how you would always attribute to me the least appealing of 
all possible interpretations :).

Whether or not we negotiate SSRCs should not be within PERC's scope. For 
the record this is how WebRTC works anyway (courtesy of some of the 
people on this list) but the matter is completely orthogonal to PERC.

What I was suggesting is the possibility for PERC endpoints and MDD to 
negotiate whether or not they will be dealing with a single end-to-end 
SSRC space, or whether they will have separate HBH and E2E SSRC spaces.

This way you get to only implement the single end-to-end option in your 
endpoints and to not support the other one.

Does this make more sense?

> before PERC is done). What about popular browsers?

I think at this point the answers that I've heard are for both browsers: 
we are not doing this now. it's not part of webrtc 1.0. we'd like to do 
it in the future.

What I'd like to avoid is PERC having a firm dependence on this last 
statement and for it to only be usable when it comes true.

Emil

>> breaking in the way browsers handle simulcast reception today. They
>> are simply not simulcast aware and the SFU hides it from them.
>>
>> Also, the availability of this option (simulcast unaware receivers)
>> and its existence today make the motivation for RID support on the
>> mode combined with the option for endpoints to not support it. In
>> other words we can have part of the PERC signalling indicate whether
>> the client and the server support these modes and whether they use
>> them. This is not beautiful (by any means) but it wouldn't prevent
>> either of us to do things their way.
>>
>> Emil
>> -- https://jitsi.org
>
>

-- 
https://jitsi.org

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 25 May 2016 14:24:19 -0700

On Wed, May 25, 2016 at 1:43 PM, Emil Ivov <[email-masked]> wrote:

> the record this is how WebRTC works anyway (courtesy of some of the people
> on this list) but the matter is completely orthogonal to PERC.
>
> negotiate whether or not they will be dealing with a single end-to-end SSRC
> space, or whether they will have separate HBH and E2E SSRC spaces.
>
> we are not doing this now.

As far as Firefox goes, we're not doing this now because PERC isn't ready.
We're looking at it soon and plan to try to implement it pretty much as
soon as it's baked enough to do.

it's not part of webrtc 1.0.

Is it even something that could be in WebRTC 1.0? I.e., does it require
changes?

> we'd like to do it in the future.
>

Yes.

-Ekr

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 25 May 2016 23:47:02 +0200

Emil,

I want trying to attribute anything negative to you, just like I didn't mean to smack the Mozilla folks in the face with my "what about popular browsers" question that should have had "other" stuck in there. :)

So negotiate a single E2E space doesn't sound helpful if the other negotiated result still leaves the other option where it changes. Multiple options just leads to the same or higher complexity.

Maybe we should make this decision once we have a better feel for the browser behavior?

Paul

-------- Original Message --------
From: Emil Ivov <[email-masked]>
Sent: May 25, 2016 10:43:47 PM GMT+02:00
To: "Paul E. Jones" <[email-masked]>
Cc: Adam Roach <[email-masked]>, Cullen Jennings <[email-masked]>, [email-masked]
Subject: Re: [Perc] Request for decision review

Emil

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Wed, 25 May 2016 18:04:46 -0500

On Wednesday, 25 May 2016, Paul E. Jones <[email-masked]> wrote:

> Emil,
>
> I want trying to attribute anything negative to you, just like I didn't
> mean to smack the Mozilla folks in the face with my "what about popular
> browsers" question that should have had "other" stuck in there. :)
>
> So negotiate a single E2E space doesn't sound helpful if the other
> negotiated result still leaves the other option where it changes. Multiple
> options just leads to the same or higher complexity.
>

The option would be for a client to refuse to participate in a conference
where an E2E SSRC space cannot be guaranteed. This means that your
endpoints will be able to work with MDDs that are implemented the
(according to you) right way and would be able to safely reject all others.

Emil

> ------------------------------
> *From:* Emil Ivov <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> *Sent:* May 25, 2016 10:43:47 PM GMT+02:00
> *To:* "Paul E. Jones" <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> *Cc:* Adam Roach <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>, Cullen Jennings <
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>,
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> This way you get to !
>  only
> implement the single end-to-end option in your
> it in the
> future.
>>  From: "Emil Ivov" <[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>>  To: "Paul E. Jones" <[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>>  Cc: "Adam Roach" <[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>; "Cullen Jennings" <[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>;
>>  [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>>>  We can allow SSRC rewriting and make it negotiable by signalli!
>>>  ng.
>>> This
>>>>>  As I have been insisting many times already: We have the!
>>>>>   option
>>>>> to
>>>  that they would apply !
>>>  3550
>>> resolution. That's pretty easy to implement.
>>>
>>>  SR!
>>>  TP
>>> endpoint would do anything meaningful with them. So what you are
>>>>>  after E2E and before HBH as that way the SFU would be abl!
>>>>>  e to de-
>>>>> or
>>>>>  re-FEC.
>>>>>
>>>>
>>>>  allow the SRTP(E2E)+FEC+SRTP(HBH) option fo!
>>>>  r FEC
>>>> order, then when the
>>>>  this using two instance!
>>>>  s of an
>>>> SRTP library today.  If a single library
>>>  If we t!
>>>>  ake the
>>>> approach of using a 64-bit identifier (in contradiction
>>>>  to RFC 3711)
>>>>
>>>
>>>>  A beautiful thing about SRTP today!
>>>>
>>>>
>>>
>>>  Cullen which, as I understand, is an expression of a conc!
>>>  ern
>>> that
>>  and its existence today ma!
>>  ke the
>> motivation for RID support on the
>>  Emil --https://jitsi.org

-- 
sent from my mobile

---

From: Emil Ivov <[email-masked]>
Date: Wed, 25 May 2016 18:12:31 -0500

On Wednesday, 25 May 2016, Eric Rescorla <[email-masked]> wrote:

>
>
> On Wed, May 25, 2016 at 1:43 PM, Emil Ivov <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>>
>>

So you are saying that simulcast itself is not a good enough reason to
implement  receiver-side simulcast support ... but a minor optimization
to PERC is ...

Obviously I don't need to be explained the reasoning. I am glad you have
this plan.

I only wish we would have a clearer view of everyone's intended delivery
dates since we are about to block PERC on them.

> Is it even something that could be in WebRTC 1.0? I.e., does it require

How would you tell FF what group an RID corresponds to?

Emil

>>> From: "Emil Ivov" <[email-masked]
>>> To: "Paul E. Jones" <[email-masked]
>>> Cc: "Adam Roach" <[email-masked]
>>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>; "Cullen Jennings" <
>>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>;
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

-- 
sent from my mobile