Subject: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term?

From: Harald Alvestrand <[email-masked]>
Date: Mon, 18 Aug 2014 13:11:26 +0200

When writing the gateway document, I found myself grappling with the 
"device" description.

It is somewhat uncomfortable, in that as first defined, it requires full 
WebRTC functionality except for the API part - this means that it should 
support data channels, full ICE, bundling and so on.

But for gateways, it makes sense to let go of a lot of these 
requirements. So a gateway is not a device. But what is the name for the 
thing that a gateway is, a device is, and a browser is, that names "the 
set of things that can successfully negotiate connectivity"? And what 
are the requirements on *that*?

I see a couple of options:

- Redefine "Device" to mean "that which can successfully communicate 
with a browser". It's free to negotiate away features if it can, but 
needs to interoperate with a browser that implements only the absolute 
minimum of what a browser has to implement.

- Define a new class of "thing" which is "the thing that can talk to 
browsers" - of which a gateway has to be an exemplar.

This is a kind of word game in some ways, but when we make definitions, 
we also define what's easy to talk about. And that can influence what we 
end up building.

What do people think?

    Harald

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 18 Aug 2014 13:24:47 +0200

Hi Harald,

I always liked "endpoint" much more than "device".

We could have different types of endpoints, and define a browser like: a 
WebRTC "full" endpoint exposing the W3C WebRTC APIs.

Just my 2 cents.

Best regards
Sergio
On 18/08/2014 13:11, Harald Alvestrand wrote:
> It is somewhat uncomfortable, in that as first defined, it requires 
> full WebRTC functionality except for the API part - this means that it 
> should support data channels, full ICE, bundling and so on.
>
> requirements. So a gateway is not a device. But what is the name for 
> the thing that a gateway is, a device is, and a browser is, that names 
> "the set of things that can successfully negotiate connectivity"? And 
> what are the requirements on *that*?
>
> This is a kind of word game in some ways, but when we make 
> definitions, we also define what's easy to talk about. And that can 
> influence what we end up building.
>
> What do people think?
>
>    Harald
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 18 Aug 2014 11:40:33 +0000

Hi Harald,

How about "gw-endpoint"? in the sense that it behaves like an "endpoint" but has different requirements than an "endpoint".

BR
Raju

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Sergio Garcia Murillo
Sent: Monday, August 18, 2014 6:25 AM
To: [email-masked]
Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term?

Hi Harald,

Just my 2 cents.

Best regards
Sergio

---

From: "Parthasarathi R" <[email-masked]>
Date: Mon, 18 Aug 2014 23:04:09 +0530

Hi Harald & all,

I'm seeing that we are discussing about four WebRTC entities in three term
which is confusing. I propose the following four entities to discuss:

1) WebRTC browser (full compliant Protocol + API) - as in
draft-ietf-rtcweb-overview-10

2) WebRTC device (Full complaint protocol) - as in
draft-ietf-rtcweb-overview-10

3) Invent new WebRTC term ("WebRTC endpoint") by lowering the bar. WebRTC
endpoint mean "that the entity which can successfully communicate with a
WebRTC browser by implementing only the absolute minimum of what a WebRTC
browser has to implement". Ex: WebRTC IVR application which is hosted in the
public internet.

4) "WebRTC gateway" is entity which has the WebRTC endpoint in one side and
interwork with other entities (like SIP entities, Jingle, ISDN or WebRTC
entities) in the another side. Here, we need additional requirements in
WebRTC gateway which has to be documented in Sec 3 of
draft-alvestrand-rtcweb-gateways-00.txt. Ex additional requirements: ICE-to
Non-ICE handling, DTLS-SRTP to RTP handling.

Please let me know your opinion on the same.

Thanks
Partha

> From: rtcweb [mailto:[email-masked]] On Behalf Of Makaraju,
> Maridi Raju (Raju)
> Sent: Monday, August 18, 2014 5:11 PM
> To: [email-masked]; Harald Alvestrand
> How about "gw-endpoint"? in the sense that it behaves like an
> "endpoint" but has different requirements than an "endpoint".
> 
> BR
> Raju
> 
>

---

From: Silvia Pfeiffer <[email-masked]>
Date: Tue, 19 Aug 2014 08:09:52 +1000

> draft-ietf-rtcweb-overview-10

To me, this is a WebRTC endpoint.

> draft-ietf-rtcweb-overview-10

To me, this is a RTCWeb endpoint (it doesn't care about the browser
API, but only the stuff that is defined in the rtcweb group of IEEE).

Silvia.

---

From: Silvia Pfeiffer <[email-masked]>
Date: Tue, 19 Aug 2014 08:32:00 +1000

> API, but only the stuff that is defined in the rtcweb group of IEEE).

BTW: I don't actually mind calling this a "WebRTC device" either. Just
thought I should add this for discussion.

Cheers,
Silvia.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 19 Aug 2014 10:19:14 +0000

My thinking is that there are only two entities we need to be concerned with.

1. WebRTC Browsers that implement both the IETF protocol requirements and the W3C API in full.

2. Things that can interoperate directly with WebRTC browsers but are not browsers. These have to implement at least a minimum set of the IETF protocol and it is irrelevant as to whether they have anything link a PeerConnection API internally. I was happy with calling these WebRTC Devices and think it is useful to define the minimum set of things that they need to support.

I am not convinced that we need to define any other entities and my thinking is that gateways are just a type of WebRTC Device and we don't need to call them out explicitly.

Regards
Andy

> From: rtcweb [mailto:[email-masked]] On Behalf Of Harald
> Alvestrand
> Sent: 18 August 2014 12:11
> To: [email-masked]
> Subject: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new
> term?
> 
> full
> the

---

From: Jim Barnett <[email-masked]>
Date: Tue, 19 Aug 2014 09:38:52 -0400

I agree.  We need to define a) WebRTC browsers, which support the full 
protocol requirements and the API, b) WebRTC Endpoints/Devices, which 
support some minimum protocol set sufficient for establishing 
connectivity.  Is there also a need to define c) Full WebRTC Devices, 
which support more than the minimum protocol set?  What would be the use 
of definition c?

We know that we have to define the maximal set a) and the minimum usable 
set b).   If we can't think of a use for c) we can omit it and add extra 
profiles later if they turn out to be useful.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 19 Aug 2014 16:00:35 +0200

On 08/19/2014 03:38 PM, Jim Barnett wrote:
> which support more than the minimum protocol set?  What would be the 
> use of definition c?

An endpoint (I kind of start to like this concept/name) would be 
conformant as long as it was able to successfully negotiate away use of 
anything that makes life difficult.

It would be required to support DTLS-SRTP key handshakes and respond to 
ICE connectivity checks, plus whatever is MUST use in -rtp-usage 
(scanning, I'm not coming up with much - it's mostly MUST respond to, 
MUST implement (but not required to use) stuff). The RTP circuit breaker 
is also a MUST implement, and since it's a single-ended thing, it makes 
no sense if it isn't also MUST use.

Scanning, I'm not even sure a WebRTC endpoint is required to send RTCP - 
but I think it should be.
(Note: The -rtp-usage draft uses "WebRTC endpoint" to mean a 
fully-featured endpoint... obviously we need to harmonize at some point.)

> We know that we have to define the maximal set a) and the minimum 
> usable set b).   If we can't think of a use for c) we can omit it and 
> add extra profiles later if they turn out to be useful.

An example of c) would be a VC device based on a browser that can be 
plugged into any network (thus needing full ICE), but runs a captive 
application that cannot be made to run any other application.

It would be nice to mandate support in such a device for full ICE and 
the MTI codecs (something I think we will have trouble with mandating 
for gateways).
>> 2. Things that can interoperate directly with WebRTC browsers but are 
>> not browsers. These have to implement at least a minimum set of the 
>> IETF protocol and it is irrelevant as to whether they have anything 
>> link a PeerConnection API internally. I was happy with calling these 
>> WebRTC Devices and think it is useful to define the minimum set of 
>> things that they need to support.
>>
>> I am not convinced that we need to define any other entities and my 
>> thinking is that gateways are just a type of WebRTC Device and we 
>> don't need to call them out explicitly.
>>
>> Regards
>> Andy
>>
>>
>>
>>

---

From: Jim Barnett <[email-masked]>
Date: Tue, 19 Aug 2014 10:26:02 -0400

Does the VC device support the full protocol requirements that are 
placed on the Browser?  If so, we can still get away with defining 
minimal protocol set, full protocol set, and then say Browser = full 
protocol set + API.

On 8/19/2014 10:00 AM, Harald Alvestrand wrote:
>> I agree.  We need to define a) WebRTC browsers, which support the 
>> full protocol requirements and the API, b) WebRTC Endpoints/Devices, 
>> which support some minimum protocol set sufficient for establishing 
> conformant as long as it was able to successfully negotiate away use 
> of anything that makes life difficult.
>
> It would be required to support DTLS-SRTP key handshakes and respond 
> to ICE connectivity checks, plus whatever is MUST use in -rtp-usage 
> MUST implement (but not required to use) stuff). The RTP circuit 
> breaker is also a MUST implement, and since it's a single-ended thing, 
> it makes no sense if it isn't also MUST use.
>
> Scanning, I'm not even sure a WebRTC endpoint is required to send RTCP 
> - but I think it should be.
>>> 2. Things that can interoperate directly with WebRTC browsers but 
>>> are not browsers. These have to implement at least a minimum set of 
>>> the IETF protocol and it is irrelevant as to whether they have 
>>> anything link a PeerConnection API internally. I was happy with 
>>> calling these WebRTC Devices and think it is useful to define the 
>>> minimum set of things that they need to support.
>>>
>>>> definitions,

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Aug 2014 10:27:54 -0400

> no sense if it isn't also MUST use.

ISTM the requirement is that a foo (device, endpoint, whatever) MUST 
support at least one of:
- draft-ietf-rtcweb-data-channel
- draft-ietf-rtcweb-rtp-usage

There are quite plausible use cases for endpoints that support only data 
channels, or only rtp. But a device that doesn't support either can't 
reasonably be considered to support webrtc in any way.

	Thanks,
	Paul

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 20 Aug 2014 01:29:24 +0200

> API, but only the stuff that is defined in the rtcweb group of IEEE).

Completely agree.

Also with this definition, an ORTC browser would still be an WebRTC 
endpoint.

Best regards
Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 20 Aug 2014 01:35:30 +0200

On 19/08/2014 16:27, Paul Kyzivat wrote:
> There are quite plausible use cases for endpoints that support only 
> data channels, or only rtp. But a device that doesn't support either 
> can't reasonably be considered to support webrtc in any way.
>
Right, but there are some other entities (gateways for example) that 
without fully implementing those requirements, are still able to talk to 
an WebRTC device/endpoint/whatever.
May I suggest that we follow the ICE naming and we call that entities, 
WebRTC lite endpoints? Just a thought.. ;)

Best regards
Sergio

---

From: "Parthasarathi R" <[email-masked]>
Date: Wed, 20 Aug 2014 06:50:02 +0530

Hi Sergio/Silvia,

WebRTC browser and WebRTC device are also WebRTC endpoints as they conform
to all WebRTC end points requirements. 

Thanks
Partha

> Sent: Wednesday, August 20, 2014 4:59 AM
> To: [email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Wed, 20 Aug 2014 10:46:08 +0100

On 19 Aug 2014, at 15:00, Harald Alvestrand <[email-masked]> wrote:
>> I agree.  We need to define a) WebRTC browsers, which support the full protocol requirements and the API, b) WebRTC Endpoints/Devices, which support some minimum protocol set sufficient for establishing connectivity.  Is there also a need to define c) Full WebRTC Devices, which support more than the minimum protocol set?  What would be the use of definition c?
> 
> An endpoint (I kind of start to like this concept/name) would be conformant as long as it was able to successfully negotiate away use of anything that makes life difficult.
> 
> It would be required to support DTLS-SRTP key handshakes and respond to ICE connectivity checks, plus whatever is MUST use in -rtp-usage (scanning, I'm not coming up with much - it's mostly MUST respond to, MUST implement (but not required to use) stuff). The RTP circuit breaker is also a MUST implement, and since it's a single-ended thing, it makes no sense if it isn't also MUST use.
> 
> Scanning, I’m not even sure a WebRTC endpoint is required to send RTCP - but I think it should be.

“RTCP is a fundamental and integral part of RTP, and MUST be implemented in all WebRTC applications.” rtp-usage-16 section 4.1

> (Note: The -rtp-usage draft uses "WebRTC endpoint" to mean a fully-featured endpoint... obviously we need to harmonize at some point.)

We certainly need to make sure the terminology is consistent, but I would think that non-browser WebRTC endpoints would need to conform to rtp-usage, since that specifies what they might be sent by a WebRTC browser, what they can send to such a browser, and what needs to be negotiated. 

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

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 20 Aug 2014 12:38:20 +0200

> “RTCP is a fundamental and integral part of RTP, and MUST be implemented in all WebRTC applications.” rtp-usage-16 section 4.1

Yep, I thought we wanted that too, but then I started to scan for 
mandatory-to-implement vs mandatory-to-use, and started being unsure; is 
it permitted to configure a WebRTC device to set RTCP-bandwidth to zero 
(the traditional means of turning off RTCP in a standards conformant 
manner, I think)?

Perhaps we should add a requirement on minimum RTCP bandwidth?
> We certainly need to make sure the terminology is consistent, but I would think that non-browser WebRTC endpoints would need to conform to rtp-usage, since that specifies what they might be sent by…
Yup, it was when I started to read it from a "what can we successfully 
negotiate away" viewpoint that I started to worry about what we had in 
fact required.

---

From: Colin Perkins <[email-masked]>
Date: Wed, 20 Aug 2014 11:47:57 +0100

On 20 Aug 2014, at 11:38, Harald Alvestrand <[email-masked]> wrote:
> Yep, I thought we wanted that too, but then I started to scan for mandatory-to-implement vs mandatory-to-use, and started being unsure; is it permitted to configure a WebRTC device to set RTCP-bandwidth to zero (the traditional means of turning off RTCP in a standards conformant manner, I think)?
> 

I wouldn’t know what minimum RTCP bandwidth to specify, but could certainly change the rtp-usage draft to say “…MUST be implemented and used…” if that would help? 

> Yup, it was when I started to read it from a "what can we successfully negotiate away" viewpoint that I started to worry about what we had in fact required.

Please send concrete suggestions for changes, if there are things you think we should fix.

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

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 20 Aug 2014 12:57:05 +0200

> I wouldn’t know what minimum RTCP bandwidth to specify, but could certainly change the rtp-usage draft to say “…MUST be implemented and used…” if that would help?
Theoretically speaking, it could be possible that all RTCP packets sent 
by a peer could be lost (dropped by the network for example) and the 
communication would still possible (as long as the content 
freshness/keep alive is done via STUN/ICE). So in practice, it should be 
possible for a WebRTC endpoint communicate with  a peer not 
implementing/sending RTCP at all.

Best regards
Sergio

---

From: Varun Singh <[email-masked]>
Date: Wed, 20 Aug 2014 15:09:56 +0300

On Wed, Aug 20, 2014 at 1:57 PM, Sergio Garcia Murillo
<[email-masked]> wrote:
>>>>>> support some minimum protocol set sufficient for establishing connectivity.
>>>>>> Is there also a need to define c) Full WebRTC Devices, which support more
>>>>>> than the minimum protocol set?  What would be the use of definition c?
>>>>>
>>>>> ICE connectivity checks, plus whatever is MUST use in -rtp-usage (scanning,
>>>>> I'm not coming up with much - it's mostly MUST respond to, MUST implement
>>>>> (but not required to use) stuff). The RTP circuit breaker is also a MUST
>>>>> implement, and since it's a single-ended thing, it makes no sense if it
>>>>> isn't also MUST use.
>>>>>
>>>> “RTCP is a fundamental and integral part of RTP, and MUST be implemented
>>>> in all WebRTC applications.” rtp-usage-16 section 4.1
>>>
>>> mandatory-to-implement vs mandatory-to-use, and started being unsure; is it
>>> permitted to configure a WebRTC device to set RTCP-bandwidth to zero (the
>>> traditional means of turning off RTCP in a standards conformant manner, I
>>> think)?
>>>
>> I wouldn’t know what minimum RTCP bandwidth to specify, but could
>> certainly change the rtp-usage draft to say “…MUST be implemented and used…”
>> if that would help?
>>
> Theoretically speaking, it could be possible that all RTCP packets sent by a
> peer could be lost (dropped by the network for example) and the
> communication would still possible (as long as the content freshness/keep
> alive is done via STUN/ICE). So in practice, it should be possible for a
> WebRTC endpoint communicate with  a peer not implementing/sending RTCP at
> all.
>

Since RTP Circuit Breaker is MTI as per rtp-usage.

Not receiving any RTCP could potentially trigger the circuit-breaker.
More so, if the stream is not sending any RTP packets in the
measurement period (between 3 RTCP reports).

Regards,
Varun

-- 
http://www.netlab.tkk.fi/~varun/

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Aug 2014 10:24:25 -0400

> I wouldn’t know what minimum RTCP bandwidth to specify, but could certainly change the rtp-usage draft to say “…MUST be implemented and used…” if that would help?

That is fine *if RTP is being used*.

Use, or even implementation, of RTP should not be required in WebRTC 
devices that don't need it.

(I know that is what you meant.)

	Thanks,
	Paul

---

From: Colin Perkins <[email-masked]>
Date: Thu, 21 Aug 2014 12:42:29 +0100

> That is fine *if RTP is being used*.

I am suggesting adding this to the RTP usage draft…

> Use, or even implementation, of RTP should not be required in WebRTC devices that don’t need it.

Perhaps, but if implementing RTP isn’t a requirement, that needs to be captured somewhere. The rtcweb-overview-11 draft currently mandates RTP be implemented. 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Aug 2014 16:33:47 -0400

> Perhaps, but if implementing RTP isn’t a requirement, that needs to be captured somewhere. The rtcweb-overview-11 draft currently mandates RTP be implemented.

It is appropriate for the overview to mandate RTP support *for browsers*.

But the current discussion is about how to frame requirements for 
compliant non-browser devices.

If there was an intent to define some non-browser *platform* for webrtc 
applications then it would probably be appropriate to mandate RTP 
support for them too. (AFAIK there is no plan to define such a platform.)

But other devices that only need data channels shouldn't be required to 
implement RTP.

	Thanks,
	Paul

---

From: "Parthasarathi R" <[email-masked]>
Date: Sat, 23 Aug 2014 03:01:48 +0530

Paul,

I agree with you that WebRTC Endpoint MAY implement data channel only and
not mandatory to implement RTP.

But I wish to differentiate between WebRTC Endpoint & WebRTC device wherein
WebRTC device MUST support RTP & data channel as it is full compliance to
WebRTC protocol requirements. Please let me know your opinion on the same.

Thanks
Partha

> From: rtcweb [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Saturday, August 23, 2014 2:04 AM
> To: Colin Perkins
> Cc: [email-masked]
> >>>>>>> I agree.  We need to define a) WebRTC browsers, which support
> the full protocol requirements and the API, b) WebRTC
> Endpoints/Devices, which support some minimum protocol set sufficient
> for establishing connectivity.  Is there also a need to define c) Full
> WebRTC Devices, which support more than the minimum protocol set?  What
> would be the use of definition c?
> >>>>>> It would be required to support DTLS-SRTP key handshakes and
> respond to ICE connectivity checks, plus whatever is MUST use in -rtp-
> usage (scanning, I'm not coming up with much - it's mostly MUST respond
> to, MUST implement (but not required to use) stuff). The RTP circuit
> >>>>>> Scanning, I'm not even sure a WebRTC endpoint is required to
> send RTCP - but I think it should be.
> >>>>> "RTCP is a fundamental and integral part of RTP, and MUST be
> implemented in all WebRTC applications." rtp-usage-16 section 4.1
> >>>>
> mandatory-to-implement vs mandatory-to-use, and started being unsure;
> is it permitted to configure a WebRTC device to set RTCP-bandwidth to
> zero (the traditional means of turning off RTCP in a standards
> conformant manner, I think)?
> >>>>
> >>> I wouldn't know what minimum RTCP bandwidth to specify, but could
> certainly change the rtp-usage draft to say ".MUST be implemented and
> used." if that would help?
> >>
> > I am suggesting adding this to the RTP usage draft.
> >
> > Perhaps, but if implementing RTP isn't a requirement, that needs to
> be captured somewhere. The rtcweb-overview-11 draft currently mandates
> RTP be implemented.
>