Re: [rtcweb] Definitions of WebRTC entities

[Harald Alvestrand <[e-mail]>]

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