[MMUSIC] Demultiplexing via indexes in RTCP SDES packets

[[e-mail] (Dale R. Worley)]

Moving this proposal over from the RTCWEB mailing list, updating and
correcting it:

I was working on an essay based on the assumption that a single video
capture is carried over a single m= line (with the various component
streams (simulcast, FEC, layered encoding, etc.) sent using different
SSRCs)...  But many existing systems don't work that way.  It would be
nice to correct that, but basing our solution on that assumption isn't
the quick way to get products to market.  ;-) So we can't assume a
small number of m= lines, which implies that we can't safely require
that each m= line has a disjoint set of payload types, which implies
that we can't demultiplex based on PT.

If multiplexing based on payload type is unworkable, how about the
following technique.  (Forgive me if someone else has already proposed
it.)

    Each SSRC is demultiplexed based on an RTCP SDES item that
    specifies the mapping between the SSRC and the m= line via which
    it is presented to the application layer.

When a media stream with new SSRC is sent, the sender inserts an RTCP
SDES item with a special multiplexing "item type".  The SDES item
contains the SSRC value and the identifier of the m= line via which
that SSRC is obtained from the application layer.  For reliability,
the sender resends this SDES item occasionally.

The receiver keeps a table which maps the SSRCs to the m= lines via
which each SSRC is to be presented to the application.  Entries in the
table are added/updated when the multiplexing SDES items are received.

Since SDES items are meant to describe the "source" of the media
stream, using an SDES item to identify how the media is supplied by
the application is probably within the semantic definition of SDES.
(If people don't like that, we could define another RTCP packet type.)

For each stream, this mechanism only adds one 8 byte SDES item
periodically in the RTCP (given that RTCP packets often contain SDES
packets, so the SDES packet header isn't charged to carrying this
item).  The overhead is reduced to 4 bytes if the RTCP periodically
contains SDES items for that SSRC anyway, and we don't have to charge
the 4 bytes carryig the SSRC.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P|    SC   |  PT=SDES=202  |             length            |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk  |                          SSRC                                 |
  1    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     MUX=11    |     length=1  |0|m= line seq. |  NULL=0       |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk  |                          ...                                  |
  2

With dexterous use of pseudo-UTF-8 encoding to encode sequence
numbers, an 8 byte item suffices for the typical case, but we still
support multiplexing an unlimited number of m= lines.  m= line
identifiers from 1 to 127 are represented

       +-+-+-+-+-+-+-+-+
       |0 s s s s s s s|
       +-+-+-+-+-+-+-+-+

while identifiers from 128 to 2047 are represented

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |1 1 0 s s s s s|1 0 s s s s s s|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and larger identifiers can be encoded if necessary.

These look like UTF-8 encodings of characters, so they shouldn't choke
code that interprets SDES items (the data values in SDES items are
UTF-8-encoded strings).

We could even support multiplexing m= lines that specify multiple
addresses or ports by encoding a second identifier, which counts the
address or port in the group (starting at 1).

This method allows multiplexing to support whatever use of m= lines
the overlying application supports/requires, since it places no
restrictions on the SDP or RTP usage.

One interesting observation is that in order to make this work in 3PCC
situations, the m= line identifiers can't be the sequence number of
the m= line in the SDP in the offer/answer exchange, because the
sender of RTCP may be different than the endpoint sending the
offer/answer, and may see different SDP.  So we need the m= line
identifier to be invariant when a 3PCC assembles/disassembles
aggregated SDP.  One choice for that is to make the m= line index be
the sequence number of the m= line *within the m= lines in the
bundle*, since all of the m= lines in a bundle are routed to the same
media-generating endpoint.

(This problem afflicts all methods that specify a demultiplexing
index, including SHIM
(draft-westerlund-avtcore-transport-multiplexing-05), KUMQUAT
(draft-worley-sdp-bundle-05), and even
draft-rosenberg-rtcweb-rtpmux-00.)

Unfortunately, using m= line position within the bundle as the m= line
index, rather than using m= line position within the overall SDP,
makes demultiplexing unstable while bundling is changing due to a new
offer/answer exchange, because the demultiplexing index for an SSRC
will change.  However, only m= lines whose transport is changing will
be affected by this instability.

Dale