Re: [rtcweb] New topic: Model for multi-unicast support

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 05 September 2011 12:05 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 4375821F8B3A for <rtcweb@ietfa.amsl.com>; Mon, 5 Sep 2011 05:05:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.505
X-Spam-Level:
X-Spam-Status: No, score=-106.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 S1qvcuhYrshY for <rtcweb@ietfa.amsl.com>; Mon, 5 Sep 2011 05:05:57 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 751B421F8B2C for <rtcweb@ietf.org>; Mon, 5 Sep 2011 05:05:57 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c47ae000000b17-f0-4e64bb8c4d37
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 9D.1C.02839.C8BB46E4; Mon, 5 Sep 2011 14:07:41 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Mon, 5 Sep 2011 14:07:40 +0200
Message-ID: <4E64BB8B.2000307@ericsson.com>
Date: Mon, 05 Sep 2011 14:07:39 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4E5F7344.4060803@alvestrand.no> <BBF498F2D030E84AB1179E24D1AC41D61C1BCA813D@ESESSCMS0362.eemea.ericsson.se>
In-Reply-To: <BBF498F2D030E84AB1179E24D1AC41D61C1BCA813D@ESESSCMS0362.eemea.ericsson.se>
X-Enigmail-Version: 1.3.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [rtcweb] New topic: Model for multi-unicast support
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, 05 Sep 2011 12:05:58 -0000

On 2011-09-03 07:31, Stefan Håkansson LK wrote:
> Harald wrote:
>> In the thread about draft-perkins-rtcweb-usage, the following
>> exchange took place:
>>>>> Speaking for some implementors of the WEBRTC API, it's also
>>>>> clear that there's a significant cost to implementing the
>>>>> multiway RTP session concept - both in code >complexity and
>>>>> API complexity. I think this warrants more discussion, where
>>>>> all 3 outcomes should be on the table:
>>>>> 
>>>>> - We recommend doing multi-unicast with a shared RTP session
>>>>> only - We recommend supporting both shared and split RTP
>>>>> sessions for multi-unicast - We recommend doing multi-unicast
>>>>> with split RTP sessions only
>>>>> 
>>>>> We should probably do this in a new thread.
>>> Indeed; I'd be interested to know what complexity you're seeing.
>>> I would have expected the shared RTP session model to decrease
>>> complexity, since the RTP layer can be >>oblivious to the detail
>>> of the underlying transport connections, and wouldn't have to
>>> worry about tracking SSRC and payload type mapping separately for
>>> each session.
>> I think this is a topic that deserves its own thread.
>> 
>> The context is use case 4.2.7, "Multiparty video communication",
>> the one without a central server; each party sends its video and
>> audio streams to all participants in the meeting directly.
>> 
>> One can imagine supporting this with a single RTP session, where
>> all video streams are equal and sent with the same SSRC to all
>> participants, all participants send receiver reports (RRs) about
>> all the SSRCs they see to all other participants, and all senders
>> send their SR reports to all participants.
> 
> To me an RTP session was connected to a port/IP address, so I don't
> understand how this could be one session (the destination port/IP
> would be different for each stream). (I expect to be corrected!) Is
> multicast assumed?
> 

No, no multicast assumed. This uses the fundamental definition of an RTP
session as a joint SSRC space as the basis. What Harald talks about here
is what I call multi-unicast, where one basically configure a
replication module under the regular RTP/RTCP stack processing to send
out each RTP and RTCP packet to multiple destinations using unicast. All
incomming traffic would preferably be received on a single port (pair)
from the other peers.


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
----------------------------------------------------------------------