Re: [AVTCORE] Slight rewording on Selective Forwarding Middlebox

Bernard Aboba <> Tue, 31 March 2015 16:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 831901A0140 for <>; Tue, 31 Mar 2015 09:42:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d4P6tLAxC1Yf for <>; Tue, 31 Mar 2015 09:42:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CF9F31A00B0 for <>; Tue, 31 Mar 2015 09:42:23 -0700 (PDT)
Received: from BLU181-W93 ([]) by over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 31 Mar 2015 09:42:22 -0700
X-TMN: [7F7rDaGv3zWDXIXFmtVLpu59m6+QrxTU]
X-Originating-Email: []
Message-ID: <BLU181-W9331685ED48AAC16F9AE4093F40@phx.gbl>
Content-Type: multipart/alternative; boundary="_bafd61e0-7f95-486f-a675-6a39bc0ed2dc_"
From: Bernard Aboba <>
To: Magnus Westerlund <>, "" <>
Date: Tue, 31 Mar 2015 09:42:21 -0700
Importance: Normal
In-Reply-To: <>
References: <> <>,<>
MIME-Version: 1.0
X-OriginalArrivalTime: 31 Mar 2015 16:42:22.0924 (UTC) FILETIME=[A97728C0:01D06BD1]
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: Tue, 31 Mar 2015 16:42:26 -0000

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. 
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. 
Also, it is possible for a device to act as both an SFU and switching mixer, so these are not orthogonal dimensions. 

> 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