[rtcweb] New use-case proposed

Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com> Fri, 11 May 2012 13:01 UTC

Return-Path: <stefan.lk.hakansson@ericsson.com>
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 71B6C21F86FD for <rtcweb@ietfa.amsl.com>; Fri, 11 May 2012 06:01:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
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 T2QMGXXivKRU for <rtcweb@ietfa.amsl.com>; Fri, 11 May 2012 06:01:03 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 62BE521F86FA for <rtcweb@ietf.org>; Fri, 11 May 2012 06:01:03 -0700 (PDT)
X-AuditID: c1b4fb25-b7b48ae0000025b3-e2-4fad0d8d725e
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B4.AC.09651.D8D0DAF4; Fri, 11 May 2012 15:01:02 +0200 (CEST)
Received: from [150.132.142.244] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 15:01:00 +0200
Message-ID: <4FAD0D8C.7020701@ericsson.com>
Date: Fri, 11 May 2012 15:01:00 +0200
From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Subject: [rtcweb] New use-case proposed
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: Fri, 11 May 2012 13:01:04 -0000

I've been sketching on a new use-case. The use-case is intended to
derive requirements that enable low complex central nodes for multi
party sessions, which in turn leads to requirements regarding
(essentially) keying solution for SRTP and the possibility for the app
to control/set things in the media configuration (in other words, for JSEP):


Multi-party with low complexity central node
==============================================

A geographically spread (charity, non-profit, school) organization
offers its members multi-party video communication via a shared virtual
room that participants can enter and leave at any time. At times there
are many persons in the virtual room (20+), at other times very few
(3-5, or even 0-1).

The application will control if few participants (a subset) are shown at
a higher fidelity or if many (all) are shown at a lower fidelity or a
mix of some few at high fidelity and the rest at much lower fidelity
given the existing bandwidth limitations between participants.

Since there are at times many persons in the virtual room, it is not
feasible to set up a mesh. The bandwidth needed by a participant exceeds
what many members have access to, especially in their uplinks, so
instead a central media node is deployed. In addition, the organization
does not have access to much funds, but has to rely on cheap hardware
(often donated) operated by volunteers.

  From this use-case a high level requirement saying something like

"It must be possible to set up media streams and encryption in such
a way that processing in a central node is minimized (no transcoding
required, no RTP packet rewriting, no decryption/re-encryption for every
outgoing flow - just simple forwarding)."

can be derived. This can in turn be broken down into more detailed
requirements such as:

- The keying solution must allow each participants to encrypt to
multiple receivers without any decryption+encryption in the middle node

- RTP sessions that have SSRCs from multiple PeerConnections being
interconneted must be supported. From a given end-point all SSRCs will
come over one PC, but the full path will be different towards different
sets of SSRCs.

- Signalling must be capable of establishing a common set of receiver
configurations over all participants.

- The API must allow for the above, i.e.:
-- The app must be able to chose a keying solution that enables
encryption to multiple receivers (if the app can have any control over
keying method used)
-- The app must be able to control SSRCs to use for outgoing streams
-- The app must be able to control the receiver configuration the
browser uses

Is this something we should consider adding to the use-case document?

Br,
Stefan