Common use of Positional Multiplex Clause in Contracts

Positional Multiplex. The key function of TIP is to enable multiple media streams, belonging to the same media type, to be transported on the same UDP channel within the boundaries of standards compliance. To accomplish this there needs to be a multiplex point for the multiple streams based on a label, here after referred to as the “position”. This section describes the mechanisms for this multiplex. All SSRC fields MUST be random 32 bit values, that are unique across the RTP session as per the RTP and SRTP standards [4]. Each unique entity that is a RTP or RTCP transmitter should have a unique SSRC value. The TIP positional multiplex value MUST be added to all RTP packets as the first CSRC value. (Note that multiple CSRC values are still allowed, but the first one must contain the TIP positional values.) The RTP CC field should be set appropriately to indicate the addition of the CSRC value. This document will henceforth refer to this value as the MUX-CSRC. The following packet diagram illustrates these rules. TIP RTP Packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ |V=2|P|X| CC=1 |M| PT | sequence number | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | timestamp | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | synchronization source (SSRC) identifier | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | contributing “positional” source (MUX-CSRC) identifier | | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | payload ... | | | | +-------------------------------+ | | | | RTP padding | RTP pad count | | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ TIP multiplexes multiple RTP media streams of the same type (audio or video) on one UDP channel. For the video stream multiplex, typicall all the streams use the same encoding format, H.264. Hence the RTP payload number is the same for all streams. Each video stream identifies its particular media configuration options via use of inband H.264 parameter sets (SPS/PPS). For the audio stream multiplex, the situation is more complex. Depending on device capabilities and the call topology multiple encoding formats such as AAC-LD, and/or G.711 and G722 audio streams may be used. Also any of the audio streams may include DTMF sent via RFC 2833 encoding. Hence multiple RTP payload numbers may be seen within the audio multiplex. The RTP media streams sent on the same UDP channel are multiplexed by using different RTP MUX-CSRC values for each stream. Note that each RTP stream has its own independent RTP sequence number and RTP timestamp space, hence a receiver should be prepared for a change in the value of the SSRC to be accompanied by a change of sequence number and timestamp. Note that multiplexing different ,yet realted, RTP streams of the same media is allowed in RTP as long as certain requirements are met [4]. Such multiplexing is actually the norm in multicast sessions. Additionally, the bits of the MUX-CSRC field are subdivided and assigned specific semantics: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sampling Clock ID | OutPos|XmitPos|RcvPos | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bits (Big-Endian) Mask (Big-Endian) Description 31-12 0xFFFFF000 Sampling Clock ID 11-8 0x00000F00 Output Position 7-4 0x000000F0 Transmitter Position 3-0 0x0000000F Receiver Position The Sampling Clock ID is a random number chosen by the transmitting endpoint to designate the media sampling clock used for this stream. If media streams share the same clock source then they should use the same value of the Sampling Clock ID. This allows TIP receivers to detect when two media streams should be strictly synchronized. This is consistent with [4]. In situations where there is no literal sampling clock, e.g. for control packets, a unique random number for the transmitter should be selected and used for this subfield. The stream positions denote a spatial relationship or functional use of the stream. Audio and video streams with the same positions are intended to accompany each other -- i.e., there is a physical correspondence between the left audio position and the left video position. The transmitter position denotes a both an RTP transmitter and an input channel as these are tightly bound. The receiver position denotes an RTP receiver and a default output channel. The output position is an option that can be used to direct a receiver to output media to a non- default channel. If the option is not used, the value of the output position SHOULD be zero. The Audio Dynamic Output option described later in this document uses this output position. The definition of the video stream position values are: Value Label Description 0 Control Multiplex control 4 Aux Auxiliary e.g. presentation, doc camera 5 <Not Used> Reserved

Positional Multiplex. The key function of TIP is to enable multiple media streams, belonging that belong to the same media type, to be transported on the same UDP channel within the boundaries of standards compliance. To accomplish this there needs to be a multiplex point for the multiple streams based on a label, here after referred to as the “position”. This section describes the mechanisms for this multiplex. .” All SSRC fields MUST be random 32 bit values, that are unique across the RTP session as per the RTP and SRTP standards [4]. Each unique entity that is a RTP or RTCP transmitter should have a unique SSRC value. The TIP positional multiplex value MUST be added to all RTP packets as the first CSRC value. (Note that multiple CSRC values are still allowed, but the first one must contain the TIP positional values.) The RTP CC field should be set appropriately to indicate the addition of the CSRC value. This document will henceforth refer to this value as the MUX-CSRC. The following packet diagram illustrates these rules. For more information about rules for positional multiplex, see section 4.2. TIP RTP Packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ |V=2|P|X| CC=1 |M| PT | sequence number | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | timestamp | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | synchronization source (SSRC) identifier | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | contributing “positional” source (MUX-CSRC) identifier | | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | payload ... | | | | +-------------------------------+ | | | | RTP padding | RTP pad count | | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ TIP multiplexes multiple RTP media streams of the same type (audio or video) on one UDP channel. For the video stream multiplex, typicall typically all the streams use the same encoding format, H.264. Hence Therefore, the RTP payload number is the same for all streams. Each video stream identifies its particular media configuration options via use of inband H.264 parameter sets (SPS/PPS). For the audio stream multiplex, the situation is more complex. Depending on device capabilities and the call topology multiple encoding formats such as AAC-LD, and/or G.711 G.711, and G722 audio streams streams may be usedused depending on the device capabilities and the call topology. Also any Any of the audio streams may include DTMF sent via RFC 2833 encoding. Hence multiple Multiple RTP payload numbers may be seen used within the audio multiplex. The RTP media streams sent on the same UDP channel are multiplexed by using different RTP MUX-CSRC values for each stream. Note that each Each RTP stream has its own independent RTP sequence number and RTP timestamp space, hence space and a receiver should be prepared for a change in the value of the SSRC to be accompanied by a change of sequence number and timestamp. Note that multiplexing different ,different, yet realtedrelated, RTP streams of the same media is allowed in RTP as long as certain requirements are met [4]. Such multiplexing is actually the norm in multicast sessions. Additionally, the bits of the MUX-CSRC field are subdivided and assigned specific semantics: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sampling Clock ID | OutPos|XmitPos|RcvPos | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bits (Big-Endian) Mask (Big-Endian) Description 31-12 0xFFFFF000 Sampling Clock ID 11-8 0x00000F00 Output Position 7-4 0x000000F0 Transmitter Position 3-0 0x0000000F Receiver Position The Sampling Clock ID is a random number that is chosen by the transmitting endpoint to designate the media sampling clock used for this stream. If media streams share the same clock source then they should use the same value of the Sampling Clock ID. This allows TIP receivers to detect when two media streams should be strictly synchronized. This is consistent with [4]. In situations where there is no literal sampling clock, e.g. for control packets, a unique random number for the transmitter should be selected and used for this subfield. The stream positions denote a spatial relationship or functional use of the stream. Audio and video streams with the same positions are intended to accompany each other -- i.e., there is a physical correspondence between the left audio position and the left video position. The transmitter position denotes a both an RTP transmitter and an input channel as these are tightly bound. The receiver position denotes an RTP receiver and a default output channel. The output position is an option that can be used to direct a receiver to output media to a non- default channel. If the option is not used, the value of the output position SHOULD be zero. The Audio Dynamic Output option described later in this document uses this output position. The definition of the video stream position values areare listed in the following table: Value Label Description 0 Control Multiplex control 4 Aux Auxiliary e.g. presentation, doc camera 5 <Not Used> ReservedPosition Description

Positional Multiplex. The key function of TIP is to enable multiple media streams, belonging to the same media type, to be transported on the same UDP channel within the boundaries of standards compliance. To accomplish this there needs to be a multiplex point for the multiple streams based on a label, here after referred to as the “position”. This section describes the mechanisms for this multiplex. All SSRC fields MUST be random 32 bit values, that are unique across the RTP session as per the RTP and SRTP standards [4]. Each unique entity that is a RTP or RTCP transmitter should have a unique SSRC value. The TIP positional multiplex value MUST be added to all RTP packets as the first CSRC value. (Note that multiple CSRC values are still allowed, but the first one must contain the TIP positional values.) The RTP CC field should be set appropriately to indicate the addition of the CSRC value. This document will henceforth refer to this value as the MUX-CSRC. The following packet diagram illustrates these rules. TIP RTP Packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ |V=2|P|X| CC=1 |M| PT | sequence number | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | timestamp | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | synchronization source (SSRC) identifier | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | contributing “positional” source (MUX-CSRC) identifier | | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | payload ... | | | | +-------------------------------+ | | | | RTP padding | RTP pad count | | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ TIP multiplexes multiple RTP media streams of the same type (audio or video) on one UDP channel. For the video stream multiplex, typicall all the streams use the same encoding format, H.264. Hence the RTP payload number is the same for all streams. Each video stream identifies its particular media configuration options via use of inband H.264 parameter sets (SPS/PPS). For the audio stream multiplex, the situation is more complex. Depending on device capabilities and the call topology multiple encoding formats such as AAC-LD, and/or G.711 and G722 audio streams may be used. Also any of the audio streams may include DTMF sent via RFC 2833 encoding. Hence multiple RTP payload numbers may be seen within the audio multiplex. The RTP media streams sent on the same UDP channel are multiplexed by using different RTP MUX-CSRC values for each stream. Note that each RTP stream has its own independent RTP sequence number and RTP timestamp space, hence a receiver should be prepared for a change in the value of the SSRC to be accompanied by a change of sequence number and timestamp. Note that multiplexing different ,yet realted, RTP streams of the same media is allowed in RTP as long as certain requirements are met [4]. Such multiplexing is actually the norm in multicast sessions. Additionally, the bits of the MUX-CSRC field are subdivided and assigned specific semantics: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sampling Clock ID | OutPos|XmitPos|RcvPos | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bits (Big-Endian) Mask (Big-Endian) Description 31-12 0xFFFFF000 Sampling Clock ID 11-8 0x00000F00 Output Position 7-4 0x000000F0 Transmitter Position 3-0 0x0000000F Receiver Position The Sampling Clock ID is a random number chosen by the transmitting endpoint to designate the media sampling clock used for this stream. If media streams share the same clock source then they should use the same value of the Sampling Clock ID. This allows TIP receivers to detect when two media streams should be strictly synchronized. This is consistent with [4]. In situations where there is no literal sampling clock, e.g. for control packets, a unique random number for the transmitter should be selected and used for this subfield. The stream positions denote a spatial relationship or functional use of the stream. Audio and video streams with the same positions are intended to accompany each other -- i.e., there is a physical correspondence between the left audio position and the left video position. The transmitter position denotes a both an RTP transmitter and an input channel as these are tightly bound. The receiver position denotes an RTP receiver and a default output channel. The output position is an option that can be used to direct a receiver to output media to a non- default channel. If the option is not used, the value of the output position SHOULD be zero. The Audio Dynamic Output option described later in this document uses this output position. The definition of the video stream position values are: Value Label Description Value Label Description 0 Control Multiplex control 4 Aux Auxiliary e.g. presentation, doc camera 5 <Not Used> Reserved