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

[Stefan Håkansson <[e-mail]>]

On 10/30/2011 10:00 PM, Timothy B. Terriberry wrote:
>>> 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.

I have some faith in that it should work. Remember that we're dealing 
with candidates for one local port only (regardless of the 
MediaStream(s) added), so it should be possible to re-use that part. The 
application must of course make sure that it adds the right MediaStreams 
before the browsers enters a stable state. A bit complicated for the web 
developer maybe, but SIP-compatible forking in itself is a corner case 
from a webrtc perspective so I think that would be OK.

>
>> 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.
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb