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

Magnus Westerlund <> Mon, 05 September 2011 12:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4375821F8B3A for <>; Mon, 5 Sep 2011 05:05:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.505
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S1qvcuhYrshY for <>; Mon, 5 Sep 2011 05:05:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 751B421F8B2C for <>; Mon, 5 Sep 2011 05:05:57 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c47ae000000b17-f0-4e64bb8c4d37
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 9D.1C.02839.C8BB46E4; Mon, 5 Sep 2011 14:07:41 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Mon, 5 Sep 2011 14:07:40 +0200
Message-ID: <>
Date: Mon, 05 Sep 2011 14:07:39 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
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-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


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: