Subject: [rtcweb] Definitions of WebRTC entities

From: Harald Alvestrand <[email-masked]>
Date: Fri, 03 Oct 2014 09:44:18 +0200

After all the feedback, I've taken another whack at this.

It seems that the term "WebRTC endpoint" is already used widely enough 
that it's worth continuing to use it. So I ended up with the following 
suggested text for -overview's definitions.

Comments?
If this seems OK, I'll emit another -overview next week with these 
definitions.

--------------------------

    o  A WebRTC User Agent (also called an UA or browser) is something 
that conforms to both the protocol specification and the Javascript API 
defined above.

    o  A WebRTC device is something that conforms to the protocol
       specification, but does not claim to implement the Javascript API.

    o  A WebRTC endpoint is either a WebRTC UA or a WebRTC device.

    o  A WebRTC-compatible endpoint is an endpoint that is capable of 
successfully communicating with a WebRTC endpoint, but may fail to meet 
some requirement of the 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.

    o  A WebRTC gateway is a WebRTC-compatible endpoint that mediates 
media traffic to non-WebRTC entities.

-----------------------------

FOR TRANSPORT:

A WebRTC-compatible endpoint is capable of inititating or accepting a 
session with a WebRTC endpoint. The following requirements on a WebRTC 
endpoint are not required for such success:

- Support for full ICE. If the endpoint is only ever going to be 
attached to the public Internet, it does not need to be able to fix its 
own external address; ICE-Lite is enough.
- Support for the full suite of MTI codecs for a WebRTC endpoint. In 
particular, audio gateways that connect to native G.711 networks may 
choose to implement G.711 and not implement Opus.
- Offering BUNDLE or RTCP-MUX
- Using MSID in its offers or answers
<should congestion cutoff requirement be in or out?>
<there will be more>

Note that support for DTLS, ICE and TURN ARE required for a 
WebRTC-compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST be 
used.

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Fri, 3 Oct 2014 11:23:10 +0000

> WebRTC-compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST be
[Raju] Though a typical WebRTC-compatible endpoint requires TURN, I don't think WebRTC gateway requires TURN handling. TURN should probably be tied to the use of full ICE or private ip; if you have public ip and use ice-lite then TURN support is not required.

BR
Raju

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 Oct 2014 12:01:20 +0000

Hi,

First, I personally see no need for all these definitions.

I think it would be enough to have:

- WebRTC endpoint (e.g. a browser)
- WebRTC-compatible endpoint (e.g. a gateway)

If people really think we need more, I won't argue against. I just think it becomes very messy, and people WILL end up using the wrong terminology :)

Second, you say:

	"Note that support for DTLS, ICE and TURN ARE required for a WebRTC-compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST be used."

You already in the bullet list said support of ICE lite, so the text is conflicting. 

I am not sure what you mean by "support for TURN". An ICE lite endpoint will not create TURN candidates etc. Of course, it may receive media via a TURN server.

What do you mean by "support for DTLS"? I think you need to be a little more specific (later you do mention DTLS-SRTP in case of RTP).

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: 3. lokakuuta 2014 10:44
To: [email-masked]
Subject: [rtcweb] Definitions of WebRTC entities

It seems that the term "WebRTC endpoint" is already used widely enough that it's worth continuing to use it. So I ended up with the following suggested text for -overview's definitions.

Comments?
If this seems OK, I'll emit another -overview next week with these definitions.

    o  A WebRTC User Agent (also called an UA or browser) is something that conforms to both the protocol specification and the Javascript API defined above.

    o  A WebRTC-compatible endpoint is an endpoint that is capable of successfully communicating with a WebRTC endpoint, but may fail to meet some requirement of the 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.

    o  A WebRTC gateway is a WebRTC-compatible endpoint that mediates media traffic to non-WebRTC entities.

FOR TRANSPORT:

A WebRTC-compatible endpoint is capable of inititating or accepting a session with a WebRTC endpoint. The following requirements on a WebRTC endpoint are not required for such success:

- Support for full ICE. If the endpoint is only ever going to be attached to the public Internet, it does not need to be able to fix its own external address; ICE-Lite is enough.
- Support for the full suite of MTI codecs for a WebRTC endpoint. In particular, audio gateways that connect to native G.711 networks may choose to implement G.711 and not implement Opus.
- Offering BUNDLE or RTCP-MUX
- Using MSID in its offers or answers
<should congestion cutoff requirement be in or out?> <there will be more>

Note that support for DTLS, ICE and TURN ARE required for a WebRTC-compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST be used.

_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 03 Oct 2014 14:47:30 +0200

Yup, turn is wrong. And ice needs to be made more precise - point is, without any ice, things will not work at all.

DTLS: A webrtc endpoint either uses data channels, which require dtls, or rtp, whuch requires DTLS-srtp, which requires dtls, so I figured it was safe to say that dtls was required.

Den 3. oktober 2014 14:01:20 CEST, skrev Christer Holmberg <[email-masked]>:
>If people really think we need more, I won't argue against. I just
>think it becomes very messy, and people WILL end up using the wrong
>terminology :)
>
>
>Second, you say:
>
>	"Note that support for DTLS, ICE and TURN ARE required for a
>WebRTC-compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST
>be used."
>
>I am not sure what you mean by "support for TURN". An ICE lite endpoint
>will not create TURN candidates etc. Of course, it may receive media
>via a TURN server.
>
>What do you mean by "support for DTLS"? I think you need to be a little
>more specific (later you do mention DTLS-SRTP in case of RTP).
>
>Regards,
>
>Christer
>
>
>
>
>o  A WebRTC User Agent (also called an UA or browser) is something that
>conforms to both the protocol specification and the Javascript API
>defined above.
>
>WebRTC-compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST
>be used.
>
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 Oct 2014 17:26:13 +0000

Hi,

>Yup, turn is wrong. And ice needs to be made more precise - point is, >without any ice, things will not work at all.
Agree. But, I think the bullet talking about “ICE lite” is enough.

>DTLS: A webrtc endpoint either uses data channels, which require dtls, >or rtp, whuch requires DTLS-srtp, which requires dtls, so I figured it >was safe to say that dtls was required.
I think it would be better to explicitly indicate the usages for which DTLS needs to be supported, ie DTLS-SRTP for RTP and as defined for data channels.
Because, DTLS can be used for many different purposes, in different ways, so just saying “support DTLS” is unclear.
Regards,
Christer

Den 3. oktober 2014 14:01:20 CEST, skrev Christer Holmberg <[email-masked]<mailto:[email-masked]>>:

Hi,

Second, you say:

What do you mean by "support for DTLS"? I think you need to be a little more specific (later you do mention DTLS-SRTP in case of

RTP).

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: 3. lokakuuta 2014 10:44
To: [email-masked]<mailto:[email-masked]>
Subject: [rtcweb] Definitions of WebRTC entities

Comments?

    o  A WebRTC device is something that conforms to the protocol
       specification, but does not

claim to implement the Javascript API.

FOR TRANSPORT:

- Support for full ICE. If the endpoint is only ever going to be attached to the public Internet, it does not need to be able to fix its own external address;

ICE-Lite is enough.

________________________________

rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 Oct 2014 17:36:14 +0000

Hi,

>Because, DTLS can be used for many different purposes, in different ways, so just saying “support DTLS” is unclear.

In addition, it is probably useful to indicate that an compatible endpoint may not necessarily terminate all DTLS usages. For example, a gateway might simply pass through the data channel, and/or the SRTP traffic.

Regards,

Christer

Second, you say:

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: 3. lokakuuta 2014 10:44
To: [email-masked]
Subject: [rtcweb] Definitions of WebRTC entities

Comments?

FOR TRANSPORT:

Note that support for DTLS, ICE and TURN ARE required for a WebRTC-compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST be used.
________________________________________

rtcweb mailing list
[email-masked]

---

From: Silvia Pfeiffer <[email-masked]>
Date: Sat, 4 Oct 2014 06:41:23 +1000

These are good!

definitions.
>    o  A WebRTC endpoint is either a WebRTC UA or a WebRTC device.

Since a webrtc UA is a superset of a webrtc device, webrtc endpoint and
webrtc device end up meaning the same, don't they?

session with a WebRTC endpoint. The following requirements on a WebRTC
endpoint are not required for such success:
>
> - Support for full ICE. If the endpoint is only ever going to be attached
to the public Internet, it does not need to be able to fix its own external
address; ICE-Lite is enough.
> - Support for the full suite of MTI codecs for a WebRTC endpoint. In
particular, audio gateways that connect to native G.711 networks may choose
to implement G.711 and not implement Opus.

Is your intent to specify which parts of the protocol are not required to
be supported by webrtc-compatible endpoints in a rfc? I think it would be
useful...

Silvia.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 06 Oct 2014 11:55:43 +0200

Den 03. okt. 2014 22:41, skrev Silvia Pfeiffer:
>
> These are good!
>
> On 3 Oct 2014 17:44, "Harald Alvestrand" <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >
> > It seems that the term "WebRTC endpoint" is already used widely 
> enough that it's worth continuing to use it. So I ended up with the 
> following suggested text for -overview's definitions.
> >
> > Comments?
> >    o  A WebRTC User Agent (also called an UA or browser) is 
> something that conforms to both the protocol specification and the 
> Javascript API defined above.
> >
> Since a webrtc UA is a superset of a webrtc device, webrtc endpoint 
> and webrtc device end up meaning the same, don't they?
>
> successfully communicating with a WebRTC endpoint, but may fail to 
> meet some requirement of the 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.
> >
> > A WebRTC-compatible endpoint is capable of inititating or accepting 
> a session with a WebRTC endpoint. The following requirements on a 
> WebRTC endpoint are not required for such success:
> >
> attached to the public Internet, it does not need to be able to fix 
> its own external address; ICE-Lite is enough.
> Is your intent to specify which parts of the protocol are not required 
> to be supported by webrtc-compatible endpoints in a rfc? I think it 
> would be useful...
>

Yes, -transport is intended to be published as an RFC. So is 
draft-alvestrand-rtcweb-gateways (if the group accepts it).

> > [email-masked] <mailto:[email-masked]>

---

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 7 Oct 2014 21:51:07 +0530

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 
2) It is not required to be endpoint but it shall be middle box.

WebRTC gateway looks more appropriate entity name in those scenarios.

Thanks
Partha

> From: rtcweb [mailto:[email-masked]] On Behalf Of Christer
> Holmberg
> Sent: Friday, October 03, 2014 11:06 PM
> To: Harald Alvestrand; [email-masked]
> Subject: Re: [rtcweb] Definitions of WebRTC entities
> 
> Hi,
> 
> >>DTLS: A webrtc endpoint either uses data channels, which require
> dtls, or rtp, whuch requires DTLS-srtp, which requires dtls, so I
> figured it
> >>was safe to say that dtls was required.
> >
> >I think it would be better to explicitly indicate the usages for which
> DTLS needs to be supported, ie DTLS-SRTP for RTP and as defined for
> data channels.
> >Because, DTLS can be used for many different purposes, in different
> ways, so just saying “support DTLS” is unclear.
> 
> In addition, it is probably useful to indicate that an compatible
> endpoint may not necessarily terminate all DTLS usages. For example, a
> gateway might simply pass through the data channel, and/or the SRTP
> traffic.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> 
>  "Note that support for DTLS, ICE and TURN ARE required for a WebRTC-
> compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST be
> used."
> 
> Note that support for DTLS, ICE and TURN ARE required for a WebRTC-
> compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST be used.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 07 Oct 2014 18:46:13 +0200

> 1) It may pass SRTP/data channel 
What do you mean by "pass"? That's a slippery term.
> 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.
> WebRTC gateway looks more appropriate entity name in those scenarios.

As written in my proposal, a WebRTC gateway is a WebRTC compatible endpoint.

I think you will have to describe more fully what the device you are
thinking about looks like; if it's just the WebRTC endpoint functions
scattered over a set of boxes, it's possible I may call it a
"distributed WebRTC-compatible endpoint".

-- 
Surveillance is pervasive. Go Dark.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Oct 2014 17:14:07 +0000

Hi,

In my opinion we have TWO types of ENDPOINTS: those that support the full set of RTCWEB toolset (e.g. browsers) and those who support a subset (e.g. gateways).

I don't really care what we call them, but we shouldn't come up with lots of different names that people are going to use wrong.

Regards,

Christer

-----Original Message-----
From: Parthasarathi R [mailto:[email-masked]] 
Sent: 07 October 2014 19:21
To: Christer Holmberg; 'Harald Alvestrand'; [email-masked]
Subject: RE: [rtcweb] Definitions of WebRTC entities

Hi Christer,

Thanks
Partha

> I am not sure what you mean by "support for TURN". An ICE lite 
> endpoint will not create TURN candidates etc. Of course, it may 
> receive media via a TURN server.
> 
> What do you mean by "support for DTLS"? I think you need to be a 
> little more specific (later you do mention DTLS-SRTP in case of RTP).
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> that conforms to both the protocol specification and the Javascript 
> API defined above.
>

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 07 Oct 2014 19:34:28 +0200

> I don't really care what we call them, but we shouldn't come up with lots of different names that people are going to use wrong.

People have also wanted to claim that something is fully
WebRTC-compliant without having a Javascript API on it. That's where the
"UA/browser" vs "Device" thing comes in.

I'm trying to make everyone happy :-)

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Oct 2014 18:27:17 +0000

Hi,

>> In my opinion we have TWO types of ENDPOINTS: those that support the >> full set of RTCWEB toolset (e.g. browsers) and those who support a subset >> (e.g. gateways).
>>
>> I don't really care what we call them, but we shouldn't come up with lots >> of different names that people are going to use wrong.
>
> People have also wanted to claim that something is fully WebRTC-compliant > without having a Javascript API on it. That's where the "UA/browser" vs 
> "Device" thing comes in.

I understand. But, why can't we then simply say "JavaScript enabled WebRTC endpoint", or something similar? 

Regards,

Christer

>> endpoint may not necessarily terminate all DTLS usages. For example, 
>> a gateway might simply pass through the data channel, and/or the SRTP 
>> traffic.
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>>
>>
>>
>> session with a WebRTC endpoint. The following requirements on a 
>> - Using MSID in its offers or answers <should congestion cutoff 
>> requirement be in or out?> <there will be
>> more>
>>

---

From: "Parthasarathi R" <[email-masked]>
Date: Wed, 8 Oct 2014 22:09:20 +0530

Hi Harald,

Please read inline.

Thanks
Partha

> From: Harald Alvestrand [mailto:[email-masked]]
> Sent: Tuesday, October 07, 2014 10:16 PM
> To: Parthasarathi R; 'Christer Holmberg'; [email-masked]
<Partha> "relay" will be more appropriate term as mentioned in Sec 5 Para 2 of draft-alvestrand-rtcweb-gateways. </Partha>

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

> As written in my proposal, a WebRTC gateway is a WebRTC compatible
<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>

> a
> WebRTC-
> >> You already in the bullet list said support of ICE lite, so the text
> is
> >> conflicting.
> >>
> endpoint
> little
> enough
> something
> API
> meet
> a
> WebRTC
> its

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 09 Oct 2014 08:58:30 +0200

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

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.

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

And I don't agree with Christer, so then we're two :-)

---

From: "Parthasarathi R" <[email-masked]>
Date: Wed, 15 Oct 2014 05:59:36 +0530

Hi Harald,

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

> Sent: Thursday, October 09, 2014 12:29 PM
> > <Partha> "relay" will be more appropriate term as mentioned in Sec 5
> Para 2 of draft-alvestrand-rtcweb-gateways. </Partha>
> >
> > <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>
> 
> > <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>
>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 15 Oct 2014 06:34:38 +0200

> Could you please update the terminology as "WebRTC compatible device" instead of WebRTC compatible endpoint as the entity is not required to be endpoint.

No.

I don't know what the device is, I don't know how to describe it, and I
don't even know if I think it should exist.

I will not define terminology for that.

---

From: "Rauschenbach, Uwe (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 15 Oct 2014 08:47:26 +0000

Hi Harald,

I wonder whether we can simplify the set of terms by removing "WebRTC endpoint".

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 

> From: rtcweb [mailto:[email-masked]] On Behalf Of ext
> Parthasarathi R
> Sent: Wednesday, October 15, 2014 2:30 AM
> To: 'Harald Alvestrand'; 'Christer Holmberg'; [email-masked]
> 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.
> 
> 
> 
> > >>> I have bit trouble with WebRTC compatible endpoint as a entity
> name
> > >> as

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 15 Oct 2014 11:39:51 +0200

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

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Wed, 15 Oct 2014 10:38:10 +0000

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:[email-masked]] On Behalf Of Harald Alvestrand
Sent: Mittwoch, 15. Oktober 2014 11:40
To: Rauschenbach, Uwe (NSN - DE/Munich); ext Parthasarathi R; 'Christer Holmberg'; [email-masked]
Subject: Re: [rtcweb] Definitions of WebRTC entities

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

>>> 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.
>>
>> instead of WebRTC compatible endpoint as the entity is not required 
>> to be endpoint.
>>
>> Thanks
>> Partha.
>>
>>
>>
>>> confusion is that WebRTC compatible endpoint which is not an 
>>> endpoint but it is a middle box. </Partha>
>>>
>>> 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.
>>>
>>>
>>> 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>
>>>

---

From: "Rauschenbach, Uwe (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 15 Oct 2014 16:55:56 +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 

> From: ext Schwarz, Albrecht (Albrecht)
> [mailto:[email-masked]]
> Sent: Wednesday, October 15, 2014 12:38 PM
> To: Harald Alvestrand; Rauschenbach, Uwe (NSN - DE/Munich); ext
> Parthasarathi R; 'Christer Holmberg'; [email-masked]
> 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).
> 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
> 
> 
> 
> 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
> > --> 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"
> >
> > 4) A WebRTC-compatible endpoint is an endpoint that is capable of
> some requirements of a WebRTC endpoint.  This may limit where in the
> they
> >> all,
> >>>>> As written in my proposal, a WebRTC gateway is a WebRTC
> compatible
> >>>>> endpoint.
> >>>>>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 15 Oct 2014 19:26:41 +0200

> 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/o…
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 implementation…

"WebRTC implementation" is defined nowhere, so I'm happy to have that 
term removed from service.

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

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.

---

From: Colin Perkins <[email-masked]>
Date: Thu, 16 Oct 2014 09:32:22 +0100

On 15 Oct 2014, at 18:26, Harald Alvestrand <[email-masked]> wrote:
> To be more precise: The term "WebRTC endpoint" is used in the rtp-usage draft. Three times.
>> 
> “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. 

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