Re: [AVTCORE] Slight rewording on Selective Forwarding Middlebox

Magnus Westerlund <> Wed, 01 April 2015 10:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 789521A0049 for <>; Wed, 1 Apr 2015 03:43:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LSKK1G68yZVm for <>; Wed, 1 Apr 2015 03:43:17 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F2A201A0032 for <>; Wed, 1 Apr 2015 03:43:16 -0700 (PDT)
X-AuditID: c1b4fb2d-f79a46d0000006b4-dd-551bcbc2c939
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id B0.12.01716.2CBCB155; Wed, 1 Apr 2015 12:43:15 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Wed, 1 Apr 2015 12:43:14 +0200
Message-ID: <>
Date: Wed, 01 Apr 2015 12:43:12 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Bernard Aboba <>, "" <>
References: <> <>, <> <BLU181-W9331685ED48AAC16F9AE4093F40@phx.gbl>
In-Reply-To: <BLU181-W9331685ED48AAC16F9AE4093F40@phx.gbl>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+Jvje7h09KhBn+7eSxe9qxkt9i/5DKz A5PH454zbB5LlvxkCmCK4rJJSc3JLEst0rdL4MrYcewHY0G7asWD17OYGxinynUxcnJICJhI zPy8kB3CFpO4cG89WxcjF4eQwFFGiXs3f7NCOMsYJdY0T2UBqeIV0JY4vf8jK4jNIqAi8afv ECOIzSZgIXHzRyMbiC0qECzxs303E0S9oMTJmU/AekUEfCRe75nADGILC3hKbLl6GmrbTEaJ 2+8PgzVwClhJPJ/4DKyIWcBA4siiOawQtrxE89bZYHEhoCMamjpYJzAKzEKyYxaSlllIWhYw Mq9iFC1OLS7OTTcy1kstykwuLs7P08tLLdnECAzNg1t+6+5gXP3a8RCjAAejEg9vQqd0qBBr YllxZe4hRmkOFiVxXjvjQyFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGI3n70zJ2bN+fXZo YFh2sPcDnTO+2Tz9BgHbpn7sPqeTM3WWWsm0P1o/z/3jf+798vzRI54hij/sZjY2XPT+UN57 NCuDc8HVz984smLe61yRvReUzqC45b3iwa+vSgpul/RsZ9Se7jnvTO45ldeTFPoYy40W5bw8 vm+ugXUUm2/qVqW2a3Jr1JVYijMSDbWYi4oTAXcww4cuAgAA
Archived-At: <>
Subject: Re: [AVTCORE] Slight rewording on Selective Forwarding Middlebox
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Apr 2015 10:43:19 -0000

Hi Bernard,

On 2015-03-31 18:42, Bernard Aboba wrote:
> The problem is that devices using the term  selective forwarding
> middlebox or Selective Forwarding Unit (SFU) can operate in more than
> one topology.  
> For example, instead of allowing SSRCs present in the session to be
> visible, some SFUs allocate their own SSRCs and thus operate more like a
> mixer. 

Yes but let us look at the respective behaviours, the first acting as a
RTP mixer that switches streams, thus selecting which of the incoming
streams are forwarded in a particular outgoing stream. The other end of
the spectrum is to project all incoming streams into each outgoing leg.
The later is what I intended to be covered by SFM description. If the
SSRC values are translated or not is less important.

> Also, a selective forwarding middlebox is not necessarily required to
> have a large number of decoder instances (although many do).  As an
> example, an SFU utilizing the "frame marking" extension discussed in
> AVTEXT at IETF 92 would presumably not require decoder instances for any
> codec, and in the case of private media, would be able to decode the
> payload since the keys would not be available. 

I agree that the SFM likely has zero decoders, the point about decoders
is however present at the receiving endpoint. There are an issue in this
that a SFM need to know the number of simultaneous decoder the endpoint

> Also, it is possible for a device to act as both an SFU and switching
> mixer, so these are not orthogonal dimensions. 

Yes, I agree some outgoing SSRCs may be switched, while other are
forwarded. But, that would fall under the composite topologies. This one
actually being a really good example of such one.

What I don't get out of this discussion is if anything actually need to
change in the document.



>> Date: Tue, 31 Mar 2015 10:46:35 +0200
>> From:
>> To:
>> Subject: Re: [AVTCORE] Slight rewording on Selective Forwarding Middlebox
>> WG,
>> Here is an update of the last two paragraphs taking care of some nits
>> and a rewording of the very last sentence. Thanks for Dan Wing for
> feedback.
>> Note that this topology could potentially be seen as a media
>> translator which include an on/off logic as part of its media
>> translation. The topology has the property that all SSRCs present in
>> the session are visible to an endpoint. It also has mixer aspects,
>> as the streams it provides are not basically translated version, but
>> instead they have conceptual property assigned to them and can be
>> both turned on/off as well as being fully or partially delivered.
>> Thus this topology appears to be some hybrid between the translator
>> and mixer model.
>> The differences between selective forwarding middlebox and a
>> switching mixer (Section 3.6.2) are minor, and they share most
>> properties. The above requirement on having a large number of
>> decoding instances or requiring efficient switching of decoder
>> contexts, are one point of difference. The other is how the
>> identification is performed, where the Mixer uses CSRC to provide
>> information on what is included in a particular RTP stream that
>> represent a particular concept. Selective forwarding gets the source
>> information through the SSRC, and instead uses other mechanisms to
>> indicate the streams intended usage, if needed.
>> I intended to submit an updated draft on Thursday if no objections are
> made.
>> Cheers
>> Magnus Westerlund
>> ----------------------------------------------------------------------
>> Services, Media and Network features, Ericsson Research EAB/TXM
>> ----------------------------------------------------------------------
>> Ericsson AB | Phone +46 10 7148287
>> Färögatan 6 | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden | mailto:
>> ----------------------------------------------------------------------
>> _______________________________________________
>> Audio/Video Transport Core Maintenance


Magnus Westerlund

Services, Media and Network features, Ericsson Research EAB/TXM
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: