Support for Multiple Clock Rates in an RTP Session
draft-ietf-avtext-multiple-clock-rates-11

[Ballot comment]
In this text: 3.2.2.  Non-monotonic timestamps

  The advantage with this method is that it works with the jitter
  calculation described in RFC 3550, as long as the correct clock rates
  are used.  It seems that this is what most implementations are using.

Is there a pointer you can include for "what most implementations are using"?

I see that you mention SIPit later in the document - if this statement is based on Robert's summary from a specific SIPit, for example, I'd be fine with that.

[Ballot comment]

- The secdir review [1] raised a question that wasn't
afaik answered. I'm not sure if there's any change
needed but be good to see an answer to that just in
case.

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04299.html

[Ballot comment]
Should the abstract say another few words about *what* clarification is being made?

Please expand "SSRC" and "SR packets" on first use.

-- Section 3.1 --

  This is
  not different than what happen at the beginning of the RTP session
  but it can be more annoying for the end-user.
 
Can you say this a different way, so that it's more usefully explanatory?  Or perhaps even omit it, if it doesn't really add anything.

-- Sections 3.2.1, 3.2.2, and 4.2 --
I found myself looking for the tables.  If you really don't want to include them in the sections that cite them, it would help to explicit say, "Table 2 in Appendix A" and so on.  Though, as a reader, I'd rather see them inline, so I can refer to them without having to scroll to the bottom of the document and back.

-- Section 4.1 --

  To accelerate lip synchronization, the next compound RTCP packet sent

Checking: is "accelerate" really the right word here?  Just thinking in plain English, I don't thinking of lip synch happening at a rate of speed.  "Facilitate", maybe?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-avtext-multiple-clock-rates-10.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

We understand that, upon approval of this document, there are no IANA Actions that need completion.  IANA requests that the IANA Considerations section of the document remain in place upon publication.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Support for Multiple Clock Rates in an RTP Session) to Proposed Standard


The IESG has received a request from the Audio/Video Transport Extensions
WG (avtext) to consider the following document:
- 'Support for Multiple Clock Rates in an RTP Session'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-10-22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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.  It updates RFC 3550.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-avtext-multiple-clock-rates/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-avtext-multiple-clock-rates/ballot/


No IPR declarations have been submitted directly on this I-D.

WG last call was requested. Magnus Westerlund did a review and found what he believes is significant issues that needs to be resolved prior to WG last call.