Re: [AVT] using RTCP for sending payload information in versteeg and levin rapid synchronization drafts

Roni, all,

Just wanted to clarify that in the http://tools.ietf.org/id/draft-levin-avt-rtcp-burst-00.txt the proposed TLV extensions mechanism hasn't been introduced to carry any media/CODEC specific information. In fact, the proposed mechanism is 100% media/data agnostic. In our view, for further optimization, the MPEG-2 structures could be (re)arranged by the server(s), but this doesn't require IETF standardization because it is transparent both to the defined mechanism and to the receiver.

The reason for introducing the extensions mechanism was to accommodate other standardization bodies (such as ATIS and DVB) that are working on commercial video/TV applications and are planning to use this IETF mechanism in their application architectures. These architectures include their own security frameworks and the protocol details to carry them.

Probably, explicitly saying in the next version of the draft that the TLV extensions MUST not carry any media/CODEC specific information will clarify the point and address the expressed concern.

Thanks,

Orit.

From: avt-bounces at ietf.org [avt-bounces at ietf.org] On Behalf Of Roni Even [ron.even.tlv at gmail.com]
Sent: Saturday, November 15, 2008 8:44 AM
To: avt at ietf.org
Subject: [AVT] using RTCP for sending payload information in versteeg and levin rapid synchronization drafts

Hi guys,

Draft http://tools.ietf.org/id/draft-versteeg-avt-rapid-synchronization-for-rtp-01.txt suggests a new use for RTCP feedback messages.

More specifically in section 7.2.1. This message is used to carry information from the payload that is not available very often as described in the paragraph. My understanding is that there will be a similar case with H.264 parameter sets which are not sent with every I-frame and are required in order to decode the stream.

For H.264 we suggested in 3984bis that a codec refresh point will include the parameter sets, this is sent as a response to FIR CCM request (the video switch case). I think that here they would not want to retransmission server to send FIR back to the multicast source.

A similar issue is in http://tools.ietf.org/id/draft-levin-avt-rtcp-burst-00.txt that in section 7 have for each message an extension field that is left open without specifying what it will be used for and can be used for similar information.

The general problem is the same in both cases since some of the information is available early in the media stream and is not repeated as often as I frames but still is needed for synchronization. The problem of joining mid-stream is similar to the video switch case in MCUs.

I am looking for feedback if this is a good use for RTCP based on the RTCP guideline drafts, and if not any are there any suggestions.

Thanks

Roni Even