Subject: Re: [AVT] accepting draft-lakaniemi-avt-rtp-evbr-02

From: "Ingemar Johansson S" <[email-masked]>
Date: Wed, 3 Sep 2008 08:04:20 +0200

Hi

In the light of the proposal below to include synch info in the SDP. I
see some problems.

Assume that an SDP offer contains a list of codecs (a layered codec is
one of them), along with the codec list the SDP offer also contains the
synch info for the different layers). Problem is (as I see it) from an
implementation point of view is that when the SDP offer is sent you
don't know:
1) Which codec is going to be used
2) If the layered codec is going to be used.. How many layers (could be
an additional config issue)
3) The initial values for the timestamps: (as an implementor I would do
the negotiation first and after this create the instances of the codecs
then), OK, you can precompute the intital timestamps beforehand.

Regards
Ingemar

> 
> ________________________________
> 
> 	From: ext [email-masked] 
> [mailto:[email-masked]] 
> 	Sent: 02 September, 2008 17:01
> 	To: Wang Ye-Kui (Nokia-NRC/Tampere)
> 	Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; BABONNEAU Gerard RD-MAPS-REN; MARJOU Xavier RD-CORE-LAN
> 	Subject: Re: [AVT] accepting 
> draft-lakaniemi-avt-rtp-evbr-02 as WG item
> 	
> 	
> 	Hi all
> 	
> 	This is an old debate that has never bring a right 
> response until today.
> 	From an IPTV application point of view. If we consider 
> that timestamp may change between multiple sessions 
> transporting a single content (audio or video), I see two 
> main constraints, notably for SVC streams:
> 	- A SVC stream may use a multicast transport (with an 
> IP multicast address for each video session) without RTCP 
> messages, so synchronizing timestamps with RTCP is not possible.
> 	- IPTV services need very fast change between channels 
> that cannot accommodate long delays from RTCP messages to 
> synchronize multiple sessions
> 	
> 	However we believe you cannot get away from a strict 
> compatibility with existing AVC and rfc 3984, and indeed a 
> synchronization between RTP  sessions must exist.
> 	
> 	According all these constraints, may we suggest you to 
> add in SDP the difference between a wall clock and the 
> timestamp in an RTP session, that I name below 
> "delta_time(layer)"?  Wall clock may be the clock of the 
> encoder for SVC. Computing the difference between timestamps 
> from two sessions allows to synchronize them, even without  
> information about this common wallclock. This is possible 
> because because these differences remain constants when the 
> time progress.
> 	
> 	Assuming that: 
> 	delta_time(layer_0) = wall_clock - timestamp(layer_0)
> 	delta_time(layer_1) = wall_clock - timestamp(layer_1)
> 	....
> 	delta_time(layer_i = wall_clock - timestamp(layer_i)
> 	
> 	Then:
> 	delta_time(layer_1) - delta_time(layer_0) = 
> timestamp(layer_1) - timestamp(layer_0)
> 	...
> 	so, synchronization become easy and faster than with 
> RTCP messages, at less for SVC with an answer at the 
> application level.
> 	
> 	If reference clocks are different, SDP must contain 
> also the timestamp value at which delta_time is computed. 
> 	
> 	Can you consider this idea is a way to resolve some 
> timestamp synchronization that could adapt also other 
> encoding schemes?
> 	We intend to write a draft to develop this idea.
> 	
> 	Regards
> 	
> 	G?rard BABONNEAU, Xavier MARJOU
> 	
> 	
> 	[email-masked] a ?crit : 
> 
> 		 
> 		  
> 
> 					The obvious problems 
> with aligned timestamps are that they don't
> 					work unless all 
> sessions use the same clock rate, and they make
> 					RFC 1889 encryption 
> even less secure.
> 					          
> 					              
> 
> 					To me it seems use of 
> the same clock rate for all the RTP sessions
> 					in a
> 					multi-session 
> transmission is obvious. You see any disadvantage of
> 					this?
> 					        
> 					            
> 
> 					I can certainly 
> envisage potential layered audio codecs where each
> 					layer has a different 
> sampling rate, and hence uses a different RTP
> 					timestamp rate.
> 					      
> 					          
> 
> 					This is surely true. 
> For this EVBR codec, layers L1 and L2 may have
> 					sampling rate of 8 or 
> 16 kHz, while other layers must have 
> 					        
> 
> 			sampling  
> 			    
> 
> 					rate
> 					of 16 kHz. However, I 
> don't see a problem of using the same 
> 					        
> 
> 			clock rate
> 			    
> 
> 					for RTP timestamps. For 
> example, in the current draft, the timestamp
> 					clock frequency of 32 
> kHz is specified.
> 					    
> 					        
> 
> 				Sure, for this one case. The 
> standard RTCP SR-based mechanism works  
> 				for all cases though.
> 				
> 				      
> 
> 		
> 		There are existing standard systems (e.g. 3GPP) 
> using RTP without RTCP - I know that this has been discussed 
> in AVT and those systems might be considered as "broken" by 
> some. However, the systems do work and are deployed. The 
> timestamp aligned method works even for such "broken" 
> systems, while the RTCP-based method does not. And so far I 
> don't where a real problem is for the timestamp aligned 
> method. The RFC 1889 issue to me is not a real issue, as I 
> cannot imagine a future standard will reference this RFC 
> instead of RFC 3550. 
> 		
> 		  
> 
> 				  
> 				      
> 
> 			Is it guaranteed that RTCP SRs allow 
> sample-accurate alignment of the 
> 			streams? I heard rumors that many 
> applications can only guarantee RTCP 
> 			SR accuracy in the range of ms.
> 			
> 			    
> 
> 		
> 		BR, YK
> 		_______________________________________________
> 		Audio/Video Transport Working Group
> 		[email-masked]
> 		https://www.ietf.org/mailman/listinfo/avt
> 		  
> 
> 
> 	-- 
> 	 
> 	BABONNEAU Gerard RD-MAPS-REN
> 	REN/MAPS/DPC
> 	Tel : +33 299124008 
> 	Email: [email-masked] 
> <mailto:[email-masked]> 
> 	R&D Rennes 4, rue du Clos-Courtel - BP 91226 - 35512 
> Cesson-Sevigne Cedex - France 
> 	
> 	
> 	Mailer ThunderBird sous Mandriva
> 	Installez simplement votre poste de travail Linux avec 
> http://web2000.rd.francetelecom.fr
> 	 
> 	
> 	
> 	
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> http://www.ietf.org/pipermail/avt/attachments/20080902/322d93d
> 4/attachment-0001.htm
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: image/gif
> Size: 1264 bytes
> Desc: orange_logo.gif
> Url : 
> http://www.ietf.org/pipermail/avt/attachments/20080902/322d93d
> 4/attachment-0002.gif
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: image/gif
> Size: 1081 bytes
> Desc: ampersand.gif
> Url : 
> http://www.ietf.org/pipermail/avt/attachments/20080902/322d93d
> 4/attachment-0003.gif 
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 2 Sep 2008 22:47:23 +0300
> From: <[email-masked]>
> Subject: Re: [AVT] accepting draft-lakaniemi-avt-rtp-evbr-02 as WG
> 	item
> To: <[email-masked]>, <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked]
> Message-ID:
> 	<[email-masked]>
> Content-Type: text/plain;	charset="us-ascii"
> 
> 
> >1) Synchronized initial timestamps
> >   Simple to implement for many people.  May not be for 
> others.  Needs 
> >to
> >       be signaled and/or part of payload spec.
> >   Problem: if they don't use the same timebase the sync will drift; 
> >you still need SR/RR to fix it.
> 
> But as there is no problem of requiring the use of the same 
> clock rate for timestamps for different sessions, this should 
> not be a problem.
> 
> >      May also cause problems
> >with RFC 1889, etc.  
> 
> Will any existing implementations of RFC 1889 using the 
> encryption method deprecated by RFC 3550 be used for 
> transport of future scalable media (e.g. SVC and EVBR)?
> 
> > Can be conf
> 
> This is a incomplete sentence. 
> 
> BR, YK 
> 
> >-----Original Message-----
> >From: ext Randell Jesup [mailto:[email-masked]]
> >Sent: 02 September, 2008 19:07
> >To: Colin Perkins
> >Cc: Wang Ye-Kui (Nokia-NRC/Tampere); [email-masked]; 
> >[email-masked]; [email-masked]
> >Subject: Re: [AVT] accepting draft-lakaniemi-avt-rtp-evbr-02 
> as WG item
> >
> >Colin Perkins <[email-masked]> writes:
> >>> So my question is simple, what is the problem you guys have
> >identified
> >>> for using aligned RTP timestamps. Could you or Jonathan or Thomas 
> >>> clarify?
> >>
> >>I don't recall that we discussed this issue, sorry. The obvious 
> >>problems with aligned timestamps are that they don't work 
> unless all 
> >>sessions use the same clock rate, and they make RFC 1889 encryption 
> >>even less secure.
> >
> >Correct me if I'm wrong, but the only real reasons for 
> random initial 
> >timestamps (and sequence numbers) is for RFC 1889 encryption and 
> >(perhaps) for reducing the ease of "hijacking" or disrupting 
> >unencrypted (or
> >un-authenticated) sessions by an attacker who isn't able to 
> monitor the 
> >media path.
> >
> >>> A further question: Is the common way of doing cross-layer 
> >>> synchronisation you are looking for targets replacing all the 
> >>> cross-layer synchronisation methods in the SVC draft and in
> >this EVBR
> >>> draft? Or you are just trying to replace the timestamps
> >based methods?
> >>
> >>There is a standard way of doing accurate timing synchronisation 
> >>across RTP sessions using RTCP SR packets. I see no reason why SVC, 
> >>MVC, EVBR, and other formats can't use it. Timing synchronisation 
> >>between sessions is separate to the way decoding order is 
> determined 
> >>(although some ways of determining decoding order might rely on 
> >>accurate time synchronisation).
> >>
> >>> Or what you are looking for is not really a generic method for 
> >>> cross-layer synchronisation but just a method on how to solve the 
> >>> delay issue associated with the RTCP SR based method?
> >>
> >>We already have a generic cross-layer timing 
> synchronisation method.  
> >>There might be a need to reduce the delay associated with
> >waiting for
> >>an RTCP SR packet, to speed that generic method up, but that's 
> >>independent of the payload format.
> >
> >That's the biggest problem so far with the generic method - startup 
> >syncronization time, especially for AVP/SAVP (as opposed to 
> >AVPF/SAVPF).
> >Even for AVPF, just because the sender *can* send extra or repeated 
> >RTCP SR/RR packets near the start of a stream doesn't mean that they 
> >will, and there's no way in the Codec Control AVPF extensions to 
> >"request" an RTCP.
> >
> >Possible solutions:
> >1) Synchronized initial timestamps
> >   Simple to implement for many people.  May not be for 
> others.  Needs 
> >to
> >       be signaled and/or part of payload spec.
> >   Problem: if they don't use the same timebase the sync will drift; 
> >you
> >       still need SR/RR to fix it.  May also cause problems with RFC 
> >1889,
> >       etc.  Can be conf
> >2) Multiple early RTCPs at start of stream
> >   Pretty simple to implement - just send RTCPs.
> >   Problem: requires AVPF/SAVPF.  Blows RTCP bandwidth that might be 
> >needed
> >       for other things.  Need to decide how much extra to send, and 
> >when
> >       to stop (new CCM message?).  May not work for non 
> point-to-point
> >       topologies(?).  Probably should be signaled.
> >3) Add "I need an NTP sync point" CCM message.
> >   Not hard to implement.  Saves bandwidth.  Don't need to 
> guess when 
> >to
> >       stop sending SR/RR.  Normally (baring non-compound RTCP) also
> >       includes your own sync info.
> >   Problems: Still some latency (though can be low), especially if 
> >there
> >       are lost packets (especially if the "I need an NTP 
> sync point" 
> >gets
> >       lost).  Decision about how to handle loss is an issue 
> (how long 
> >to
> >       wait).  Needs rtcp-fb additions (probably).
> >4) Specify the initial cross-layer sync in the negotiation.
> >   Allows sync on the very first packets in the streams.  Occurs on
> >       a reliable channel.
> >   Problems: sync may drift; RR/SR still needed.  May be 
> hard for some
> >       applications to get what "will be" a sync point 
> before stream is
> >       established, especially in decomposed UAs.  May affect RFC1889
> >       security (not sure, not sure if we care).  May yield larger 
> >SDPs,
> >       though you don't *need* to give the NTP time for each stream, 
> >just a
> >       set of timestamps that are of roughly equal NTP time (nearest 
> >packet
> >       to a common NTP time).
> >
> >Others?
> >  
> >--
> >Randell Jesup, Worldgate (developers of the Ojo videophone), 
> ex-Amiga 
> >OS team [email-masked] "The fetters imposed on liberty at 
> home have 
> >ever been forged out of the weapons provided for defence 
> against real, 
> >pretended, or imaginary dangers from abroad."
> >		- James Madison, 4th US president (1751-1836)
> >
> >
> 
> 
> ------------------------------
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
> 
> 
> End of avt Digest, Vol 53, Issue 5
> **********************************
> 
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt