Subject: Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid-rtp-sync-02.txt

From: Thomas Schierl <[email-masked]>
Date: Fri, 06 Mar 2009 17:42:39 +0100

Dear All,

As we already got a few comments, I would like to pick out the following 
one raised by Roni:

Might there be a security issue if an NTP timestamp is contained in the 
header extension in plain and is at the same time included in the 
encrypted portion of an RTCP SR packet?

Thomas

-- 
Thomas Schierl
--------------
Fraunhofer HHI

Colin Perkins wrote:
> This draft is a merger between draft-perkins-avt-rapid-rtp-sync-01.txt 
> and draft-schierl-avt-rtp-ntp-for-layered-codecs-00.txt.
>
> Please send any comments to the list. We'd like this to be considered 
> for adoption as an AVT working group draft.
>
> Colin
>
>
>
> Begin forwarded message:
>> From: [email-masked]
>> Date: 13 February 2009 14:45:01 GMT
>> To: [email-masked]
>> Subject: I-D Action:draft-perkins-avt-rapid-rtp-sync-02.txt
>> Reply-To: [email-masked]
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>>
>>     Title           : Rapid Synchronisation of RTP Flows
>>     Author(s)       : C. Perkins, T. Schierl
>>     Filename        : draft-perkins-avt-rapid-rtp-sync-02.txt
>>     Pages           : 18
>>     Date            : 2009-02-13
>>
>> This memo outlines how RTP multimedia sessions are synchronised, and
>> discusses how rapidly such synchronisation can occur.  We show that
>> most RTP sessions can be synchronised immediately, but that the use
>> of video switching multipoint conference units (MCUs) or large source
>> specific multicast (SSM) groups can greatly increase the initial
>> synchronisation delay.  This increase in delay can be unacceptable to
>> some applications that use layered and/or multi-description codecs.
>>
>> This memo updates the RTP Control Protocol (RTCP) timing rules to
>> reduce the initial synchronisation delay for SSM sessions.  A new
>> feedback packet is defined for use with the Extended RTP Profile for
>> RTCP-based Feedback (RTP/AVPF), allowing video switching MCUs to
>> rapidly request resynchronisation.  Two new RTP header extensions are
>> defined to allow rapid synchronisation of late joiners, and guarantee
>> correct timestamp based decoding order recovery for layered codecs in
>> the presence of clock skew.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-perkins-avt-rapid-rtp-sync-02.txt 
>>
>
>
>

----
Visit us at

CeBIT 2009 / March 3-8 / Hannover, Germany / Hall 9, Booth B36 and A30
http://www.hhi.fraunhofer.de/en/news-events/cebit-2009/

OFC 2009 / March 24-26 / San Diego, California / Hall B1, Booth 411
http://www.ofcnfoec.org/

---

From: Colin Perkins <[email-masked]>
Date: Mon, 9 Mar 2009 15:08:23 +0000

On 17 Feb 2009, at 09:56, <[email-masked]> wrote:
> OK with this draft that improve the synchronization time between  
> multiple sessions. I guess its usage is larger than SVC and multi- 
> description codecs.
> Some remarks to consider in this document.
> 1) If a multicast (or broadcast) session has no feedback channel,  
> the source must send peiodically synchronization messages, with a  
> short period (as ~200ms or less, for example).

If there's no feedback channel, and you want faster synchronisation  
than provided by the regular RTCP SR packets, you'd probably send the  
synchronisation information in an RTP header extension on the packets  
that comprise random access points of the media.

> 2) RTP header extension adds 12 bytes. The source must reserve them  
> in all packets in order to avoid fragmentation at IP level, because  
> (I suppose?) insertion of this extension header may be independant  
> of the RTP payload building.

That's one design choice, certainly, and might be appropriate for non- 
interactive applications. If you're coding live media, you'd probably  
do something more network aware in the codec though.

> This is very bad when packet losses occur. So could be possible to  
> have RTP packets that contain only header and extension for  
> synchronization?

No - use RTCP SR packets for this case.

> 3) The receiver must have confidence with synchronization  
> information it receives. It is the responsability of the sources to  
> give precize information.

Sure, but that's true of any synchronisation mechanism.

> 4) About variant A and B, it depends the precision that  
> synchronization needs: a 16 bit information for ntp fraction and 8  
> bits for ntp seconds could be sufficient, because 16 bit fraction  
> give 15 micro-second precision, and period between synchronization  
> messages never exceed 250 seconds. Could a 32 bit word contain all  
> these information? This may be usefull if extension is in a RTP  
> message with data, according to IP fragmentation.

That's certainly a possible third option. I'd be interested in other  
feedback from implementers on the appropriate header extension size  
(option A has the advantage of compatibility with ISMA, but the other  
options have lower overhead).

-- 
Colin Perkins
http://csperkins.org/