Roni Even
-----Original Message-----
From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
Sent: Tuesday, November 11, 2008 4:08 AM
To: Roni Even; avt at ietf.org
Subject: RE: [AVT] Comments
ondraft-versteeg-avt-rapid-synchronization-for-rtp-01
Hi Roni,
Thanks for reading the draft and your comments. Please see inline.
Hi,
I reviewed the draft.
My first impression was that the intention was to have a general
mechanism but when reading the text it looks to me that you are
trying
to address only MPEG2-TS based on the first paragraph of section 6.
Do
you see it as a general solution or only for MPEG2-TS. If it intends
to
be a general mechanism the text about MPEG2-TS can be an appendix.
The comments from the first meeting were to separate the
payload-independent and specific messages. And we did that. We don't
recall being asked to carry the mpeg-specific stuff to the appendix,
but
certainly we can do that, although we feel that many readers would
benefit from the description of a typical motivating example. The
problem space is described using MPEG examples, but the protocol
solution describes a generic solution with payload-specific
extensions.
In section 6.1 you discuss the information that is not part of the
burst RTP stream (TSRAP). A similar information may be the parameter
sets in H.264. You suggest an RTCP message for sending payload
information which should be in RTP, why not send it as RTP packet
with
sequence number that precede the first packet in the burst.
MPEG2-TS can also carry H.264, TSRAP would apply to such contents as
well. Here, we are trying to model the acceleration burst as an RTP
retransmission flow. The sequence numbering of the original flow is
preserved. A reference to an RTP number should map between the primary
flow and any acceleration/repair flow. If we re-use RTP sequence
numbers, this makes an ambiguous reference to that sequence number.
Since TSRAP is not in the original data flow, it can't be carried as a
retransmission in the repair flow.
In section 7 you define new messages but the FMT you specify are
already used in RFC5104.
Yes, we noticed that after the submission. We will fix this.
For the RMS message you have a maximum receive bitrate, you should
say
that this number cannot be bigger than the b= SDP parameter.
Yes, reference to the SDP descriptor makes sense and we may add this
note.
The document should discuss how this mechanism works with SRTP
Is your question about the case when the original data flow is in
SRTP?
Since we are not modifying the source flow (or packets), SRTP should
work just fine. But extracting the TSRAP info from an encrypted flow
may
require additional processes on the retransmission server. Are you
asking about how this could be done?
BR,
-acbegen
Roni Even
(Not as AVT chair)
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt