Re: [rtcweb] Definitions of WebRTC entities

"Rauschenbach, Uwe (NSN - DE/Munich)" <uwe.rauschenbach@nsn.com> Wed, 15 October 2014 16:56 UTC

Return-Path: <uwe.rauschenbach@nsn.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991B21A8A27 for <rtcweb@ietfa.amsl.com>; Wed, 15 Oct 2014 09:56:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wa4zfZ0OieD for <rtcweb@ietfa.amsl.com>; Wed, 15 Oct 2014 09:56:07 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 004BA1A8A10 for <rtcweb@ietf.org>; Wed, 15 Oct 2014 09:56:06 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s9FGu0Gm002551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Oct 2014 16:56:01 GMT
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s9FGtvr2014530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Oct 2014 18:55:57 +0200
Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 15 Oct 2014 18:55:57 +0200
Received: from DEMUMBX005.nsn-intra.net ([169.254.5.176]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0195.001; Wed, 15 Oct 2014 18:55:57 +0200
From: "Rauschenbach, Uwe (NSN - DE/Munich)" <uwe.rauschenbach@nsn.com>
To: "ext Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com>, Harald Alvestrand <harald@alvestrand.no>, ext Parthasarathi R <partha@parthasarathi.co.in>, 'Christer Holmberg' <christer.holmberg@ericsson.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Definitions of WebRTC entities
Thread-Index: AQHP3t3hUWjlVh63kk6YNu/uIc2KBpweJDoAgAAM5gCAAE3fgIAAAswAgAY0V4CAAAcDgIABkGkAgADwDACACQFVAIAApGuA///1UoCAABBLAIAAUpHg
Date: Wed, 15 Oct 2014 16:55:56 +0000
Message-ID: <56C2F665D49E0341B9DF5938005ACDF8194C1087@DEMUMBX005.nsn-intra.net>
References: <542E53D2.5040500@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D465376@ESESSMB209.ericsson.se> <C45C84E3-FC63-4DF6-ABDE-701FC7584E3C@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D465985@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465A34@ESESSMB209.ericsson.se> <00f501cfe24a$b8515930$28f40b90$@co.in> <543418D5.8010509@alvestrand.no> <006301cfe316$6d3c5590$47b500b0$@co.in> <54363216.3060700@alvestrand.no> <010d01cfe80f$1c8e3930$55aaab90$@co.in> <56C2F665D49E0341B9DF5938005ACDF8194C0459@DEMUMBX005.nsn-intra.net> <543E40E7.4030609@alvestrand.no> <786615F3A85DF44AA2A76164A71FE1AC3418E0@FR711WXCHMBA03.zeu.alcatel-lucent.com>
In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC3418E0@FR711WXCHMBA03.zeu.alcatel-lucent.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.119]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 9382
X-purgate-ID: 151667::1413392161-0000437E-B7BE1F8B/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sp7PfBhMAl1hLb8YUT0OQdrR7sc
Subject: Re: [rtcweb] Definitions of WebRTC entities
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Oct 2014 16:56:10 -0000

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

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.

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. 

Kind regards,
Uwe 


> -----Original Message-----
> From: ext Schwarz, Albrecht (Albrecht)
> [mailto:albrecht.schwarz@alcatel-lucent.com]
> Sent: Wednesday, October 15, 2014 12:38 PM
> To: Harald Alvestrand; Rauschenbach, Uwe (NSN - DE/Munich); ext
> Parthasarathi R; 'Christer Holmberg'; rtcweb@ietf.org
> Subject: RE: [rtcweb] Definitions of WebRTC entities
> 
> I'm also reluctant using "endpoint" as qualifier for WebRTC entities
> because in communication networks the notion of endpoint is
> fundamentally tight to a protocol (layer) (see e.g. (N)-connection-
> endpoint in ITU-T X.200).
> Now, "WebRTC" is not a single protocol, rather a suite of protocols in
> concert.
> E.g., we got
> (DTLS)-connection-endpoints,
> (SCTP)-connection-endpoints,
> (UDP)-connection-endpoints,
> (RTP)-connection-endpoints,
> etc
> within an WebRTC entity.
> 
> Two cents from my side, of course you may always expand these OSI-ISO
> base terms towards an (WebRTC)-endpoint (by highlighting the service
> access point aspects and the "(WebRTC)-connection" concept).
> 
> -Albrecht
> 
> 
> 
> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald
> Alvestrand
> Sent: Mittwoch, 15. Oktober 2014 11:40
> To: Rauschenbach, Uwe (NSN - DE/Munich); ext Parthasarathi R; 'Christer
> Holmberg'; rtcweb@ietf.org
> Subject: Re: [rtcweb] Definitions of WebRTC entities
> 
> On 10/15/2014 10:47 AM, Rauschenbach, Uwe (NSN - DE/Munich) wrote:
> > Hi Harald,
> >
> > I wonder whether we can simplify the set of terms by removing "WebRTC
> endpoint".
> 
> The reason for adding it was that it was already used in the RTCWEB RTP
> document, in harmony with the usage of "endpoint" in other RTP-releated
> specs.
> 
> I'll take others' input on whether it's worth removing the term or
> keeping it.
> 
> Note - from a strictly formalistic point of view, replacing all
> occurences of "WebRTC device" with "WebRTC endpoint" would have exactly
> the same effect. But the terms feel more comfortable to use in
> different contexts.
> 
> >
> > What was the reason for introducing the term "WebRTC endpoint"?
> Wouldn't it be enough to have "WebRTC UA", "WebRTC device" and "WebRTC-
> compatible device" (plus WebRTC gateway as special widespread case of
> compatible device)?
> >
> >
> > A slight change in the chain of terms in -overview-12 could reduce
> the number of definitions without losing meaning (I think):
> >
> >
> > 1) A WebRTC User Agent (also called a WebRTC UA or a WebRTC browser)
> is something that conforms to both the protocol specification and the
> Javascript API defined above. A WebRTC User Agent conforms to both the
> protocol specification and the Javascript API.
> > --> keep as is
> >
> > 2) A WebRTC device is something that conforms to the protocol
> specification, but does not claim to implement the Javascript API.
> > --> replace "claim" by "have". This results in <WebRTC UA> IS-A
> <WebRTC device> and we can pull out "WebRTC endpoint". (This is also
> better in line than the current chain with the statement in the draft
> "All WebRTC browsers (UAs) are WebRTC devices, so any requirement on a
> WebRTC device also applies to a WebRTC browser"
> >
> > 3) A WebRTC endpoint is either a WebRTC User Agent or a WebRTC
> device.
> > --> delete
> >
> > 4) A WebRTC-compatible endpoint is an endpoint that is capable of
> successfully communicating with a WebRTC endpoint, but may fail to meet
> some requirements of a WebRTC endpoint.  This may limit where in the
> network such an endpoint can be attached, or may limit the security
> guarantees that it offers to others.
> > --> replace "endpoint" by "device"
> >
> > 5) A WebRTC gateway is a WebRTC-compatible endpoint that mediates
> traffic to non-WebRTC entities.
> > --> replace "endpoint" by "device"
> >
> > Kind regards,
> > Uwe
> >
> >
> >
> >> -----Original Message-----
> >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext
> >> Parthasarathi R
> >> Sent: Wednesday, October 15, 2014 2:30 AM
> >> To: 'Harald Alvestrand'; 'Christer Holmberg'; rtcweb@ietf.org
> >> Subject: Re: [rtcweb] Definitions of WebRTC entities
> >>
> >> Hi Harald,
> >>
> >> <snip>
> >>>>> 2) It is not required to be endpoint but it shall be middle box.
> >>>> What do you mean by "middle box"? Again, that term is slippery.
> >>> <Partha> I intent to say that the entity which is between two
> >>> endpoints and it does not end any media session itself. Here, The
> >>> confusion is that WebRTC compatible endpoint which is not an
> >>> endpoint but it is a middle box. </Partha>
> >> Seems that this entity (whatever it's called) isn't an endpoint at
> >> all, so defining terms for endpoints shouldn't be relevant to
> >> whatever this device is.
> >>
> >> There's always more boxes in the middle..... although as long as
> they
> >> don't have the DTLS keys, it's limited what they can do to the
> packets.
> >> <snip>
> >>
> >> Could you please update the terminology as "WebRTC compatible
> device"
> >> instead of WebRTC compatible endpoint as the entity is not required
> >> to be endpoint.
> >>
> >> Thanks
> >> Partha.
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Harald Alvestrand [mailto:harald@alvestrand.no]
> >>> Sent: Thursday, October 09, 2014 12:29 PM
> >>> To: Parthasarathi R; 'Christer Holmberg'; rtcweb@ietf.org
> >>> Subject: Re: [rtcweb] Definitions of WebRTC entities
> >>>
> >>> On 10/08/2014 06:39 PM, Parthasarathi R wrote:
> >>>> Hi Harald,
> >>>>
> >>>> Please read inline.
> >>>>
> >>>> Thanks
> >>>> Partha
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Harald Alvestrand [mailto:harald@alvestrand.no]
> >>>>> Sent: Tuesday, October 07, 2014 10:16 PM
> >>>>> To: Parthasarathi R; 'Christer Holmberg'; rtcweb@ietf.org
> >>>>> Subject: Re: [rtcweb] Definitions of WebRTC entities
> >>>>>
> >>>>> On 10/07/2014 06:21 PM, Parthasarathi R wrote:
> >>>>>> Hi Christer,
> >>>>>>
> >>>>>> I have no issue with WebRTC User Agent, WebRTC device, WebRTC
> >>>>> endpoint.
> >>>>>> I have bit trouble with WebRTC compatible endpoint as a entity
> >> name
> >>>>> as
> >>>>>> 1) It may pass SRTP/data channel
> >>>>> What do you mean by "pass"? That's a slippery term.
> >>>> <Partha> "relay" will be more appropriate term as mentioned in Sec
> >> 5
> >>> Para 2 of draft-alvestrand-rtcweb-gateways. </Partha>
> >>>>>> 2) It is not required to be endpoint but it shall be middle box.
> >>>>> What do you mean by "middle box"? Again, that term is slippery.
> >>>> <Partha> I intent to say that the entity which is between two
> >>> endpoints and it does not end any media session itself. Here, The
> >>> confusion is that WebRTC compatible endpoint which is not an
> >>> endpoint but it is a middle box. </Partha>
> >>>
> >>> Seems that this entity (whatever it's called) isn't an endpoint at
> >> all,
> >>> so defining terms for endpoints shouldn't be relevant to whatever
> >> this
> >>> device is.
> >>>
> >>> There's always more boxes in the middle..... although as long as
> >>> they don't have the DTLS keys, it's limited what they can do to the
> >> packets.
> >>>
> >>>
> >>>>>> WebRTC gateway looks more appropriate entity name in those
> >>> scenarios.
> >>>>> As written in my proposal, a WebRTC gateway is a WebRTC
> compatible
> >>>>> endpoint.
> >>>>>
> >>>> <Partha> As per your proposal, we need to define WebRTC compatible
> >>> endpoint first which is super set of WebRTC gateway. Then, we need
> >>> to clarify which kind of WebRTC compatible endpoint qualify as
> >>> WebRTC gateway. But Christer wishes to have only two definition
> >> (Full/Subset).
> >>> </Partha>
> >>>
> >>> And I don't agree with Christer, so then we're two :-)
> >> _______________________________________________
> >> rtcweb mailing list
> >> rtcweb@ietf.org
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb