2. Structure of the RTP Packet 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|X| CC=1 |M| PT | sequence number | RTP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | Hdr +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifier(s) | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | RTP | 61883-1 isochronous data blocks (quadlet aligned) | Pay- . . . load | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 - An RTP packet for 61883-1 isochronous stream 2.1. The RTP Header The fields of the fixed RTP header have their usual meanings defined in [RFC3550]. version (V): 2 bits This field identifies the version of RTP. This payload format is defined for operation with RTP version two (2). padding (P): 1 bit If the padding bit is set, the packet contains one or more additional padding octets at the end which are not part of the payload. The last octet of the padding contains a count of how many padding octets should be ignored, including itself. Padding may be needed by some encryption algorithms with fixed block sizes or for carrying several RTP packets in a lower-layer protocol data unit. extension (X): 1 bit If the extension bit is set, the fixed header MUST be followed by exactly one header extension. The extension bit is normally set to zero (0); this payload format makes no reference to any extension. CSRC count (CC): 4 bits The CSRC count contains the number of CSRC identifiers that follow the fixed header. marker (M): 1 bit The marker bit is always zero in this payload format. (This bit is intended to allow significant events such as frame boundaries to be marked in the packet stream.) Payload Type (PT): 7 bits A dynamically allocated payload type field which designates the payload as 61883-1 isochronous data blocks. sequence number: 16 bits The sequence number increments by one for each RTP data packet sent, and may be used by the receiver to detect packet loss and to restore packet sequence. The initial value of the sequence number SHOULD be random (unpredictable) to make known-plaintext attacks on encryption more difficult, even if the source itself does not encrypt according to the method in Section 9.1, because the packets may flow through a translator that does. Techniques for choosing unpredictable numbers are discussed in [ ]. Timestamp: 32 bits The timestamp is a 32-bit unsigned integer count of isochronous cycles, representing the start of the isochronous interval to which the first data block of the payload is assigned. The initial value of the timestamp SHOULD be random, as for the sequence number. The RTP standard requires that the timestamp increment uniformly and monotonically with time. The timestamp value is associated with a corresponding 61883-native Cycle Timer value as illustrated in Figure 2. Timestamps are correlated with wallclock time by means of RTCP Sender Report messages, and multiple streams are time-sycnhronized by this mechanism even though their timestamps have different random offsets or originate from distinct non- synchronous 1394 busses. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (MSB) timestamp (LSB) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cycle sec | cycle count | cycle offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ cycle offset = 0 cycle count = timestamp mod 8000 cycle sec = ( floor( timestamp/8000 ) ) mod 128 Figure 2 - RTP Timestamp and 1394 Cycle Timer SSRC: 32 bits The SSRC field identifies the synchronization source. This identifier SHOULD be chosen randomly, with the intent that no two synchronization sources within the same RTP session will have the same SSRC identifier. An example algorithm for generating a random identifier is presented in [RFC3550]. Although the probability of multiple sources choosing the same identifier is low, all RTP implementations must be prepared to detect and resolve collisions. CSRC list: 0 to 15 items, 32 bits each The CSRC list identifies the contributing sources for the payload contained in this packet. The number of identifiers is given by the CC field. If there are more than 15 contributing sources, only 15 can be identified. As described in [RFC3550], CSRC identifiers are inserted by mixers, using the SSRC identifiers of contributing sources. For example, for audio packets the SSRC identifiers of all sources that were mixed together to create a packet are listed, allowing correct source indication at the receiver. 2.1. The RTP Payload The payload consists of one or more 61883-1 data blocks associated with a single stream (i.e. 1394 channel). The data blocks are concatenated with each block zero-padded to a quadlet (32-bit) boundary. All data blocks in an RTP packet SHALL be associated with a single isochronous interval on the 1394 bus. A single RTP packet MAY contain several data blocks and MAY contain data blocks belonging to distinct source packets, provided that is SHALL conform to one of the following two possibilities: (1) the RTP packet contains only data blocks from a single source packet (2) the RTP packet contains only complete source packets. In other words, RTP packets will be source-packet-aligned except when a single source packet containing several data blocks is divided across several RTP packets. ---- 61883-over-AVB Study Group email list ---- DELETE THIS FOOTER from copies, forwards, and replies