[RTW] IETF drafts

[Stefan Håkansson LK]

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 at alvestrand.no 
> [mailto:rtc-web-bounces at alvestrand.no] On Behalf Of Harald Alvestrand
> Sent: den 24 november 2010 14:52
> To: rtc-web at 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 at alvestrand.no
> > http://www.alvestrand.no/mailman/listinfo/rtc-web
> >    
> 
> 
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>