[RTW] IETF drafts

[Harald Alvestrand]

On 11/19/10 11:27, Stefan Håkansson LK wrote:
> I've quickly browsed the two drafts 
> (draft-alvestrand-dispatch-rtcweb-protocols [1] and 
> draft-alvestrand-dispatch-rtcweb-datagram [2]) published under 
> dispatch. They are a good start, but I have some initial comments:
Thanks Stefan!
> 1. The use of the terms Session and Channel defined in [2] is not 100% 
> clear. In addition, the term Connection is frequently used in [1] and 
> [2] but not defined. This should be clarified.
In [2], it's used inconsistently in section 6 (the last piece I added) - 
it should be "username and password used to establish the channels for a 
session", not "username and password used to establish the connection". 
The other usages are referring to underlying transports, and are kind of 
undefined - those parts are really handwavey at the moment.
> 2. It should be clarified that each Channel is using a unique port 
> (i.e. is not multiplexed)
The way I imagine Sessions in [2] is that they correspond to an ICE 
association - several associations can share the same port at one end, 
but the port +address combination will have to be unique. If used for 
client/server, typically the server would announce one port in its 
candidates to all clients, and the clients would pick ephemeral ports.
This is a requirement when using ICE+UDP channels, I'm not sure it's a 
requirement for other channel types.

Experience shows that people tend to want to reduce UDP port usage, so I 
would not rule out either putting RTP + RTCP on the same session, or 
even having mutiple video streams (with different SSRCs) on the same 
session.
> 3. The API must not only support the selection (based on a 
> negotiation) of media format, in order to make it possible to have a 
> meaningful negotiation it must also support query of the supported 
> media formats
Indeed. Both that a script must be able to query the devices attached 
locally, and that the script must be able to exchange data with the 
remote end (possibly via the backend) to figure out what the other end 
is willing to accept. This should be made clear in [1] (protocols).
> 4. It should be mentioned that the voice and video streams must have 
> some basic rate control applied so that they do not starve other traffic
Yes, I'm not sure how this needs to be formulated - do we need to refer 
to TFRC? How, if at all, does DSCP play into the picture?
> 5. The statements on echo control and voice level in Section 8 of [1] 
> are very vague. Maybe something like: "Echo cancellation should be 
> provided to avoid disturbing echo during conversation" and "The level 
> of the speaking voice should be configurable to a desired level" would 
> be better?
Indeed, the main purpose of saying anything was to point out that 
something needs to be said - your suggestions sound better to me!
> More input will come!
> Br,
> Stefan
>
>
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>