Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00]

["Timothy B. Terriberry" <[e-mail]>]

>> I think the most encouraging response I got before on this list was
>> that the API should always produce the same list of ICE candidates for
>> a given Web browser session. Because of this, all the offers from the

I don't think this is possible, depending on what you mean by "web 
browser session". People's web browsers move around, change which 
networking device they're using, etc., at any time. At a minimum, you 
need some interface to raise an error and deal with the fallout when you 
require this behavior and it can't be provided. The PeerConnection 
factory/cloning solution could potentially give you that (it could 
simply fail if it can't use the same ICE candidates anymore).

>> WebRTC client would be the same and simultaneous forking can be
>> implemented by creating a new peer connection for each answer,
>> generating and discarding the offer (since it is the same as the offer
>> from the original peer connection in this session) and feeding a new
>> answer to it.
> I considered it when we discussed this last, but I'm not sure it works.

I'm confident it doesn't. Again, external cameras can be plugged in and 
unplugged, etc., by the user at any time, and these can change the 
capabilities exposed in the offer. This is also something you have to 
deal with, if you really rely on "same offer" behavior.

> If we support SDES, the offer also contains crypto keys. Reusing crypto
> keys for all created connections would be a huge security vulnerability.

I'm starting to come to the opinion that we shouldn't support SDES. If 
we're doing it just for interop with legacy, we'd get better interop 
with fewer headaches by supporting plain RTP. We'd have a distinction 
between the two that I could actually explain to users, and less chance 
of (unnoticed) downgrade attacks.