Re: [AVT] Comments ondraft-versteeg-avt-rapid-synchronization-for-rtp-01

["Ali C. Begen (abegen)" <abegen at cisco.com>]

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