Re: [rtcweb] Definitions of WebRTC entities

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>

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

> 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".
> 
> >
> > Thanks
> > Partha
> >
> >> -----Original Message-----
> >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer
> >> Holmberg
> >> Sent: Friday, October 03, 2014 11:06 PM
> >> To: Harald Alvestrand; rtcweb@ietf.org
> >> 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
> >> <christer.holmberg@ericsson.com>:
> >> 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:rtcweb-bounces@ietf.org] On Behalf Of Harald
> >> Alvestrand
> >> Sent: 3. lokakuuta 2014 10:44
> >> To: rtcweb@ietf.org
> >> 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
> >> rtcweb@ietf.org
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> >>
> >> --
> >> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> >> _______________________________________________
> >> rtcweb mailing list
> >> rtcweb@ietf.org
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 
> --
> Surveillance is pervasive. Go Dark.