Subject: [avtext] I-D Action: draft-ietf-avtext-multiple-clock-rates-00.txt

From: [email-masked]
Date: Tue, 07 Jun 2011 00:35:30 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Extensions Working Group of the IETF.

	Title           : Support for multiple clock rates in an RTP session
	Author(s)       : Marc Petit-Huguenin
	Filename        : draft-ietf-avtext-multiple-clock-rates-00.txt
	Pages           : 10
	Date            : 2011-06-01

   This document clarifies the RTP specification when different clock
   rates are used in an RTP session.  It also provides guidance on how
   to interoperate with legacy RTP implementations that use multiple
   clock rates.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avtext-multiple-clock-rates-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-multiple-clock-rates-00.txt

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 13 Jun 2011 15:07:42 +0200

Hi,

I have reviewed this WG 00 version, and thanks the other for taking my
comments into consideration in the previous version.

I have some additional comments and suggestions for improvements.
However I think it is important that we get input from the WG on these
questions.

The below are my views as an individual, not WG chair.

1. Section 1:
"This document first tries to list in Section 2 and subsections all
   the various algorithms used by existing RTP implementations."

Wouldn't it better to state that this section "lists all known
algorithms used in RTP implementations of the time of writing." Or
something like this. To avoid using "all" without a qualifier.

2. Section 4.1:
> Each time the clock rate changes, the start_offset and capture_start
>    values are calculated with the following formulas:
> 
>    start_offset = (capture_time - capture_start) * previous_clock_rate
>    capture_start = capture_time

I think it is important to elaborate on what "capture_time" is in this
formula. That it is the capture time of the first instant the new
timestamp rate is going to be used.

3. Section 4.1:

I am still not quite happy about these recommendations:

   An RTP Sender with RTCP turned on MUST use a different SSRC for each
   different clock rate.

Because in more advanced applications like video conferencing with
centralized mixing the impact of switching SSRC is so big. It can
involved the following mechanisms that will be effected:

- Any connection to application logic, side boards etc.
- The issue that who a SSRC becomes unknown until an CNAME is
distributed to everyone that needs to know, that include speaker
indication using CSRC.
- RTP retransmission, that needs to use another SSRC and then acquire
the binding using CNAME is SSRC multiplexed.
- The fact that switching and "BYE" an SSRC prevents an receiver to
request retransmission of the packet that has been lost but not yet
delivered when the SSRC is given up.
- TMMBR limiations set on a SSRC value that needs to be transfered to
the new one.

So I think "MUST" is way to strict as rule. Especially as there are
rules that make this problem much less an issue as soon as
implementations has been updated. But that will be a bit more work as we
should also include clarifications and fixes on the found issues around
RTCP clock rate switches. And recommendations for how to avoid the issue
in the future.

4. Section 4.2:

 D(i,j) = (arrival_time_j * clock_rate_i - timestamp_j) -
   (arrival_time_i * clock_rate_i - timestamp_i)

I think it is important that this is expanded a bit.

First of all that we will only avoid an error if "j" is the first packet
for the new Timestamp Rate. Thus we should likely discuss how one gets
this value to be a sane one in any RTCP report. Likely by doing the
calculation twice, one up to the switch and then a second time from the
switch forward.

If one doesn't get the packet which is first of the switch, then I think
we should consider if we need to discuss how one use the two nearest SRs
to calculate the actual point of the switch.

If my math hasn't gone wrong I think

NTP_of_Switch = (TS_j-TS_i+ R_i*N_i - R_j*N_j)/(R_i-R_j)

Where i is an RTCP SR prior to the switch and j is an RTCP SR after the
switch and TS is the timestamp value, N the NTP value and R the
timestamp rate at that moment.

What I don't know is how robust this is to a non-consistent method of
timestamp value switch.

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: Wed, 22 Jun 2011 12:37:42 -0700

I plan to update and publish a new version of the draft this week-end,
incorporating the comments below, so if someone else has comments on the
document, please send them as soon as possible.

Thanks.

On 06/13/2011 06:07 AM, Magnus Westerlund wrote:
> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext
> 

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