Re: [rtcweb] How to multiplex between peers

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 25 July 2011 11:53 UTC

Return-Path: <magnus.westerlund@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 41DB121F8B56 for <rtcweb@ietfa.amsl.com>; Mon, 25 Jul 2011 04:53:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.497
X-Spam-Level:
X-Spam-Status: No, score=-106.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5teykr5Mh1A for <rtcweb@ietfa.amsl.com>; Mon, 25 Jul 2011 04:53:36 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 95F7221F86C3 for <rtcweb@ietf.org>; Mon, 25 Jul 2011 03:31:00 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-42-4e2d45e2e9cd
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D8.E1.20773.2E54D2E4; Mon, 25 Jul 2011 12:30:59 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Mon, 25 Jul 2011 12:30:58 +0200
Message-ID: <4E2D45D0.5050103@ericsson.com>
Date: Mon, 25 Jul 2011 06:30:40 -0400
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Stephan Wenger <stewe@stewe.org>
References: <CA5085E1.2EE33%stewe@stewe.org>
In-Reply-To: <CA5085E1.2EE33%stewe@stewe.org>
X-Enigmail-Version: 1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: Jonathan Lennox <jonathan@vidyo.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>, Colin Perkins <csp@csperkins.org>
Subject: Re: [rtcweb] How to multiplex between peers
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: Mon, 25 Jul 2011 11:53:37 -0000

On 2011-07-23 17:12, Stephan Wenger wrote:
> Hi Magnus,
> 
> Not sure you got the context right here.  The "removal of multiparty
> support" was related to my suggestion for a feature list of what I called
> RTPv3, which would need to co-exist with RTPv2 (that includes multiparty
> support).

Ok, I misunderstood that.

> 
> That said, if I'm not completely mistaken, you can implement the
> multiparty use cases using the "RTCP terminating MCU" topology of RFC
> 5117.  This is common implementation practice in video conferencing.  If
> you do so, the multiparty support of RTPv2 is neither exercised nor needed
> in a multiparty video conference.

First of all if you do that you loose functionality as discussed in RFC
5117. For example the indication of who actually sent a packet
originally or contribute to the mix can't be provided unless you let the
SSRC or CSRC plus CNAMES be forwarded across the Mixer/MCU.

In addition it forces the central unit into one particular
implementation, instead of allowing to use what it most appropriate.

An RTP mixer when you want something that has functionality and
application enhancing behavior and the cost is more complexity.

Or you use an relay which simply copies a packet from one entity to all
the others. That is the simplest central node you can build and it will
have no media processing at all.

Also, in any gateway case to existing legacy you don't want to have to
implement additional gatewaying functions just because one want to use
non standard RTP.

For me it is clear that ensuring that RTCWEBs RTP usage is vanilla will
help us avoid a lot of problems down the road.

If we are going to multiplex this mechanism needs to have a behavior
that doesn't change the core behaviors of RTP. If we can do that the
multiplexing becomes much less a hot topic.


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------