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

From: Roni Even <[email-masked]>
Date: Sat, 07 Nov 2009 08:55:24 +0200

Hi Ali,

I read the draft and think it is important.

I have two general comments

1.       According to RFC 3550 section 5.2 you should not ssrc multiplex
different media 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.

2.       On the BW I suggest having the maximum BW at the session level in
your example  b=as:22000, and also note the unlike AS the TIAS is in bits/s
and not kbit/s. It may also 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.

Roni Even

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 7 Nov 2009 07:10:06 -0800

Hi Roni,

> -----Original Message-----
> From: Roni Even [mailto:[email-masked]]
> Sent: Saturday, November 07, 2009 1:55 AM
> To: [email-masked]
> Cc: Ali C. Begen (abegen)
> Subject: Review of draft-begen-avt-rams-scenarios-00
> 
> Hi Ali,
> 

Thanks for reading the draft.
 
> 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