Support for Multiple Clock Rates in an RTP Session
draft-ietf-avtext-multiple-clock-rates-11
Yes
(Gonzalo Camarillo)
No Objection
(Benoît Claise)
(Brian Haberman)
(Jari Arkko)
(Martin Stiemerling)
(Pete Resnick)
(Richard Barnes)
(Stewart Bryant)
(Ted Lemon)
Note: This ballot was opened for revision 10 and is now closed.
Gonzalo Camarillo Former IESG member
Yes
Yes
(for -10)
Unknown
Spencer Dawkins Former IESG member
Yes
Yes
(2013-11-20 for -10)
Unknown
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.
Barry Leiba Former IESG member
No Objection
No Objection
(2013-11-15 for -10)
Unknown
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?
Benoît Claise Former IESG member
No Objection
No Objection
(for -10)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -10)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -10)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -10)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -10)
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
(for -10)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2013-11-19 for -10)
Unknown
- 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
Stewart Bryant Former IESG member
No Objection
No Objection
(for -10)
Unknown
Ted Lemon Former IESG member
No Objection
No Objection
(for -10)
Unknown