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: 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. 2. It should be clarified that each Channel is using a unique port (i.e. is not multiplexed) 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 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 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? More input will come! Br, Stefan
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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
Harald,
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.
I'll have to think a bit about that - it's outside my competence zone!
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? Maybe it is for the time being sufficient to mention that some rate control should be in place? At a later stage TFRC, TFWC or other solutions could be discussed. DSCP is something different to me. Br, Stefan -----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Harald Alvestrand Sent: den 24 november 2010 14:52 To: rtc-web@alvestrand.no Subject: Re: [RTW] IETF drafts
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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
participants (2)
-
Harald Alvestrand -
Stefan Håkansson LK