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

Randell Jesup <randell-ietf@jesup.org> Thu, 11 August 2011 21:18 UTC

Return-Path: <randell-ietf@jesup.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E290A21F8B23 for <rtcweb@ietfa.amsl.com>; Thu, 11 Aug 2011 14:18:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.474
X-Spam-Level:
X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nJMcfjqzV3y for <rtcweb@ietfa.amsl.com>; Thu, 11 Aug 2011 14:18:24 -0700 (PDT)
Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id EC60821F8B22 for <rtcweb@ietf.org>; Thu, 11 Aug 2011 14:18:23 -0700 (PDT)
Received: from pool-98-111-140-38.phlapa.fios.verizon.net ([98.111.140.38] helo=[192.168.1.12]) by arthur.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1QrceY-0006g1-T9 for rtcweb@ietf.org; Thu, 11 Aug 2011 16:18:58 -0500
Message-ID: <4E4446D2.6040809@jesup.org>
Date: Thu, 11 Aug 2011 17:17:06 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4E4292B2.8000904@alvestrand.no> <4E42A17B.3070004@jesup.org> <4E43F08A.4010808@alvestrand.no>
In-Reply-To: <4E43F08A.4010808@alvestrand.no>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - arthur.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [rtcweb] Use case change request: Identity in multiuser calls
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Aug 2011 21:18:25 -0000

On 8/11/2011 11:08 AM, Harald Alvestrand wrote:

> On 08/10/11 17:19, Randell Jesup wrote:
>> 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).
> If we do multiple video streams inside an RTP session, we don't need
> re-negotiation of o/a to add more streams. We might consider the
> proposed extensions in
> draft-westerlund-avtcore-multistream-and-simulcast to add information
> about number of streams to O/A (he suggests that for max backwards
> compatibility, we should assume that no more than one stream per RTP
> session can be handled unless the extension is used, but that might be
> an overly conservative suggestion).

My problem with that is that all streams are not equal.  I can handle a lot
more CIF streams than I can HD streams.  So while a suggestion is good, there
should be some way to say "too much", if not before a stream is added, then after
the fact (that might be good to have anyways).


>> 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.
> Hangouts put all the video streams into one RTP session, and all the
> audio streams into another RTP session. Renegotiation would be needed if
> it didn't.
That assumes they all are using the same parameters/payloads (or ones agreed to
in the m= lines of the existing participants).  I'm not 100% sure that's a
valid assumption - and we need to be able to renegotiate at that point anyways
(new person doesn't support an optional codec being used, for example).  But on
the other hand maybe it's simpler to not try to handle all the funny edge cases
here and force/allow the clients to renegotiate if they don't like the state of
the call.

We should think through the case of multiple video sessions in a conference (example:
one for participants, one for presentations, and perhaps even a second camera for
some participants.)  I don't see any blocker here other than properly identifying which
is the "user" video and which is "presentation" and that may be a W3 issue or an
application issue even.


>> Note that this requires the central server to decrypt and re-encrypt the
>> streams (as I believe Harald's wording above would).
> Not necessarily - if key negotiation goes via the server, the server
> could make sure the key used in the server-to-client direction is the
> same key as that used in the client-to-server direction - but if you
> want to put 2 media streams into the same RTP session, and do keying per
> RTP session, the server would have to decrypt-then-encrypt.

Do we have enough control of the key selection (and the timing of it) to
do that?  Plus, I see that as an optimization - the server knows the key;
whether the keys are the same or different and if it actually decodes and
re-encodes are performance details (though perhaps important ones).

If the server doesn't know the key, we're in an end-to-end exchange scenario
where the server just acts as a forwarder, and the ends will authenticate each
incoming stream separately, and the server has much more limited ability to
interact with the conference.

-- 
Randell Jesup
randell-ietf@jesup.org