Subject: Re: [AVTCORE] Slight rewording on Selective Forwarding Middlebox

From: Magnus Westerlund <[email-masked]>
Date: Wed, 1 Apr 2015 12:43:12 +0200

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: [email-masked]
>> To: [email-masked]
>> 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: [email-masked]
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/avt

-- 

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: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 1 Apr 2015 12:46:41 +0200

On 2015-03-31 19:15, Roni Even wrote:
> I am wondering how collisions
> are detected if the SFM uses the same source address for all streams
> he is sending (SSRC multiplexing) 

The reason that having the capability of translating the SSRC values is
desirable is to avoid the SSRC collision issue. If one do not translate
the SSRCs then one need to ensure that any joining endpoint doesn't use
the SSRCs already present in the RTP session, or is forced to change by
sending it the used SSRC. However, the more reliable way is likely
signalling.

Cheers

Magnus Westerlund