Subject: Re: [avtext] Comments on draft-ietf-avtext-multiple-clock-rates-00.txt

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 11 Jul 2011 13:46:39 -0700

I just released a new version of this draft that incorporate the two first
points below.  Unfortunately, and I apologize for that, I did not had the time
to work on the two remaining points.  I will have more time to work on that
before Taipei and we should still be on time for the submission in December as
per the charter.

On 06/13/2011 06:07 AM, Magnus Westerlund wrote:
> 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.

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