Re: [AVT] Review of draft-begen-avt-rams-scenarios-00

["Ali C. Begen (abegen)" <abegen at cisco.com>]

Hi Roni,

> -----Original Message-----
> From: Roni Even [mailto:Even.roni at huawei.com]
> Sent: Saturday, November 07, 2009 1:55 AM
> To: avt at ietf.org
> Cc: Ali C. Begen (abegen)
> Subject: Review of draft-begen-avt-rams-scenarios-00
> 
> Hi Ali,
> 
> I read the draft and think it is important.

Thanks for reading the draft.
 
> I have two general comments
> 
> 
> 
> 1.       According to RFC 3550 section 5.2 you should not ssrc multiplex different media

RFC 3550 uses "should not" and I agree. But, the mere goal of the draft was to present some examples we have seen in practice and how their individual requirements would apply to RAMS.

> types like audio and video. As for 4.4 look at RFC 3550 section 5.1 in the definition of
> payload type, it is not allowed.

This is also a "should not" in 3550, which I also agree with. I can revise section 4.4, but it already says that PT-muxing has several disadvantages. 
 
> 2.       On the BW I suggest having the maximum BW at the session level in your example

Knowing the individual bitrates is more useful if not all streams will be acquired concurrently, right?

> b=as:22000, and also note the unlike AS the TIAS is in bits/s and not kbit/s. It may also

I must have missed it.

> be good for the RS to indicate the maximum bw it can send for the retransmission if you
> want the RR to have an indication of what rate it can request but it is not critical.

So, are you suggesting a new SDP attribute for this? The problem I see with that is that value will be time varying. So, putting it in the SDP makes little sense IMO.

Cheers,
-acbegen

 
> 
> 
> Roni Even