Re: [rtcweb] Definitions of WebRTC entities

[Harald Alvestrand <[e-mail]>]

On 10/07/2014 07:14 PM, Christer Holmberg wrote:
> 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'm trying to make everyone happy :-)

>
> Regards,
>
> Christer
>
>
>
>
> -----Original Message-----
> From: Parthasarathi R [mailto:[e-mail]] 
> Sent: 07 October 2014 19:21
> To: Christer Holmberg; 'Harald Alvestrand'; [e-mail]
> Subject: RE: [rtcweb] Definitions of WebRTC entities
>
> 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
>
>> -----Original Message-----
>> From: rtcweb [mailto:[e-mail]] On Behalf Of Christer 
>> Holmberg
>> Sent: Friday, October 03, 2014 11:06 PM
>> To: Harald Alvestrand; [e-mail]
>> 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
>>
>>
>>
>>
>>
>>
>> Den 3. oktober 2014 14:01:20 CEST, skrev Christer Holmberg
>> <[e-mail]>:
>> 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:[e-mail]] On Behalf Of Harald 
>> Alvestrand
>> Sent: 3. lokakuuta 2014 10:44
>> To: [e-mail]
>> Subject: [rtcweb] Definitions of WebRTC entities
>>
>> 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.
>> ________________________________________
>>
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb


-- 
Surveillance is pervasive. Go Dark.