[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
Colin -
Thanks for the detailed feedback. I agree with Ali's responses.
Regarding your last item - I agree that NAT presents some challenges in
this environment. We have recently sent an analysis of the NAT issues
described in sections 9 an 10 to the AVT list. We have tried to
summarize the 4 alternative NAT solutions that have been suggested,
showing the up-side and down-side of each. I would love to see a more
elegant solution to this dificult problem, and look forward to feedback
from the list.
Bill VerSteeg
-----Original Message-----
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of
Colin Perkins
Sent: Sunday, June 21, 2009 7:54 AM
To: Audio/Video Transport (AVT) WG
Subject: 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/
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt