Subject: [avtext] Comments on draft-petithuguenin-avtext-multiple-clock-rates-00

From: Magnus Westerlund <[email-masked]>
Date: Thu, 24 Mar 2011 10:35:58 +0100

Hi,

This mail is my personal opinions and not as a WG chair.

I have reviewed the draft and think it is a reasonable starting point
for meeting the WG's milestone.

However, I do have some technical comments.

1. Why haven't you considered to use the actual clock derivation method
that results in a correct result assuming no packet loss occurs, and
where RTCP will work to correct it when it occurs.

In my view the method in 2.2.1 is incorrect in one important detail:

timestamp = previous_timestamp + (current_capture_time -
   previous_capture_time) * current_clock_rate

The "current_clock_rate" should actually be previous clock rate. If one
uses the clock rate from the previous packet to cover the time period up
to a switch then one avoids any discontinuities and the jitter doesn't
make a jump before one knows what the new clock rate is.

It is also consistent with logical thinking for any media that had
duration. Take for example audio with 20 ms frame lengths, the RTP TS
value for a packet with one frame provides the time at the start of the
frame. Then the frame has a duration of 20 ms, thus resulting in that
the timestamp value of any next frame that are aligned with the current
will be starting at last_TS+0.02*clock_rate.

Thus resulting in that the formula should read:
timestamp = previous_timestamp + (current_capture_time -
   previous_capture_time) * previous_clock_rate

One also needs to reconsider the arrival formulas to use previous:
 (1)  current_time_capture = (current_timestamp - previous_timestamp) /
      previous_clock_rate + previous_time_capture
   (2)  transit = previous_clock_rate * (time_arrival -
      current_time_capture)
   (3)  previous_time_capture = current_time_capture
   (4) previous_clock_rate = current_clock_rate

Using these formulas to update table 2:

   +-------+-------+-----------+---------+---------+--------+----------+
   | Capt. | Clock | RTP       | Arrival | Transit | Jitter | Average  |
   | time  | rate  | timestamp | time    |         |        | jitter   |
   +-------+-------+-----------+---------+---------+--------+----------+
   | 0     | 8000  | 0         | 0.1     | 800     |        |          |
   | 0.02  | 8000  | 160       | 0.12    | 800     | 0      | 0        |
   | 0.04  | 8000  | 320       | 0.14    | 800     | 0      | 0        |
   | 0.06  | 8000  | 480       | 0.16    | 800     | 0      | 0        |
   | 0.08  | 16000 | 640       | 0.18    | 800     | 0      | 0        |
   | 0.1   | 16000 | 960       | 0.2     | 1600    | 0      | 0        |
   | 0.12  | 16000 | 1280      | 0.22    | 1600    | 0      | 0        |
   | 0.14  | 8000  | 1600      | 0.24    | 1600    | 0      | 0        |
   | 0.16  | 8000  | 1760      | 0.26    | 320     | 0      | 0        |
   +-------+-------+-----------+---------+---------+--------+----------+

Which I think avoids all the issues with the jitter etc.

If a packet loss occur with the first packet with the new rate then
there will be a jitter value here due to the definition of jitter as
using the timestamp values of the older packet part of the calculation.

2. Also I think Section 2.2.2 points to a naive implementation of that
method. As I see it when you do calculations based on that method you
need to use the more expanded formula:

timestamp = (capture_time-capture_start) * clock_rate + Start_offset

Then every time you change the rate you need to set new values for
"capture_start" and Start_offset:

Start_offset = (capture_time_start_of_new_rate-capture_start)
*previous_clock_rate
capture_start = capture_time_start_of_new_rate

3. Section 4:

   An RTP Sender with RTCP turned off (i.e. by setting the RS and RR
   bandwidth modifiers defined in [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 is calculated as
   described in Section 2.2.2.

   An RTP Sender with RTCP turned on MUST use a different SSRC for each
   different clock rate.  An RTCP BYE MUST be sent and a new SSRC MUST
   be used if the clock rate switches back to a value already seen in
   the RTP stream.

Here I found the recommendations to be the reverse of what I would
expect. If you don't have RTCP then you can't handle and clock rate
switch, because if a packet loss occurs either as the last or first
packet of the switch the receiver loses sync.

If you have RTCP then you can recover from that by reestablishing the
sync point after the switch. Thus this is robuster against packet loss.

4. Section 4:

   To accelerate lip synchronization, the next compound RTCP packet sent
   by the RTP sender MUST contain multiple SR packets, the first one
   containing the mapping for the current clock rate and the next SR
   packets containing the mapping for the other clock rates seen during
   the last period.

Isn't this going to create interoperability issues? The inclusion of
multiple SRs in the same compound packet is that going to work well. I
think my implementations would have issues with that. I think there are
uncertainties in the interpretation of how one sends compound packets
with multiple SSRCs being there source. I have run into this in another
context, namely RTP Retransmissions using SSRC multiplexing. Then one
end-point has two SSRCs used for transmitting packets. In that case
including both in the same RTCP compound packet appeared to create
issues in two regards:

1. Calculation of when these packets are allowed to send and how they
fulfill the RTCP bandwidth rules.

2. How they handle the inter SSRC reporting. Because unless one of the
SSRC's aren't reporting that they see the other SSRC's media stream, it
will look like there is a bifurcation of the RTP session for any third
party monitor.

Do you have any data that such behavior will work with existing
implementation?

The above comments also applies to the second paragraph of section 5.

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: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 28 Mar 2011 05:34:51 +0200

Hi Magnus,

Thanks for the review, and sorry to not responding sooner.

> where RTCP will work to correct it when it occurs.

This formula looks good, but remember that what I put in the draft is not what 
is the correct formula or what formula I would have used, but the formula that, 
after talking with few fellow implementers and trying to decipher FOSS 
implementations, is used in most implementations.  My goal my this draft is not 
to show people what they should have done - which is pointless - but what they 
should do in future implementations so it works with existing implementations.

So if you say that the formula here is used in actually deployed 
implementations, then I will be happy to add it to the list (but it cannot 
replace the existing formula, because this is what is used in the field).

> Using these formulas to update table 2:

A the difference of the formula in 2.2.1 (which is what people actually use)), 
the formula in 2.2.2 is the one that the I-D tentatively set as the formula for 
future implementations that does not want to use a different SSRC (more about 
this below).

Now you do not explain why this formula is better than the simpler formula 
capture_time * clock_rate.  See also my response to the next comments.

> packet of the switch the receiver loses sync.

The reason for this recommendation is that most VoIP implementations do not 
implement RTCP, do not support multiple SSRC, and will never support multiple 
SSRC (nobody managed to convince them to do it in the last ten years, that will 
not happen now, it's a lost cause).  So that recommendation was to try to help a 
little bit with this situation.  Honestly I'd rather put a "MUST use a different 
SSRC" here, and get completely rid of the formula in the previous section of 
this email (that does not change that we need to interpret these formulas 
correctly on the receiving side, but a least we do not have to recommend a 
formula for sending as we would always use different SSRCs in new implementations).

> Do you have any data that such behavior will work with existing

Well, that was Colin Perkins and David Oran's recommendation (10/15/2009 
emails).  I can revisit that if needed.

-- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 28 Mar 2011 09:47:51 +0200

Marc, WG

See Inline

> replace the existing formula, because this is what is used in the field).

Ok, I did misunderstand that. I think one should use this formula for
how one should implement this.

> capture_time * clock_rate.  See also my response to the next comments.

Well, it avoids the jump backwards in TS that you got unless you adjust
the start point.

> formula for sending as we would always use different SSRCs in new implementations).

I do see two problems here. One is how well will this single SSRC
implementation support an SSRC switch? That appears to at least be
potentially an issue.

Secondly, I think we should recommend a good formula that works. Yes,
without the RTCP you can still become un-synchronized when switching and
facing a packet loss. But apparently these VoIP vendors don't care about
that if they only have a single SSRC and no RTCP.

> emails).  I can revisit that if needed.

Well, I think one should test this at SIPIT before actually recommending
it. I see it as being problematic.

Cheers

Magnus Westerlund