rtcweb D. Worley
Internet-Draft Ariadne
Intended status: Standards Track February 8, 2013
Expires: August 12, 2013
A Generic Bundling Mechanism for SDP
draft-worley-sdp-bundle-00
Abstract
This is an introduction to m= line-based multiplexing based on a
series of examples.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 12, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Worley Expires August 12, 2013 [Page 1]
Internet-Draft SDP Bundling February 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Desiderata . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Introduction in Pictures . . . . . . . . . . . . . . . . . . . 9
5.1. Example: audio and video . . . . . . . . . . . . . . . . 9
5.2. Example: two audio and two video . . . . . . . . . . . . 13
5.3. Example: virtual classroom: one audio, two videos,
and a group of videos . . . . . . . . . . . . . . . . . . 15
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Revision History . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. draft-worley-sdp-bundle-00 . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
Worley Expires August 12, 2013 [Page 2]
Internet-Draft SDP Bundling February 2013
1. Introduction
TBD
Worley Expires August 12, 2013 [Page 3]
Internet-Draft SDP Bundling February 2013
2. Terminology
[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.)
Worley Expires August 12, 2013 [Page 4]
Internet-Draft SDP Bundling February 2013
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.
Worley Expires August 12, 2013 [Page 5]
Internet-Draft SDP Bundling February 2013
3. Overview
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.
Worley Expires August 12, 2013 [Page 6]
Internet-Draft SDP Bundling February 2013
4. Desiderata
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
Worley Expires August 12, 2013 [Page 7]
Internet-Draft SDP Bundling February 2013
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.
Worley Expires August 12, 2013 [Page 8]
Internet-Draft SDP Bundling February 2013
5. Introduction in Pictures
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.
5.1. Example: audio and video
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:
Worley Expires August 12, 2013 [Page 9]
Internet-Draft SDP Bundling February 2013
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
Worley Expires August 12, 2013 [Page 10]
Internet-Draft SDP Bundling February 2013
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:
Worley Expires August 12, 2013 [Page 11]
Internet-Draft SDP Bundling February 2013
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:
Worley Expires August 12, 2013 [Page 12]
Internet-Draft SDP Bundling February 2013
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.
5.2. Example: two audio and two video
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.
Worley Expires August 12, 2013 [Page 13]
Internet-Draft SDP Bundling February 2013
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
Worley Expires August 12, 2013 [Page 14]
Internet-Draft SDP Bundling February 2013
5.3. Example: virtual classroom: one audio, two videos, and a group
of videos
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:
Worley Expires August 12, 2013 [Page 15]
Internet-Draft SDP Bundling February 2013
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
Worley Expires August 12, 2013 [Page 16]
Internet-Draft SDP Bundling February 2013
6. Acknowledgments
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")
Worley Expires August 12, 2013 [Page 17]
Internet-Draft SDP Bundling February 2013
7. IANA Considerations
TBD
Worley Expires August 12, 2013 [Page 18]
Internet-Draft SDP Bundling February 2013
8. Security Considerations
There are no known security implications of these behaviors.
Worley Expires August 12, 2013 [Page 19]
Internet-Draft SDP Bundling February 2013
9. Revision History
9.1. draft-worley-sdp-bundle-00
Initial version.
Worley Expires August 12, 2013 [Page 20]
Internet-Draft SDP Bundling February 2013
10. References
10.1. Normative References
[sip] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
10.2. Informative References
[service-examples]
Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
K. Summers, "Session Initiation Protocol Service
Examples", RFC 5359, October 2008.
Worley Expires August 12, 2013 [Page 21]
Internet-Draft SDP Bundling February 2013
Author's Address
Dale R. Worley
Ariadne Internet Services, Inc.
738 Main St.
Waltham, MA 02451
US
Phone: +1 781 647 9199
Email: worley@ariadne.com
Worley Expires August 12, 2013 [Page 22]