Rapid Synchronisation of RTP Flows
draft-ietf-avt-rapid-rtp-sync-13

A good document, thanks.

I found "can be synchronised immediately" jarred a little. I guess it is immediate from a certain point of time :-)

What is the impact of some of the elements in the multimedia session not being updated to support these extensions? One of the cases mentioned in the document is middleboxes that may not understand the header extensions and may remove them, another would be if some of the receivers or the sender are not updated. I understand that the protocol extensions are designed robustly and with backwards compatibility in mind so that nothing breaks, but what are the tools at hands of a manager to understand which elements in the network support the extensions and which ones do not?

From the discussions with the editors I understand that these cases are known and understood and that there are methods for a nertwork operator to detect them like  logging which receivers are generating rapid resynchronisation requests or inspecting the signalling exchange (for in-band delivery of synchronisation metadata). It would be good if these were documented in the RFC.

1. Have the identifiers "urn:ietf:params:rtp-hdrext:ntp-56" and "urn:ietf:params:rtp-hdrext:ntp-64" passed Expert Review in accordance with RFC 5285?

2. Please check some of the lower-case conformance language ("may", "should", "must"). Here are some examples where the all-caps versions might be appropriate:

   The RTP extension
   for unicast-based rapid acquisition of multicast RTP sessions
   [16] may be used to reduce the time taken to receive the access
   points in some scenarios.

   If the use of non-compound RTCP [5] was
   previously negotiated, both the feedback request and the RTCP SR
   response may be sent as non-compound RTCP packets.

   The media source may ignore RTCP-SR-REQ
   packets if its regular schedule for transmission of synchronisation
   metadata can be expected to allow the receiver to synchronise the
   media streams within a reasonable time frame.

   Once a receiver has synchronised the components of a layered, multi-
   description, or multi-view flow using the RTP header extensions as
   described in Section 4.1, it may then derive a decoding order based
   on the synchronised timestamps as follows (or it may use information
   in the RTP payload header to derive the decoding order, if present
   and desired).

   Flows may also include packets corresponding to additional sampling
   instants that are not present in the flows on which they depend.

   The
   decoding order of the RTP flow hierarchy may be indicated by
   mechanisms defined in [8] or by some other means.

   These timestamps may be derived using
   the NTP format timestamp provided in the RTCP sender reports or as
   shown in the figure directly from the NTP timestamp contained in the
   RTP header extensions as indicate by the timestamp in "<x>".

   If a feedback
   target receives an RTCP-SR-REQ feedback message in such a case, the
   request should be forwarded to the media source.

   Receivers should use both the information
   contained in RTCP SR packets and the in-band mapping of RTP and NTP-
   format timestamps as input to the synchronisation process,

   For H.264 SVC, the Empty NAL unit packet [9] should be used.

   The receiver should decode the packets in all the component RTP flows
   as follows:

   Accordingly, a receiver must
   estimate the skew on the NTP-format clock in order to align RTP
   timestamps across sessions.

   o  The sender must negotiate the use of the RTP header extensions
      described in Section 3.3, and must periodically and synchronously
      insert such header extensions into all the RTP flows forming the
      separate components of the layered, multi-description, or multi-
      view flow.

For other uses of the lowercase words, you might consider changing "may" to "might" or "can", "should" to "ought" or "will", and "must" to "needs to" or some other appropriate phrase.

Questions about 2119 language (i.e., should these be capitalized?):

1) and media security keys should have been ...
2) the request should be forwarded to the media source ...
3) Receivers should use both the ...
4) The sender must negotiate the use of the RTP header extensions described in Section 3.3, and must periodically ...
5) For H.264 SVC, the Empty NAL unit packet [9] should be used.
6) The receiver should decode ...

I support Sean's discuss on clock synchronization