Subject: [AVT] Comments on draft-perkins-avt-rtp-and-rtcp-mux-00.txt

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 11 Sep 2006 16:59:10 -0400

Specific comments:
1) Since RTCP packets have to be sent as compounds with SR/RR first
(right?), why do the other RTCP PT's matter for collisions?  Because they
could be sent over TCP, and thus be a stream?  Or just for protocol purity
of them being "packets"?  Perhaps that should be stated in the draft, in
case someone wonders.

2) What does this mean for bandwidth values encoded in SDP?  Should it
include the RTCP overhead in b=AS, or not?  Or mandate using RFC 3556
b=RS/RR encoding?

3) The example SDP in section 5.1 has "IP6" twice in the connection line.

-hadriel

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Randell Jesup <[email-masked]>
Date: Mon, 11 Sep 2006 17:19:32 -0400

>of them being "packets"?  Perhaps that should be stated in the draft, in

Good point - RTCP does ALWAYS have to start with SR or RR, so those are
the only ones you need to worry about.  Even on TCP, you know the framing
of packets, so others won't be an issue.

>include the RTCP overhead in b=AS, or not?  Or mandate using RFC 3556

Good question.  If you include the BW of the RTCP (b=AS:<rtp+rtcp>), then
some QoS solutions will allocate that plus 5% for RTCP.  That may not
be a big problem (some wasted reservation, if the QoS reserver doesn't
understand this draft).  If you use AS, you should include it because a
QoS service might reserve on a per-port basis.  RS/RR might make sense
(I'd have to brush up on them).

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Thu, 14 Sep 2006 15:20:42 -0700

> -----Original Message-----
> From: Randell Jesup [mailto:[email-masked]]
> Sent: Monday, September 11, 2006 2:20 PM
> To: Hadriel Kaplan
> Cc: [email-masked]; [email-masked]
> Subject: Re: [AVT] Comments on
draft-perkins-avt-rtp-and-rtcp-mux-00.txt
> of packets, so others won't be an issue.

[A] Is a new RTP profile allowed to relax the requirement that RTCP
packet need not always start with SR or RR? 

I see such relaxation useful with existing profile AVPF which allows
much smaller RTCP intervals than AVP. I prefer to use such benefit in a
unicast environment for providing only relevant feedback to the sender
and avoid unnecessary resource consumption by packing RR/SR with each
and every AVPF feedback message. A receiver can however continue to send
RR/SR messages at the same resolution as AVP used to provide. Mandating
RR in every RTCP packet for the sake of increasing the resolution of
statistics isn't really a big plus in this scenario. Not having to stick
an RR (and other irrelevant messages) will reduce the average RTCP
packet size, Avg., RTCP interval, and average bit rate of RTCP stream.
All these provide benefits in some network environments.

If there are any (future) implementations which do not stick RR/SR with
every out going RTCP packet, they would definitely benefit from avoiding
the collision of RTP PT with RTCP PT of non SR/RR packets. Hence, it
would be safe to avoid such collision with all possible payload types of
RTCP packets.

> (I'd have to brush up on them).

For a session negotiated with offer/answer model:
Per current definition, AS specifies the max receive bandwidth for the
media stream. If there is no RS/RR, as a receiver, I would allocate QoS
for (AS + 5% of AS) for the receive stream. If there is RS/RR, as a
receiver, I would allocate QoS for (AS + RS from the SDP answer + RR
from the SDP answer)

> 
> --
> Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga
OS
> team

---

From: Colin Perkins <[email-masked]>
Date: Fri, 15 Sep 2006 18:31:13 +0100

> of them being "packets"?  Perhaps that should be stated in the  

Mostly it was for robustness to broken nodes which might send non- 
compound RTCP packets. I'll clarify.

> include the RTCP overhead in b=AS, or not?  Or mandate using RFC 3556

I agree that something needs to be added, and Harikishan Desineni's  

> receiver, I would allocate QoS for (AS + RS from the SDP answer + RR

If there are no objections, I'll add words along those lines.

> 3) The example SDP in section 5.1 has "IP6" twice in the connection  

Will fix.

Thanks!
Colin