Subject: [avtext] Status of draft-ietf-avtext-multiple-clock-rates

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 02 Jan 2012 09:46:09 -0800

I did not had the time to work on this draft for the last 6 months, so let's
restart this by a summary of the goals, what was done so far, and what need to
be done to finish this.

This all started with the realization that, even if RFC 3550 clearly says that
multiple clock rates should not be used in the same SSRC, there is deployed
implementations that do exactly that, which creates 3 problems:  First, RFC 3550
does not explain how to calculate the RTP timestamp in this case.  Second, it is
not obvious to find what was the clock rate used with a specific RTCP SR packet.
 And third this make the calculation of the interarrival jitter difficult to do
correctly.

So there is 4 goals for this drafts:

1. Catalog the various formulas that legacy implementations use to generate the
RTP timestamp when using the same SSRC for different clock rates.

2. Define new normative rules for RTP Sender that have to deal with multiple
clock rates, so the RTP timestamp and RTCP SR can be correctly processed by
legacy implementations.

3. Defines new normative rules for RTP Receiver so they can correctly interpret
RTP timestamp and RTCP SR from both legacy and new implementations, and also so
they can generate RTCP packets containing correct interarrival jitter in all cases.

4. Do an analysis of the correctness of each combination of legacy RTP Senders
and RTP Receivers with the RTP Sender and RTP Receiver defined by this
specification.

For goal #1, we did not, in my opinion, fully catalog the behavior of the legacy
implementations and the survey done by Robert Sparks at Sipit did not return a
lot of data.  I will do an analysis of all the FOSS RTP stack I can find but
this still do not help for proprietary implementations.  I understand that
people could be reluctant to talk about there implementations, but please
contact me directly in any case.  We can arrange a NDA and anonymize the result
if needed.

For goal #2 and #3, Magnus Westerlund helped designed a new formulas.  There is
still some pending issues raised by Magnus in his last email[1], but there is no
doubt that we can reach some consensus here.

Work on goal #4 cannot be started until we finish the cataloging and reach
consensus on #2 and #3.  The difficulty here is to prove that everything will be
working for any combination of RTP Sender/Receiver, which would require writing
a lot of code.  Instead I prepared a Coloured Petri Net (CPN) model with
cpntools[2] that will permit to simulate the various cases in a way that will be
easily verifiable by everybody (I will publish the cpntool files under a AGPL3
license).

So we have the following action items:

- - Please contact me directly if you have an RTP implementation that deals with
multiple clock rates (even is it use different SSRC).
- - I will work on available FOSS RTP implementations.
- - I will answer Magnus email as soon as possible.
- - I will publish a new version of the draft before its expiration on January 12th.

Thanks.

[1] http://www.ietf.org/mail-archive/web/avtext/current/msg00162.html
[2] http://cpntools.org/

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 17 Jan 2012 15:21:19 +0100

WG and Marc,

I wonder if we can in a realistic timeframe complete all the goals to
the extent you indicate. The WG chairs propose adjusted milestones to
complete this in the WG by the summer.

So far the progress and especially the WG's interest hasn't been all
that good. I don't want to blame you, simple do a reality check. From
my perspective I think the most important is to ensure that goal 2 and
3 are completed. Anything on one simple supports the fact that there
are brokenness and diversity in the implementations deployed. Thus I
don't see how we can avoid having cases when legacy and well working
solution is less than optimal.

>From my perspective it is more important to allow the future to work
better, rather than having the transition be perfect. I do want WG
input on this, but if the WG's interest and especially energy to work
on it is limited I rather focus on the most important parts and
downgrade the ambitions for the less important parts.

WG, please provide your view on how we should handle this. Note, that
if you say do more, then I will expect that you are willing to help
out realize that.

Cheers

Magnus

On 2012-01-02 18:46, Marc Petit-Huguenin wrote:
> I did not had the time to work on this draft for the last 6 months,
> so let's restart this by a summary of the goals, what was done so
> far, and what need to be done to finish this.
> 
> This all started with the realization that, even if RFC 3550
> clearly says that multiple clock rates should not be used in the
> same SSRC, there is deployed implementations that do exactly that,
> which creates 3 problems:  First, RFC 3550 does not explain how to
> calculate the RTP timestamp in this case.  Second, it is not
> obvious to find what was the clock rate used with a specific RTCP
> SR packet. And third this make the calculation of the interarrival
> jitter difficult to do correctly.
> 
> 1. Catalog the various formulas that legacy implementations use to
> generate the RTP timestamp when using the same SSRC for different
> clock rates.
> 
> 2. Define new normative rules for RTP Sender that have to deal with
> multiple clock rates, so the RTP timestamp and RTCP SR can be
> correctly processed by legacy implementations.
> 
> 3. Defines new normative rules for RTP Receiver so they can
> correctly interpret RTP timestamp and RTCP SR from both legacy and
> new implementations, and also so they can generate RTCP packets
> containing correct interarrival jitter in all cases.
> 
> 4. Do an analysis of the correctness of each combination of legacy
> RTP Senders and RTP Receivers with the RTP Sender and RTP Receiver
> defined by this specification.
> 
> For goal #1, we did not, in my opinion, fully catalog the behavior
> of the legacy implementations and the survey done by Robert Sparks
> at Sipit did not return a lot of data.  I will do an analysis of
> all the FOSS RTP stack I can find but this still do not help for
> proprietary implementations.  I understand that people could be
> reluctant to talk about there implementations, but please contact
> me directly in any case.  We can arrange a NDA and anonymize the
> result if needed.
> 
> For goal #2 and #3, Magnus Westerlund helped designed a new
> formulas.  There is still some pending issues raised by Magnus in
> his last email[1], but there is no doubt that we can reach some
> consensus here.
> 
> Work on goal #4 cannot be started until we finish the cataloging
> and reach consensus on #2 and #3.  The difficulty here is to prove
> that everything will be working for any combination of RTP
> Sender/Receiver, which would require writing a lot of code.
> Instead I prepared a Coloured Petri Net (CPN) model with 
> cpntools[2] that will permit to simulate the various cases in a way
> that will be easily verifiable by everybody (I will publish the
> cpntool files under a AGPL3 license).
> 
> - Please contact me directly if you have an RTP implementation that
> deals with multiple clock rates (even is it use different SSRC). -
> I will work on available FOSS RTP implementations. - I will answer
> Magnus email as soon as possible. - I will publish a new version of
> the draft before its expiration on January 12th.
> 
> Thanks.
> 
> 
> [1]
> http://www.ietf.org/mail-archive/web/avtext/current/msg00162.html 
> [2] http://cpntools.org/
> 
> _______________________________________________ avtext mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/avtext
> 

-- 

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]
----------------------------------------------------------------------