Re: [rtcweb] Definitions of WebRTC entities

Den 03. okt. 2014 22:41, skrev Silvia Pfeiffer:
>
> These are good!
>
> On 3 Oct 2014 17:44, "Harald Alvestrand" <harald@alvestrand.no 
> <mailto:harald@alvestrand.no>> wrote:
> >
> > 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.
>
> Since a webrtc UA is a superset of a webrtc device, webrtc endpoint 
> and webrtc device end up meaning the same, don't they?
>
> >    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.
> >
> >
>
> Is your intent to specify which parts of the protocol are not required 
> to be supported by webrtc-compatible endpoints in a rfc? I think it 
> would be useful...
>

Yes, -transport is intended to be published as an RFC. So is 
draft-alvestrand-rtcweb-gateways (if the group accepts it).

> Silvia.
> _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org <mailto:rtcweb@ietf.org>
> > https://www.ietf.org/mailman/listinfo/rtcweb
>