Subject: [AVT] Comments on draft-versteeg-avt-rapid-synchronization-for-rtp-01

From: "Roni Even" <[email-masked]>
Date: Mon, 10 Nov 2008 20:10:49 +0200

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.

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.

In section 7 you define new messages but the FMT you specify are already
used in RFC5104.

For the RMS message you have a maximum receive bitrate, you should say that
this number cannot be bigger than the b= SDP parameter.

The document should discuss how this mechanism works with SRTP

Roni Even

(Not as AVT chair)

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 10 Nov 2008 18:08:28 -0800

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

---

From: "Roni Even" <[email-masked]>
Date: Tue, 11 Nov 2008 09:38:24 +0200

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:[email-masked]] 
Sent: Tuesday, November 11, 2008 4:08 AM
To: Roni Even; [email-masked]
Subject: RE: [AVT] Comments
ondraft-versteeg-avt-rapid-synchronization-for-rtp-01

Hi Roni,

to

BR,
-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 11 Nov 2008 00:11:24 -0800

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

> 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.
> 
> 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.
> 
> Yes, reference to the SDP descriptor makes sense and we may 
> add this note.
> 
> 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)
> > 
> 
>

---

From: David R Oran <[email-masked]>
Date: Sat, 15 Nov 2008 17:05:24 -0500

On Nov 10, 2008, at 1:10 PM, Roni Even wrote:

> 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.
>
> information which should be in RTP, why not send it as RTP packet  
> with sequence number that precede the first packet in the burst.
>
With what payload type? It can't be a retransmission payload, because  
it is not a retransmission of a packet of the original stream. It  
seems awfully heavy weight to start defining a whole new set of  
payload formats for this kind of information, soem of which is payload- 
format specific and some which is not.

> For the RMS message you have a maximum receive bitrate, you should  
> say that this number cannot be bigger than the b= SDP parameter.
>
What do you think needs to be said that isn't said in the SRTP  
specifications. The retransmission session is a normal RTP session  
which is protected with SRTP just like any other RTP session. Am I  
missing something?

---

From: David R Oran <[email-masked]>
Date: Sat, 15 Nov 2008 17:13:32 -0500

On Nov 11, 2008, at 2:38 AM, Roni Even wrote:

> RTP packets.
It;s available spread around in multiple RTP packets, so  
retransmitting those packets will surely confuse a receiver who has  
not yet build up RTP state. Constructing new RTP packets from these is  
effectively inventing a new payload format, which seems a very heavy- 
weight way to do this.

> So why do you want to send it using RTCP.
See above, plus the efficiency gains of only sending exactly what is  
needed. W are not trying to re-estblih the clocking regime from  
earlier in the stream than the new synchronization point; instead w  
are just trying to "prime" the decoder/application state so that it  
has built up the necessary state to lock onto the media at the new  
synchronization point.

> information and
This is information which is bound into the realtime decoder/ 
application state rather than (semi-)static stream description  
information. One could imagine moving some of it to SDP, like PAT/PMT  
in the case of MPEG2TS (RFC2250) payload formats, but this method  
won't work for things like ECMs, which carry dynamic encryption keys  
for media.

RTCP seems the most natural channel to use. Do you think we're  
misguided here?

DaveO.

>> trying
>> with
>> say