Kumquat: A Generic Bundle Mechanism for the Session Description Protocol (SDP)

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, the media are organized into a single RTP session. The transport-related properties of the RTP session (e.g., transport 5-tuple, encryption, ICE) are described by the transport-related attributes of a single media description. At the interface between the SDP-configured layer and the higher, application layer, the media are organized into several RTP sessions. The application-related properties of the RTP session (e.g., media type and label) are 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 encoding name and its parameters are accessible to the application. This gives the bundle mechanism freedom to place constraints on the use of payload types. The bundle is signaled in the session description by a "group" attribute with semantics "KUMQUAT". The first media description listed in the group is the "bundle" media description (MD), whose transport information describes the transport association via which the RTP packets will be sent. The remaining (zero or more) media descriptions listed in the group are the "constituent" MDs. RTP packets received from the applications for these MDs are encapsulated and sent on the transport association for the bundle MD. RTP packets received from the transport association for the bundle MD are deencapsulated and sent to the applications for the constituent MDs. A new payload type (codec) named "kumquat" is defined to be used for this encapsulation. In offer/answer usage, we must arrange that the bundle mechanism is backward compatible with entities that do not understand the bundle mechanism. This requirement drives many features of this solution. In addition, many devices in current usage (especially SBCs) apply more restrictions on the usage of SDP than one would expect from abstract consideration of their roles in the network. Some features of this solution are constructed to avoid these restrictions.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . The important RFCs in this area use inconsistent terminology. Here, we use: Media is (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 octets used to encode and transmit the abstract media content. (Taken from .) A media stream is a set of RTP packets that are generated by and interpreted by one codec. The RTP packets of a media stream are identified by a unique SSRC. (Taken from CLUE's work.) A capture is a set of media streams that originate from one (physical or virtual) media source and should be composed to provide rendering of that source. For example, media streams from one origin including layered encodings, forward error correction streams, recovery streams, and simulcasted media streams of varying bit rates compose one capture. (Taken from .) A transport association is a single data path between two hosts, such as a TCP connection, or a pair of UDP ports that send packets to each other. A transport association is identified by the identity of the protocol being used, the relevant host addresses, and the relevant port numbers. In the case of unicast communications, these form a "5-tuple", namely, the protocol, the host addresses of the two hosts, and the port numbers used on the two hosts. In the case of multicast sessions, these form a "3-tuple", namely, the protocol, the multicast address, and the port number. In SDP, a transport association is specified by the address and port of a media description (and possibly the same information from the matching offer/answer SDP). If a media description specifies multiple addresses or ports, each address or port specifies one transport association. (Taken from .) (This is called an "RTP session" by .) A transport flow is the data that flows across a transport association. (Taken from .) A media description is one group of lines in a session description demarcated by an m= line. By synecdoche, a media description is often referred to as "an m= line". A transport association group is the set of transport associations denoted by one media description. Usually the m= line specifies only one port and the c= line specifies only one address, and so the media description's transport association group contains only one transport association. A transport flow group is the set of transport flows of the transport associations of a transport association group. (Taken from section 2.) A session description is an SDP instance. (Taken from section 2.) A multimedia session is the totality of the media that is transmitted/received as described by a particular session description. (Taken from .) An RTP session is a group of media streams which must not have duplicated SSRC values because the endpoints share RTCP reporting information. Note that an RTP session may encompass more than one multimedia session. RTP sessions are not fully described by session descriptions.

This section lists desiderata for the bundle mechanism in SDP. (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 at the same time.) The first section lists desiderata that are arise from considering the ways applications may wish to bundling. The second section lists desiderata that arise from compatibility with existing Internet infrastructure.

These desiderata describe features that we would like the bundling mechanism to provide. For each bundle, there is a group of media descriptions which describe the application-level RTP sessions. This specification must allow the same granularity of description as when the media flows were not multiplexed. This description includes identifiers which connect the media flows with the application and with each other. This requirement is taken from . For each bundle, there is a media description that describes the transport-level RTP session. DES F1 and DES F2 do not specify whether the transport-level media description may or may not also be one of the application-level media descriptions. There must be a uniform way to deal with new SDP parameters, so that newly defined SDP parameters do not require a specific updating of the bundling procedures. This desideratum is taken from slides-interim-2013-rtcweb-1-10.pdf. Multiple separate bundles within one SDP must be supported. 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.) 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 representation 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 token payload type in rejected m= lines.) 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 or reject each constituent RTP session within it, (2) reject the bundle as a whole, or (3) reject the bundling and selectively accept or reject each constituent RTP session as separate RTP sessions. Presumably answer (3) resembles that which would be produced by an answerer that does not understand the bundle mechanism. It is a lower priority that the answerer can distinguish between accepting the bundle while rejecting all of its constituents, and rejecting the bundle as a whole. But those two conditions differ conceptually regarding whether any "framing" actions of the bundle are performed. 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. The RTCP information for each media stream 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. So regarding RTCP, this desideratum appears to be straightforward to satisfy. 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. In the terminology of , the constituent media descriptions are now part of one RTP session. When an offer is constructed, the offerer must not need to preallocate TURN relays for constituent media descriptions. When both endpoints support bundling, the mechanism must not require the offerer to allocate TURN relays for constituent media descriptions. This desideratum was suggested by Andrew Hutton. It must be possible to add and remove one way video flows within the bundle without requiring an additional offer/answer cycle. Presumably this can be accomplished as it is now, with a single media description carrying multiple video flows that are distinguished only by their SSRCs. This desideratum is taken from slides-interim-2013-rtcweb-1-10.pdf. Bundling must not interfere with ICE usage, and in particular, ICE's ability to negotiate both IPv4 and IPv6 addresses simultaneously. This desideratum was suggested by Andrew Hutton.

These desiderata describe compatibility of the bundling mechanism with with non-supporting endpoints or with existing entities in the Internet infrastructure. In offer/answer usage, an endpoint using the bundle mechanism must interwork correctly with an endpoint that does not understand the bundle mechanism. Interworking must continue when SDP endpoints are replaced with other endpoints during a sequence of offer/answer exchanges (such as happens in 3PCC or call transfers "behind an SBC"), including when a supporting endpoint is replaced by a non-supporting endpoint or vice-versa. SDP features (e.g., the codec set and ICE) are generally designed so that an offerer always offers every facility it is willing to support in the current situation, regardless of whether it was agreed to by the answerer in a preceding exchange. Thus, if the current answerer is a different endpoint than the previous answerer, the new answerer will negotiate a compatible set of facilities without needing knowledge of its predecessor's SDP. The offerer will smoothly transition to the new facilities. This property is required to support 3PCC situations (e.g., and ). This desideratum was suggested by Richard Ejzak. Avoid using media types in m= lines other than audio and video unless required for user media, as some SBCs reject SDP that uses other media types. This desideratum was suggested by Hadriel Kaplan. Any additional m= lines prescribed by the bundle mechanism should be ordered after the constituent m= lines. Many devices that have only one audio or video channel accept the first m= line with that media type and reject any further ones SBCs generally pass through attributes that they do not understand. SBCs generally pass through codec specifications that they do not understand, even if they are configured to transcode certain specific codecs. This non-desideratum was suggested by Hadriel Kaplan. After offer/answer processing is finished, if the exchanged SDP is examined by a non-supporting SBC, the set of transport associations that it sees being specified for media exchange should be the set that are actually used for media transfer. This is needed because SBCs monitor the packet traffic on the transport associations and if no media is seen on one of the associations for a significant period of time, the SBC will tear down the call. This desideratum was suggested by Hadriel Kaplan. In a session description, no endpoint of a transport association may be used multiple times. Such duplication is not defined by . Some SBCs do not support such duplication (ultimately, because it was not supported by ), and they reject SDP specifying duplicated transport association endpoints. This desideratum was suggested by Cullen Jennings. Offer/answer processing between supporting processors must be completed in one exchange. When interworking between supporting and non-supporting processors, it is less desirable but admissible that a second offer/answer exchange may be needed to complete configuring the multimedia session. If an intermediate entity provides transcoding between codecs, and if the offer/answer does not specify encryption of a media stream, the media stream should be able to take advantage of the transcoding facility. The non-encrypted case is not expected to be very common. Encrypted media can't be transcoded by an intermediate entity.

This section is non-normative. (This section was suggested by Charles Eckel.) This is an introduction to SDP bundling via a series of examples of offer/answer processing. Some mandatory SDP lines have been omitted from the examples for brevity. Long SDP lines have been folded by using trailing backslashes. Blank lines have been inserted for clarity.

Here is a typical, non-bundled SDP example with both audio and video media:

o=- 2890844526 2890844526 IN IP4 host.example.com c=IN IP4 10.0.1.1 This SDP media description (MD) provides the transport information about the audio and also identifies the role of the audio from the application's point of view. In this case, the fact that it is the first audio m= line suffices to tell the application how to treat it. In more complex cases, label or content attributes might be used to communicate the proper handling to the application. m=audio 10000 RTP/AVP 0 8 97 a=rtcp-mux a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=candidate:0 1 UDP 2113601791 10.0.1.1 10000 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51000 typ srflx \ raddr 10.0.1.1 rport 10000 This MD provides the transport information about the video and also identifies the role of the video from the application's point of view. m=video 10002 RTP/AVP 31 32 a=rtcp-mux a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=candidate:0 1 UDP 2113601791 10.0.1.1 10002 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51002 typ srflx \ raddr 10.0.1.1 rport 10002 We call the RTP that is described by each media description (MD) a transport flow (TF). The audio and video are carried in separate TFs, which each have a separate transport association (address/port).

With SDP bundling, we add an additional MD to describe a single "bundle" TF to carry both the audio and video information, and a group attribute to show the association of the bundle MD with the constituent MDs:

o=- 2890844526 2890844526 IN IP4 host.example.com c=IN IP4 10.0.1.1 The following group attribute declares which MDs are included in the multiplexed MD: mid:con1 and mid:con2 are the constituent MDs whose TFs (from the application point of view) will be carried by the TF of the first-designed MD, mid:bundle, which is the bundle MD. a=group:KUMQUAT bundle con1 con2 This MD provides the application-level description of the audio TF. As in the previous example, it is the first audio m= line. It includes any attributes which apply to the audio media from the application point of view, including the payload type definitions. When interpreted by a supporting processor, the transport information is ignored. When interpreted by a processor that does not support bundling, the transport information sets up the transport association for the audio TF. m=audio 10002 RTP/AVP 0 8 97 a=mid:con1 a=rtcp-mux a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 This MD provides the application-level description of the video TF. As in the previous example, it is the first video m= line. It includes any attributes which apply to the video media from the application point of view. As in the audio MD, the association information is used only by a processor that does not support bundling. m=video 10004 RTP/AVP 31 32 a=mid:con2 a=rtcp-mux a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 This MD provides the transport information for the bundle TF, including any attributes which apply to the transport. We use RTCP multiplexing [RFC5761], so only one set of ICE candidates (and only one TURN relay) is needed for each MD. The MD is artificially given the media type "audio" (which is ugly, but it avoids rejection by SBCs) and it is placed after all of the constituent MDs so as to not affect their positions as "first audio MD", etc. The MD lists a single payload type for the "kumquat" payload format, which is used to encapsulate the RTP of the constituent TFs. m=audio 10000 RTP/AVP 127 a=mid:bundle a=rtcp-mux a=rtpmap:127 kumquat a=candidate:0 1 UDP 2113601791 10.0.1.1 10000 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51000 typ srflx \ raddr 10.0.1.1 rport 10000 If this SDP bundle is accepted, RTP provided by the application for the audio TF will be encapsulated into a kumquat payload and then be sent from port 10000. The encapsulation also contains the ordinal index (i.e., 0) of the audio TF and the payload type of the original audio RTP. RTP provided by the application for the video TF will be encapsulated into a kumquat payload and then be sent from port 10000. The encapsulation also contains the ordinal index (i.e., 1) of the video TF and the payload type of the original video RTP. RTP that is received on port 10000 is interpreted according to the kumquat payload format: The constituent MD ordinal index is extracted. The encapsulated RTP and its payload type are then interpreted according to the constituent MD.

If the answerer supports SDP bundling, and desires to accept the offered bundle and its constituent MDs, the answerer signals that it accepts the SDP bundling by providing a matching group:KUMQUAT attribute in the answer. As always in offer/answer, the MDs in the answer correspond to the MDs in the offer by ordinal position. The answerer provides the necessary transport information for the bundle MD. The answerer understands that MDs mid:con1 and mid:con2 are incorporated into MD mid:bundle, and ignores their transport information. It accepts each constituent MD by providing an answer MD for each of them that specifies a null address and port 9 (the discard port).

o=- 2890844526 2890844526 IN IP4 answer.example.com c=IN IP4 10.0.2.1 a=group:KUMQUAT bundle con1 con2 m=audio 9 RTP/AVP 0 8 97 c=IN IP4 0.0.0.0 a=mid:con1 a=rtcp-mux a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 m=video 9 RTP/AVP 31 32 c=IN IP4 0.0.0.0 a=mid:con2 a=rtcp-mux a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 m=audio 20000 RTP/AVP 127 a=mid:bundle a=rtcp-mux a=rtpmap:127 kumquat a=candidate:0 1 UDP 2113601791 10.0.2.1 20000 typ host a=candidate:1 1 UDP 1694194431 198.51.100.35 51090 typ srflx \ raddr 10.0.2.1 rport 20000 Because the offer contained real addresses and ports for the constituent MDs and the answer accepted them, intermediate entities may expect the offerer to send at least RTCP on the transport association. To prevent such an intermediate entity from timing-out the multimedia session (because such RTCP will not be sent), the offerer needs to update its offer to withdraw the real address and ports for the constituent MDs, replacing them with a null address and port 9.

o=- 2890844526 2890844527 IN IP4 host.example.com c=IN IP4 10.0.1.1 a=group:KUMQUAT bundle con1 con2 m=audio 9 RTP/AVP 0 8 97 c=IN IP4 0.0.0.0 a=mid:con1 a=rtcp-mux a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 m=video 9 RTP/AVP 31 32 c=IN IP4 0.0.0.0 a=mid:con2 a=rtcp-mux a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 m=audio 10000 RTP/AVP 127 a=mid:bundle a=rtcp-mux a=rtpmap:127 kumquat a=candidate:0 1 UDP 2113601791 10.0.1.1 10000 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51000 typ srflx \ raddr 10.0.1.1 rport 10000 The answerer responds with the same answer as before.

SDP bundling allows for backward compatibility in case the answerer does not understand bundling. If the answerer does not understand bundling, it ignores the group attribute, and effectively sees the offer as:

o=- 2890844526 2890844526 IN IP4 host.example.com c=IN IP4 10.0.1.1 m=audio 10002 RTP/AVP 0 8 97 a=rtcp-mux a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 m=video 10004 RTP/AVP 31 32 a=rtcp-mux a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 m=audio 10000 RTP/AVP 127 a=rtcp-mux a=rtpmap:127 kumquat a=candidate:0 1 UDP 2113601791 10.0.1.1 10000 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51000 typ srflx \ raddr 10.0.1.1 rport 10000 If the answerer wishes to accept the first audio and video streams, it assembles this answer:

o=- 2890844526 2890844526 IN IP4 answer.example.com c=IN IP4 10.0.2.1 The absence of the group attribute informs the offerer that bundling was rejected. The audio MD is accepted. Transport information is provided, but it does not include ICE candidates, because the offer did not provide ICE candidates for the first and second MDs. m=audio 20000 RTP/AVP 0 8 97 a=rtcp-mux a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 The video MD is accepted. Transport information (using a different port) is provided. m=audio 20002 RTP/AVP 31 32 a=rtcp-mux a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 The bundle MD is rejected by the answerer because the only offered codec was kumquat, and the answerer does not implement it. m=audio 0 RTP/AVP 127 Because the group attribute is not present in the response, the offerer knows that the answerer does not support bundling (or does not want to consider the offered bundle). The offerer knows that the answerer wants to establish one audio TF and one video TF, and formally, that has been done. But if transport requires ICE candidates describing TURN relays, the offerer must send an updated offer containing those ICE candidates for the constituent MDs:

o=- 2890844526 2890844527 IN IP4 host.example.com c=IN IP4 10.0.1.1 No group attribute is included, to ensure that this update only sets transport attributes, and does not trigger bundle-supporting behavior if the answering entity has changed in the meantime. Provide ICE candidates for the audio MD. (We can reuse the ICE candidates (and TURN relay) previously offered for the bundle MD.) m=audio 10000 RTP/AVP 0 8 97 a=mid:con1 a=rtcp-mux a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=candidate:0 1 UDP 2113601791 10.0.1.1 10000 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51000 typ srflx \ raddr 10.0.1.1 rport 10000 Provide ICE candidates (and a separate TURN relay) for the video MD. m=video 10002 RTP/AVP 31 32 a=mid:con2 a=rtcp-mux a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=candidate:0 1 UDP 2113601791 10.0.1.1 10002 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51002 typ srflx \ raddr 10.0.1.1 rport 10002 The bundle MD must still be listed, but it is disabled. m=audio 0 RTP/AVP 127 a=mid:bundle The answerer then provides an answer that contains ICE candidates:

o=- 2890844526 2890844527 IN IP4 answer.example.com c=IN IP4 10.0.2.1 m=audio 20000 RTP/AVP 0 8 97 a=rtcp-mux a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=candidate:0 1 UDP 2113601791 10.0.2.1 20000 typ host a=candidate:1 1 UDP 1694194431 198.51.100.35 51090 typ srflx \ raddr 10.0.2.1 rport 20000 m=audio 20002 RTP/AVP 31 32 a=rtcp-mux a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=candidate:0 1 UDP 2113601791 10.0.2.1 20002 typ host a=candidate:1 1 UDP 1694194431 198.51.100.35 51092 typ srflx \ raddr 10.0.2.1 rport 20002 m=audio 0 RTP/AVP 127 The ICE negotiations proceed, the transport associations are established, and RTP flows.

The baseline procedure requires the offerer to update its offer when it discovers that the answerer does not support SDP bundling if TURN relays are needed to support the constituent MDs. The offerer can avoid this delay by providing transport information for the constituent MDs as well as for the bundle MD. The penalty is that the offerer must preallocate TURN relays for both the constituent MDs as well as the bundle MD.

o=- 2890844526 2890844526 IN IP4 host.example.com c=IN IP4 10.0.1.1 a=group:KUMQUAT bundle con1 con2 m=audio 10000 RTP/AVP 0 8 97 a=mid:con1 a=rtcp-mux a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=candidate:0 1 UDP 2113601791 10.0.1.1 10000 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51000 typ srflx \ raddr 10.0.1.1 rport 10000 m=video 10002 RTP/AVP 31 32 a=mid:con2 a=rtcp-mux a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=candidate:0 1 UDP 2113601791 10.0.1.1 10002 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51002 typ srflx \ raddr 10.0.1.1 rport 10002 m=audio 10004 RTP/AVP 127 a=mid:bundle a=rtcp-mux a=rtpmap:127 kumquat a=candidate:0 1 UDP 2113601791 10.0.1.1 10004 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51004 typ srflx \ raddr 10.0.1.1 rport 10004 If the answerer understands bundling and accepts the bundle, it accepts the constituent MDs (with a null address and port 9) and accepts the bundle MD. If the answerer does not understand bundling, it accepts the constituent MDs and rejects the bundle MD.

In this example, a presentation involves four media roles: the speaker's audio, the floor microphone, the video of the speaker, and the video of the speaker's slides. We use separate MDs for each media stream because each TF has a different role; the application will handle each of them in distinctly different ways.

o=- 2890844526 2890844526 IN IP4 host.example.com c=IN IP4 10.0.1.1 a=group:KUMQUAT b c1 c2 c3 c4 m=audio 10002 RTP/AVP 0 8 97 a=mid:c1 a=label:speaker-audio a=rtcp-mux a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 Note that different constituent MDs can use the same payload types (for the same or different codecs), because the kumquat encapsulation captures the constituent MD ordinal index separately from the payload type. m=audio 10004 RTP/AVP 0 8 97 a=mid:c2 a=label:floor-mic a=rtcp-mux a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 G722 m=video 10006 RTP/AVP 103 104 a=mid:c3 a=label:speaker-video a=rtcp-mux a=rtpmap:103 H261/90000 a=rtpmap:104 MPV/90000 m=video 10008 RTP/AVP 103 104 a=mid:c4 a=label:slides a=rtcp-mux a=rtpmap:103 H261/90000 a=rtpmap:104 MPV/90000 m=multipart 10000 RTP/AVP 127 a=mid:b a=rtcp-mux a=rtpmap:127 kumquat a=candidate:0 1 UDP 2113601791 10.0.1.1 10000 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51000 typ srflx \ raddr 10.0.1.1 rport 10000

This example is the teacher's connection to a virtual classroom server. The media descriptions are tagged using the "content" attribute. The media comprises: 1. one audio channel, for sending the teacher's voice and receiving the voice of a selected student 2. one video channel, for sending the teacher's presentation 3. one video channel, for sending the teacher's face 4. one video channel, for receiving a dynamically varying set of students' faces The fourth TF (for students' faces) contains a large and dynamically varying set of video captures. These can be handled by a single TF because they all have essentially similar roles -- the application will process them as a set. As Adam Roach would say, "no control surfaces are necessary to talk about and/or manipulate the individual streams". In particular, this allows a large number of captures to be handled without mentioning them in the SDP, at the expense of not allowing the SDP to describe any of them individually. Similarly, the number of captures can vary without having to renegotiate the SDP. (In contrast, the third TF (the teacher's face) is a separate TF because it is processed in a different role than that of the students' faces.) In unbundled usage, there would be one transport association for the fourth TF. Incoming RTP from that association would be demultiplexed by the application based on the SSRC values, which would be unique for each student. With bundling, once the single transport TF is demultiplexed based on the ordinal index in the kumquat encapsulation, deencapsulated RTP packets destined for the fourth TF (index = 3) would be further demultiplexed by their SSRC values. The offered SDP is:

o=- 2890844526 2890844526 IN IP4 host.example.com c=IN IP4 10.0.1.1 a=group:KUMQUAT b c1 c2 c3 c4 The audio channel is send/receive. m=audio 10002 RTP/AVP 0 8 97 a=mid:c1 a=label:speaker-audio a=content:speaker a=rtcp-mux a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 The teacher's face and presentation are send-only. m=video 10004 RTP/AVP 103 104 a=mid:c2 a=label:speaker-video a=content:speaker a=sendonly a=rtcp-mux a=rtpmap:103 H261/90000 a=rtpmap:104 MPV/90000 m=video 10006 RTP/AVP 105 106 a=mid:c3 a=label:presentation a=content:slides a=sendonly a=rtcp-mux a=rtpmap:105 H261/90000 a=rtpmap:106 MPV/90000 The student video input is receive-only and is limited to 24 simultaneous SSRCs. m=video 10008 RTP/AVP 105 106 a=mid:c4 a=label:student-thumbnails a=recvonly a=max-recv-ssrc:* 24 a=rtcp-mux a=rtpmap:105 H261/90000 a=rtpmap:106 MPV/90000 m=multipart 10000 RTP/AVP a=mid:b a=rtcp-mux a=candidate:0 1 UDP 2113601791 10.0.1.1 10000 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51000 typ srflx \ raddr 10.0.1.1 rport 10000

This example contains one audio MD and two SCTP MDs, which are used for Webrtc datachannels.

TBD (Here lies the real description.)

TBD

SDP bundling uses a payload type named "kumquat" to encapsulate the RTP packets of several constituent TFs into RTP packets of one TF. Each constituent TF has a distinct index value in the range 0 to 254 (inclusive). When kumquat is used within SDP bundling, the index value is the ordinal index of the MD within the session description. (The indexes start with 0 for the first MD.) When the application delivers a payload (and associated descriptive information such as SSRC) in the context of a constituent MD to be transmitted, it is encapsulated into a kumquat payload and the kumquat payload is transmitted using the transport association of the bundle MD. When a kumquat payload arrives on the transport association of the bundle MD, the kumquat payload is interpreted to construct a payload (and associated descriptive information). That payload is delivered to the application in the context of the constituent MD identified by the index value.

The format of a kumquat protocol payload contains a four-octet fixed part followed by zero or more CSRC identifiers, header extension, and the encapsulated payload. Note that this diagram is of the kumquat payload only, and does not include the RTP header before the payload.

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|0|X| CC |M| PT | index |transport flow | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | contributing source (CSRC) identifiers | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extension | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | encapsulated payload | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This field contains the value 2. This field contains the value 0. If this field is 1, the extension field is present. This field contains the count of the number of CSRC identifiers that follow the fixed part. This field contains the "marker" bit associated with the encapsulated payload. This field contains the payload type number associated with the encapsulated payload. The meaning of PT is defined by the TF identified by the index field. This field contains the index value identifying the constituent media description that the encapsulated payload is associated with. The range of index values is 0 to 254 (inclusive). The value 255 is reserved for further standardization and MUST NOT be used. This field contains the index of the transport flow within the transport flow group of the constituent media description. That is, it identifies one of the series of ports or addresses specified by the media description, if the media description specified multiple ports or addresses. The range of index values is 0 to 255. (If the media description does not specify a range of ports or addresses, the transport flow index is 0.) This variable-length field contains the four-octet CSRC identifiers associated with the encapsulated payload. The number of CSRC identifiers is given by the CC field. This variable-length field is present only if the X field is 1. If it is present, its format is the same as the extension field of the RTP header. In particular, its length is always a multiple of four octets. This variable-length field contains the payload of the payload type specified by the PT field (interpreted in the context of the constituent MD identified by the index field). There is no defined meaning for the RTP marker bit in association with a kumquat payload. (Note that this is the M field of the RTP header that precedes the kumquat payload, not the M field of the kumquat payload itself.) Its value MUST be 0. The kumquat payload represents an RTP packet containing the following data: The V field is 2. The pad field is unspecified, because the need for padding is determined only when the RTP packet is considered in the context of the transport protocol. These fields are taken from the corresponding fields of the kumquat payload data. These fields are taken from the corresponding fields of RTP header before the kumquat payload. These fields are taken from the corresponding fields of the kumquat payload data. This field is taken from the encapsulated payload field of the kumquat payload data. Graphically, the kumquat encoding sets up the following equivalence between an RTP packet of the constituent TF and an RTP packet of the bundle TF:

RTP packet in the context of the bundle media description (with PT1 specifying kumquat encoding): 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 RTP header: +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X1| 0 |0| PT1 | sequence number | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extension (per X1 bit) | | .... | +=+=+=+==+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Payload of kumquat payload type: +=+=+=+==+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |V=2|0|X2| CC |M| PT2 | index | 0 | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extension (per X2 bit) | | .... | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | contributing source (CSRC) identifiers (per CC) | | .... | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | encapsulated payload | | .... | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RTP packet in the context of the constituent media description identified by index: 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 RTP header: +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X2| CC |M| PT2 | sequence number | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extension (per X2 bit) | | .... | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | contributing source (CSRC) identifiers (per CC) | | .... | +=+=+=+==+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Payload of PT2 payload type: +=+=+=+==+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | encapsulated payload | | .... | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The kumquat encapsulation usually adds four octets to the length of the encapsulated RTP packet. The encapsulation overhead can be larger if there is a need for a separate RTP header extension for the kumquat RTP packet.

TBD

TBD Need to discuss here how the encryption associations are set up. For SRTP/SRTCP, it would be possible to have either one association for all multiplexed streams, or one for each constituent MD, because SRTP preserves the PTs. (Have to verify that and check whether SRTCP preserves SSRCs.) But SCTP-over-DTLS can't be demultiplexed before it's decrypted, so there can be only one DTLS crypto association.

TBD

Key: x = feature present in proposal - = feature not present in proposal . = feature not discussed in proposal N/A = feature is not relevant because of another feature choice worley-sdp-bundle-05 (KUMQUAT) | ietf-mmusic-sdp-bundle-negotiation-03 (BUNDLE) | | holmberg-mmusic-sdp-mmt-negotiation-00 (MMT) | | | alvestrand-one-rtp-02 (TOGETHER) | | | | ejzak-mmusic-bundle-alternatives-01 | | | | | Roach alternative 1a | | | | | |(roach-mmusic-mlines-00) | | | | | | Roach alternative 1b | | | | | | | Roach alternative 2 | | | | | | | | westerlund-avtcore- | | | | | | | | |transport-multiplexing-05 | | | | | | | | |(SHIM) V V V V V V V V V MD grouping: one - - - - - - x - - per type - - - - - x - - - none x x x x x - - x x Separate bundle MD: no - x - x x x x x x m=anymedia - - x - - - - - - m=audio x - - - - - - - - m=multipart - - - - - - - - - Immediate update: none - - x x x x x x x for support x x - - - - - - - for compat. x - - - - - - - - Constituent MD ports after establishment: N/A - - - - - x x - - same - x - x - - - x x different - - - - - - - - - null x - - - - - - - - rejected - - x - x - - - - Bundle MD payload types: N/A - - - - - x x - - one MD - x - x . - - x x all MDs - - x - . - - - - encap. x - - - . - - - - Constituent MD payload types: N/A - - - - - x x - - overlapping x - - - . - - x x distinct - x x x . - - - - Demultiplexing based on: N/A - - - - - x x - - PT - x x x . - - x - encap. x - - - . - - - x Rejection of bundle MD based on: N/A - x - x x x x x x media type - - x - - - - - - proto - - - - - - - - - codec x - - - - - - - - Addresses/ports in constituent MDs in offer: N/A - - - - - x x - - NA,ZP - - - - - - - - - NA,NZP - - - - x - - - - RA,ZP - - - - - - - - - RA,NZP,U x x x - x - - - - RA,NZP,S - x - x - - - x x NA = null address, RA = real address ZP = zero port, NZP = non-zero port U = unique ports, S = shared port

Are the constituent media descriptions combined into grouped media descriptions? All media are combined into one media description. All media of each media type are combined into one media description (which has that type). Each constituent media description is separate in the session description. This proposal does not aggregate constituent MDs so that attributes can be provided directly for each constituent MD.

Is there a separate bundle media description, and if so, what media type does it have? There is no separate bundle media description. There is a separate bundle media description of type "anymedia". There is a separate bundle media description of type "audio". There is a separate bundle media description of type "multipart". This proposal has a separate bundle MD so that attributes can be provided for the bundle MD independently of any constituent MD.

Is an immediate updated offer/answer used during session establishment? No. Yes, when establishing a session using bundling. Yes, when establishing a session not using bundling. This proposal requires updates for bundled answers (to tell intermediate entities to not expect media for constituent transport associations) and for non-bundled answers (to provide TURN ICE candidates, if needed).

What are the effective port numbers in MDs after the session is established? There are not multiple media descriptions because constituent MDs are combined. Port numbers in the MDs are the same. Port numbers in the MDs are different. All but one MD have null addresses. All but one MD have a zero port number (and thus are formally rejected). This proposal signals null connection addresses for constituent MDs to prevent intermediate entities from expecting to see media for the constituent transport associations.

What payload types are listed for the bundled MD? There is no MD describing the bundle as a whole. The bundle MD lists the payload types of one constituent MD. The bundle MD lists the payload types of all constituent MDs. The bundle MD lists one payload type for an encapsulation codec. This proposal uses one payload type in the bundled media description because (1) only the encapsulated PT is sent on that transport association, and (2) to ensure that answerers that do not implement bundling reject this MD.

What is the relationship between the payload types of the constituent MDs? There are not multiple media descriptions because constituent MDs are combined. Different constituent MDs may have overlapping payload type numbers. Different constituent MDs may not have overlapping payload type numbers. This proposal allows constituent MDs to use overlapping payload types because it relies on an encapsulation to demultiplex the constituent MDs.

What is the basis for the demultiplexing of RTP? Demultiplexing is not done because incoming RTP is not attributed to specific constituent MDs (possibly because constituent MDs are combined). Demultiplexing is done based on payload type numbers. Demultiplexing is done based on data carried in an encapsulation. This proposal does demultiplexing based on information in the encapsulated payload format.

We must ensure that the bundle MD is rejected by non-supporting endpoints. What method is used to ensure rejection? There is no bundle MD. The bundle MD uses a special media type value. The bundle MD uses a special proto value. The bundle MD uses (only) a special codec name. This proposal uses one encapsulated payload type in the bundled media description to ensure that answerers that do not implement bundling reject this MD.

There are a number of alternative ways that the offerer can configure the constituent media descriptions. Method 1 2 3 4 5 6 Coded in chart asNA,ZPNA,NZPRA,ZPRA,NZP,URA,NZP,URA,NZP,S Offered addressnullnullrealrealrealreal Offered portzeronon-zerozeronon-zero, uniquenon-zero, uniquenon-zero, shared TURN candidates?nonononoyesyes Supporting answerer accepts?yesyesyesyesyesyes Update needed for supporting answerer?nonopossiblyyesyesno Non-supporting answerer accepts?noprobablynoyesyesyes Update needed for non-supporting answerer?yesyesyesyesnono DisadvantagesACECDABCEBCBGBFG This is the address offered for the MD. There are two choices, a null address (0.0.0.0 for IPv4 or "invalid." for IPv6 or mixed IPv4/IPv6) or a real address of the offerer. This is the port that is offered. It can be either non-zero or zero (which indicates a stream that is not being offered). If the offered port is non-zero and the offered address is real, the port can be either unique, or shared with the other media descriptions in the bundle. If the offered address is real, are TURN candidates for the address provided (if they are needed)? If the answerer supports bundling, does it accept this media description? We assume the answer is Yes, so that acceptance of the constituent media descriptions can be signaled to the offerer. Is an SDP update needed to complete session setup if the answerer supports bundling? If an update is needed, it is needed to inform intermediaries that there will be no media sent based on the connection information in this media description; the update is not needed to establish communications and does not delay the application. If the answerer does not support bundling, does it accept this media description (without a further update)? Is an SDP update needed to complete session setup if the answerer does not support bundling? If an update is needed, in all cases, it is needed to establish communication. The disadvantages of each alternative: Media descriptions that are rejected (have zero ports) are not allowed to be members of a group (in the offer). An SDP update is needed for a supporting answerer to prevent intermediaries from timing out the multimedia session. An SDP update is needed for a non-supporting answerer to establish communications. Although a media description with a non-zero port but a null address is formally offered (although shown as on-hold via the old method), it is possible that the answerer will not consider it to be offered and many not accept it even if it otherwise wood. If the offered port is zero, the media description is not formally offered and the answerer should not accept it. SDP offers with multiple media descriptions that use the same port number (for the same real address) may be rejected by intermediaries. A TURN relay must be allocated for the constituent media description before the offer is sent. In my estimation, the worst disadvantages are A (zero port in offer), E (acceptance of offer with zero port), and F (duplicate port numbers), because they involve violations of or are known to trigger limitations of large numbers of intermediate devices. Disadvantage D (offering a MD with a null address) is nearly as severe, as we expect it to cause undesired behavior in many non-supporting answerers. Disadvantages C (update needed to communicate with non-supporting answerer) and G (TURN relay must be preallocated) are moderate, and disadvantage B (updated needed to prevent intermediaries from timing out) is the least severe (because it never delays the establishment of communication). Applying these priorities to the possible solutions, methods 4 and 5 (offer real address, non-zero unique port, with/without TURN candidates) are tied for the best choices, with the choice made based on the relative importance of minimizing preallocation of TURN relays compared to quickly establishing communication with non-supporting answerers.

This section discusses the constraints regarding demultiplexing datagrams from multiple protocols that are presented on one transport flow. This is an expansion of the analysis in section 5.1.2. The first octets of datagrams generated by particular protocols are: Protocol First octet Second octet Third octet Fourth octet STUN0x00, 0x010x00, 0x01 RTP0x80 to 0xBF0x00 to 0xC7, 0xCD to 0xFF RTCP0x80 to 0xBF0xC8 to 0xCC RTP/RTCPv30xC0 to 0xFF DTLS0x14 to 0x170x030x03 SCTPsource port highsource port lowdest. port highdest. port low TBD RFC 5764 specifies that the first octet of a DTLS packet is in the range 0x14 to 0x3F. RFC 5246 and RFC 6374 together specify the first octet is a "ContentType", with the range 0x14 to 0x17. Are additional octet values reserved for expansion? What is the range that should be reserved in practice? The most generalized stack of protocols we consider is this:

Layer 6: ... application interfaces ... ||| ||| ||| ||| V V V V | | | | | | | | Layer 5: | | | SCTP | | | | | | | | RTP SRTP | | Layer 4: RTCP SRTCP SCTP DTLS [ STUN ] \ | | | / --------------- ---------------- V | | Layer 3: [ encapsulation STUN ] [ \ / ] [ ---- --------- ] [ V ] | | Layer 2: [ DTLS STUN ] [ \ / ] [ ------- --------- ] [ V ] | | Layer 1: [ TURN ] | | Layer 0: UDP This is the base layer of this analysis, where packets are carried by UDP. If a packet arrives from a TURN relay for which we are a client, the TURN encapsulation must be removed before further processing. This need can be detected because the packet arrives from the client-facing address/port of a TURN server of which this entity is a client. If DTLS is applied to the bundle transport flow as a whole, that use of DTLS will have been negotiated. However, before deciphering, STUN packets need to be separated. STUN packets can be distinguished from DTLS packets by their first or second octets. If the bundling method uses encapsulation, decapsulation is done at this point in the protocol stack. However, before decapsulating, STUN packets need to be separated. The encapsulation method must allow encapsulated packets to be distinguished from STUN packets, if STUN packets have not been demultiplexed at layer 2 (due to DTLS encryption of the entire transport stream). All proposed encapsulation techniques ensure the first octet of the encapsulation is in the range allowed for the first octet of RTP, 0x80 to 0xBF, and thus is distinguishable from STUN. At this layer, most of the protocols are demultiplexed. RTP/SRTP, SRTP/SRTCP, DTLS, and STUN are distinguished by the values of the first two octets of the packet. SRTP/SRTCP is distinguished from RTP/RTCP by negotiation with the other endpoint -- SRTP/SRTCP is never multiplexed with RTP/RTCP. SCTP can be distinguished from the other protocols if the other endpoint agrees to use only SCTP port numbers in the range 0x4000 to 0x7FFF. This restriction can be specified here, because this limitation is only needed when bundling is implemented, which happens only when when both endpoints support bundling. (This particular range is chosen to avoid collision with a future RTP/RTCP version 3. The range of SCTP ports can be chosen arbitrarily because the SCTP ports are not used to route packets to this entity, as they are encapsulated in UDP.) If the layer 4 protocol is DTLS, the protocol above it will always be SCTP. The method used to demultiplex the various application interface streams varies depending whether encapsulation is used and if not, on the layer 4/5 protocol. If the layer 4 protocol is encapsulated, the encapsulation determines which constituent media description is to be assigned to this packet, and then application demultiplexing is done as normal for for that particular media description. Otherwise, the constituent media description must be determined by a method that is specific to the layer 4/5 protocol: An RTP/SRTP packet is assigned to the constituent media description which specifies its payload type number. (If encapsulation is not used, the constituent media descriptions must specify distinct payload type numbers.) An RTCP/SRTCP sub-packet is dispatched to the application which receives the RTP media stream containing the SSRC that is carried in the RTCP sub-packet. An SCTP packet is assigned to the constituent media description which specifies its destination port number. (If encapsulation is not used, the constituent media descriptions must specify distinct SCTP port numbers.)

If an SBC wishes to prevent positively the transport of certain media types or codecs, and enforces that by examining the content of RTP packets, the use of kumquat encoding may defeat the examination. TBD

TBD

Many people have provided input for this proposal regarding both the technical aspects and the organization of the presentation. Chief among them are the authors of the predecessor proposals ( (TOGETHER), (MMT), and (BUNDLE)): Harald Alvestrand, Jonathan Lennox, and Christer Holmberg. In addition, input was provided by Charles Eckel, Andrew Hutton, Cullen Jennings, Hadriel Kaplan, Paul Kyzivat, Adam Roach, and Robert Sparks.

Note to RFC Editor: Please remove this section before publication.

Initial version.

Thoroughly revise the text and structure of the document.

Heavily revise Terminology regarding media flows. Revise Desiderata, including adding that multiple separate bundles must be possible, and noninterference with ICE negotiation. Add section on ICE considerations. Change "fusion" to "bundle". Use a=rtcp-mux in examples to be more realistic (and to shorten the examples). Correct the use of ICE in answers; ICE candidates are not provided if an offered MD does not contain ICE candidates. Add an example of a fast-start offer.

Add design comparison . Use bibxml references. Add DES C9, regarding continued usage of transcoding facilities offered by intermediate entities.

Add demultiplexing considerations .

Change recommendation for SCTP port numbers from 0xC000-0xFFFF to 0x4000-0x7FFF to avoid collision with a future RTP/RTCP version 3. Add the transport flow index to the KUMQUAT encapsulation. Add section on choices for offering constituent MDs . Revise the examples to show offering "real address, non-zero port, no ICE candidates". Add note to DES C9 (support intermediate transcoding facilities) saying that intermediate transcoding facilities are not expected to be very useful, given that encryption will be the normal use case. Add an example with SCTP MDs. Add a section for encryption considerations. Revise generalized demultiplexing diagram to make explicit the optional RTP encapsulation layer. Update comparison chart for draft-ejzak-mmusic-bundle-alternatives-01 and draft-westerlund-avtcore-transport-multiplexing-05. Update comparison chart to discuss alternative address/port/candidate policies for offering constituent MDs.