Subject: [avtext] Comments on draft-ietf-avtext-multiple-clock-rates-05

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Jun 2012 09:42:35 +0200

Hi,

I have reviewed the draft and found some significant issues that I think
should be addressed prior to a WG last call.

1. Section 4.1: The RTP extension defined in Perkins & Schierl [RFC6051]
MAY be used to accelerate the synchronization.

I would suggest that you change this to:

The RTP header extension defined in "Rapid Synchronisation of RTP Flows"
[RFC6051] MAY be used to accelerate the synchronization.

That tells the reader more about which type of extension and what it is
for than the previous formulation.

2. Section 4.2: I found one sever error in the formula:

First:
start_offset = (capture_time - capture_start)
                              * previous_clock_rate

This is missing to add the original start_offset to the new offset
calculated. Thus the start_offset calculation should be:

start_offset = (capture_time - capture_start)
                              * previous_clock_rate + start_offset

3. Section 4.2: Then I think the timestamp calculation should make clear
where the initial random offset is to be added. And to my understanding
it needs to be added in the timestamp formula which thus should read:

timestamp = (capture_time - capture_start) * clock_rate
                      + start_offset + random_initial_offset

Or as an alternative, set the initial values, i.e:
 start_offset = 0

to

 start_offset = random_initial_offset'

And that works to.

4. Section 4.3:

I think one has to clarify that "j" is the newer arrival compared to "i"
which is the previous arrival.

5. Section 4.3:
   For interoperability with legacy RTP implementations, an RTP receiver
   MAY use the information in two consecutive SR packets to calculate
   the clock rate used, i.e. if Ni is the NTP timestamp for the SR
   packet i, Ri the RTP timestamp for the SR packet i and Nj and Rj the
   NTP timestamp and RTP timestamp for the previous SR packet j, then
   the clock rate can be guessed as the closest to (Ri - Rj) / (Ni -
   Nj).

Frankly, I don't see how this is correct or which information around the
used clock rate that you try to derive. I have to assume that you know
the previous RTP clock rate. But you have failed to receive any new RTP
packets so the receiver doesn't yet know which clock rate is used. Lets
assume that you have three clock rates in use in this RTP session, lets
say 32k, 16k and 8k. You where running at 32k. Applying the above
formula when the switch was very close before sending the second SR
packet to 8k. Then you could plug in values like the following:

Ri = 400000
Ni = 0

Switch happens 3.8 seconds into this interval
Rj = 400000 + 121600 + 1600 = 523200
Nj = 4.0 s

Then the above formula yields a value of = (400000 - 523200) / (0 - 4) =
30800

That says you only that a switch to a lower than current clock rate has
happened. Not which of them. This formula will only yield a correct
result when there are no switches in between the two SR used to
calculate the value.

To my understanding in the presence of packet loss you require both a
RTP packet indicating the current payload type and an RTCP SR or
equivalent time sync info to determine correctly where the switch
happened (assuming a correct monotonically increasing timestamp space).

6. I wonder if not this specification should clarify the unclarity
regarding monotonically increasing RTP timestamp values that this is
required. Not only the clock one derives it from. And that put into
section 4.

7. Section 4. I think Section 4 should contain the equivalent of table 2
and 3 to provide what values that the formulas in 4.2 and 4.3 provides.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Glen Zorn <[email-masked]>
Date: Sun, 24 Jun 2012 07:54:49 +0700

> for than the previous formulation.

The "Perkins & Schierl" construct was an attempt to avoid the typical
practice of writing something like "[RFC6051] defines...", which is
abominable.  However, reproducing the title of a referenced document is
even worse stylistically.  How does the existing text not tell the
reader what the extension is for?

>                               * previous_clock_rate + start_offset

I'm not sure I understand.  By "original start offset", do you mean the
initial vale of the start_offset variable?  That is zero, so I don't see
how it helps to add it in every time, so it must be something else?

> where the initial random offset is to be added. 

The first paragraph of the section says:

   An RTP Sender with RTCP turned off (i.e. by setting the RS and RR
   bandwidth modifiers [RFC3556] to 0) SHOULD use a different SSRC for
   each different clock rate but MAY use different clock rates on the
   same SSRC as long as the RTP timestamp without the random offset is
calculated 
   as explained below[...]

> And to my understanding

...

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 25 Jun 2012 13:05:30 +0200

> reader what the extension is for?

We are at least in agreement that just an RFC number is insufficient. I
have to say that I am currently not confused by the old sentence due to
it containing sufficient context to determine which specification it is
without remembering all the RFC numbers. I do say that my proposal can
be improved significantly when it comes to removing redundancy and make
it more readable. That it is horribly stylistically I don't agree with,
and I think the benefit in many cases warrants such an approach.

Take this as a suggestion from me.

> how it helps to add it in every time, so it must be something else?

Yes, the first time you switch it will be zero. The next time it will be
non-zero and must be included to avoid erronous values after a second
switch.

>    same SSRC as long as _the RTP timestamp without the random offset is
> calculated_
>    as explained below[...]
> 

Yes, but I think we can improve this by including the random offset into
the calculation so they don't do it in the wrong step with the wrong
result. Either initially or at the end works. Doing it somewhere in the
middle is not a good idea.

-- 

Magnus Westerlund