Re: [rtcweb] State of the Forking discussion

[Randell Jesup <[e-mail]>]

On 11/3/2011 6:13 AM, Magnus Westerlund wrote:
> I think it is important that there are in fact at least two important
> questions here.
>
> 1. Is forking needed to be supported at all?

Yes.

> 2. If it is supported in which form would it supported in.

B4, but I disagree with the assertion that the driving force should be 
SIP interop (though that's a positive aspect).

I've mentioned before non-SIP uses of WebRTC that require forking, and 
where parallel forking would be preferable (see, 
Wolfgang/Hadriel/Michael - non-SIP-related reasons!) ;-)

1) mesh conference

You send an offer to the server (say to invite my-work-group to chat). 
The server forwards the OFFER to each member of my-work-group.  Each 
member who answers both accepts your offer, and sends their own offer to 
the server to be mirrored to the other members of my-work-group.  Note 
that in this case the app (interacting with the server) is cognizant of 
the mesh conference state, which active offers are from members of the 
mesh, etc.  Without forking this would require many more offers to be 
generated. I think parallel forking would make it faster and easier for 
an application developer to implement architectures like this.

Also (IMPORTANT): would generation of "new" offers require separate user 
consent for security?  How would rtcweb distinguish between that and a 
totally different call to another destination?

2) games

In games (or virtual "3d space" conferences where locality comes into 
play) you might have a "hanging" offer with the server used to connect 
you to another player when the radio you, or come close to you, etc. 
Again the speed and consent issues come into play, plus the ease of use 
for the application writer.

There are more, I'm just recounting some I'd already mentioned.

> Additional considerations:
>
> Shared SDES keys: B2 to B4 will result in that SDES keys from the
> Offering party to be used towards all invited parties. This is security
> risk as any of the invited parties can spoof the offering side towards
> any of the other invited parties. This threat can be resolved by having
> the inviter rekey immediately after having received an answer.

I'm on record as seriously disliking SDES, but if it's used that would 
be a way to resolve it before media is allowed to flow.


-- 
Randell Jesup
[e-mail]