Re: [rtcweb] Definitions of WebRTC entities

[Christer Holmberg <[e-mail]>]

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.