Re: [rtcweb] #15: Section 4.8: SSRC signaling

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

> From: Bernard Aboba <[e-mail]>
> 
> If you have several devices per host (e.g. Multiple cameras) each
> using simulcast or layered coding, are supporting screen
> sharing/data channel/audio+video and also have a single m= line for
> each RTP stream, then this isn't so outlandish.

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 that isn't how existing systems work, and it may not be
workable at all.  It would be nice to correct that, but that probably
isn't the quick way to get products to market.  ;-)

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 gives
    the mapping between the SSRC and the m= line via which it is
    presented to the application layer (that is, the constituent m=
    line sequence number).

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 sequence number of the m= line via
which that SSRC is obtained from the application layer.  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 close to its intention.  (If one doesn't like that,
we could define another RTCP packet type.)

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 multiplexing).  The overhead is reduced
to 4 bytes if the RTCP periodically contains SDES items for the SSRC
anyway.

        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, and even support
multiplexing m= lines that specify multiple addresses or ports.

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.

In addition, demultiplexing is stable even while the bundling is
changing due to a new offer/answer exchange, because the SSRC on the
incoming RTP packets will be stable, even while the media stream is
redirected from one transport endpoint (for the old bundle) to another
transport endpoint (for the new bundle).

Dale