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

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

Hi Roni,

> 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.

Which synch topics are missing? Please advise.

MPEG2-TS issues are detailed in Section 5. Synchronization is discussed
in Section 6, and in that section the proposed approach is not specific
to MPEG2-TS. We simply attempted to give examples in the MPEG2-TS
context, when it is appropriate to do so.  

> 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.

Of course, the info we put together to form the TSRAP data comes from
the RTP packets, however that information is not available in a single
or a few packets. It is dispersed over a large range. It would not
benefit us to burst all those packets. Instead, we form the TSRAP data
from the source stream, and put it into a single RTCP packet.

This is explained on page 14, with the paragraph starting with "In the
case of IP/UDP/RTP/MPEG2-TS encapsulated video streams ..." More
detailed information is again available in Section 5. 

Note that if the underlying application does not have a notion of "key
information," there may not be a need for this RTCP packet carrying the
payload-specific information. In that case, figure 2 would still hold,
with the exception that in step 3, only the unicast burst would be
provided.
 
> 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.

The rapid synchronization method as described here may also be used in
non-SDP environments, so it needs to be self-contained (as much as
possible).

-acbegen

> 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