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

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

Hi

Comments below
Regards
Ingemar
> -----Original Message-----
> From: Randell Jesup [mailto:rjesup at wgate.com] 
> Sent: den 14 november 2008 16:39
> To: Ingemar Johansson S
> Cc: Ye-Kui.Wang at nokia.com; avt at ietf.org
> Subject: Re: [AVT] 
> draft-schierl-avt-rtp-multi-session-transmission-00.txt
> 
> "Ingemar Johansson S" <ingemar.s.johansson at ericsson.com> writes:
> >> >>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.
> 
> SRTP doesn't use header extensions.  (I think ZRTP was doing 
> so, but I don't know if they kept that or if there were 
> alternatives, and I think ZRTP just would consider that a 
> case where the channel couldn't be secured if there's no 
> alternative channel (RTCP?) for key exchange.)
Maybe I misunderstand things here but..Tried to read through RFC3711 but
I failed to find anything that metions something like that SRTP
precludes the use of header extensions. It is correct that the header
exension is sent as open information but I don't see this as an issue as
long as the information in the header extension does not reveal any
encrypted information. 

> 
> There's no easy way to know (except maybe by asking the ZRTP 
> people) how often this happens. Certainly Asterisk and things 
> like it would be a major blocker to this (they act as kind-of 
> B2BUA's -- don't get me started on what a mess their 
> implementations are).  I haven't seen a true SBC that 
> stripped them - but on the other hand I haven't used header 
> extensions except occasionally.
> 
> >> 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.
> 
> That does cover the requirement that header extensions can't 
> be mandatory, though the details and consequences of the 
> fallback need the be worked out.
OK

> 
> Adding it to every packet is a big no-no as mentioned.  Which 
> packets would it need to be added to, taking into account 
> packet loss, startup, etc?
OK, needs to be clarifies. 

> 
> The scheduling issues may mean that these extensions don't 
> get transmitted for a while, but another issue is that the 
> inserters of the extensions aren't always coordinated -- 
> witness ZRTP which in the current implementation acts as a 
> wrapper layer - if the main RTP stack adds an extension, that 
> means that ZRTP can't use that packet for an extension.
> This should be ok, and ZRTP has to account for this 
> possibility (as well as packet loss).
I believe that for cases like SVC and G.718 it should be possible to
synchronize the transmission of "alignment-info" as the layers after all
stem from the same encoder and it is probably in these cases that the
need to ensure perfect alignment is the biggest (for audio codecs it
must match to the sample) 


> 
> --
> 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