Re: [rtcweb] Definitions of WebRTC entities

[Colin Perkins <[e-mail]>]

On 15 Oct 2014, at 18:26, Harald Alvestrand <[e-mail]> wrote:
> On 10/15/2014 06:55 PM, Rauschenbach, Uwe (NSN - DE/Munich) wrote:
>> Hi Harald, all,
>> 
>> I concur with Albrecht w.r.t. the meaning of "WebRTC endpoint". You mention below that "endpoint" is included mainly because it is used in the rtp-usage draft. But an "RTP endpoint" (a source and/or destination of RTP streams) may be different from a "WebRTC endpoint" (e.g. a mixing device).
> To be more precise: The term "WebRTC endpoint" is used in the rtp-usage draft. Three times.
>> 
>> I believe that in the RTP usage draft, the meaning of "endpoint" is usually "RTP endpoint" with the interpretation "RTP endpoint that supports WebRTC". Terms used as well are "WebRTC implementations of RTP endpoints" and "WebRTC implementation". If we interpret "endpoint" that way, and maybe do some editorial update of -rtp-usage replacing "WebRTC endpoint" with "WebRTC implementation" or "WebRTC-aware endpoint" (I can volunteer to write a proposal), there will be no clash with the proposal to drop "WebRTC endpoint" from -overview.
> 
> “WebRTC implementation" is defined nowhere, so I'm happy to have that term removed from service.

Once we decide on the desired terms, we can align the RTP usage draft with them. 

>> The more neutral "device" for WebRTC entities allows to include entities that may not be the original source or final sink of RTP media streams. "Entity" would be an alternative for "Device" but I seem to recall there was dislike for that term previously.
> 
> I would be happy to exclude devices that are participating in, but not terminating, an RTP session (such as RTP translators and other quasi-multicast devices) from consideration in this set of documents.
> 
> I think we already have strong advice against them:
> 
>  "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 congestion
>      control algorithm or RTP circuit breaker that handles point to
>      multipoint, which has not yet been standardised.
> 
> "
> 
> If we were to start talking about them, this is a topic of far more wide-ranging debate than mere terminology.

There are allowed topologies with RTP mixers and translators where a device participates in, but does not terminate, an RTP session, and the RTP usage draft needs to refer to such middleboxes in places. I’m not sure we need a WebRTC-specific term for such a middlebox for the RTP usage draft, though.


-- 
Colin Perkins
https://csperkins.org/