Share via

3.1 RTP Details

  • Article

This protocol MAY have multiple RTP sessions sharing the same transport as long as these RTP sessions have non-overlapping SSRC ranges. If the transport is shared, the SSRC range MUST be configured by the method specified in [MS-SDPEXT] section 3.1.5.31. When the SSRC range is set, the SSRC throttling is disabled and RTP packets with SSRC outside the specified range MUST be dropped.

This protocol MAY multiplex multiple related streams in one RTP session using different SSRCs.

This protocol differs from [RFC3550] in the CSRC values used in the CSRC list. If the sender is a mixer, this protocol uses the MSI of the contributing sources as CSRC values in the CSRC list<36>.

The SSRC throttling mechanism works by means of two states, which are called normal mode and throttling mode. Every time the SSRC changes, the receiver enters the throttling mode, in which further SSRC changes are restricted, and packets with unexpected SSRCs are dropped. The receiver goes back to the normal mode only after a given amount of time has passed without any SSRC change. A high-level overview of this behavior is illustrated in the following diagram. Detailed specifications of the states, transitions, and actions are given in sections 3.1.1 to 3.1.7.

Synchronization source throttling

Figure 2: Synchronization source throttling

The sequence number throttling mechanism is analogous to the SSRC throttling mechanism, but is done using the values stored on the RTP participant, which means one set per SSRC, while the SSRC throttling is global for the RTP session.

A throttling algorithm SHOULD be used on the receiver side. Another example of a throttling mechanism is the probation mechanism specified in [RFC3550] sections 6.2.1 and A.1.

To get correct dominant speaker notification on the protocol clients, the mixer MUST use the first element in the CSRC list as that of the dominant speaker. Receivers can implement special treatment, such as visual indication on the interface, for the dominant speaker, which is the first CSRC on the CSRC list. Mixer SHOULD implement an algorithm to select the dominant speaker. For an example, see section 4.2. The nature and behavior of the dominant speaker selection algorithm on the mixer and its usage by the protocol clients is up to the implementation and out of the scope of this specification.

Either the participant time-out timer specified in section 3.1.2 or the time-out algorithm in [RFC3550] section 6.3.5 MUST be used.