Subject: Re: [Perc] Minutes from Design Team call #3

From: Emil Ivov <[email-masked]>
Date: Tue, 10 May 2016 10:42:28 -0500

Hey all,

I was trying to get myself updated on PERC's status and stumbled upon
these. Specifically, I was very surprised to find out that SSRCs have
again become immutable ...

There was abundant feedback on this list from implementers stating
this would make PERC particularly inconvenient to support by today's
SFUs.

Could someone please tell me how I am completely misreading everything
and that it's all a misunderstanding on my side?

Thanks,
Emil

On Wed, Dec 2, 2015 at 5:36 PM, Richard Barnes <[email-masked]> wrote:
> Hey all,
>
> Please find below the chairs' notes from the design team call we had on Monday.
>
> --Richard
>
>
> PERC Design Team Call #3
>
> # Chairs introduction
>
> * Future calls will follow Virtual Interim process
> * This call is focused on figuring out what capabilities the MDD needs
> to modify header fields
>
>
> # Discussion of Header Fields
>
> Summary of conclusions on call:
>
>   Field       Can be modified?    Send original?
>   V               No                   ---
>   X               Yes            Maybe (see extn)
>   M               No                   ---
>   PT              Yes                  Yes
>   SEQ             Yes                  Yes
>   Timestamp       No                   ---
>   SSRC            No                   ---
>   CSRC/CC         No                   ---
>   Extension       Yes                  TBD
>
> ---
>
> V - MDD MUST NOT change
>
> P - MDD MUST NOT change
>
> X - MDD needs to be able to change
>     -- Original value may be necessary for E2E integrity-protected extns
>
> M - MDD MUST NOT change
>     -- M is used to signal to endpoints to reset jitter buffers
>     -- ... but it's tied to SSRC, so switching SSRC could be the signal
>     -- Might need to document how this relates to SSRC / source indication
>
> PT - MDD needs to be able to change
>    -- MDD can always trash the conference
>    -- needs changing to match PTs across individual sessions
>    -- Security considerations about malicious PT changes
>    -- No immediate need for the original value at the receiver
>    -- ... but we should keep the option open
>
> SEQ - MDD needs to be able to change
>
> -- For, e.g., consistent loss detection with stream on/off behavior
>
> -- Different from network attacker b/c long silences are normal
>
> -- Replay attacks might need extra mechanism
>
> -- e.g., authenticated ROC in EKT
>
> -- Delay attack might be better handled with timestamp / RTCP
>
> -- Original value needed at the endpoint
>
>
> Timestamp - MDD MUST NOT change
>
> -- MDD might want to change if MSM are used
>
> -- No MSM , no need to fudge the timespatmp
>
> -- When changed needs to preserve the original value
>
> -- No need to change if SSRC is immutable
>
>
> SSRC - MDD MUST NOT change
>
> -- Splicing attack - needs source to be verified ?
>
> -- Need higher level layer to ensure SSRCs are end to end
> authenticated somehow [[ or otherwise have the right properties ]]
>
> -- Might need to come back and make it mutable later
>
> -- Need to better express to the list why this design is simpler (Magnus/Adam)
>
> -- Might be making some topologies incompatible with this decision
>
> -- ... and we should be explicit about this
>
>
> CSRC - MDD MUST NOT change
>
> -- ... and by implication, CSRC Count (CC)
>
>
> Header Extensions
>
> -- ID values behave similar to PT (signaling based assignment)
>
> -- ... so MDD might need to align them
>
> -- Needs more discussion of how
>
> -- RFC5450
>
> -- MDD MUST NOT change
>
> -- Not used widely today and might not be in future (ref RMCAT )
>
> -- RFC6051
>
> -- MDD MUST NOT change, might need more discussions
>
> -- no timestamp rewriting implies no changing of this value
>
> -- Tied to E2E RTCP decision
>
> -- RFC6464
>
> -- removing or not removing might not matter
>
> -- b/w might force to remove but having it allows end-point to verify
> the authenticity of source reporting its audio level
>
> --  RFC6465
>
> -- MDD MUST NOT Modify
>
> --  Encrypted or not ( needs more discussion for all the audio
> levels). Use HBH as the baseline to drive these discussions.
>
> -- CVO
>
> -- MUST NOT MODIFY
>
> -- [[ Ran out of time here ]]
>
>
> Path Forward:
>
> -- Work through existing extensions to see what capabilities are needed
>
> -- Write protocol mechanism for capabilities, handling guidlines per header
>
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc

-- 
https://jitsi.org

---

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

Inconvenient is an understatement. Even the most basic SFU scenarios (like simulcast) require SSRC modification. 

> On May 10, 2016, at 8:42 AM, Emil Ivov <[email-masked]> wrote:
> 
> Hey all,
>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 10 May 2016 10:02:10 -0600

Yes, that topic was extensively discussed on the calls. One of the issue was questions on how RTCP would work. Other issues were along lines of how receiver would know what key to use. There was also the splicing attack. It's worth noting that endpoints can change SSRC at along the way, it's just the MDD that can not change them. 

> On May 10, 2016, at 9:42 AM, Emil Ivov <[email-masked]> wrote:
> 
> Hey all,
>

---

From: Emil Ivov <[email-masked]>
Date: Tue, 10 May 2016 14:21:33 -0500

I don't get it. PERC is the new thing and I assume adoption is, at
least to some extent, an objective for the WG.

If PERC needs an identifier with constraints that are incompatible
with common practices, then PERC should simply define a new id with
the behaviour, color, shape and smell that please PERC. It would then
add that to RTP and RTCP and do whatever it pleases with it. It can be
a copy of the original SSRC, it could only look like it or it could be
something entirely different, whatever works.

The point is: PERC should take the real world into account because the
opposite is likely not going to work in PERC's favor.

Has that option been considered and rejected? Are the reasons recorded
anywhere or can we discuss them here?

Emil

-- 
https://jitsi.org

---

From: Luis Lopez <[email-masked]>
Date: Tue, 10 May 2016 21:49:26 +0200

Hi,

I already provided my vision as an SFU implementor some months ago but I would like to stress it again: I’m with Emil. Avoiding SSRC re-writing will significantly decrease the impact of PERC in the implementors community as we’ll need to drop in the trash most of our previous code and mechanism for managing lots of features including simulcast, voice-power-based switching and many others. Probably I’m missing something, but the arguments I’ve seen in favor of inmutable SSRCs do not, IMO, justify a decision with such relevant implications in implementations.

Best regards.

L.

> El 10 may 2016, a las 21:21, Emil Ivov <[email-masked]> escribió:
>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 10 May 2016 16:04:00 -0700

I agree. Without SSRC rewriting PERC does not apply to any real world conferencing scenarios. 

But since the proposed key management scheme has similar security properties to SRTP/SDES, that might be just as well.

> On May 10, 2016, at 12:49 PM, Luis Lopez <[email-masked]> wrote:
> 
> Hi,
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 11 May 2016 07:47:24 +0200

On Wed, May 11, 2016 at 1:04 AM, Bernard Aboba <[email-masked]>
wrote:

> But since the proposed key management scheme has similar security
> properties to SRTP/SDES, that might be just as well.
>

Hmm... Unless I've badly misanalyzed it, this is not correct. While the
scheme does permit one side to dictate the keys, they are not available to
a passive signaling server. What have I misunderstood?

-Ekr

> > I already provided my vision as an SFU implementor some months ago but I
> would like to stress it again: I’m with Emil. Avoiding SSRC re-writing will
> significantly decrease the impact of PERC in the implementors community as
> we’ll need to drop in the trash most of our previous code and mechanism for
> managing lots of features including simulcast, voice-power-based switching
> and many others. Probably I’m missing something, but the arguments I’ve
> seen in favor of inmutable SSRCs do not, IMO, justify a decision with such
> relevant implications in implementations.
> >
> > Best regards.
> >
> > L.
> >
> >>> Yes, that topic was extensively discussed on the calls. One of the
> issue was questions on how RTCP would work. Other issues were along lines
> of how receiver would know what key to use. There was also the splicing
> attack. It's worth noting that endpoints can change SSRC at along the way,
> it's just the MDD that can not change them.
> >>>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 11 May 2016 00:52:48 -0700

On May 10, 2016, at 10:47 PM, Eric Rescorla <[email-masked]> wrote:
> 
>> On Wed, May 11, 2016 at 1:04 AM, Bernard Aboba <[email-masked]> wrote:
> Hmm... Unless I've badly misanalyzed it, this is not correct. While the scheme does permit one side to dictate the keys, they are not available to

[BA] The proposed hop by hop key sharing between the KMF and MDD is not more secure than an SRTP/SDES exchange between the same parties, since in both cases a key that was formerly known only by 2 parties with DTLS/STTP is now possessed by 3 parties instead. 

This enables governments to request hop-by-hop keying material from endpoints, the KMF or MDD owners rather than merely from the endpoints and MDD, creating more risk particularly when the KMF and MDD are located in different countries. Also, since the KMF possesses e2e keys both the KMF and endpoint owners are now potential targets for key disclosure requests.  While PERC is focusing on media confidentiality, in surveillance scenarios meta-data disclosure is as valuable as decrypting media - and PERC could increase those risks.

For small groups an e2e key exchange would be preferred so that e2e keys were held only in endpoints which neither a KMF nor MDD could possess.  It also would be preferred for endpoint - MDD hop-by-hop keys to be known only by those parties.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 11 May 2016 10:07:09 +0200

On Wed, May 11, 2016 at 9:52 AM, Bernard Aboba <[email-masked]>
wrote:

> [BA] The proposed hop by hop key sharing between the KMF and MDD is not
> more secure than an SRTP/SDES exchange between the same parties, since in
> both cases a key that was formerly known only by 2 parties with DTLS/STTP
> is now possessed by 3 parties instead.
>

But the hop-by-hop keys are not sufficient to recover the communications
traffic. Only the end-to-end keys are sufficient for that. That's the point
of the design. It's true that the KMF has the keys and that's one of the
reasons why it's desirable to have one of the endpoints be the KMF.

This enables governments to request hop-by-hop keying material from
> endpoints, the KMF or MDD owners rather than merely from the endpoints and
> MDD, creating more risk particularly when the KMF and MDD are located in
> different countries.
>

But again, the hop-by-hop keys are not very useful

For small groups an e2e key exchange would be preferred so that e2e keys
> were held only in endpoints which neither a KMF nor MDD could possess.
>

Yes, I agree. Unfortunately, this is a much larger change to the protocols
and endpoints.

In any case, I don't think the security properties are comparable to SDES.

-Ekr

>  It also would be preferred for endpoint - MDD hop-by-hop keys to be known
> only by those parties.
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 11 May 2016 14:56:22 -0600

> On May 10, 2016, at 5:04 PM, Bernard Aboba <[email-masked]> wrote:
> 

Could you please provide details of exactly what you mean here?

---

From: Emil Ivov <[email-masked]>
Date: Wed, 11 May 2016 17:01:21 -0500

> Could you please provide details of exactly what you mean here?

I saw a bunch of exact scenarios mentioned here. Things like simulcast
and active speaker switching for example have numerous popular
implementations through SSRC rewriting. Those include implementations
from Kurento, Google, Microsoft, Janus, Jitsi and likely many others.

Unless we are explicitly trying to sabotage PERC adoption by all of
those, I cannot for the life of me understand why we are so stuck on
forbidding rewriting SSRCs. I never saw a satisfactory answer on the
subject. The answers that I heard were basically:

A) Because otherwise that scr*ws up authentication because we cannot
keep track of the overwrites across RTP and RTCP: obviously this is
not true as we could simply not use SSRCs for PERC-specific purposes
and define PERC specific IDs
and
B) You are not correct and I, who have never implemented an SFU in my
life, am telling you that you can reimplement your SFU to not rely on
SSRC rewriting and it will be a piece of cake. I hope I don't have to
comment on B.

As an IETF WG, PERC's behaviour on this topic has been very confusing
to me and I am almost at the point where willful disruption is the
only possible explanation that I can find. If we do proceed to ignore
implementers the same way we are going to find ourselves debating the
same concerns in IETF last call where reason would have a better
chance of prevailing.

E2E encryption is too important of a subject for us to botch this work.

Emil

-- 
https://jitsi.org

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 11 May 2016 23:12:33 +0000

Emil,

>and define PERC specific IDs

I'm not following that one.  RTCP is HBH, so not an issue.  Why would we 
need a PERC-specific ID?  I assume this is as an alternative to the SSRC 
in the cryptographic context?  We would not need that given "double" 
defined a field that could record the original E2E SSRC value.  (Yes 
that is now removed, but see below.)

>SSRC rewriting and it will be a piece of cake. I hope I don't have to

It is indeed a fact that you can write a switching function that does 
not require changing SSRCs.

>same concerns in IETF last call where reason would have a better

I think the issue is this: you've not attended the meetings.  We had 
accommodated the option to change nearly everything in the RTP header 
via the OHB in "double".  During a recent meeting, it was decided to 
limit the scope of what can be changed.  We made the original "double" 
proposal to allow for anything to be changed 
(https://tools.ietf.org/html/draft-jennings-perc-double-00) and 
participants in the meeting said to reduce the possible set down to PT 
and sequence number, so we produced 
https://tools.ietf.org/html/draft-jennings-perc-double-01 accordingly.  
This change was proposed in a conference call, if I recall, and then 
discussed face-to-face before the document moved forward to WG adoption.

I do not recall any person on a phone call or in the meeting room who 
opposed the changes.  It came as a pleasant surprise to the authors that 
everyone was agreeable to such a narrow set of fields that could be 
changed.

Can we support changing SSRCs?  Yes, we can put it back in.  We will 
need to change the way we have the OHB encoded, but it's certainly 
possible.

>E2E encryption is too important of a subject for us to botch this work.

I can only encourage you to participate in meetings when they're called 
and to comment on drafts as they're published.  Heck, even if you cannot 
make a face-to-face meeting, the -01 draft has been out there since 
March 21 and nobody commented on that change until this week.

Paul

---

From: "David Benham (dbenham)" <[email-masked]>
Date: Thu, 12 May 2016 01:39:28 +0000

[dbenham>]   If a Gov can successfully compel an org with access to KMF to cough up key info, that Gov can also compel that org to entitle the Gov's recording devices to be valid endpoints in any of that org's conferences.  Thus that Gov can listen in to any conference regardless of which entity is handing out HBH info.  

[dbenham>]   This is already true with what is proposed in the drafts.  PERC endpoints choose their own E2E media keys and send that key info to the other endpoints in the conference by encrypting it with the E2E KEK (aka EKT_Key assigned by the KMF).   Neither the KMF or MDD have the E2E media keys used by endpoints, period.

---

From: Luis Lopez <[email-masked]>
Date: Thu, 12 May 2016 10:22:18 +0200

Hi Paul,

Could you develop on this?
> 
> It is indeed a fact that you can write a switching function that does not require changing SSRCs.

I’m very interested in figuring out know to support features such as simulcast or active speakers switching in an SFU without SSRC rewriting? I your plan is to negotiate a bunch of SSRCs per participant and just switch on/off each of them when appropriate, I’m afraid this will not work.

Best regards.

L.

---

From: Emil Ivov <[email-masked]>
Date: Thu, 12 May 2016 08:23:52 -0500

Hey Paul

On Wed, May 11, 2016 at 6:12 PM, Paul E. Jones <[email-masked]> wrote:
> need a PERC-specific ID?

My point is that if you need an immutable ID then you can define your
own. As I already stated in this thread: that new ID can be a copy of
the original SSRC or something new: whatever works.

> I assume this is as an alternative to the SSRC in
> the cryptographic context?  We would not need that given "double" defined a
> field that could record the original E2E SSRC value.  (Yes that is now
> removed, but see below.)
>

Yes you can do that. You can also travel from Paris to London via
Sydney: few people are making that choice though. All SFUs I am aware
of overwrite SSRCs even if the one that you wrote might have taken a
different path.

> accommodated the option to change nearly everything in the RTP header via
> the OHB in "double".  During a recent meeting, it was decided to limit the
> scope of what can be changed.  We made the original "double" proposal to
> allow for anything to be changed
> (https://tools.ietf.org/html/draft-jennings-perc-double-00) and participants
> in the meeting said to reduce the possible set down to PT and sequence
> number, so we produced
> https://tools.ietf.org/html/draft-jennings-perc-double-01 accordingly.  This
> change was proposed in a conference call, if I recall, and then discussed
> face-to-face before the document moved forward to WG adoption.
>
> everyone was agreeable to such a narrow set of fields that could be changed.

I am stunned!

Paul, we first had this very conversation five months ago:

https://www.ietf.org/mail-archive/web/perc/current/msg00136.html

Numerous implementors commented here. This should have been the end of it.

then a bit later I raised it again here:

https://www.ietf.org/mail-archive/web/perc/current/msg00222.html

Now this.

So are you now saying: "well Emil the issue is that you are not
present on all meetings so every time we try to sneak this back in,
you are not there to stop us and that's your problem!"

> Can we support changing SSRCs?  Yes, we can put it back in.  We will need to
> change the way we have the OHB encoded, but it's certainly possible.
>
> I can only encourage you to participate in meetings when they're called and
> to comment on drafts as they're published.  Heck, even if you cannot make a
> face-to-face meeting, the -01 draft has been out there since March 21 and
> nobody commented on that change until this week.

It is one thing to encourage involvement when new decisions are being
made. I support this and we are all doing our best.

It is a completely different thing to require participation so that
the same points can be made over and over and over again.

Emil

-- 
https://jitsi.org

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 12 May 2016 10:41:08 -0600

> On May 11, 2016, at 4:01 PM, Emil Ivov <[email-masked]> wrote:
> 

Emil, I have designed and implemented multiple SFU products over the years (first one in 2004) including ones that use SSM multicast which make things much more complicated. When I read someone say that they would have to rewrite all their code if the identifier they changed was inside a RTP header instead of being in the SSRC, I feel like it might be a lot less work that rewriting all the code. It's not that much difference if you move where in the RTP packet you grab the identifier that you are changing. 

So help folks understand here, how do all theses system that do SSRC rewrite deal with RTCP?  

> to me

So in fairness here ... 

The WG talked a bunch about this last summer and fall. 

In October Magnus and others wrote draft-westerlund-perc-rtp-field-considerations with a section on SSRC and I and other wrote draft-jennings-perc-double-00 which allowed SSRC to change. 

We have had several meetings since then and two IETF where those documents were discussed as they evolved and people argued for what they are now. In Nov you said that you had tried to to a non SSRC changing implementation but it did not work well but never provided any technical details on what did or did not work. I'm not going to try and update you on everything that happened on theses meeting but as a practical matter I think the things that would be most helpful to me at this point would be 

1) how you deal with RTCP when the MMD changes the SSRC
2) why changing SSRC worked out better than not for interop with endpoints

> and I am almost at the point where willful disruption is the

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 12 May 2016 10:51:52 -0600

> On May 12, 2016, at 2:22 AM, Luis Lopez <[email-masked]> wrote:
> 
> Hi Paul,
> 

I don't think I know what you mean  by negotiate SSRC? Most uses of SIP don't even pass the SSRC in the SDP.  Allowing the RTP sender to arbitrarily change the SSRC is a pretty core port of RTP so if that is not working it sounds like a pretty broken receiver.

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 13 May 2016 00:57:10 +0000

Luis,

>I’m very interested in figuring out know to support features such as 
>simulcast or active speakers switching in an SFU without SSRC 
>rewriting? I your plan is to negotiate a bunch of SSRCs per participant 
>and just switch on/off each of them when appropriate, I’m afraid this 
>will not work.

I think it's important to mindful of the fact that PERC does not define 
every aspect of the system, but will instead rely on the work performed 
in other IETF WGs.  Active Speaker switching is one example. The MDD 
might use audio levels indicated in RTP headers (RFC 6464), for example. 
  Whatever method is employed, the MDD cannot rely on what is observed in 
the media payload, since that will be encrypted.  And when it switches 
based on audio levels, it would be really nice if it also switched the 
related video flow of the active speaker when the first I-frame is 
received.  Again, this is where we rely on work on other WGs (e.g., 
draft-ietf-avtext-framemarking).  We might not want to be concrete in 
specifying the use of RFC 6464, either.  Consider a conference with only 
deaf participants.  Maybe we want a different mechanism for such 
conferences, but it's certainly not this group that should decide how 
that works.

There is a need to be able to associate audio with video flows, and for 
simulcast we have the additional need to be able to identify the 
alternative simulcast flows.  For that, we have tools like 
draft-ietf-mmusic-sdp-simulcast, MID (RFC 5888), and RID 
(draft-ietf-avtext-rid and draft-ietf-mmusic-rid).  Where we identify a 
need, we can address those in the appropriate working group.  However, 
PERC is not the place to solve every challenge related to conferencing.

I would not recommend negotiating a bunch of SSRCs, as I'd prefer to 
just utilize what's defined in RFC 3550 and allow normal collision 
detection procedures to be followed.  Since we are using EKT, we are not 
at risk of the "one-time pad" problem defined in RFC 3711, thus 
collisions will not introduce security vulnerabilities.  Mechanisms like 
RTCP and SDES carried in RTP (draft-ietf-avtext-sdes-hdr-ext) are 
sufficient for conveying information (with the latter being end-to-end 
secure), though we might find the need to enhance those tools.  Again 
though, many of the other elements we might need are really outside the 
scope of PERC and  we should actively contribute to that work where we 
identify something that might make PERC work better.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 13 May 2016 02:27:30 +0000

Emil,

>the original SSRC or something new: whatever works.

We do not really need an identifier, except to address the one security 
issue raised here:
https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01#section-7.2.4

With the agreement reached (after a lot of discussion) back in December 
not to change the SSRC, this issue no longer exists.

>of overwrite SSRCs even if the one that you wrote might have taken a

I'm scratching my head on this. ISTM that remapping SSRC is the longer 
path from Paris to London. I appreciate that you might not have seen all 
of the products on the market; there certainly are some that do not 
rewrite SSRCs.  So, I am curious why you cannot build a system that just 
leaves the SSRCs alone.

>>via
>>participants

Yes, I recall the older conversation and, in fact, we had it in our 
draft to allow the SSRC to change.  However, the decision to not modify 
the SSRC followed email exchange and the decision has been in place 
since at least early December.

>https://www.ietf.org/mail-archive/web/perc/current/msg00222.html

Yes, at the time it was an active topic of discussion.  The decision was 
made, minutes reported, documents updated, etc.  I think it is the rest 
of us who were participating in the meetings who should be stunned at 
this issue being raised again.

>you are not there to stop us and that's your problem!"

No, I don't expect anyone to be at every meeting.  However, you do need 
to appreciate that the decision is now 5 months old the group has 
long-since considered this issue closed.

>>need to

I think you're mis-characterizing the events.  The SSRC issue was an 
active topic of discussion back in November / December.  We had to 
settle how we were going to deal with every header field and Magnus led 
that dialog taking us through a couple of hours of discussion as we went 
through each and every header value.  That meeting was held on November 
30 and a recording for that meeting posted to the list:
https://cisco.webex.com/ciscosales/lsr.php?RCID=2684921e717d4b45aadb88d9a8774ce5

The SSRC dialog was at 1:01:43 and we talked about it for about 20 
minutes.  I think it might be worth your time to review that.  Maybe you 
have a valid point not raised by others in the meeting, but I really 
think it's unfortunate that you re-raise this issue after we revised the 
drafts and went through another IETF meeting where the group adopted 
text based on this decision.

Paul

---

From: Emil Ivov <[email-masked]>
Date: Fri, 13 May 2016 11:42:36 -0500

On 12.05.16 г. 11:41, Cullen Jennings wrote:
>> I saw a bunch of exact scenarios mentioned here. Things like
>> simulcast and active speaker switching for example have numerous
>> popular implementations through SSRC rewriting. Those include
>> implementations from Kurento, Google, Microsoft, Janus, Jitsi and
>> likely many others.
>>
>> Unless we are explicitly trying to sabotage PERC adoption by all
>> of those, I cannot for the life of me understand why we are so
>> stuck on forbidding rewriting SSRCs. I never saw a satisfactory
>> answer on the subject. The answers that I heard were basically:
>>
>> A) Because otherwise that scr*ws up authentication because we
>> cannot keep track of the overwrites across RTP and RTCP: obviously
>> this is not true as we could simply not use SSRCs for PERC-specific
>> purposes and define PERC specific IDs and B) You are not correct
>> and I, who have never implemented an SFU in my life, am telling you
>> that you can reimplement your SFU to not rely on SSRC rewriting and
>> it will be a piece of cake. I hope I don't have to comment on B.
>
>
> Emil, I have designed and implemented multiple SFU products over the
> years (first one in 2004) including ones that use SSM multicast which
> make things much more complicated. When I read someone say that they
> would have to rewrite all their code if the identifier they changed
> was inside a RTP header instead of being in the SSRC, I feel like it
> might be a lot less work that rewriting all the code. It's not that
> much difference if you move where in the RTP packet you grab the
> identifier that you are changing.

It is. Now what you say may be true when you only care about a handful 
of endpoints that you control. The situation with WebRTC is 
significantly more complex though, because of all the dynamics. There 
are a bunch of endpoint implementations some in big organisations with 
complex priorities. While they would all acknowledge privacy is 
important, I don't think PERC would score very high on their priority 
lists because things related to easily perceptible user experience would 
beat it any day of the week.

This however, is not the most important point of this debate.

> So help folks understand here, how do all theses system that do SSRC

We terminate it. All of it.

>> As an IETF WG, PERC's behaviour on this topic has been very
>> confusing to me
>
> So in fairness here ...
>
> In October Magnus and others wrote
> draft-westerlund-perc-rtp-field-considerations with a section on SSRC
> and I and other wrote draft-jennings-perc-double-00 which allowed
> SSRC to change.
>
> We have had several meetings since then and two IETF where those
> documents were discussed as they evolved and people argued for what
> they are now. In Nov you said that you had tried to to a non SSRC
> changing implementation but it did not work wellbut never provided
> any technical details on what did or did not work.

I believe I did though. The problems with making SSRCs visible to the 
endpoints is that it requires the endpoints to switch between streams 
themselves.

This is pretty much a lost cause with WebRTC because the JS app has too 
little information to do that in a quick and stable way. It also 
requires WebRTC endpoints to reimplement that same switching code across 
platforms (i.e. write a Java impl on Android and an iOS/swift one for iOS).

Now, I somehow feel that someone is ready to jump and say: "yeah, but 
that's because your browsers were using non-standard offer/answer and it 
all would have been peachy if they did".

The first part of that statement would be sort of true (although it is 
hardly a cause a cause for the problem ... this is more related to use 
of RID than the offer/answer semantics). The second part is 
non-verifiable and I am very sceptical that it would be in the near 
future. It would basically mean that browsers have to completely change 
the way they feed packets to all their CC engines and decoders and make 
them use RIDs instead of SSRCs for all of those.

You are certainly welcome to explain to all these people how you've been 
doing this since 2004 and how they really should roll their sleeves and 
get on top of it because it's super easy ... but until I see it 
happening I would remain highly sceptical that they would.

That again is still not the main point of this debate.

> I'm not going to
> try and update you on everything that happened on theses meeting but
> as a practical matter I think the things that would be most helpful
> to me at this point would be
>

As stated above: all RTCP is terminated at the MMD. It has RTX caches, 
it generates its own SRs and RRs and PLIs and FIRs.

> 2) why
> changing SSRC worked out better than not for interop with endpoints

Explained above.

Now ... the main point of this debate is the following:

We have a bunch of incumbent implementations that are extremely popular 
today, that are being used by hundreds of millions of people and that 
all do things a certain way.

PERC is hoping to gain adoption by all of those.

PERC is new work that is carrying no legacy and is such has significant 
freedom in the design choices it is making.

The main point is therefore that: it doesn't matter exactly how much 
time it takes implementors to rewrite, re-test and re-deploy their 
simulcast implementations. What matters is that this rewrite effort is 
without a doubt bigger than the effort it would take PERC to accomodate 
them and work around SSRC rewriting.

In other words: it *is* all the same to you, so please be nice to us.

Emil

>
>
>> and I am almost at the point where willful disruption is the only
>> possible explanation that I can find. If we do proceed to ignore
>> implementers the same way we are going to find ourselves debating
>> the same concerns in IETF last call where reason would have a
>> better chance of prevailing.
>>
>> -- https://jitsi.org
>> _______________________________________________ Perc mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/perc
>
>

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Fri, 13 May 2016 12:05:18 -0500

Hey Paul,

> not to change the SSRC, this issue no longer exists.

Let's please get that reversed. We need SSRC and seq num rewriting to be 
possible so let's find a different solution to that *one* security issue 
that wouldn't make a bunch of implementers whine on this list every few 
months.

It is not a big deal for this WG's work. It has a huge impact on the 
adoption of that work though.

>>>  It is indeed a fact that you can write a switching function that
>>> does not
>>>  require changing SSRCs.
>>
> path from Paris to London.

You will understand as soon as you try to implement an SFU that works 
well with WebRTC today.

> I appreciate that you might not have seen all
> of the products on the market;

I am pretty sure I know about most of the WebRTC compatible ones.

> there certainly are some that do not
> rewrite SSRCs.

And they, whoever they are, would be just fine if we relaxed the 
requirements on immutable seq nums and SSRCs.

> So, I am curious why you cannot build a system that just
> leaves the SSRCs alone.

I have already built my system. So have Google and Vidyo and Janus and 
Microsoft and Kurento. We are *all* rewriting sequence numbers and SSRCs.

> this issue being raised again.

I cannot believe you are making that point. Did you at any point see any 
of the concerned implementers come back and say: "Oh right! That totally 
makes sense now! Forget about immutable seq nums and SSRCs, we can do 
with out them. Roll on!"

As a responsible document editor, *that* is what you should be looking 
for. Same for all actively participating WG members.

You know me, you know Lorenzo, you know Bernard I assume you also know 
people from the other companies/orgs implementing simulcast through SSRC 
and seq num rewrites.

Did you see them take part of the discussion? Did you take any steps to 
go and check with them?

"You weren't there to complain then, so get lost now" is a pretty bad 
argument and I certainly didn't expect it from someone with your 
experience.

> long-since considered this issue closed.

I fail to see how that is in any way relevant. The concerns were stated 
before the decision was made. The people having made the concerns were 
absent when it was decided to not address them.

This doesn't mean they didn't care. If they didn't they wouldn't have 
stated them. This simply means that they trusted the WG to do the right 
thing.

It did not!

> text based on this decision.

I couldn't agree more. It is very unfortunate and so easily avoidable if 
only steps had been taken to ping the concerned parties.

Now ... can we please stop this arguing and just work around the issue 
with s.num/ssrc rewriting?

Please!

Emil

-- 
https://jitsi.org

---

From: Lorenzo Miniero <[email-masked]>
Date: Fri, 13 May 2016 19:27:45 +0200

On Fri, 13 May 2016 12:05:18 -0500
Emil Ivov <[email-masked]> wrote:

> >>>> cannot keep track of the overwrites across RTP and RTCP:
> >>>> obviously this is not true as we could simply not use SSRCs for
> >>>> PERC-specific purposes and define PERC specific IDs  
> >>>
> >> My point is that if you need an immutable ID then you can define
> >> your own. As I already stated in this thread: that new ID can be a
> >> copy of the original SSRC or something new: whatever works.  
> >
> > We do not really need an identifier, except to address the one
> > security issue raised here:
> > With the agreement reached (after a lot of discussion) back in
> > December not to change the SSRC, this issue no longer exists.  
> 
> Let's please get that reversed. We need SSRC and seq num rewriting to
> be possible so let's find a different solution to that *one* security
> issue that wouldn't make a bunch of implementers whine on this list
> every few months.
> 
> >>>  field that could record the original E2E SSRC value.  (Yes that
> >>> is now removed, but see below.)
> >>>  
> >>>>  B) You are not correct and I, who have never implemented an SFU
> >>>> in my life, am telling you that you can reimplement your SFU to
> >>>> not rely on SSRC rewriting and it will be a piece of cake. I
> >>>> hope I don't have to comment on B.  
> >>>
> >> Sydney: few people are making that choice though. All SFUs I am
> >> aware of overwrite SSRCs even if the one that you wrote might have
> >> taken a different path.  
> >
> > I'm scratching my head on this. ISTM that remapping SSRC is the
> > longer path from Paris to London.  
> 
> I have already built my system. So have Google and Vidyo and Janus
> and Microsoft and Kurento. We are *all* rewriting sequence numbers
> and SSRCs.
> 
> >>>> confusing to me and I am almost at the point where willful
> >>>> disruption is the only possible explanation that I can find. If
> >>>> we do proceed to ignore implementers the same way we are going
> >>>> to find ourselves debating the same concerns in IETF last call
> >>>> where reason would have a better chance of prevailing.  
> >>>
> >>>  I think the issue is this: you've not attended the meetings.  We
> >>> had accommodated the option to change nearly everything in the RTP
> >>> header via
> >>>  in the meeting said to reduce the possible set down to PT and
> >>> sequence number, so we produced
> >>>  I do not recall any person on a phone call or in the meeting
> >>> room who opposed the changes.  It came as a pleasant surprise to
> >>> the authors that
> > draft to allow the SSRC to change.  However, the decision to not
> > modify the SSRC followed email exchange and the decision has been
> > in place since at least early December.
> >  
> > Yes, at the time it was an active topic of discussion.  The
> > decision was made, minutes reported, documents updated, etc.  I
> > think it is the rest of us who were participating in the meetings
> > who should be stunned at this issue being raised again.  
> 
> I cannot believe you are making that point. Did you at any point see
> any of the concerned implementers come back and say: "Oh right! That
> totally makes sense now! Forget about immutable seq nums and SSRCs,
> we can do with out them. Roll on!"
> 
> As a responsible document editor, *that* is what you should be
> looking for. Same for all actively participating WG members.
> 
> You know me, you know Lorenzo, you know Bernard I assume you also
> know people from the other companies/orgs implementing simulcast
> through SSRC and seq num rewrites.
> 
> Did you see them take part of the discussion? Did you take any steps
> to go and check with them?
> 

That's probably needless to say, but I obviously support Emil, Luis and
other implementors on this. Emil has already voiced my concerns much
better than I would have been able to do, so I won't add to that.

What I'd like to highlight, though, is that I certainly don't recall
such a decision being echoed on the ML, as I would expect in the IETF
typically, especially on an aspect that had seen such controversy. Had
this happened, we definitely would have made our point timely again,
and not 5 months later.

Lorenzo

> > No, I don't expect anyone to be at every meeting.  However, you do
> > need to appreciate that the decision is now 5 months old the group
> > has long-since considered this issue closed.  
> 
> I fail to see how that is in any way relevant. The concerns were
> stated before the decision was made. The people having made the
> concerns were absent when it was decided to not address them.
> 
> stated them. This simply means that they trusted the WG to do the
> right thing.
> 
> It did not!
> 
> >> It is one thing to encourage involvement when new decisions are
> >> being made. I support this and we are all doing our best.
> >>
> > settle how we were going to deal with every header field and Magnus
> > led that dialog taking us through a couple of hours of discussion
> > as we went through each and every header value.  That meeting was
> > held on November 30 and a recording for that meeting posted to the
> > list:
> > minutes.  I think it might be worth your time to review that.
> > Maybe you have a valid point not raised by others in the meeting,
> > but I really think it's unfortunate that you re-raise this issue
> > after we revised the drafts and went through another IETF meeting
> > where the group adopted text based on this decision.  
> 
> I couldn't agree more. It is very unfortunate and so easily avoidable
> if only steps had been taken to ping the concerned parties.
> 
> Now ... can we please stop this arguing and just work around the
> issue with s.num/ssrc rewriting?
> 
> Please!
> 
> Emil
> 
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 14 May 2016 03:21:23 +0000

Emil,

>>December

The group concluded that sequence numbers could be changed.  So, I think 
only the SSRC is an issue, right?  Or are there other fields?  (The 
three fields that can change per current agreement is PT, X, and 
sequence number.)

As an aside, I would still prefer we did not re-write RTP sequence 
numbers, but I appreciate the argument that it would be more appropriate 
for the receiver in terms of RFC 3550 intent.

>You will understand as soon as you try to implement an SFU that works 

Given that browsers today do not support what's being proposed, I don't 
see where you're going.  Browsers will have to explicitly add support 
for PERC, and I think they'll be able to manage.

>Microsoft and Kurento. We are *all* rewriting sequence numbers and 

But it's not doing PERC. It's not doing end-to-end encryption with HBH 
in the middle, using appropriate logic for switching based on active 
speaker, and simulcast in a manner that will allow the receiver to 
compose media flows into something useful.  There are still many things 
we need to realize PERC in practice.  Let's avoid designing around what 
we have and figure out what we need.  I'm personally unconvinced that 
SSRC rewriting buys us anything.

>>>Numerous implementors commented here. This should have been the end 
>>>of
>>>it.
>>>
>totally makes sense now! Forget about immutable seq nums and SSRCs, we 
>can do with out them. Roll on!"

People from Cisco, Ericsson, Mozilla, Vidyo, Huawei, etc. were on a call 
and we reached agreement following a discussion about it.  It was a 
public call, minutes reported, etc.  We then revised the documents 
accordingly, published them, and then reviewed them face-to-face with a 
much larger audience.  Nobody presented a technical argument during that 
time for why this will not work, and the adopted approach is definitely 
in the spirit of RFC 3550.

>Did you see them take part of the discussion? Did you take any steps to 

I think your frustration with me is like "shooting the messenger."  If 
you'll listen to that recording I referenced in my last message, I 
suspect you will not even hear me speak up on the issue.  No decision 
was done in a vacuum; I'm just responding to the fact that you're 
digging up bones at this point.

>argument and I certainly didn't expect it from someone with your 

Again, don't shoot the messenger here, but the decision was reached 5 
months ago, with all of the material put put online for discussion, a 
F2F meeting held, etc.  So, to some extent I think it is reasonable to 
counter-argue with why you're re-opening points that were considered 
closed.  A good technical argument for why the current agreement is 
flawed would be helpful, but you are not making such an argument.

>>need

With all due respect, it's been out on the list for 5 months, documents 
published showing how it will work, etc.  I told you I don't expect 
people will be at meetings (they cost money), but the particular meeting 
where this agreement was reached cost no money to attend, recording was 
posted, minutes posted, documents revised and published several months 
later with no strong opposition to the decision, then no opposition at 
the meeting in April, etc.

>stated them. This simply means that they trusted the WG to do the right 

You are suggesting that the decision of the WG is somehow technically 
flawed, but what you're really concerned about is that you have to do 
some work to support PERC.  Everyone has to do some work to support 
PERC.  It is two-pass encryption with a switching function in the 
middle, DTLS-SRTP from the endpoints (which is not common at all 
presently, but viewed as far more secure than Security Descriptions), 
etc.

>if only steps had been taken to ping the concerned parties.

This was not a secret meeting.  As I noted above, the meeting was called 
in public, recording posted in public, meeting minutes from two 
different people posted in public, time elapsed with no departure from 
that consensus, so in March we revised the documents per the agreement 
in December and an announcement was sent to the list.  We then had a 
meeting F2F and discussed the texts again and adopted them.  So, you 
were pinged. :)

>with s.num/ssrc rewriting?

PERC will allow rewriting sequence numbers so that systems can strictly 
comply with RFC 3550 (and to help network monitoring functions that are 
looking for packet drops,  I guess).  But, I do not know what to tell 
you on SSRC.  I'm just one guy in the crowd here.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 14 May 2016 03:45:31 +0000

Lorenzo,

>this happened, we definitely would have made our point timely again,
IETF 94 was pretty much in agreement, so a call for getting Concensus:
https://www.ietf.org/mail-archive/web/perc/current/msg00125.html

And we did have a lot of discussion on this on the list.  During that 
time Magnus undertook a very careful study into the problem and all 
other RTP headers.

Meeting to take up the issues on what is and is not immutable was 
announced (based on previously posted poll):
https://www.ietf.org/mail-archive/web/perc/current/msg00193.html

Minutes posted by different attendees (one chair):
https://www.ietf.org/mail-archive/web/perc/current/msg00216.html
https://www.ietf.org/mail-archive/web/perc/current/msg00231.html

Emil asked about the decision:
https://www.ietf.org/mail-archive/web/perc/current/msg00222.html
(There was no follow-up to this, as I assume that all of those who 
favored the decision had nothing to say. Nobody opposed the group 
decision explicitly.)

There was dialog over the next few months on other things, but this 
issue was not raised again.

I posted an announcement on the revised set of drafts (nearly 4 months 
later near the end of March):
https://www.ietf.org/mail-archive/web/perc/current/msg00260.html

We then had an IETF meeting in April where documents were again 
considered.

So, everything has been out in the open for discussion.

Paul

---

From: Emil Ivov <[email-masked]>
Date: Sat, 14 May 2016 14:38:50 -0500

Hey Paul,

On 13.05.16 г. 22:21, Paul E. Jones wrote:
> only the SSRC is an issue, right?

They both go hand in hand and yes, immutable SSRCs is the missing piece.

> Or are there other fields?  (The

Timestamps. That's part of the simulcast package.

>>>>>> in my
> see where you're going.

I said: doing away with SSRC rewriting will significantly complicate the 
life of SFUs

You said: it sounds to me that the very fact they are doing SSRC 
re-writing is the source of their complication.

I said: If you were to implement a WebRTC compatible SFU, you would 
understand exactly how SSRC rewriting is the (significantly) simpler option.

> Browsers will have to explicitly add support

I wouldn't be so sure. We have no people here representing Chrome. We've 
had people from MS speak against it and the only pro-voice from a 
browser vendor has been Adam's.

> But it's not doing PERC.

No it is not. I would really like it to but what you are asking us to do 
in order to support PERC is to throw away our simulcast implementation 
and I am not going to do that.

If it ever came to that then I'd much rather do without PERC and rely on 
something more reasonable even if it meant depending on rich clients.

> It's not doing end-to-end encryption with HBH

It buys us adoption. Whether that matters to you is a different subject.

> in the spirit of RFC 3550.

This is going in circles ... Look, if that's what this is about then I 
am happy to take the blame for not taking that point far enough.

Now that this is out of the way, could we please revisit the decisions? 
Chairs? ADs? All?

It wouldn't be a big deal. It wouldn't hurt anyone, and it would make 
this entire problem go away.

> digging up bones at this point.

As a co-author in two of the three WG documents you are more than just a 
messenger. Didn't mean to shoot anyone though. I am grateful you have 
engaged in the discussions!

> flawed would be helpful, but you are not making such an argument.

That's ... quite a confusing statement. People from Microsoft, Kurento, 
Janus, as well as myself have all explained how our implementations rely 
on SSRC rewriting for things such as simulcast. How is that not a 
technical argument?

> the meeting in April, etc.

Again, happy to take the blame if that would make things better. Now 
that it is all out there and everyone is well aware of the tradeoffs, 
could we please reverse this decision? It would be a trivial change for 
PERC and it would make the difference between adopting or ignoring it 
for a bunch of implementers.

> flawed,

That's quite a misrepresentation and I would appreciate it if you didn't 
attribute to me statements I never made. I have never said anything 
about PERC being technically broken in its current state.

All this is about is the fact that it is going in a direction that 
compromises its adoption.

> but what you're really concerned about is that you have to do
> presently, but viewed as far more secure than Security Descriptions), etc.

Oh come on Paul. Really? Some work? Do you really believe that or are 
you just writing it to be spiteful?

I am happy to ask my team to do the work to implement PERC support. What 
I will not do is ask them to do that and then go and reimplement 
simulcast just because the people who created the protocols decided they 
didn't care about our problems.

> This was not a secret meeting.

Please point me to the message where I said that it was.

> As I noted above, the meeting was called

Well if the crowd doesn't care then I guess we wouldn't either. At this 
point I can only consider that this was the goal all along so ... good job!

Emil
-- 
https://jitsi.org

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Sun, 15 May 2016 01:22:34 +0000

I'd note that the meeting you specifically refer to in this mail was formally called as a design team meeting (not an interim meeting), and a design team meeting has no decision making process for the working group.

Any design team results always need to be presented to the working group and agreed (or rejected).

Regards

Keith

-----Original Message-----
From: Perc [mailto:[email-masked]] On Behalf Of EXT Paul E. Jones
Sent: 14 May 2016 04:46
To: Lorenzo Miniero; Emil Ivov
Cc: Richard Barnes; LuLop; [email-masked]; Cullen Jennings; Bernard Aboba
Subject: Re: [Perc] Minutes from Design Team call #3

Lorenzo,

And we did have a lot of discussion on this on the list.  During that time Magnus undertook a very careful study into the problem and all other RTP headers.

Meeting to take up the issues on what is and is not immutable was announced (based on previously posted poll):
https://www.ietf.org/mail-archive/web/perc/current/msg00193.html

Emil asked about the decision:
https://www.ietf.org/mail-archive/web/perc/current/msg00222.html
(There was no follow-up to this, as I assume that all of those who favored the decision had nothing to say. Nobody opposed the group decision explicitly.)

There was dialog over the next few months on other things, but this issue was not raised again.

I posted an announcement on the revised set of drafts (nearly 4 months later near the end of March):
https://www.ietf.org/mail-archive/web/perc/current/msg00260.html

We then had an IETF meeting in April where documents were again considered.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 14 May 2016 21:35:24 -0400

They were at the following IETF meeting.

Paul

-------- Original Message --------
From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Sent: May 14, 2016 9:22:34 PM EDT
To: "Paul E. Jones" <[email-masked]>, Lorenzo Miniero <[email-masked]>, Emil Ivov <[email-masked]>
Cc: Richard Barnes <[email-masked]>, LuLop <[email-masked]>, "[email-masked]" <[email-masked]>, Cullen Jennings <[email-masked]>, Bernard Aboba <[email-masked]>
Subject: Re: [Perc] Minutes from Design Team call #3

Regards

Keith

-----Original Message-----
From: Perc [mailto:[email-masked]] On Behalf Of EXT Paul E. Jones
Sent: 14 May 2016 04:46
To: Lorenzo Miniero; Emil Ivov
Cc: Richard Barnes; LuLop; [email-masked]; Cullen Jennings; Bernard Aboba
Subject: Re: [Perc] Minutes from Design Team call #3

Lorenzo,

Paul

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 23 May 2016 10:46:04 +0000

The PERC IETF95 meeting minutes state:

Mo’s Notes:
Magnus Westerlund: Should we revisit immutable SSRC discussion?
Chair: Let's discuss on list.

Harald’s Notes
Magnus: Please revisit consensus on whether SSRC is immutable or not.
Chairs: Will do offline.

I looked at the recording and actually what Magnus said was that it was not clear whether there was consensus on this issue.  Looking back at the mailing list and minutes I don’t think there has ever been any clear consensus on this issue or decision made.

Regards
Andy

From: Perc [mailto:[email-masked]] On Behalf Of Paul E. Jones
Sent: 15 May 2016 02:35
To: Drage, Keith (Nokia - GB); Lorenzo Miniero; Emil Ivov
Cc: Richard Barnes; LuLop; [email-masked]; Cullen Jennings; Bernard Aboba
Subject: Re: [Perc] Minutes from Design Team call #3

Paul
________________________________
From: "Drage, Keith (Nokia - GB)" <[email-masked]<mailto:[email-masked]>>
Sent: May 14, 2016 9:22:34 PM EDT
To: "Paul E. Jones" <[email-masked]<mailto:[email-masked]>>, Lorenzo Miniero <[email-masked]<mailto:[email-masked]>>, Emil Ivov <[email-masked]<mailto:[email-masked]>>
Cc: Richard Barnes <[email-masked]<mailto:[email-masked]>>, LuLop <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Cullen Jennings <[email-masked]<mailto:[email-masked]>>, Bernard Aboba <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Perc] Minutes from Design Team call #3

Regards

Keith

-----Original Message-----
From: Perc [mailto:[email-masked]] On Behalf Of EXT Paul E. Jones
Sent: 14 May 2016 04:46
To: Lorenzo Miniero; Emil Ivov
Cc: Richard Barnes; LuLop; [email-masked]<mailto:[email-masked]>; Cullen Jennings; Bernard Aboba
Subject: Re: [Perc] Minutes from Design Team call #3

Lorenzo,

What I'd like to highlight, though, is that I certainly don't recall
such a decision being echoed on the ML, as I would expect in the I!

 ETF

Paul

________________________________

Perc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/perc

________________________________

Perc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/perc

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 23 May 2016 16:50:48 -0700

Luis said:

"Could you develop this?"

[BA] A switching function that does not require changing SSRCs is quite
difficult to develop.  Basically, this would require the SFU to act as an
RTP translator.

To my knowledge, I do not believe that an SFU with any sophistication has
been done this way, because of the complexity that it would introduce.

On Thu, May 12, 2016 at 1:22 AM, Luis Lopez <[email-masked]> wrote:

> simulcast or active speakers switching in an SFU without SSRC rewriting? I
> your plan is to negotiate a bunch of SSRCs per participant and just switch
> on/off each of them when appropriate, I’m afraid this will not work.
>
> Best regards.
>
> L.
>
>
>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 24 May 2016 09:50:16 -0700

Can you explain what part of this becomes significantly more complicated if you don’t change the SSRC because that has not been my experience. 

> On May 23, 2016, at 4:50 PM, Bernard Aboba <[email-masked]> wrote:
> 
> Luis said: 
> 
> [BA] A switching function that does not require changing SSRCs is quite difficult to develop.  Basically, this would require the SFU to act as an RTP translator. 
> 
> To my knowledge, I do not believe that an SFU with any sophistication has been done this way, because of the complexity that it would introduce. 
> 
> On Thu, May 12, 2016 at 1:22 AM, Luis Lopez <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Paul,
>

---

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

On 24.05.16 г. 11:50, Cullen Jennings wrote:
>
> Can you explain what part of this becomes significantly more complicated
> if you don’t change the SSRC because that has not been my experience.

Sender ≡≡≡> SFU ---> Receiver [ RTP stack --> Decoder --> Video Tag]

The single stream to the right of the SFU has to be fed into the 
receiver and its components as a continuous RTP flow, so that it goes 
through the same chain  of RTP streams, decoder and video tag. This 
makes stream switches transparent and gives you a smooth user experience.

If you weren't re-writing SSRCs you would inevitably end with something 
like this:

<monospace>

Sender ≡≡≡> SFU ---> Receiver1[ RTPstream1 --> Decoder1 --> Video Tag1]
                 ---> Receiver2[ RTPstream2 --> Decoder2 --> Video Tag2]
                 ---> Receiver3[ RTPstream3 --> Decoder3 --> Video Tag3]

</monospace>

So there is the general practicality concern with this approach which is 
that a switching logic on the receiver would require reimplementing it 
on all supporting clients. With WebRTC this would basically imply: JS, 
objc/swift and Java implementations of the exact same thing.

More importantly though there is the bigger concern that nothing in 
WebRTC today allows you to do that switching at the "right time" so that 
you have a good user experience. Not in the stack and certainly not in JS.

Receiver-side RID would supposedly address this but we have never seen 
that working. We would have to wait for consensus on the API and the 
SDP, then for browsers to implement it and then for SFUs to redo their 
implementations.

There is no good reason for PERC to be dependent on all of that (unless 
you actually want it to not be adopted).

Again, please note that relaxing the requirement on SSRC rewriting DOES 
NOT in anyway require you to do it. You can still wait for receiver-side 
RID support to land if that's what you want.

Emil

>
>> On May 23, 2016, at 4:50 PM, Bernard Aboba <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Luis said:
>>
>> [BA] A switching function that does not require changing SSRCs is
>> quite difficult to develop.  Basically, this would require the SFU to
>> act as an RTP translator.
>>
>> To my knowledge, I do not believe that an SFU with any sophistication
>> has been done this way, because of the complexity that it would
>> introduce.
>>
>>>     does not require changing SSRCs.
>>
>>     I’m very interested in figuring out know to support features such
>>     as simulcast or active speakers switching in an SFU without SSRC
>>     rewriting? I your plan is to negotiate a bunch of SSRCs per
>>     participant and just switch on/off each of them when appropriate,
>>     I’m afraid this will not work.
>>
>>     Best regards.
>>
>>     L.
>>
>>
>>
>> [email-masked] <mailto:[email-masked]>

-- 
https://jitsi.org