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

["Roni Even" <ron.even.tlv at gmail.com>]

Hi,
The request in the last meeting had to do with which RTCP messages should be
used. My comment is that when you read the draft it does not read as a
general solution but more like MPEG2-TS solution. It discussed MPEG2-TS
topics and not the synchronization topics.

As for using RTCP for payload parameter what confuses me first is that I
have not seen in RFC-2250 that there is MPEG2-TS information which is not
carried in the RTP stream, so I assume that all information is available as
RTP packets. So why do you want to send it using RTCP.
In H.264 RFC3984, the parameter sets can be carried as SDP information and
this would have been a reason to find some way to send it like you
suggested. On the other hand the motivation for sending it in SDP was for
reliability which RTCP does not have so the information may be sent in the
RTP stream and not in the RTCP.

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