Subject: [MMUSIC] Text for BUNDLEd MID-signaled ssrc's moving between m= lines

From: Jonathan Lennox <[email-masked]>
Date: Fri, 9 Jan 2015 16:42:35 +0000

Hi, all — as promised, here’s some proposed text for BUNDLE about SSRCs moving between “m=“ lines.

To review, the use case for this is Selective Forwarding Middleboxes that don’t rewrite SSRC values, but which need to change the semantic (associated with an “m=“ line) for a stream they’re forwarding.  (E.g., from primary speaker to previous speaker.)

This text is for the mid section, I think; there will probably need to be some other revisions in the document to accompany this, e.g. in 10.1.1 and the like.  I’ll leave it to the editors to figure out how all this goes together...

A given SSRC MUST, at any given time, only transmit RTP/RTCP packets associated with a single "m=" line.  However, an SSRC MAY move from one “m=" line to another, as long as the “m=“ lines have the same primary media type (audio, video, etc.) and (following the guidelines of [RFC7160]) the payload types being used have the same clock rate.

When an SSRC moves “m=“ lines, the MID header extension SHOULD (if negotiated) be sent, with the new MID value, in some RTP packets, in the same manner as when a source is first introduced.  If the source’s association with an “m=“ line was also signaled in SDP in an “a=ssrc” attribute, its association with its new m= line MUST also be sent in a new SDP offer or answer as soon as practical.

When an SSRC is moved from one bundled m= line to another one, the sender MAY encode the stream “straight through" without a decoder refresh point.  If the receiver’s architecture is such that it cannot transfer the necessary decoder state from one m= line to another, it SHOULD request a state refresh for the SSRC, e.g. with an FIR or PLI feedback message.

Because RTP and RTCP are typically sent over UDP, it is possible for packet reordering to cause RTP or RTCP packets with old MID values to be received after an SSRC’s MID association has changed.  Receivers SHOULD take steps to recognize and detect such old packets, to avoid an SSRC being incorrectly associated with its old “m=" line.

One approach to achieve this would be for receivers to remember the RTP timestamp and (if received in RTP) sequence number of the most recent time a MID association was received for an SSRC.   The new MID association SHOULD be ignored if: the new association was received in an RTP packet, and the packet’s RTP sequence number (modulo cycles) is older than the sequence number with which the MID was most recently received; if the new association is in an RTCP compound packet which carries an SR for the SSRC, and the RTP timestamp in the SR is older than the timestamp of most recent association for the MID; or if the new association is in an RTCP compound packet which carries an RR for the SSRC, but RTP traffic has been received from the SSRC since its most recent SR/RR, within the latest RTCP interval, such that an SR would be expected for the SSRC.

If additional mechanisms to recognize old packets are available (such as SRTP rollover counters, SRTCP indices, or the extended sequence numbers for video/raw streams [RFC4175]), they SHOULD also be used to detect old packets carrying old MID associations.

And for the specific MID SDES item section:

To ensure that reordered RTCP packets are detected correctly ([ref the section above]), the MID SDES item SHOULD be sent in regular compound RTCP packets (i.e., not reduced-size RTCP [RFC5506]), with an SR or RR corresponding to the SSRC whose MID is being sent.

Comments?  Do people agree this satisfies the use case?  Are there any holes in it?