[MMUSIC] Encapsulation and demultiplexing

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

It turns out the demultiplexing STUN, RTP/RTCP/SRTP/SRTCP, SCTP, and
DTLS (presumably encapsulating SCTP) is straightforward, as long as we
ensure that SCTP (outside of DTLS) uses a restricted range of port
numbers.

There are two versions of encapsulation now on the table:


The KUMQUAT encapsulation (draft-worley-sdp-bundle) adds four octets
to the beginning of an RTP packet to make it into a new RTP packet.
The new packet has a chosen PT to identify the encapsulation, and uses
the 2-octet "sequence" field of the first word of the RTP header to
carry the indexes of the constituent media description and of the
transport flow (in case the MD has multiple transport flows).

It's not clear that there is a need to have an encapsulation carefully
reproduce the structure of an RTP packet.  Indeed, the encapsulation
doesn't need to be very careful to make packets that look like RTP
packets:  The fixed header of an RTP packet is only three 4-octet
words, and the second and third words are 32-bit binary numbers, so
KUMQUAT would be just as effective if it merely prepended a 4-octet
word that resembled the first word of an RTP header.

Using this simplified KUMQUAT encapsulation, encapsulation of SCTP is
straightforward:  Just prepend the KUMQUAT header word.

If RTP is being encapsulated with KUMQUAT, there is no reason not to
encapsulate SCTP or SCTP-over-DTLS with it also.  Encapsulation allows
demultiplexing without requiring distinct SCTP port numbers between
media descriptions, and the octet savings of not encapsulating SCTP is
small (given the relative size of the RTP).


The SHIM encapsulation
(draft-westerlund-avtcore-transport-multiplexing) uses a two-octet
prefix containing a 14-bit "session ID".  Each SDP media description
has an attribute to specify the session IDs to be used to encapsulate
RTP and the RTCP for that media description.

The remaining two bits of the two-octet prefix are fixed as "10",
presumably so the first octet values have the same range as those of
RTP/RTCPv2.

Although the draft does not say so, an SCTP packet stream can be a
constituent session of a SHIM encapsulation in the same way as an RTP
packet stream.


One requirement question that should be examined is whether, if
encapsulation is done, there is any value in making the encapsulated
packet look like a RTP packet, or whether there is any benefit to
preserving four-octet alignment of RTP fields.

The major advantage of an encapsulated solution over an unencapsulated
solution is that an encapsulated solution does not require the
constituent media descriptions to have disjoint sets of payload types
(or SCTP port numbers).  Since previous uses of SDP have no
interaction between the payload types of different media descriptions,
existing entities may have difficulty coordinating payload types
between media descriptions.  E.g., if the entity is assembling its
media streams from several sources, and thus assembling its SDP from
several constituent SDPs, the disjointness restriction may require the
entity to recode the payload type numbers of constituent transport
flows in order to multiplex them.

Dale