Re: [rtcweb] Draft proposal for updating Multiparty topologies in draft-ietf-rtcweb-rtp-usage

["Roni Even" <[e-mail]>]

Hi Magnus,
I am OK with the text.
Do you think that for Multiparty we should state that a mixed conference
(WebRTC and non WebRTC participants) is possible and should also support
these rules.
 
Roni 


> -----Original Message-----
> From: rtcweb [mailto:[e-mail]] On Behalf Of Magnus
> Westerlund
> Sent: 15 April, 2014 6:14 PM
> To: Harald Alvestrand; [e-mail]
> Subject: Re: [rtcweb] Draft proposal for updating Multiparty topologies in
draft-
> ietf-rtcweb-rtp-usage
> 
> Hi,
> 
> I have considered these comments and are okay with modifying the
> recommendation. I have modified the proposed text from Harald somewhat.
> My proposal is the following:
> 
> 
>    WebRTC implementations of RTP endpoints implemented according to this
>    memo are expected to support all the topologies described in
>    [I-D.ietf-avtcore-rtp-topologies-update] where the RTP endpoints send
>    and receive unicast RTP packet streams to and from some peer device,
>    provided that peer can participate in performing congestion control
>    on the RTP packet streams.  The peer device could be another RTP
>    endpoint, or it could be an RTP middlebox that redistributes the RTP
>    packet streams to other RTP endpoints.  This limitation means that
>    some of the RTP middlebox-based topologies are not suitable for use
>    in the WebRTC environment.  Specifically:
> 
>    o  Video switching MCUs (Topo-Video-switch-MCU) SHOULD NOT be used,
>       since they make the use of RTCP for congestion control and quality
>       of service reports problematic (see Section 3.8 of
>       [I-D.ietf-avtcore-rtp-topologies-update]).
> 
>    o  The Relay-Transport Translator (Topo-PtM-Trn-Translator) topology
>       SHOULD NOT be used because its safe use requires a point to
>       multipoint congestion control algorithm or RTP circuit breaker,
>       which has not yet been standardised.
> 
>    The following topology may be used, however it has considerations
>    worth noting:
> 
>    o  Content modifying MCUs with RTCP termination (Topo-RTCP-
>       terminating-MCU) MAY be used.  Note that in this RTP Topology, RTP
>       loop detection and identification of active senders is the
>       responsibility of the WebRTC application; since the clients are
>       isolated from each other at the RTP layer, RTP cannot assist with
>       these functions (see section 3.9 of
>       [I-D.ietf-avtcore-rtp-topologies-update]).
> 
> 
> Please provide feedback on this text!
> 
> Please see further response to questions and comments inline below.
> 
> 
> On 2014-04-07 15:44, Harald Alvestrand wrote:
> > On 04/07/2014 01:15 PM, Magnus Westerlund wrote:
> >> On 2014-04-07 10:12, Harald Alvestrand wrote:
> 
> >>> In my (strong) opinion: This recommendation is wrong.
> >>>
> >>> All central conferencing units that use individual RTP sessions with
> >>> clients fall into this category. This includes, I believe, every
> >>> single multiuser video conferencing system based on WebRTC in
> >>> existence (and there are many of them).
> >> Do they? The point of this topology is that it terminates the source
> >> identification and hides when it is performing any type of mixing or
> >> switching operation. You can perform this with a back to back RTP
> >> session style without breaking this property. Just by correctly
> >> linking information between the sessions.
> >
> > Is there a definition for "correctly linking information"?
> > In particular, are you thinking of mappings that preserve SSRC?
> > Because that's not the ones I'm thinking of.
> 
> The correctly linking information is mostly a question of preserving
CNAMEs
> across the middlebox to ensure that an end-point can determine
> synchronization contexts, and origin if CSRC are used. As we add
additional
> meta data about streams they may also needs to preserved depending on
> scope. Here it becomes a question of how one deals with APPID and MSID.
> 
> Preserving SSRC is a choice, if one does it then loop detection works, if
one
> doesn't preserve it it doesn't. Preserving it avoids having to remap any
> information that have global scope across the legs.
> 
> It becomes a choice on what complexities one needs to handle, common
> uniqueness requirements versus remapping I think is the major trade-off.
> 
> >
> >>   Which means that the individual RTP session is from the
> >> identification part inseparable from an SFM or classic RTP mixer.
> >> Only the SSRC level loop detection gets impacted.
> >>
> >> I do understand that people have implemented it this way.
> >> Implementation are not necessarily equivalent to recommended practice.
> >
> > But when there's one common practice, and no recommended practice,
> > that might be a gentle hint that there's a reason why people are doing
> > it - indeed, it might be worth making it a recommended practice.
> 
> You are welcome to propose changes regarding this to the topologies-update
> document in AVTCORE WG.
> 
> >>
> >>> I believe the recommendation should be:
> >>>
> >>> * Content modifying MCUs with RTCP termination
> >>> (Topo-RTCP-terminating-MCU) MAY be used. Note that in this scenario,
> >>> RTP loop detection and identification of active senders is the
> >>> resposibility of the application; since the clients are isolated
> >>> from each other at the RTP layer, RTP cannot assist with these
functions.
> >>>
> >> If this topology was without issues, then one would simply remove the
> >> bullet, and let it fall under the general clause. However, it clearly
> >> needs that warning. Which results in this topology being both
> >> positively and negatively treated in regards to the other "you may
> >> encounter this topology".
> >
> > It might need that warning - I'm not sure it's a real issue; loop
> > detection is only an issue when you have potential loops, and in a
> > single-mixer architecture, that potential is minimal (each endpoint
> > knows perfectly well the difference between what it's sourcing and
> > what it's receiving). Identification of active senders can be an
> > application-layer thing.
> 
> Yes, I agree that in a basic conference application with only a single
server
> instance this is unlikely to form a loop. If one starts doing more complex
things,
> including multi-server conferences or PeerConnection Meshes things become
> more complex. The later we anyway have removed the RTP loop detection due
> to the CNAME being unique on PeerConnection level, but I do think that is
the
> right trade-off from privacy point of view.
> 
> >
> > Anyway, I stand by my statement: SHOULD NOT is the wrong thing to say.
> 
> I do accept this, and are willing to change the recommendation.
> 
> 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]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb