[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] I-D Action:draft-ietf-avt-rapid-acquisition-for-rtp-01.txt
On 16 Jun 2009, at 16:45, Internet-Drafts at ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Audio/Video Transport Working Group
of the IETF.
Title : Unicast-Based Rapid Acquisition of Multicast RTP
Sessions
Author(s) : B. Steeg, et al.
Filename : draft-ietf-avt-rapid-acquisition-for-rtp-01.txt
Pages : 41
Date : 2009-06-16
I had some minor comments:
Section 6: Do the RR and RS send the usual periodic RTCP reports on
the retransmission session? I assume they do, but it'd be good to
state that explicitly to avoid confusion.
Section 7: Are the RAMS messages sent as part of compound RTCP
packets, or is the non-compound extension assumed? I can see
advantages to using compound packets, and it would be good if the
draft explicitly stated that they were used, according to the usual
rules.
Section 7: Have you considered using several feedback message type
(FMT) values, one for each of the RAMS-R, RAMS-I, and RAMS-T messages,
instead of a single value with subtypes? It's not clear that the extra
level of indirection buys anything.
Section 7.3: The Earliest Multicast Join Time and Burst Duration both
specify times. The latter is specified in RTP clock units, the former
says you need to decide between milliseconds and RTP clock units. It
would make things easier for implementers if these were both the same.
Section 7.3: Is there any reason why a server would switch between
supporting and not supporting updated requests within a single
session? If not, then the S bit might be better signalled in the SDP,
rather than in-band in each message.
Section 7.3 and 7.4: It's not clear why extended RTP sequence numbers
are used, since the top 16 bits are always zero.
Section 7.3 "Note that if the RAMS requests has been accepted, RS MUST
send this field as least once": Why is this a MUST? The RR must be
able to work without this field, since the RAMS-I packet might be
lost, so while I can see why this should be a SHOULD, I don't see the
motivation for a MUST.
Section 9: As I've mentioned off-line to the authors, I don't find
this compelling.
Cheers,
Colin
--
Colin Perkins
http://csperkins.org/