Re: [AVT] draft-schierl-avt-rtp-multi-session-transmission-00.txt

["Ingemar Johansson S" <ingemar.s.johansson at ericsson.com>]

Hi

Comments inline below 

Regards 
Ingemar

> -----Original Message-----
> From: Randell Jesup [mailto:rjesup at wgate.com] 
> Sent: den 13 november 2008 19:51
> To: Ye-Kui.Wang at nokia.com
> Cc: Ingemar Johansson S; avt at ietf.org
> Subject: Re: [AVT] 
> draft-schierl-avt-rtp-multi-session-transmission-00.txt
> 
> <Ye-Kui.Wang at nokia.com> writes:
> >I tend to agree with Ingemar that the problem of the RTP header 
> >extension mechanism is not serious. If the RTP header extension 
> >mechanism is based on decoder order numbers of coded data 
> units, then I 
> >think it is really generic and applies to any layered or 
> multi-source 
> >codec, including flexible scalable video codecs such as SVC.
> 
> 
> Ingemar Johansson writes;
> >>I have a comment on
> >>draft-schierl-avt-rtp-multi-session-transmission-00.txt
> >>
> >>
> >>=============
> >>7.2.6.  RTP header extension
> >>
> >>   The RTP header extension may be used to add generic 
> signaling about
> >>   Data Alignment to RTP packets.
> >>
> >>7.2.6.1.  Identified problems
> >>
> >>   RTP header extensions are required to be ancillary 
> information which
> >>   can safely be discarded by receivers which do not 
> understand them.
> >>   Data alignment mechanisms do not satisfy this requirement.
> >>=============
> >
> >>My question is ..how serious is the identified problem ?. 
> >>My gut feeling is that a receiver that implements e.g decoding of 
> >>G.718 content will likely update the RTP stack to recognize header 
> >>extensions if header extensions are used to carry e.g the NTP 
> >>timestamp related to the RTP timetstamp in the RTP header.
> 
> What if an intermediary deletes the header extension?  (SBC, 
> B2BUA, raw message store, etc).
There is of course a risk that this may happen. 
However I am curious as to what extent this may actually happen as it
would also cause the authentication to fail in case SRTP is used.

> 
> This isn't to say it might not be a good idea - but requiring 
> header extensions to pass through may not be a good idea.  
> You also have issues where you can't use multiple header 
> extensions in the same RTP packet, so moving too much to them 
> is a problem.
Ok. A fallback is always to use RTCP SR (which is sent anyway), the
convergence will be slower and clock-skew compensation will complicate
an implementation somewhat but it will anyway be a fallback solution.
The additional method (if possible to use) will speed up convergenge.
As for the problem with multiple header extensions, I would not believe
that you need to add the "timing alignent" header extension in every
packet. Also I believe it is up to the sender to prioritize between the
header extensions.


> 
> --
> Randell Jesup, Worldgate (developers of the Ojo videophone), 
> ex-Amiga OS team rjesup at wgate.com "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
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt