A Generic Bundling Mechanism for SDP

TBD

[Insert RFC 2119 boilerplate here.] 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, 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.

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 in SDP. * 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.

This is an introduction to m= line-based multiplexing based on a series of examples. Some mandatory SDP lines have been omitted from the examples for brevity.

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

o=- 2890844526 2890844526 IN IP4 host.example.com c=IN IP4 host.example.com 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). m=audio 10000 RTP/AVP 0 8 97 a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \ raddr 192.0.2.240 rport 51091 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 This MD provides the transport information about the video and also describes the role of the video from the application's point of view. m=video 10002 RTP/AVP 31 32 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \ raddr 192.0.2.240 rport 51091 We call the RTP that is described by each media description (MD) a media describee (MDee), so we have an unambiguous name for it. The audio and video are carried in separate MDees. In m= line multiplexing, we add a special m= line to describe a single MDee to carry both the audio and video information:

o=- 2890844526 2890844526 IN IP4 host.example.com c=IN IP4 host.example.com Declare which MDs are included in the multiplexed MD: mid:c0 is the multiplexed MDee, and it contains the RTP that would be sent in MDees c1 and c2. a=group:BUNDLE c0 c1 c2 This MD provides the transport information for the multiplexed MDee, including any attributes which apply to the transport. The MD also must provide the allowed payload types, which is the list of the distinct payload types specified for c1 and c2. m=multipart 10000 RTP/AVP 0 8 97 31 32 a=mid:c0 a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \ raddr 192.0.2.240 rport 51091 This MD provides the application-level description of the audio MDee -- it is still the first audio m= line. It includes any attriutes which apply to the audio media specifically. m=audio 10002 RTP/AVP 0 8 97 a=mid:c1 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 This MD has transport information (including the port number in the m= line and the a=candidate attributes) to provide fallback support. More about that later. a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \ raddr 192.0.2.240 rport 51091 This MD provides the application-level description of the video MDee -- it is still the first video m= line. It includes any attriutes which apply to the video media specifically. m=video 10004 RTP/AVP 31 32 a=mid:c2 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \ raddr 192.0.2.240 rport 51091 RTP that is received on port 10000 is demultiplexed by the payload type -- PTs 0, 8, and 97 are identified as belonging to the audio MDee, and PTs 31 and 32 are identified as belonging to the video MDee. The answerer understands that the second and third MDs are incorporated into the first MD, and ignores their transport information. It provides no a=candidate attributes for them in the answer, and gives the dummy non-zero value "9" (the discard port) as the port number to show that it accepted those constituent MDs.

o=- 2890844526 2890844526 IN IP4 answer.example.com c=IN IP4 answer.example.com a=group:BUNDLE c0 c1 c2 m=multipart 20000 RTP/AVP 0 8 97 31 32 a=mid:c0 a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \ raddr 192.0.2.240 rport 51091 m=audio 9 RTP/AVP 0 8 97 a=mid:c1 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 m=video 9 RTP/AVP 31 32 a=mid:c2 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 m= line multiplexing allows for upward compatibility in case the answerer does not understand multiplexing. In that case, the answerer ignores the a=group line, and effectively sees the offer as this:

o=- 2890844526 2890844526 IN IP4 host.example.com c=IN IP4 host.example.com a=group:BUNDLE c0 c1 c2 This MD has an unknown media type, and the answerer will reject it: m=multipart 10000 RTP/AVP 0 8 97 31 32 a=mid:c0 a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \ raddr 192.0.2.240 rport 51091 This MD is an ordinary audio MD: m=audio 10002 RTP/AVP 0 8 97 a=mid:c1 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \ raddr 192.0.2.240 rport 51091 m=video 10004 RTP/AVP 31 32 This MD is an ordinary video MD: a=mid:c2 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \ raddr 192.0.2.240 rport 51091 So the answerer assembles this answer:

o=- 2890844526 2890844526 IN IP4 answer.example.com c=IN IP4 answer.example.com a=group:BUNDLE c0 c1 c2 This MD is rejected because it is not understood: m=multipart 0 RTP/AVP 0 m=audio 20000 RTP/AVP 0 8 97 This MD is accepted. Transport information is provided: a=mid:c1 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \ raddr 192.0.2.240 rport 51091 This MD is accepted. Transport information is provided: m=video 20002 RTP/AVP 31 32 a=mid:c2 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \ raddr 192.0.2.240 rport 51091 Because the first MD is rejected, the offerer knows that the answerer has not accepted multiplexing, and it proceeds to interpret the second and third MDs directly.

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. (Blank lines are inserted for clarity.) We use separate MDs because each MDee has a different *role*, the application will handle them in distinctly different ways.

o=- 2890844526 2890844526 IN IP4 host.example.com c=IN IP4 host.example.com a=group:BUNDLE c0 c1 c2 c3 c4 m=multipart 10000 RTP/AVP a=mid:c0 m=audio 10002 RTP/AVP 0 8 97 a=mid:c1 a=label:speaker-audio a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \ raddr 192.0.2.240 rport 51091 m=audio 10004 RTP/AVP 100 101 102 a=mid:c2 a=label:floor-mic a=rtpmap:100 PCMU/8000 a=rtpmap:101 PCMA/8000 a=rtpmap:102 iLBC/8000 a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \ raddr 192.0.2.240 rport 51091 m=video 10006 RTP/AVP 103 104 a=mid:c3 a=label:speaker-video a=rtpmap:103 H261/90000 a=rtpmap:104 MPV/90000 a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \ raddr 192.0.2.240 rport 51091 m=video 10008 RTP/AVP 105 106 a=mid:c4 a=label:slides a=rtpmap:105 H261/90000 a=rtpmap:106 MPV/90000 a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \ raddr 192.0.2.240 rport 51091

This example is the teacher's connection to a virtual classroom server. The media is: - one audio channel, for sending the teacher's voice and receiving the voice of any selected student - one video channel, for sending the teacher's presentation - one video channel, for sending the teacher's face - one video channel, for receiving a dynamically varying set of students' faces The second video MDee contains a large and variable set of video captures. These are handled by a single MDee 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. Once the single transport MDee is demultiplexed based on payload type into the four MDees , the second video MDee is demultiplexed based on SSRC. The SDP is:

o=- 2890844526 2890844526 IN IP4 host.example.com c=IN IP4 host.example.com a=group:BUNDLE c0 c1 c2 c3 c4 m=multipart 10000 RTP/AVP a=mid:c0 m=audio 10002 RTP/AVP 0 8 97 a=mid:c1 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 m=video 10004 RTP/AVP 103 104 a=mid:c2 a=label:speaker The teacher's face and presentation is send-only: a=sendonly a=rtpmap:103 H261/90000 a=rtpmap:104 MPV/90000 m=video 10006 RTP/AVP 105 106 a=mid:c3 a=label:presentation a=sendonly a=rtpmap:105 H261/90000 a=rtpmap:106 MPV/90000 m=video 10008 RTP/AVP 105 106 a=mid:c4 a=label:student-thumbnails The student video input is receive-only and limited to 24 simultaneous SSRCs: a=recvonly a=max-recv-ssrc:{*:24} a=rtpmap:105 H261/90000 a=rtpmap:106 MPV/90000

TBD Describe how people helped me. List of predecessor drafts and their authors. Long list of people who have helped me directly. draft-alvestrand-one-rtp ("TOGETHER") H. Alvestrand draft-holmberg-mmusic-sdp-mmt-negotiation ("MMT") C. Holmberg, H. Alvestrand draft-ietf-mmusic-sdp-bundle-negotiation ("BUNDLE")

TBD

There are no known security implications of these behaviors.

Initial version.