Subject: [MMUSIC] A conceptual model of SDP bundling and related desiderata

From: [email-masked] (Dale R. Worley)
Date: Mon, 4 Feb 2013 22:27:52 -0500 (EST)

Here is the next edition of my thoughts about SDP bundling.  (See
y'all tomorrow!)

* Terminology

The important RFCs in this area use inconsistent terminology.  Here,
we use:

- "transport association" and "5-tuple"

A 5-tuple is the description of a particular transport association,
such as a TCP connection.  The components of the 5-tuple are the
identity of the protocol being used and the addresses and transport
ports of the two endpoints.

- "media"

We use this term for (1) media content, considered in an abstract way,
that is, without consideration of its particular encoding or the
framing information around it, and (2) the particular bits and bytes
used to encode and transmit the abstract media content.

- "multimedia session"

We use this term for the totality of the media that is
transmitted/received as described by a particular session description
(i.e., SDP instance).  This is taken from RFC 4566 section 2.

- "RTP session"

We use this term for the totality of the media that is
transmitted/received as described by a particular media description
(i.e., m= line) in a particular session description.  Since each media
description specifies one 5-tuple, RTP sessions correspond to
transport associations.  This is taken from RFC 3550 section 2.2.  (In
SIP usage (RFC 3264), this is called a "media stream", which term is
used in RTP usage to refer to the RTP with a single SSRC.)

It is understood that the RTP session can be dissected into "media
streams" that have separate SSRCs, but that is not relevant in this
analysis.  E.g., in SIP telephony, various activities of the far
endpoint can cause the ultimate source of the audio (and hence the
SSRC) to change dynamically without warning, but each new source
stands in for the previous one seamlessly in the user interface.

(However, there is a way (RFC 4566 section 5.14) for an m= line to
specify a set of ports and thus a set of related RTP sessions.  We do
not address that.)

In general, further agreed terminology is needed to describe the
aggregate of media possessing a particular SSRC, etc., but that is not
needed for this discussion.

* Conceptual structure

The central idea of bundling is to multiplex the media that would be
several RTP sessions into one RTP session, with particular emphasis on
allowing one transport association to carry media that are presented
to the higher, application layer, as multiple RTP sessions.

At the interface between the SDP-configured layer and the lower,
transport layer, we want the media organized into a single RTP
session.  The transport-related properties of the RTP session (e.g.,
transport 5-tuple, encryption, ICE) will be described by the
transport-related attributes of a single media description.

At the interface between the SDP-configured layer and the higher,
application layer, we want to have the media organized into several
RTP sessions.  The application-related properties of the RTP session
(e.g., media type and label) will be described by the
application-related attributes of separate media descriptions.

(There are some attributes (e.g., bandwidth limitation) that can apply
separately to both the bundled RTP session and the constituent RTP
sessions.)

However, we do not include the payload type numbers as information
available to the application; only the codec identity and its
parameters are accessible to the application.  This gives the bundling
mechanism freedom to place constraints on the use of payload types.

The application may distinguish between the media of each constituent
RTP session in ways that are not determinable from the properties of
the media themselves.  (E.g., in telepresence systems or in systems
where multiple video feeds are to be assembled into one large image,
multiple video streams have non-trivial relationships that are
specified by additional application-level SDP attributes.  Or there
may be several RTP sessions whose media types are the same but whose
logical roles in the multimedia session are not interchangeable.)

The application considers all media within a particular RTP session to
be a single logical media stream, regardless of changes in codec
(payload type) and SSRC (which often happen because the ultimate
source of the media changes).  E.g., a SIP telephone sends/receives
SDP with one audio media description, and all RTP sent/received within
that RTP session is connected to/from the telephone's user interface,
despite that far-end call transfer events or audio conference
processing may cause the payload type and SSRC of received RTP to
change without warning.

* Desiderata for a bundling mechanism

(I use the term "desiderata" -- "things that are desired" -- rather
than "requirements", because we may discover that we can't optimally
satisfy all of these criteria.)

    DES 1:  For each bundle, there is a group of media descriptions which
    describe the application-level RTP sessions.

    DES 2:  For each bundle, there is a media description that describes
    the transport-level RTP session.

These requirements do not specify whether the transport-level media
description may or may not also be one of the application-level media
descriptions.

    DES 3:  Bundles may contain other bundles as constituents.

Of course, no bundle may directly or indirectly contain itself.

I don't expect any current implementation to implement bundles within
bundles, but we should design the mechanism to allow this, as some day
we will likely need it.

    DES 4:  A bundle may contain zero constituents.

A bundle with no constituents serves no purpose for the transport of
media, but we are likely to someday need to describe such a bundle.
(Compare that an SDP m= line is syntactically constrained to specify
at least one payload type.  When SDP was used only to specify
multicast sessions, this constraint was common sense.  But once SDP
offer/answer was invented, when a media description was rejected, the
natural construction would be an m= line with a zero port and no
payload types.  But a payload type was syntactically required, so we
now have to provide at least one useless payload type for rejected m=
lines.)

    DES 5:  If an answerer that does not understand the bundle
    mechanism processes an offer that contains a bundle, it must
    interpret it as the collection of application-level media
    descriptions, and the offerer must be able to properly interpret
    the answer that it produces.

    DES 6:  If an answerer that does understand the bundle mechanism
    processes an offer that contains a bundle, it must be able to (1)
    accept the bundle and selectively accept/reject each constituent
    RTP session within it, (2) reject the bundle as a whole, or (3)
    reject the bundling and selectively accept/reject each constituent
    RTP session as separate RTP sessions.

Presumably answer (3) is like that which would be produced by an
answerer that does not understand the bundling mechanism.

    DES 7:  There must be a reliable way to demultiplex incoming RTP
    into the separate application-level RTP sessions.  Similarly,
    there must be a reliable way to demultiplex the associated RTCP
    information.

I know little about RTCP, but I believe that the RTCP information is
tagged with the SSRC about which it reports, and the SSRC is used to
correlate the RTCP reports with the RTP sessions containing media with
the same SSRC.  If so, RTCP demultiplexing requires no additional
specification, as RTCP is understood in the same way as in non-bundled
RTP.

    DES 8:  The specification must specify any needed additional
    procedures for handling SSRC collisions between media sources
    within different application-level RTP sessions, as those can now
    collide.

Dale