Associating Time-Codes with RTP Streams
RFC 5484

[Ballot comment]
1. I support Magnus's DISCUSS.

2. Sections 7 and 8 seem to be informative, and it would be good to make this clear in the document.

[Ballot comment]
1. I support Magnus's DISCUSS.

2. Sections 7 and 8 seem to be normative, and it would be good to make this clear in the document.

[Ballot comment]
I support Magnus's DISCUSS. Concerning the DISCUSS from Russ, section 7.1.2 in RFC 2026 speaks about 'other proprietary specification' that is not widely available - this does not seem to be the case here.

[Ballot comment]
Section 3:

There are at least two section references that reference the wrong sections for the solution, they point at 5.3 and 5.4 instead of 6.3 and 6.4.

[Ballot discuss]
Section 5:

There is an substantial oversight in the definition of the signalling information in that it does not provide a reference to which RTP timestamp rate the frame duration is provided in. As an RTP session may have multiple RTP payload types and these may have different timestamp rates there need to be an explicit indication of which clock the frame duration is provided in. To me there is two possible solutions:

1. Provide the RTP timestamp rate the duration is provided in.

2. Reference the one or more RTP payload types that have the same timestamp rate.

I think solution one has the benefit in that it doesn't need to be rewritten in case of offer/answer negotiation changing RTP payload type numbers or removing certain payload types. That as long as no further binding in needed.

When this has been introduced one also needs to introduce multiple extmap lines for the different payload types so that it is clear what information is used in which case. Alternatively one uses the payload type and provide all possible combinations of frame durations vs RTP timestamp rate.

Section 6.3:

Any RTP payload type switch that result in a change of timestamp will also here be an issue. Especially as this format allows one to project a binding into the future. Therefore I think one needs to indicate which RTP timestamp rate one does assume to be valid at the point of binding. Using RTP payload type to indicate this requires 7 bits which isn't available. Also the header extension ID field doesn't fit either.

However, the simplest solution is probably to not support this on this level and instead provide updated information. Thus whenever one is switching payload type that has different timestamp bit-rates one is required to use the header extension in the RTP stream in the first 3 packets after the switch. Then include the correct binding in the new packet and say to use the RTP timestamp rate for the currently incoming payload type.

[Ballot discuss]
Miguel Garcia raised a question during IESG Last Call that has not
  received been discussed as far as I can tell.  This document makes
  normative reference to two specifications that are not widely
  available:

    http://store.smpte.org/product-p/smpte%200012m-1-2008.htm
    http://store.smpte.org/product-p/eg%200040-2002.htm

  According to RFC 2026 Section 7.1.2, the IESG may request that not
  widely available specifications are published as informational RFCs.
  Miguel is bringing this issue to the IESG's attention.

IANA Last Call comments:

Action 1:

Upon approval of this document, the IANA will make the following
assignments in the "RTCP Control Packet types (PT)" registry at
http://www.iana.org/assignments/rtp-parameters

abbrev. name value Reference
------------ ----- ---------
SMPTETC SMPTE time-code mapping TBD (194) [RFC-avt-smpte-rtp-13]


Action 2:

Upon approval of this document, the IANA will make the following
assignmentsin the "RTP Compact Header Extensions" registry at
http://www.iana.org/assignments/rtp-parameters

Extension URI Description Contact Reference
------------- ----------- ------- ----------
smpte-tc SMPTE time-codes ??? [RFC-avt-smpte-rtp-13]

Issue

Colin pointed out that someone may be tempted to think that the SMPTE time-codes, if used on two or more streams, could be used to provide synchronization, and if they yield to that temptation, might leave the usual RTCP sender report sync. info out of the streams. This paragraph makes it clear that (a) they cannot leave out the usual sync. mechanisms and (b) the draft does not constrain the timecodes in two or more streams to be the same, in the general case, in a paragraph at the end of section 3.

Proposed text:

In the case that a presentation contains more than one stream senders MUST continue to send the standard RTP synchronization information in RTCP, even if the streams carry SMPTE time-codes that could be used for synchronization.  In fact, when time-code is carried by more than one stream, this draft does not constrain the time-codes: at a given point in time, they may be the same, or they may differ (e.g. if they carry the original time-codes of different source material that was edited together).

Was this WGLC?

One significant question

I'm worried about the very limited frame range in the compact format. I understand the limitation of SMPTE but we already have lots of cameras that do way over 60 fps - I realize frame rates above this are not used as much in consumer stuff but it is used in lots of other places. What do you think of some idea like adding a second extension that just carried a frame number. A packet could cary both extensions if it needed to represent high frame numbers and there are probably usages  where one could compute the time information other than the frame number from other information available and just have the frame number packet.

Rest of stuff is small...

Need to update examples and IANA section once the hdrext registry stuff is sorted out.

The IANA section should be split into something that is the template for what you want to be in the final RFC and then a note to IANA about what they need to do and make it clear that can be removed by the RFC Editor.

Security section should say that this can be integrity protected with SRTP.

The order of the bits does not seem 100% clear - the usual packer layout drawing might be best way to do this.

The SMPTE-12M is not accessible without paying for it. This is obviously not a show stopper but it does make it less desirable to have this as a normative reference. Do you see a problem with defining the Full Format bits in this document and pointing out that this is the same bit format used by 12M and moving 12M to an informational reference.

It seems like the smpte-eg40 reference should be informational.

Might be a good idea to define or provide a pointer for NTSC.

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?

Tom Taylor  is the Document Shepherd.
I have personally reviewed this version of the document and consider it ready for forwarding.

(1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

This draft grew out of a discussion of the transport of SMPTE time codes
in January, 2005.
Initial draft, draft-singer-smpte-rtp-00.txt (2005-2-15), used RTCP
transport only. Concern that discontinuities could cause SMPTE markings
carried in RTCP to get out of synch with the RTP timestamps. Conclusion
was that SMPTE information should also be carried in the RTP stream.

Further discussion of requirements in Feb-March 2005. Concluded that
a flexible header mechanism would be desirable. At the same time, the
work was put out to SMPTE TV Systems Technology Committee for review.

draft-singer-smpte-rtp-01.txt issued 2005-6-1 along with
draft-singer-rtp-hdrext-00.txt, describing a general header extension
mechanism (currently with the AD).

Agreed at the Paris meeting (IETF 63) and confirmed on the list that
these should be Working Group documents.

draft-ietf-avt-smpte-rtp-00.txt published 2005-8-16
Comments by Colin Perkins.
draft-ietf-avt-smpte-rtp-01.txt published 2006-2-9
One of two open issues resolved through discussion with
members of the SMPTE, who reviewed the work.
Author's proposal for the other one agreed on list.
draft-ietf-avt-smpte-rtp-02.txt 2006-6-7
draft-ietf-avt-smpte-rtp-03.txt 2006-6-15
Colin Perkins comments, mainly editorial, 2006-6-23.
draft-ietf-avt-smpte-rtp-04.txt 2006-8-16
draft-ietf-avt-smpte-rtp-05.txt 2006-10-19
draft-ietf-avt-smpte-rtp-06.txt 2006-12-6
draft-ietf-avt-smpte-rtp-07.txt 2006-12-15
This last reflects nits review of related hdrext draft.

WGLC announced 2006-12-18, to close 2007-1-14. No comments received.
Reviews requested 2007-1-8 from members of the AVT review team).
Ladan Gharai responded 2007-02-07.
draft-ietf-avt-smpte-rtp-08.txt 2007-02-14 in response to these
comments.
draft-ietf-avt-smpte-rtp-09.txt 2007-02-23
draft-ietf-avt-smpte-rtp-10.txt 2007-02-26
Nit fixes.

(1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue.

All OK.

(1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Many of the WG's active members have addressed it. On that basis,
consensus appears to be strong.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews?

The document passes idnits. The following nits exist:
- extra 's' in esssentially' in the second paragraph of page 6
- the reference to hdrext needs to be up-versioned to -12
- in accordance with the IANA Considerations section of
draft-ietf-avt-rtp-hdrext-12.txt, the document must indicate that it
updates draft-ietf-avt-rtp-hdrext-12.txt

(1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].

All OK.

(1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation?

All OK except the third nit identified under (1.g).

(1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?

Not applicable.

(1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

This document describes a method to inform RTP clients when RTP
packets are transmitted at a time other than their 'nominal'
transmission time. It also provides a mechanism to provide improved
inter-arrival jitter reports from the clients, that take into account
the reported transmission times.

Working Group Summary

This RTP header extension was first defined within draft-ietf-avt-rtp-hdrext
as an initial application of the RTP header extension mechanism that draft
defines. As a result of WG discussion in July, 2006, it was moved to a
separate draft. Additional discussion resulted in further changes up through
Working Group Last Call. There is a strong Working Group consensus in favour
of the present document.

Document Quality

Solicited review comments from Qiaobing Xie and Ron Frederick provided a
final polish to the document.

Personnel

Tom Taylor is the Document Shepherd for this document?

Cullen Jennings is the Responsible Area Director?
No IANA expert is needed.