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

[Magnus Westerlund <[e-mail]>]

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:
> 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
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
> 
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------