Hi
Some comments after reading in more detail thorugh the
docs.
I believe that Colin makes a very strong nd valid point
that the RTCP-SR rate will likely be high enough to yield a fairly fast
synchronization.
The problem I see is in clock-skew and clock-resolution.
Clock-skew compensation requires that a number of RTCP-SR are received to be
able to compensate for the clock-skew. The clock-resolution (10-15ms
mentioned for Windows Vista) can be a
problem.
In order to this to become a problem the lack of
accuracy should in e.g the G.718 case be a frame-slip (20ms) i.e a
layer is applied with a N*20msec offset. Now how big is this risk ?. I
would believe that clock-skew is a relatively small risk given the relative fast
RTCP-SR rate. Clock accuracy can however be a problem and I would not
neglect it.
Also.. How do one detect that the layers are not
synchronized?. Must admit hear that it is some time since I read the G.718
draft, what is the method to detect this.
As for the proposed solution in draft-schierl-avt-rtp-multi-session-transmission to
use the same RTP timestamp for teh
different layer. Given the weakened security is acceptable this is probably
useful. One limitation is of course that it assumes the same RTP timestamp clock
for the different layers, perhaps not an issue today but what about the future
?.
Header extensions: Although header extensions are quite
simple and would make it simple to overcome the clock-skew and clock-accuracy
issue there seems to be a number of serious issues. However my feeling is that
some of the issues are sort of corner cases. When services are created codecs
are bundled with transports some of these issues would go away. I recall that
header extensions are proposed to be used in some 3GPP service despite the
possible issues.
My 5 cents
/Ingemar
I think it is nice to go into a deeper discussion on a particular
solution, but we should first solve the following questions:
"Do we need a
new solution or an extension to the existing mechanism? And, are the arguments
collected in the draft convincing reasons for going that way?"
Let us
assume one special problem goes away - the delay in presence of multiple
receivers allowing bidirectional communication (see:
draft-perkins-avt-rapid-rtp-sync-00).
Thanks,
Thomas
--
Thomas Schierl
--------------
Fraunhofer HHI
Randell Jesup wrote:
"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.)
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.
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?
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).
----
Visit us at
MEDICA 2008 / Duesseldorf, Germany /
19 - 22 November 2008 / Hall 16, Booth D55
http://www.medica.de
SOCCEREX 2008 /
Gauteng, South Africa / 23 - 26 November 2008 / Booth V1-B1 a
http://www.soccerex.com