Subject: [MMUSIC] Demultiplexing via indexes in RTCP SDES packets

From: [email-masked] (Dale R. Worley)
Date: Mon, 29 Apr 2013 17:59:58 -0400 (EDT)

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 30 Apr 2013 09:52:57 +0200

Hi Dale,

I do agree that part of a solution is the possibility to bind one or a
set of SSRCs to a particular usage that is signalled somehow. However,
there is several different types of bindings that is needed here. Just
binding to a m= line is likely short sighted, restrictive and incomplete.

I support your proposal of including a level of indirection enabling us
to avoid having to update the SDP for any addition of SSRCs, which a
a=ssrc based solution would require.

However, SDP is not the only signalling solution, it is the currently
dominating one, but if you ever is going enable us of breaking out of
the SDP trap, we need to ensure that the solutions around are not SDP
specific. Thus, using SDES items for in stream bindings are something I
support, but the label should be done in such a way that it can be
handled as labels for a particular purpose and thus be included in other
signalling solutions.

Then the next question is what intentions of bindings that you intended
to do. There are several different ones that I see we have need in the
near future. So lets look at some examples:

- Application related usage of video streams, for example if a SSRC is
currently carrying a main video or a thumbnail and thus which negotiated
constraints it tries to adhere to.

- Is the this SSRC part of a simulcast set, and if which quality strata
does it carry

- Is this SSRC a related repair or retransmission stream to another
primary media carrying SSRC.

One issue is that for example the first can easily be a dynamic process,
some implementations will reconfigure a SSRC between application purpose
due to user or application input.

Just these three above examples points to one very clear issues in
making progress here. We must try to clearly define the usage different
people see. See which is the same, which is orthogonal and which must be
possible to have in place at the same time.

This is the realization we have come to with in the discussion around
the SRCNAME proposal:
http://tools.ietf.org/html/draft-westerlund-avtext-rtcp-sdes-srcname

This discussion has proven the importance of having common terminology
and I hope we can make progress with the grouping taxonomy, because that
document will discuss both object names and different possible relation
ships between these different types of object, like RTP sessions, SSRCs,
FEC groups.

Early version of grouping taxonomy that do need work.
https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping-taxonomy/

Simulcast proposal
https://datatracker.ietf.org/doc/draft-westerlund-avtcore-rtp-simulcast/

Our review of known use cases for richer grouping and naming:
https://datatracker.ietf.org/doc/draft-burman-rtcweb-mmusic-media-structure/

I think all of these are relevant.

I think one important question here is if you really want and think it
is possible to bind have each different usage or purpose for an RTP
media stream (specific SSRC) can be captured with its own unique Media
Description (m= block)?

I also think it is important to realize that a particular SSRC may at
the same time have multiple relationships, for example it can be the
primary for a retransmission, part of a FEC group, be a particular
simulcast quality strata.

Please don't bind identifier and group ides to SDP concepts. Lets use a
level of indirection that both enables usage without SDP in certain
cases, and which can be bound to other signalling solutions in the future.

Cheers

Magnus

On 2013-04-29 23:59, Dale R. Worley wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
> 
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------