Re: [AVTCORE] Slight rewording on Selective Forwarding Middlebox

[Magnus Westerlund <[e-mail]>]

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

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

Cheers

Magnus

> 
> 
> 
>> Date: Tue, 31 Mar 2015 10:46:35 +0200
>> From: [e-mail]
>> To: [e-mail]
>> 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 [phone]
>> Färögatan 6 | Mobile [phone]
>> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/avt


-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------