Re: [Perc] Request for decision review

[Emil Ivov <[e-mail]>]

It is probably worth reminding there IS a middle ground that allows
PERC to function with both SSRC rewriting and use of RID. We simply
need to convey the original SSRC to the receiver and have PERC code
use that for verification. That's all.

We've been through this before. The only meaningful argument against
this is Paul's: "The code wouldn't be as pretty as I want it to be
because PERC would no longer be implementable as a double standard
SRTP unprotect".

As a result we are going toward something incompatible with most
popular SFU implementations, mandating support for receiver-side
RID-based simulcast that NO ONE implements today, that will not be
part of WebRTC 1.0 and that is not even fully specified on the IETF.

Chairs, ADs, ... please, please, please, let's get back to a state of sanity.

Emil

On Wed, Jul 20, 2016 at 4:35 PM, Miguel París Díaz <[e-mail]> wrote:
> Hello Paul,
> we rewrite the SSRC because currently it is the way to associate a
> MediaStreamTrack to an RTP stream.
>
> Analysing the case of video quality switching (simulcast):
>
> Rewriting SSRCs at the SFU side improves the QoE a lot due the switch is
> transparent for the endpoint which receives the RTP stream, applies the
> JitterBuffer, decrypts it, creates encoded frames, decodes frames, applies
> sync-buffer (for interstream synchronization (typically audio and video))
> and renders the video. So the logic in the client is quite easier and smooth
> when switchings.
>
> If we do NOT do that, the another possibility (I didn't found others) is
> negotiating with the receiver N SSRCs (each one per quality) performing
> ON/OFF at the SFU side and doing the switching in the receiver. For doing
> that:
>
> You have N MediaStreamTracks.
> You have to detect at application layer when a MediaStreamTrack stops
> receiving media using getUserMedia API's events (which takes at least 500ms)
> You have to detect the the new enabled MediaStreamTrack, which can take a
> lot of times due to JitterBuffer restarting, decoder restarting, etc.
> You have to deal with audio-video synchronization that may be quite
> difficult.
> The endpoint uses more resources (CPU and memory)
> etc.
> In conclusion it is a pain for the users because they see freeze video time
> to time (the QoE is very bad)
>
> Rewriting timestamps is needed because there are usually some offsets
> between different qualities.
>
>
> 2016-07-20 14:34 GMT+02:00 Paul E. Jones <[e-mail]>:
>>
>> Miguel,
>>
>> The current design of PERC is one where there is an E2E encryption step
>> using regular SRTP.  An intermediary does not have the E2E keys and,
>> therefore, cannot change anything about the packet.  Then, that packet is
>> encrypted HBH using a different key that the next hop device will have.
>> Assuming the next hop device is an MDD (nor "Media Distributor"), that
>> device could have the liberty of changing the sequence numbers and, in fact,
>> it will be obliged to do so if it does not always forward all of the streams
>> (since not forwarding some streams will mean the cryptographic context gets
>> out of sync).
>>
>> So in the typical case, the MDD will change the sequence number and might
>> insert a new header extension to carry the original value.  It might also
>> change the payload type value.
>>
>> How, as the endpoint receives a packet, it will decrypt the HBH packet and
>> reconstruct the E2E packet using the OHB field.  But what is there?  Well,
>> it's the original packet as created by the sending endpoint.  Even if we
>> change the SSRC or sequence number, the original values are there and
>> preserved.  So, other than out of necessity (sequence number changed to keep
>> crypto context in sync and PT changed to ensure the right PT value is
>> received as expected), I'm still not convinced that changing the SSRC really
>> buys us anything.  Sure, we could change it.  We actually has space in the
>> OHB originally to allow that.  But for what purpose?  Changing or not
>> changing an SSRC value should not have any affect whatsoever on the QoE.
>> (I'm not saying the SSRC has no importance, but I question the need to
>> rewrite them.)
>>
>> I'm not sure how the other identifiers you mention might help improve QoE.
>> Maybe expand on that little?
>>
>> One important point to consider in all of this is that WebRTC browsers
>> MUST be PERC-aware, else they cannot participate in conferences.  If they're
>> not PERC-aware, then there would have to be a middlebox that "downgrades"
>> for those older browsers and it can rewrite whatever it wants, since it
>> would be in possession of keys and would strip off one layer of encryption
>> to produce a legacy SRTP flow (or no SRTP at all).
>>
>> Paul
>>
>> ------ Original Message ------
>> From: "Miguel París Díaz" <[e-mail]>
>> To: "Emil Ivov" <[e-mail]>
>> Cc: "Eric Rescorla" <[e-mail]>; "Paul E. Jones"
>> <[e-mail]>; "Adam Roach" <[e-mail]>; "[e-mail]"
>> <[e-mail]>; "Cullen Jennings" <[e-mail]>
>> Sent: 7/20/2016 6:56:59 AM
>> Subject: Re: [Perc] Request for decision review
>>
>>
>> Hello everybody,
>> I understand the point of Emil because as implementer I am worried about
>> having hard restrictions which avoid or hinder the implementation of
>> features requested by the market, and this could make PERC unusable.
>>
>> So I think that firstly we should reach consensus about which features or
>> uses cases must be allowed to be implemented and then discuss the low level
>> details taking into account that we won't can add restrictions which avoid
>> these features.
>> This may also apply to others WGs and not only to PERC. Even having
>> support for rid, mid, etc. could ease the design of PERC.
>>
>> Ones of the features affected with the current status are:
>>   1 - Video quality switching (simulcast)
>>   2 - Dominant Speaker switching
>>
>> These features must also offer an high QoE for the users. For that, the
>> experience tells me that it should be performed in the SFU side. In our
>> current implementation:
>>   1 - Video quality switching (simulcast) is performed rewriting SSRCs,
>> seqnums and timestams
>>   2 - Dominant Speaker switching is performed rewriting SSRCs, seqnums
>> andt timestams. Notice that it would be consider and attack [1] when it is
>> the best way (easy, efficient and
>> with high QoE) we found to implement this feature.
>>
>> This is working in the WebRTC context using endpoints like Chrome or
>> Firefox. To implement them following current PERC status:
>> Could (1) be implemented without SSRCs rewriting and using RID instead?
>> I think so, but should be ensure that endpoints support that before make
>> SSRC immutable?
>> Could (2) be implemented without SSRCs rewriting and using MID instead?
>> Could (2) be implemented even without adding a specific RTP stream using
>> idea [2]?
>> I think so, but should be ensure that endpoints support that before make
>> SSRC immutable?
>>
>> These questions tell me that if endpoints does not support them, features
>> requested by the market and PERC will be incompatible :S.
>>
>> Best regards!!
>>
>> Refs
>> [1]
>> https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01#section-7.2.4
>> [2] https://www.ietf.org/mail-archive/web/mmusic/current/msg16611.html
>>
>> 2016-05-26 1:12 GMT+02:00 Emil Ivov <[e-mail]>:
>>>
>>>
>>>
>>> On Wednesday, 25 May 2016, Eric Rescorla <[e-mail]> wrote:
>>>>
>>>>
>>>>
>>>> On Wed, May 25, 2016 at 1:43 PM, Emil Ivov <[e-mail]> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 25.05.16 г. 15:20, Paul E. Jones wrote:
>>>>>>
>>>>>> Emil,
>>>>>>
>>>>>> You are saying that endpoints would negotiate via signaling which SSRC
>>>>>> 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?
>>>>>
>>>>>> 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?
>>>>>
>>>>>
>>>>> I think at this point the answers that I've heard are for both
>>>>> browsers: we are not doing this now.
>>>>
>>>>
>>>> As far as Firefox goes, we're not doing this now because PERC isn't
>>>> ready.
>>>
>>>
>>> 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.
>>>
>>>
>>>> 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?
>>>
>>>
>>> How would you tell FF what group an RID corresponds to?
>>>
>>> Emil
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> we'd like to do it in the future.
>>>>
>>>>
>>>> Yes.
>>>>
>>>> -Ekr
>>>>
>>>>
>>>>
>>>>>
>>>>> 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
>>>>>
>>>>>>
>>>>>> Paul
>>>>>>
>>>>>> ------ Original Message ------
>>>>>> From: "Emil Ivov" <[e-mail]>
>>>>>> To: "Paul E. Jones" <[e-mail]>
>>>>>> Cc: "Adam Roach" <[e-mail]>; "Cullen Jennings"
>>>>>> <[e-mail]>;
>>>>>> [e-mail]
>>>>>> 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:
>>>>>>>
>>>>>>> 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:
>>>>>>>>
>>>>>>>> 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 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.
>>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>>>> 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".
>>>>>>>>
>>>>>>>>
>>>>>>>> Of course it's SRTP.  It just happens to be two passes of SRTP, but
>>>>>>>> it's
>>>>>>>> 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
>>>>>>>> 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).
>>>>>>>>
>>>>>>>>
>>>>>>>>>> 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?
>>>>>>>>
>>>>>>>>
>>>>>>>> No, lamenting that this would not align with what RFC 3711 says to
>>>>>>>> use
>>>>>>>> to identify the context.
>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>> You mean E2E here.
>>>>>>>
>>>>>>>>  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.
>>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>> If we take the approach of using a 64-bit identifier (in
>>>>>>>> contradiction
>>>>>>>> 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
>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> https://jitsi.org
>>>>>
>>>>> _______________________________________________
>>>>> Perc mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/perc
>>>>
>>>>
>>>
>>>
>>> --
>>> sent from my mobile
>>>
>>> _______________________________________________
>>> Perc mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/perc
>>>
>>
>>
>>
>> --
>> Miguel París Díaz
>> ------------------------------------------------------------------------
>> Computer/Software engineer.
>> Researcher and architect in http://www.kurento.org
>> http://twitter.com/mparisdiaz
>> ------------------------------------------------------------------------
>
>
>
>
> --
> Miguel París Díaz
> ------------------------------------------------------------------------
> Computer/Software engineer.
> Researcher and architect in http://www.kurento.org
> http://twitter.com/mparisdiaz
> ------------------------------------------------------------------------
>



-- 
https://jitsi.org