Re: [rtcweb] Use case change request: Identity in multiuser calls

[Randell Jesup <[e-mail]>]

On 8/10/2011 10:16 AM, Harald Alvestrand wrote:

> In draft-ietf-rtcweb-use-cases-and-requirements, I would like to extend
> one part of the scenario "4.3.3 Video conferencing system with central
> server".
> I would like to add one more paragraph:
> "All participant are authenticated by the central server, and authorized
> to connect to the central server. The participants are identified to
> each other by the central server, and the participants do not have
> access to each others' credentials such as e-mail addresses or login IDs".
> This is necessary in order to drive use cases that resemble Google
> Hangout, where it is a requirement that people are able to participate
> without disclosing their Google login IDs to each other.
> (in the particular case of Hangout, the display name on their profile
> *is* disclosed ... but that's a different matter)
> The reason I think this is important is that it feeds directly into the
> discussion of what WebRTC needs to authorize: The final source or
> destination of media, or the identity of the handler at the first hop.
> In at least the case of Hangouts, the requirement is to *not* authorize
> the final source or destination.
Could this be handled by defining this case as a central server which is
the target of the "call", and which provides in response 1 or more video/
audio streams to the caller.  So you're only authenticating the server, and
the server is responsible for stripping and replacing the authentication
info for the forwarded streams.  The conferencing aspect is merely an aspect
of the service the server provides.  It might merge the video streams,
selectively forward them depending on speaker or on preference of the viewer,
and do similar things with audio.

While in theory it's largely covered by the point-to-point case (for example,
a point-to-point call should support multiple streams), a separate
use-case is still useful here since it both highlights conferencing-specific
issues (such as larger numbers of streams, etc).

We should consider ways for a client to indicate how many simultaneous decodes
it's willing/able to handle.  This lets the server be smart about what it
sends (it may be as simple as rejecting video streams on re-negotiation of o/a
- and that may help handle things such as where the number of streams supported
varies with the type of encoding/resolution/frame-rate, or other client-side loads).

For example, as people join a "Hangout", the server would re-negotiate to add
a video/audio pair (using SDP grouping I assume).  If the client can't handle
another one, it could reject the add (or renegotiate to lower the complexity/size
of existing streams, perhaps).  The server might then send the N most "interesting"
streams, or combine streams, etc.  SDP+o/a may not be optimal here but I think it
would get the job done.

Note that this requires the central server to decrypt and re-encrypt the
streams (as I believe Harald's wording above would).

The "and authorized to connect to the central server" I think is unneeded -
that's up to the policy of the server; there's no reason it can't allow
arbitrary (non-authorized) connections if the service/server so choose.
The same for authenticating the users - that's up to the server/service.
One can run encryption without authenticating the users.

-- 
Randell Jesup
[e-mail]