AVT B. Ver Steeg Internet-Draft A. Begen Intended status: Standards Track Cisco Systems Expires: January 8, 2009 T. Van Caenegem Alcatel-Lucent Bell July 7, 2008 Unicast-Based Rapid Synchronization with RTP Multicast Sessions draft-versteeg-avt-rapid-synchronization-for-rtp-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 8, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract When a receiver joins a multicast session, it may need to acquire and parse certain key information before it can process any data sent in the multicast session. Depending on the join time, length of the key information repetition interval, size of the key information as well as the application and transport properties, the time lag before a receiver can usefully consume the multicast data, which we refer to VerSteeg, et al. Expires January 8, 2009 [Page 1] Internet-Draft Rapid Synchronization for RTP Flows July 2008 as the synchronization delay, varies and may be large. This is an undesirable phenomenon for receivers that frequently switch among different multicast sessions, such as video broadcasts. In this document, we describe a method using existing RTP and RTCP protocol machinery that reduces the synchronization delay. In this method, an auxiliary unicast RTP session carrying the key information to the receiver precedes/accompanies the multicast flow. This unicast flow may be transmitted at a faster than natural rate to further accelerate the synchronization. The motivating use case for this capability is multicast applications that carry real-time compressed audio and video. However, the proposed method can also be used in other types of multicast applications where the synchronization delay is long enough to be a problem. VerSteeg, et al. Expires January 8, 2009 [Page 2] Internet-Draft Rapid Synchronization for RTP Flows July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 6 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Elements of Delay in Multicast Streams . . . . . . . . . . . . 7 5. Elements of Delay in Video Systems . . . . . . . . . . . . . . 9 5.1. Overview of MPEG-2 Transport Streams . . . . . . . . . . . 9 5.2. Key Information Latency in Video Applications . . . . . . 11 5.2.1. PSI (PAT/CAT/PMT) Acquisition Delay . . . . . . . . . 11 5.2.2. Random Access Point Acquisition Delay . . . . . . . . 11 5.3. Buffering Delays in Video Applications . . . . . . . . . . 12 5.3.1. Network-Related Buffering Delays . . . . . . . . . . . 13 5.3.2. Application-Related Buffering Delays . . . . . . . . . 13 5.4. Breakdown of Typical Synchronization Delays in IPTV . . . 14 6. Rapid Synchronization . . . . . . . . . . . . . . . . . . . . 14 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Message flows and State Machines . . . . . . . . . . . . . 16 6.3. Encoding of the Signaling Protocol . . . . . . . . . . . . 19 6.4. Shaping the Burst . . . . . . . . . . . . . . . . . . . . 19 6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 19 7. Session Description Protocol (SDP) Signaling . . . . . . . . . 19 8. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 22 9. Open Source RTP Receiver Implementation . . . . . . . . . . . 22 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 14.1. Normative References . . . . . . . . . . . . . . . . . . . 23 14.2. Informative References . . . . . . . . . . . . . . . . . . 23 Appendix A. Protocol Encoding Option #A . . . . . . . . . . . . . 24 A.1. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 25 A.2. RTP Sequence Number for the First Rapid Synchronization Packet . . . . . . . . . . . . . . . . . . 26 A.3. Earliest IGMP Join Time . . . . . . . . . . . . . . . . . 26 A.4. Rapid Synchronization End Time . . . . . . . . . . . . . . 26 A.5. TSRAP Data . . . . . . . . . . . . . . . . . . . . . . . . 26 A.6. Actual Rapid Synchronization Fill . . . . . . . . . . . . 27 A.7. Join-Time Rapid Synchronization Fill . . . . . . . . . . . 27 Appendix B. Protocol Encoding Option #B . . . . . . . . . . . . . 27 B.1. RMS-R RTCP Message Format . . . . . . . . . . . . . . . . 27 B.2. RMS-I RTCP Message Format . . . . . . . . . . . . . . . . 27 B.3. RMS-T RTCP Message Format . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . . . . 30 VerSteeg, et al. Expires January 8, 2009 [Page 3] Internet-Draft Rapid Synchronization for RTP Flows July 2008 1. Introduction Most multicast flows carry a stream of inter-related data. Certain information must first be acquired by the receivers to start processing any data sent in the multicast session. This document refers to this information as "Key Information." The key information is conventionally sent periodically in the multicast session and usually consists of items such as a description of the schema for the rest of the data, references to which data to process for the receivers, encryption information including keys, as well as any other information required to process the data in the multicast flow. Real-time multicast applications require the receivers to buffer data. The receiver may have to buffer data to smooth out the network jitter, to allow loss-repair methods such as forward error correction and retransmission to recover the missing packets, and to satisfy the data processing requirements of the application layer. When a receiver joins a multicast session, it has no control over what point in the flow is currently being transmitted. Sometimes the receiver may join the session right before the key information is sent in the session. In this case, the required waiting time is usually minimal. Similarly, the receiver may also join the session right after the key information has been transmitted. In this case the receiver has to wait for the key information to appear again in the stream before it can start processing any multicast data. In some other cases, the key information is not contiguous in the flow but dispersed over a large period, which forces the receiver to wait for all of the key information to arrive before starting to process the rest of the data. The net effect of waiting for the key information and waiting for various buffers to fill up is that the receivers may experience significantly large delays in data processing. In this document, we refer to the difference between the time a receiver joins the multicast session and the time the receiver acquires all the necessary key information as the "Synchronization Delay." The synchronization delay may not be the same for different receivers; it usually varies depending on the join time, length of the key information repetition interval, size of the key information as well as the application and transport properties. The varying nature of the synchronization delay adversely affects the receivers that frequently switch among multicast sessions. In this specification, we address this problem for RTP-based multicast applications and describe a method that uses the fundamental tools offered by the existing RTP and RTCP protocols [RFC3550]. In this method, either the multicast source (or the distribution source in a VerSteeg, et al. Expires January 8, 2009 [Page 4] Internet-Draft Rapid Synchronization for RTP Flows July 2008 single-source multicast (SSM) session) retains key information for a period after transmission, or an intermediary network element joins the multicast session and continuously caches the key information as it is sent in the session and acts as a feedback target (See [I-D.ietf-avt-rtcpssm]) for the session. When a receiver wishes to join the same multicast session, instead of simply issuing an Internet Group Management Protocol (IGMP) [RFC3376] Join message, it sends a request to the feedback target address for the session asking for the key information. The feedback target starts a unicast retransmission RTP session and sends the key information to the receiver over that session. If there is spare bandwidth, the feedback target may also burst the key information at a faster than natural rate. As soon as the receiver acquires the key information, it can join the multicast group and start processing the multicast data. This method potentially reduces the synchronization delay. We refer to this method as "Unicast-based Rapid Synchronization with RTP Multicast Sessions." A simplified network diagram showing the rapid synchronization method through an intermediary network element is depicted in Figure 1. +-----------------+ +--->| Intermediary | | ...| Network Element | | : |(Feedback Target)| | : +-----------------+ | v +--------+ +------+ +--------+ | RTP |---->|Router|........>|Joining | | Sender | | |-------->| RTP | +--------+ +------+ |Receiver| | +--------+ | | +--------+ +----------->|Existing| | RTP | |Receiver| +--------+ ---> RTP Multicast Flow ...> RTP Unicast Flow Figure 1: Rapid synchronization through an intermediary network element A primary design goal in this solution is to use the existing tools in the RTP protocol family. This improves the versatility of the existing implementations, and promotes faster deployment and better interoperability. To this effect, we use the unicast retransmission VerSteeg, et al. Expires January 8, 2009 [Page 5] Internet-Draft Rapid Synchronization for RTP Flows July 2008 support of RTP [RFC4588] and the capabilities of RTCP to handle the signaling needed to accomplish the synchronization. The packet(s) carrying the key information are sent by the feedback target in the auxiliary unicast session for rapid synchronization. These are constructed as retransmission packets that would have been sent in a unicast RTP session to recover the missing packets at a receiver that has never received any packet. In fact, there is a single RTP session used for both rapid synchronization and loss repair. The conventional RTCP feedback message that requests the retransmission of the missing packets [RFC4585] indicates their sequence numbers. However, upon joining a new session the receiver has never received a packet and thus, does not know the sequence numbers. Instead, the receiver sends an RTCP feedback message indicating "picture loss" to request the key information needed to rapidly synchronize with the main multicast session. [RFC4585] provides support for this special RTCP feedback message. It is also worth noting that in order to issue the initial RTCP message to the feedback target, the SSRC of the session to be joined must be known prior to any packet reception, and hence, needs to be signaled out-of-band (or in-band). In a Session Description Protocol (SDP) description, the SSRC MUST be signaled through the 'ssrc' attribute [I-D.ietf-avt-rtcpssm]. In the rest of this specification, we have the following outline: In Section 4, we describe the delay components in generic multicast applications. In Section 5, we introduce the delay components that are specific to MPEG-based video. We provide the protocol details of the rapid synchronization method in Section 6. Section 7 and Section 8 discuss the SDP signaling issues with examples and NAT- related issues, respectively. Finally, in Section 9 we provide a pointer to an open source RTP Receiver code that implements the functionalities introduced in this document. Note that Section 3 provides a list of the acronyms used frequently in this document. It should be noted that while we primarily focus on multicast applications that carry compressed audio and video in explaining the protocol details, the same described method can also be used in multicast applications that carry other types of data. 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. VerSteeg, et al. Expires January 8, 2009 [Page 6] Internet-Draft Rapid Synchronization for RTP Flows July 2008 3. Acronyms This document uses the following acronyms frequently: CAT: Conditional access table. DTS: Decoding timestamp. ECM: Entitlement control message. EMM: Entitlement management message. ES: Elementary stream. GoP: Group of pictures. IDR: Instantaneous decoding refresh. MPEG2-TS: MPEG2 transport stream. MPTS: Multi program transport stream. PAT: Program association table. PCR: Program clock reference. PMT: Program map table. PSI: Program specific information. PTS: Presentation timestamp. RAP: Random access point. SPTS: Single program transport stream. TSRAP: Transport stream random access point. 4. Elements of Delay in Multicast Streams In an any-source (ASM) or a single-source (SSM) multicast delivery system, there are three major elements that contribute to the overall synchronization delay when a receiver switches from one multicast session to another one. These are: VerSteeg, et al. Expires January 8, 2009 [Page 7] Internet-Draft Rapid Synchronization for RTP Flows July 2008 o Multicast switching delay o Key information latency o Buffering delays Multicast switching delay is the delay that is experienced to leave the current multicast session (if any) and join the new multicast session. In typical systems, the multicast join and leave operations are handled by a group management protocol. For example, the receivers and routers participating in a multicast session may use the Internet Group Management Protocol (IGMP) [RFC3376]. In [RFC3376], when a receiver wants to join a multicast session, it sends an IGMP Join message to its upstream router and the routing infrastructure sets up the multicast forwarding state to deliver the packets of the multicast session to the new receiver. Depending on the proximity of the upstream router, the current state of the multicast tree, the load on the system and the protocol implementation, the join times vary. Current systems provide join latencies usually less than 200 milliseconds (ms). If the receiver had been participating in another multicast session before joining the new session, it needs to send an IGMP Leave message to its upstream router to leave the session. The leave times are usually smaller than the join times, however, it is possible that the Leave and Join messages may get lost, in which case the multicast switching delay inevitably increases. Key information latency is the time it takes the receiver to acquire the key information. It is highly dependent on the proximity of the actual time the receiver joined the session to the next time the key information will be sent to the receivers in the session, whether the key information is sent contiguously or not, and the size of the key information. For some multicast flows, there is a little or no interdependency in the data, in which case the key information latency will be nil or negligible. For other multicast flows, there is a high degree of interdependency. One example is the multicast flows that carry compressed audio/video. For these flows, the key information latency may become quite large and be a major contributor to the overall delay. We describe the interdependency associated with audio/video flows in detail in Section 5. The buffering component of the overall synchronization delay is driven by the way the application layer processes the payload. In many multicast applications, an unreliable transport protocol such as UDP [RFC0768] is often used to transmit the data packets, and the reliability, if needed, is usually addressed through other means such as forward error correction and retransmission [I-D.ietf-rmt-pi-norm-revised]. These loss repair methods require VerSteeg, et al. Expires January 8, 2009 [Page 8] Internet-Draft Rapid Synchronization for RTP Flows July 2008 buffering at the receiver side to function properly. In many applications, it is also often necessary to de-jitter the incoming data packets before feeding them to the application. The de- jittering process also increases the buffering delays. Besides these network-related buffering delays, there are also specific buffering needs that are required by the individual applications. For example, MPEG decoders require a significant amount of content to be available in the decoder buffers prior to starting to decode the content. We describe these buffering requirements for audio/video applications in detail in Section 5. 5. Elements of Delay in Video Systems For typical multicast-based video delivery systems, the multicast switching delay (time required to leave the previous multicast session and join the new session) is not the primary contributor to the overall synchronization delay. The multicast flows are typically already present at the edge or deep in the network, the propagation delays for join operations are modest, and the multicast routers can typically process the Join and Leave messages quickly. Even if the edge multicast router is not currently a member of the requested multicast session, the multicast routing control messages propagate through the network rapidly and trees are built without experiencing large delays. Even in cases where a number of tree branches need to be built to the edge multicast router, this cost is frequently amortized over a large number of receivers such that only the first receiver joining the group experiences the increased delay. Further, this delay can be eliminated at the cost of extra bandwidth in the network core by having the edge routers do static joins for the set of sessions they expect receivers to be interested in. These techniques usually provide a well-bounded multicast switching delay. Once the join operation completes and a receiver starts receiving media content for the first time in a multicast session, it often experiences a considerable amount of key information latency and buffering delays. In the following subsections, we discuss the details of these delay elements, using MPEG2 Transport Streams as the motivating use case. 5.1. Overview of MPEG-2 Transport Streams MPEG2 Transport Stream (MPEG2-TS) [MPEG2TS] is an encapsulation method and transport that multiplexes digital video and audio content, together with ancillary metadata, and produces a synchronized multiplexed stream that is tailored for transport over packet or cell-oriented networks. MPEG2-TS is ubiquitous in broadcast applications over both terrestrial and satellite networks. VerSteeg, et al. Expires January 8, 2009 [Page 9] Internet-Draft Rapid Synchronization for RTP Flows July 2008 Both Advanced Television Systems Committee (ATSC) in North America and Digital Video Broadcasting (DVB) in Europe use MPEG2-TS in their standards. MPEG2-TS has been standardized by both ISO and ITU [MPEG2TS]. While MPEG2-TS was originally limited to carry MPEG-2 encoded content, the specification was later extended to cover MPEG- 4/AVC video/audio encoding standards as well. MPEG2-TS is a container format that describes the schema of the audio and video content and the in-band control information. Prior to multiplexing, an audio and a video encoder output audio and video Elementary Streams (ES), respectively. The ES streams are then packetized to form the Packetized Elementary Streams (PES). The resulting elements are called PES packets. A transport stream (TS) encapsulates several PES streams and other data, and carries them in TS packets. The RTP payload format for carrying TS packets in an RTP stream is specified in [RFC2250]. In addition to the audio and video ES streams, there are ES streams that carry control data. Program Specific Information (PSI) consists of metadata carried in the transport stream. PSI includes Program Association Table (PAT), Conditional Access Table (CAT) and Program Map Table (PMT). A PAT has information about all the programs carried in the transport stream. It lists the 13-bit Program IDs (PID) for all the PMTs, associating them with the individual programs. Each of the ES streams of a particular program in the transport stream also has the same PID values. This way, a decoder at the receiving side can extract the desired TS packets from the transport stream by checking their PID values. If the transport stream is not a Multi-Program Transport Stream (MPTS), but rather it is a Single-Program Transport Stream (SPTS), all the ES streams in the transport stream correspond to a single program and the PAT data is not carried. CAT defines the type of the scrambling used (either at the PES or TS level), and identifies all the PID values of the TS packets that contain the Entitlement Management Messages (EMM). In addition to containing the PID values of each ES stream associated with a particular program, the PMT table also includes private data associated with the program such as the PID value of the packet containing the Entitlement Control Messages (ECM). The data contained in the EMM and ECM messages are vital in descrambling encrypted content. Note that PSI is carried in clear and is never scrambled so that a receiver which just started receiving the transport stream can process the PSI. The PAT, CAT and PMT tables must be parsed by the decoder in order to find the ES streams, private data as well as the encryption information for a given program. MPEG2-TS produces output that is synchronized to a common clock VerSteeg, et al. Expires January 8, 2009 [Page 10] Internet-Draft Rapid Synchronization for RTP Flows July 2008 across all the ESs in the multiplex. To assist the audio and video decoders, programs periodically provide a Program Clock Reference (PCR) value in the transport stream. PCR values are embedded in the TS adaptation field headers and are inserted by the encoder at least every 100 ms. A PCR timestamp represents the value of the encoder's system clock when it was sampled. The system clock is driven by a local 27 MHz oscillator. PCR is extremely important in native MPEG-2 transport to keep the decoders synchronized. For example, the periodically sent Decoding Timestamps (DTS) and Presentation Timestamps (PTS) are specified relative to the PCR value and the decoders use the PCR value as the basis for a master clock during decoding and playout. 5.2. Key Information Latency in Video Applications We classify the key information latency into two categories. 5.2.1. PSI (PAT/CAT/PMT) Acquisition Delay As we discussed in Section 5.1, the video (and the audio as well) in an MPEG2 TS is self describing, and the receiver must parse certain control information in the PAT, CAT and PMT tables (i.e., PSI) contained in the transport stream in order to know how to parse the rest of the stream (i.e., to find the audio and video elementary streams, private data and the encryption information for a given program). Many video services employ content encryption and the encryption keys must be parsed as well for decrypting the content. In order to enable various system elements to process video effectively, certain portions of the stream are left unencrypted. The PAT/PMT tables are always in the clear. The structure of the ECMs is also in the clear, although the ECM content which contains keying material is encrypted. The PSI information is repeated periodically in the transport stream, thus, when a receiver joins the multicast session, it needs to wait until the next time PSI is sent in the transport stream. Editor's note: Do we need to list how frequent PSI/PCR/etc is repeated in ATSC and/or DVB standards? Update: This will be addressed in the next revision. 5.2.2. Random Access Point Acquisition Delay Conventional MPEG2 video encoders encode the video content in Groups of Pictures (GoP). Each GoP is encoded independently from other GoPs and starts with an intra-coded frame (I-frame) that does not have any reference to other frames in the same GoP, i.e., an I-frame contains VerSteeg, et al. Expires January 8, 2009 [Page 11] Internet-Draft Rapid Synchronization for RTP Flows July 2008 the representation of an entire picture and can be decoded independently. Thus, the start of an I-frame is said to be a Random Access Point (RAP). On the other hand, due to the temporal compression, rest of the frames in the same GoP may have references to the I-frame or to other frames in the same GoP. Due to this interdependency among the frames, one generally has to receive certain elements of the GoP prior to decoding or rendering any part of the GoP. For example, the decoder can decode a frame that is dependent on two other frames only after these two frames are decoded. Usually, GoP durations are between 500 ms and one second. However, more advanced codecs may use longer GoPs to gain from the encoding efficiency. When a receiver joins the multicast session, it needs to wait until the next RAP shows up in the multicast stream before it can start decoding. Since the frame that is currently being multicast does not depend on the join time, the average time a receiver waits for RAP, i.e., the average RAP acquisition delay, is half of the GoP duration. Hence, for longer GoPs, the RAP acquisition delay is proportionally longer. Advanced Video Coding (AVC) (also called MPEG4 part 10) compression is very similar to MPEG2 compression. It has a few more compression tools available, including Hierarchical GoPs. In a hierarchical GoP, the dependent frames of a GoP may reference the key frame at the start of this GoP or the key frame at the start of the next GoP. This additional dependency causes a longer RAP acquisition delay, as the decoder must receive two I-frames (spread between two logical GoPs) before decoding can commence. AVC also has the ability to insert Instantaneous Decoding Refresh (IDR) frames. Frames that follow an IDR frame cannot reference frames that precede an IDR frame. IDR frames are useful for editing AVC streams, but are typically do not appear often enough in streaming video to be useful in a stream synchronization context. Note that in order for an intermediary network element such as a retransmission server to find the random access points in the video stream (e.g., I-frames), the necessary structural information must be in the clear if the intermediary is not in possession of the necessary keys. 5.3. Buffering Delays in Video Applications We classify the buffering delays into two categories. VerSteeg, et al. Expires January 8, 2009 [Page 12] Internet-Draft Rapid Synchronization for RTP Flows July 2008 5.3.1. Network-Related Buffering Delays In general, multicast-based video applications use an unreliable underlying transport protocol such as UDP [RFC0768] to distribute the content to a large number of receivers. This is largely due to the fact that these applications are one way in nature and providing closed-loop reliability does not scale well when the number of receivers is large or the acceptable playout delay is small, or both. Rather, if there is a need for reliability, the applications may employ one or more loss-repair methods to recover the packets missing at each receiver (The Reliable Multicast Transport Working Group has several standardized solutions for this problem. Refer to [I-D.ietf-rmt-pi-norm-revised] for details). For example, forward error correction (FEC) may be used proactively and/or on-demand to provide reliable transmission to a potentially very large multicast group in a scalable manner [I-D.ietf-fecframe-framework]. Similarly, retransmissions may be used in RTP-based SSM sessions where the retransmissions can be handled by local repair servers rather than the source itself [I-D.ietf-avt-rtcpssm]. However, regardless of the type of the loss-repair method(s) adopted by an application, loss- recovery operations always require additional buffering at the receiver side. The amount of buffering increases with the FEC block size when FEC is used, and with the round-trip time between the receiver and the local repair server when retransmission is used. Audio and video decoders demand almost jitter-free content. If any jitter is introduced during the transmission in the network or due to the loss repair methods, the jitter has to be smoothed out before the content is fed to the decoder. This is called de-jittering and it usually adds up to the buffering delay. 5.3.2. Application-Related Buffering Delays The application buffering requirements for MPEG-encoded content are quite rigorous, particularly for the MPEG-based video applications. Video compression devices apply more bits to represent certain scenes than they do for other scenes. A very complex scene (individual picture) requires considerably more information than a simple scene. Furthermore, pictures that are entirely intra-coded, e.g., I-frames, consume more bits compared to pictures that make use of predictive coding. Each scene is shown by the decoder at a certain fixed frame rate (e.g., 24 fps or 30 fps). Since some scenes are comprised more bits than other scenes, the output rate of the decoder buffer is usually variable. However, the network flow is typically Constant Bit Rate (CBR) or Capped Variable Bit Rate (Capped VBR). The net effect is that the input rate to the decoder buffer is close to constant, but the output rate is highly variable. VerSteeg, et al. Expires January 8, 2009 [Page 13] Internet-Draft Rapid Synchronization for RTP Flows July 2008 The video encoders keep track of the decoder buffer size, and use this information to regulate the temporal compression. This forces the decoder buffer to "breathe." In order to avoid underflow, the decoder buffer must fill up to a certain level prior to starting to decode and play the content. The decoder buffer size required to avoid underflow is dependent on the encoder, and the encoder signals the decoder buffering requirements in-band. Typical decoder buffer requirements for MPEG2 content range from one second to two seconds. However, AVC/MPEG4 part 10 encoders usually tend to use more temporal compression, and thus require a larger buffer at the decoder side. This consequently increases the buffering delays. 5.4. Breakdown of Typical Synchronization Delays in IPTV Editor's note: This section will provide typical ranges for each of the delay components based on our observations in the field. This section is for educational and illustrative purposes. 6. Rapid Synchronization The video systems we consider as a use case in this document encapsulate multicast video flows in an IP/UDP/RTP/MPEG2-TS/ format. Typical codecs include MPEG2 and AVC/MPEG4 part 10, although other codecs are also in use. The IP and UDP wrappers are well understood and ubiquitous. Many legacy video deployments do not use RTP encapsulation. However, in order to use the rapid synchronization method specified in this document, RTP encapsulation is clearly required. We start this section with an overview of the rapid synchronization method. 6.1. Overview RTP [RFC3550], together with [RFC4588] and [RFC4585] provide the mechanisms needed to encapsulate a data flow and use RTCP feedback to implement a robust error-recovery mechanism for that flow. When packets are lost, a receiver may use RTCP NACK messages to request retransmission of those packets using RTP retransmission packets. In order to achieve rapid synchronization, the receiver can use this retransmission mechanism to request all of the data from the most recent RAP. We therefore employ a new RTP/RTCP-based mechanism that boils down to "I do not have synchronization with the stream. Send me a repair burst that will cover all of the required data from a recent RAP to the point the stream has reached in the multicast session." Note that the rapid synchronization flow and the normal VerSteeg, et al. Expires January 8, 2009 [Page 14] Internet-Draft Rapid Synchronization for RTP Flows July 2008 repair flow share the same RTP session. In order to reduce the synchronization delay associated with processing a new RTP encapsulated multicast flow, either the media source may retain the stream state, and/or a Retransmission Server (RS) may cache that flow near the egress edge and provide an accelerated unicast burst to the requesting receiver. Which element performs these functions depends on the desired scale of the system. The protocol machinery is agnostic to the difference, as both use the RTCP feedback target address as the way to identify the element performing these functions. Where a Retransmission Server (RS) is employed, it semi-permanently joins the multicast session and receives the RTP steams it wishes to cache so that it can perform the retransmission functions. For the rapid synchronization support, RS parses the incoming flows, looking for the key information. The key information may be segregated by RS into two components - the key information that occurs in sequence with the RTP data and that which does not occur in RTP sequence order. When acquiring an RTP session, the RTP Receiver (RR) sends an RTCP message to the feedback target requesting an accelerated burst of data from the multicast session via unicast including any key information that occurs in sequence with the RTP data plus any optional key information that does not occur in RTP sequence order. In the case of IP/UDP/RTP/MPEG2-TS encapsulated video streams, the key information that may not occur in the RTP sequence order may consist of the information required to demultiplex and decode the MPEG2 TS. We refer to this information as the Transport Stream Random Access Point (TSRAP). The TSRAP information includes the PAT, PMT, PCR and optionally the ECMs. The TSRAP information can be either provided in the unicast burst to RR or it is sent from the feedback target to RR in an RTCP packet. The sequential key information, on the other hand, (i.e., the PES header, I-frame and subsequent data) is always sent in the unicast RTP flow, using the RTP retransmission payload format. This has several advantages, including easy correlation between the packets in the RTP session carrying the unicast burst and those of the multicast session, and the ability of the receiver to utilize the same algorithms for reception and processing the key information as it does for dealing with RTP retransmissions during the normal session operation. The RTP data is sent from the feedback target to the receiver starting with the sequential key information via unicast as described VerSteeg, et al. Expires January 8, 2009 [Page 15] Internet-Draft Rapid Synchronization for RTP Flows July 2008 above. The MPEG data sent in the unicast burst starts with an Elementary Stream Random Access Point (ESRAP). This includes a PES header containing a PTS, followed by a sequence header, followed by an I-frame. The unicast burst continues at a higher than natural rate until the unicast burst catches up with the real-time multicast flow. 6.2. Message flows and State Machines The flow diagram for unicast-based rapid synchronization is sketched in Figure 2. In this figure, we have an RTP Sender and an RTP Receiver (RR). The rapid synchronization support is provided in this scenario by a Retransmission Server (RS), although the message flows are identical to the case where the rapid synchronization is performed by a feedback target co-located with the media source. Note that [I-D.ietf-avt-rtcpssm] permits the feedback target to be a retransmission server, since it is a logical function to which RRs send their unicast feedback. Editor's note: In Figure 2, not all messages are shown. The flow diagram will be revised and improved in the next revision. +--------+ | RTP | | Sender | +--------+ | v +--------------+ | Router |<----- (1) IGMP Leave -------+ | |<----- (5) IGMP Join ------+ | +--------------+ | | | | | | +-------+ +--- (6) New Multicast Flow ---+ | | | | | | v v | | +--------------+ +----------+ | | <.... (2) RTCP NACK PLI .... | | |Retransmission| & Buffer Requirements | RTP | | Server | .. (3) Burst Description ..> | Receiver | | (RS) | .... (4) Unicast Burst ....> | (RR) | | | <.. (7) Burst Termination .. | | +--------------+ +----------+ ---> Multicast Flows and IGMP Messages ...> Unicast Flows VerSteeg, et al. Expires January 8, 2009 [Page 16] Internet-Draft Rapid Synchronization for RTP Flows July 2008 Figure 2: Flow diagram for unicast-based rapid synchronization The following steps describe rapid synchronization in detail: 1. RR sends an IGMP Leave message [RFC3376] to its upstream multicast router to leave the current multicast session. 2. RR sends an RTCP packet that contains a NACK PLI message [RFC4585] for the new multicast RTP session to the feedback target address of that session. [RFC4585] specifies that the packet type for a payload-specific feedback message to be 206 and the feedback message type to be 1. The RTCP packet contains the SSRC of RR and the SSRC of the media source. Note that since no RTP packets have yet been received for this session, the SSRC must be obtained out-of-band or in-band. For sessions described using SDP [RFC4566], the SSRC MUST be signaled using the 'ssrc' attribute of the media description (The 'cname' source attribute MUST also be present [I-D.ietf-mmusic-sdp-source-attributes]). RR may also send an RTCP APP packet that specifies the minimum amount of data it requires from RS and optionally the maximum amount of data it can receive from RS (Note that this APP packet is usually sent in a compound RTCP packet that also includes the NACK PLI message). This information is used by RS to prepare a rapid synchronization that conforms with RR's buffer requirements. The format of this APP packet is described in Appendix A. As an alternative to the APP packet, a new RTCP transport-layer feedback message [RFC4585] called Rapid Multicast Synchronization Request (RMS-R) could also be defined. This message may contain the buffer sizing information of RR in its feedback control information field. 3. RS receives the NACK PLI and APP packets, and decides whether to accept the rapid synchronization request or not. If RS accepts the request, it sends an RTCP packet to RR that comprises fields that can be used to describe the burst that RS will generate and send, including the indication when RR should switch to the multicast stream. This RTCP message is referred to as the Rapid Multicast Synchronization Information (RMS-I). For the RMS-I message, Appendix A defines an RTCP APP packet format and Appendix B defines a new RTCP message. The RMS-I message may be sent multiple times towards RR. Note that RS learns the IP address and port information for RR from the RTCP NACK PLI or RMS-R packet it received. (This description glosses over the NAT details. Refer to Section 8 for a discussion of NAT-related issues.) If RS cannot provide a unicast rapid synchronization session, RS VerSteeg, et al. Expires January 8, 2009 [Page 17] Internet-Draft Rapid Synchronization for RTP Flows July 2008 rejects the request and informs RR immediately via the RMS-I message. If RR receives RMS-I indicating that the rapid synchronization request has been denied, it abandons the rapid synchronization attempt and immediately joins the RTP multicast session by sending an IGMP Join message [RFC3376] to its upstream multicast router for the new multicast session. 4. If RS accepts the rapid synchronization request, it transmits (in addition to the RMS-I message) the unicast RTP burst data and any additional RTCP APP message(s) that may contain key information (TSRAP) that is not provided in the unicast RTP burst. The RTCP RMS-I message is either sent prior to the data burst or during the data burst, with the appropriate value settings in its fields. 5. At the appropriate moment (as indicated or computed from the burst parameters in the RTCP packet), RR sends an IGMP Join message [RFC3376] to its upstream multicast router for the new RTP multicast session. 6. RR starts receiving the multicast RTP flow. 7. If RS had not explicitly indicated the size of the unicast burst in the RMS-I message, RR can be asked in the RMS-I message to explicitly indicate to RS when multicast synchronization has been completed which triggers RS to stop the unicast burst. To this effect, a new RTCP message called Rapid Multicast Synchronization Process Termination (RMS-T) is to be defined. This may be a new transport-layer feedback RTCP message [RFC4585] that may be transmitted more than once by RR for redundancy reasons. Alternatively, an RTCP BYE message can be used to make RS stop the unicast burst. Note that when RR joins the multicast session, RR may receive the same packet from both the multicast session and unicast burst. The impact of this and measures that can be taken to minimize the impact of receiving duplicate packets will be addressed in Section 6.4. It is possible that RR may decide to switch to a new multicast session while an earlier rapid synchronization request is still pending or active. In that case, RR SHOULD cancel the pending/active rapid synchronization operation before it sends a new request for the new multicast session. To cancel the pending request and stop any existing rapid synchronization operation, RR SHOULD send an RTCP BYE packet for the unicast retransmission session. Upon receiving an RTCP BYE packet, RS MUST terminate the rapid synchronization operation, and cease transmitting any further packets of the associated unicast burst. Note that in addition to the RTCP BYE VerSteeg, et al. Expires January 8, 2009 [Page 18] Internet-Draft Rapid Synchronization for RTP Flows July 2008 packet in the unicast session, an RTCP BYE packet MUST also be sent for the session associated with the multicast source stream if RR already joined the multicast session. Against the possibility of the RTCP BYE packet being lost and thus failing to stop the rapid synchronization operation, RR MAY send multiple BYE packets for the unicast session as long as it follows the RTCP timer rules of [RFC3550]. 6.3. Encoding of the Signaling Protocol Editor's note: This section discusses the format of the control packets that are exchanged to support rapid synchronization. Currently, there are two proposals. These proposals are explained in Appendix A and Appendix B. Based on the discussion in the WG, we will adopt one of these proposals, or a hybrid of the two. TBC. 6.4. Shaping the Burst Editor's note: This section will discuss sizing of the buffers, output buffer overload protection, output bandwidth management, adjustment of burst rate and duration. TBC. 6.5. Failure Cases Editor's note: This section will discuss what happens if the request for rapid synchronization gets lost, or rapid synchronization fails, or when there are no available resources, etc. TBC. 7. Session Description Protocol (SDP) Signaling This section provides an SDP [RFC4566] example for enabling rapid synchronization with RTP multicast sessions. The following example uses the SDP grouping semantics [RFC3388], the RTP/AVPF profile [RFC4585], the RTP retransmissions [RFC4588], the RTCP extensions for SSM sessions with unicast feedback [I-D.ietf-avt-rtcpssm] and the source-specific media attributes [I-D.ietf-mmusic-sdp-source-attributes]. In the example, we have two primary source streams and two unicast retransmission streams for each of these source streams. The source VerSteeg, et al. Expires January 8, 2009 [Page 19] Internet-Draft Rapid Synchronization for RTP Flows July 2008 streams are multicast from a distribution source (with a source IP address of 8.166.1.1) in different multicast groups. For each source stream, a feedback target address (9.30.30.1) is also specified with the 'rtcp' attribute. The receiver(s) can report missing packets on the source stream to the feedback target and request retransmissions. The parameter 'rtx-time' specifies the time in milliseconds (measured from the time a packet was first sent) that the sender (in this case the feedback target) keeps an RTP packet in its buffers available for retransmission. For the first source stream, only the conventional retransmission support is enabled. For the second source stream, both the conventional retransmission and rapid synchronization support is enabled. This is achieved by the "a=rtcp-fb:98 nack pli" line. The parameter 'pli' denotes a payload-specific feedback message and stands for Picture Loss Indication [RFC4585]. When a receiver requires rapid synchronization for a new multicast session it wants to join, it sends an RTCP NACK PLI message to the feedback target. This RTCP packet has to have the SSRC of the primary source session for which rapid synchronization is requested for. However, since this receiver has not received any RTP packets from this primary source session yet, the receiver MUST learn the SSRC value from the 'ssrc' attribute of the media description [I-D.ietf-avt-rtcpssm]. In addition to the SSRC value, the 'cname' source attribute MUST also be present in the SDP description [I-D.ietf-mmusic-sdp-source-attributes]. Note that listing the SSRC values for the primary source sessions in the SDP file does not create a problem in SSM sessions when an SSRC collision occurs. This is because in SSM sessions, a receiver that observed an SSRC collision with a media source MUST change its own SSRC [I-D.ietf-avt-rtcpssm] by following the rules defined in [RFC3550]. A feedback target that receives a NACK PLI feedback message becomes aware that the prediction chain at the receiver side has been broken or does not exist any more. If the necessary conditions are satisfied (as outlined in Section 7 of [RFC4585]) and available resources exist, the feedback target MAY react to the NACK PLI message by sending the key information and an intra update. VerSteeg, et al. Expires January 8, 2009 [Page 20] Internet-Draft Rapid Synchronization for RTP Flows July 2008 v=0 o=ali 1122334455 1122334466 IN IP4 rtp.rocks.com s=Rapid Synchronization Examples t=0 0 a=group:FID 1 2 a=group:FID 3 4 a=rtcp-unicast:rsi m=video 40000 RTP/AVPF 96 i=Primary Source Stream #1 c=IN IP4 224.1.1.1/255 a=source-filter: incl IN IP4 224.1.1.1 8.166.1.1 a=recvonly a=rtpmap:96 MP2T/90000 a=rtcp:40001 IN IP4 9.30.30.1 a=rtcp-fb:96 nack a=mid:1 m=video 40002 RTP/AVPF 97 i=Unicast Retransmission Stream #1 (Ret. Support Only) c=IN IP4 9.30.30.1 a=recvonly a=rtpmap:97 rtx/90000 a=rtcp:40003 a=fmtp:97 apt=96 a=fmtp:97 rtx-time=3000 a=mid:2 m=video 41000 RTP/AVPF 98 i=Primary Source Stream #2 c=IN IP4 224.1.1.2/255 a=source-filter: incl IN IP4 224.1.1.2 8.166.1.1 a=recvonly a=rtpmap:98 MP2T/90000 a=rtcp:41001 IN IP4 9.30.30.1 a=rtcp-fb:98 nack a=rtcp-fb:98 nack pli a=ssrc:123321 cname:iptv-ch32@rtp.rocks.com a=mid:3 m=video 41002 RTP/AVPF 99 i=Unicast Retransmission Stream #2 (Ret. and Rapid Synch. Support) c=IN IP4 9.30.30.1 a=recvonly a=rtpmap:99 rtx/90000 a=rtcp:41003 a=fmtp:99 apt=98 a=fmtp:99 rtx-time=5000 a=mid:4 VerSteeg, et al. Expires January 8, 2009 [Page 21] Internet-Draft Rapid Synchronization for RTP Flows July 2008 8. NAT Considerations TBC. 9. Open Source RTP Receiver Implementation An open source RTP Receiver code that implements the functionalities introduced in this document is available at the following URL: http://www.cisco.com/en/US/docs/video/cds/cda/vqe/2_0/user/guide/ ch1_over.html The code is also available at: ftp://ftpeng.cisco.com/ftp/vqec/ 10. Open Issues o Do we need a new RTCP XR [RFC3611] block type for reporting the performance of rapid synchronization? o Do we need a new nack parameter for indicating rapid synchronization support for non-video streams in an SDP? PLI is mostly meaningful in video applications. 11. Security Considerations TBC. 12. IANA Considerations This document will register new RTCP packet types. TBC. 13. Acknowledgments TBC. 14. References VerSteeg, et al. Expires January 8, 2009 [Page 22] Internet-Draft Rapid Synchronization for RTP Flows July 2008 14.1. Normative References [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [MPEG2TS] ITU-T H.222.0, "Generic Coding of Moving Pictures and Associated Audio Information: Systems", May 2006. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002. [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006. [I-D.ietf-avt-rtcpssm] Ott, J., "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback", draft-ietf-avt-rtcpssm-17 (work in progress), January 2008. [I-D.ietf-mmusic-sdp-source-attributes] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-source-attributes-01 (work in progress), February 2008. 14.2. Informative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [I-D.ietf-rmt-pi-norm-revised] Adamson, B., "NACK-Oriented Reliable Multicast (NORM) Protocol", draft-ietf-rmt-pi-norm-revised-06 (work in progress), January 2008. VerSteeg, et al. Expires January 8, 2009 [Page 23] Internet-Draft Rapid Synchronization for RTP Flows July 2008 [I-D.ietf-fecframe-framework] Watson, M., "Forward Error Correction (FEC) Framework", draft-ietf-fecframe-framework-01 (work in progress), November 2007. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC2250] Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar, "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998. [I-D.ott-avt-rtcp-guidelines] Ott, J. and C. Perkins, "Guidelines for Extending the RTP Control Protocol (RTCP)", draft-ott-avt-rtcp-guidelines-01 (work in progress), June 2008. [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003. Appendix A. Protocol Encoding Option #A [RFC3550] specifies the format of the RTCP APP packets as depicted in Figure 6. In an RTCP APP packet, the payload type MUST be set to 204. The Subtype field is used to allow a set of APP packets to be defined under one unique name or for any application-dependent data. The Name field is chosen by the person defining the APP packets and it MUST be unique among the APP packets the intended application might receive. The Application-dependent data field contains the information (at a length of in multiples of 32 bits) to be interpreted by the intended application (not RTP itself). [RFC3550] specifies that RTP receivers SHOULD ignore the APP packets with unrecognized names. VerSteeg, et al. Expires January 8, 2009 [Page 24] Internet-Draft Rapid Synchronization for RTP Flows July 2008 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| Subtype | PT=APP=204 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC/CSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name (ASCII) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Application-dependent data : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Format of an RTCP APP packet Section 6.7 of [RFC3550] and [I-D.ott-avt-rtcp-guidelines] state that RTCP APP packets are intended for experimental use and they are not appropriate to be registered in a standards document. Thus, as part of the standardization process of this specification, we are planning to convert the APP packets into standardized RTCP packet types and register them with IANA. This will promote interoperability among different implementations. The data is encoded in the Application-dependent data field by using Type/Length/Value (TLV) elements. o Type: A single-octet identifier that defines the type of the parameter represented in this TLV element. o Length: A two-octet field that indicates the length of the Value field. o Value: Variable sized set of octets that contains the specific value for the parameter. Note that all multi-octet values are in network-byte order. The following TLV elements are defined in this document: A.1. Padding This type has no Length or Value fields. It is to pad the Application-dependent data field to a multiple of 32-bit words [RFC3550]. VerSteeg, et al. Expires January 8, 2009 [Page 25] Internet-Draft Rapid Synchronization for RTP Flows July 2008 Type Length Value iana_tlv1 - - A.2. RTP Sequence Number for the First Rapid Synchronization Packet This is the RTP sequence number of the first packet that will be sent as part of the rapid synchronization. This allows RR to know if one or more packets are dropped at the beginning of rapid synchronization. Type Length Value iana_tlv2 4 32-bit extended RTP sequence number 32-bit extended RTP sequence number is constructed by putting the 16- bit RTP sequence number in the lower two bytes and octet 0's in the higher two bytes. A.3. Earliest IGMP Join Time This is time difference (in RTP clock ticks) between the start of rapid synchronization and the earliest time instant when RR could join the new multicast session. Type Length Value iana_tlv3 4 32-bit delta time in RTP clock ticks A.4. Rapid Synchronization End Time This is time difference (in RTP clock ticks) between the end of the first packet sent in rapid synchronization and the time instant when rapid synchronization will end. Type Length Value iana_tlv4 4 32-bit delta time in RTP clock ticks A.5. TSRAP Data Description. Type Length Value iana_tlv5 N Encoded TSRAP data Editor's note: This section should define the TLV elements for the TSRAP data. VerSteeg, et al. Expires January 8, 2009 [Page 26] Internet-Draft Rapid Synchronization for RTP Flows July 2008 A.6. Actual Rapid Synchronization Fill This is the amount of backfill that RR can expect in its buffer as a result of the rapid synchronization (in ms). Type Length Value iana_tlv6 4 Amount of rapid synchronization fill in ms A.7. Join-Time Rapid Synchronization Fill This is the amount of backfill that RR can expect in its buffer as a result of the rapid synchronization at the time of the earliest IGMP Join (in ms). Type Length Value iana_tlv7 4 Amount of rapid synchronization fill at IGMP Join in ms Appendix B. Protocol Encoding Option #B B.1. RMS-R RTCP Message Format This is an RTCP transport-layer feedback message [RFC4585]. The fields are set as follows: FMT field: 2 FCI field: 4-byte field: Amount of rapid synchronization fill in milliseconds. B.2. RMS-I RTCP Message Format This is similar to the RTCP transport-layer feedback message [RFC4585] but with a new payload type. FCI comprises: 2-byte field: RTP sequence number for the first rapid synchronization packet. 4-byte field: Earliest IGMP join time. All zeroes means not specified. 4-byte field: Rapid synchronization end time. All zeroes means not specified. VerSteeg, et al. Expires January 8, 2009 [Page 27] Internet-Draft Rapid Synchronization for RTP Flows July 2008 1-byte field: IGMP join time now. This can only have value 0 or 1; 1 = time to join multicast is now. If 1, then previous 2 fields MUST be all zeroes. 1-byte field: RS response. This can only have value 0 or 1 or 2; 0 = RS will not service rapid synchronization request. 1 = RS services rapid synchronization request; RR MUST NOT issue RMS-T message when multicast is received. 2 = RS services rapid synchronization request; RR MUST issue RMS-T message when multicast is received. The RMS-I message may be sent multiple times at the start or prior to the RTP unicast burst, or during the RTP unicast burst. B.3. RMS-T RTCP Message Format FMT field: 3 FCI field: 2-byte packet identifier field: Contains the sequence number of the first received RTP packet of the multicast stream. Authors' Addresses Bill Ver Steeg Cisco Systems 5030 Sugarloaf Parkway Lawrenceville, GA 30044 USA Email: billvs@cisco.com Ali Begen Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA Email: abegen@cisco.com VerSteeg, et al. Expires January 8, 2009 [Page 28] Internet-Draft Rapid Synchronization for RTP Flows July 2008 Tom Van Caenegem Alcatel-Lucent Bell Copernicuslaan 50 Antwerpen, 2018 Belgium Email: Tom.Van_Caenegem@alcatel-lucent.be VerSteeg, et al. Expires January 8, 2009 [Page 29] Internet-Draft Rapid Synchronization for RTP Flows July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). VerSteeg, et al. Expires January 8, 2009 [Page 30]