Re: [rtcweb] Definitions of WebRTC entities

["Parthasarathi R" <[e-mail]>]

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