idnits 2.17.1 

draft-ietf-avt-rtp-mps-03.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** The document seems to lack a License Notice according IETF Trust
     Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009
     Section 6.b -- however, there's a paragraph with a matching beginning.
     Boilerplate error?

     (You're using the IETF Trust Provisions' Section 6.b License Notice from
     12 Feb 2009 rather than one of the newer Notices.  See
     https://trustee.ietf.org/license-info/.)


  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  -- The draft header indicates that this document updates RFC3640, but the
     abstract doesn't seem to directly say this.  It does mention RFC3640
     though, so this could be OK.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

     (Using the creation date from RFC3640, updated by this document, for
     RFC5378 checks: 2001-09-21)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  -- The document date (July 28, 2009) is 5378 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  -- Possible downref: Non-RFC (?) normative reference: ref. '14496-1'

  -- Possible downref: Non-RFC (?) normative reference: ref. '14496-3'

  -- Possible downref: Non-RFC (?) normative reference: ref. '23003-1'

  ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866)

  -- Obsolete informational reference (is this intentional?): RFC 5246
     (Obsoleted by RFC 8446)


     Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------


2	AVT                                                           F. de Bont
3	Internet-Draft                                       Philips Electronics
4	Updates: 3640 (if approved)                                    S. Doehla
5	Intended status: Standards Track                          Fraunhofer IIS
6	Expires: January 29, 2010                                     M. Schmidt
7	                                                      Dolby Laboratories
8	                                                        R. Sperschneider
9	                                                          Fraunhofer IIS
10	                                                           July 28, 2009

12	  RTP Payload Format for Elementary Streams with MPEG Surround multi-
13	                             channel audio
14	                     draft-ietf-avt-rtp-mps-03.txt

16	Status of this Memo

18	   This Internet-Draft is submitted to IETF in full conformance with the
19	   provisions of BCP 78 and BCP 79.

21	   Internet-Drafts are working documents of the Internet Engineering
22	   Task Force (IETF), its areas, and its working groups.  Note that
23	   other groups may also distribute working documents as Internet-
24	   Drafts.

26	   Internet-Drafts are draft documents valid for a maximum of six months
27	   and may be updated, replaced, or obsoleted by other documents at any
28	   time.  It is inappropriate to use Internet-Drafts as reference
29	   material or to cite them other than as "work in progress."

31	   The list of current Internet-Drafts can be accessed at
32	   http://www.ietf.org/ietf/1id-abstracts.txt.

34	   The list of Internet-Draft Shadow Directories can be accessed at
35	   http://www.ietf.org/shadow.html.

37	   This Internet-Draft will expire on January 29, 2010.

39	Copyright Notice

41	   Copyright (c) 2009 IETF Trust and the persons identified as the
42	   document authors.  All rights reserved.

44	   This document is subject to BCP 78 and the IETF Trust's Legal
45	   Provisions Relating to IETF Documents in effect on the date of
46	   publication of this document (http://trustee.ietf.org/license-info).
47	   Please review these documents carefully, as they describe your rights
48	   and restrictions with respect to this document.

50	Abstract

52	   This memo describes extensions for the RTP payload format defined in
53	   RFC3640 for the transport of MPEG Surround multi-channel audio.
54	   Additional Media Type parameters are defined to signal backwards
55	   compatible transmission inside an MPEG-4 audio elementary stream.  In
56	   addition a layered transmission scheme without using the MPEG-4
57	   systems framework is presented to transport an MPEG Surround
58	   elementary stream via RTP in parallel with an RTP stream containing
59	   the downmixed audio data.

61	Table of Contents

63	   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
64	   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
65	   3.  Definitions and Abbreviations  . . . . . . . . . . . . . . . .  4
66	     3.1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . .  4
67	     3.2.  Abbreviations  . . . . . . . . . . . . . . . . . . . . . .  4
68	   4.  Transport of MPEG Surround . . . . . . . . . . . . . . . . . .  4
69	     4.1.  Embedded spatial audio data in AAC payloads  . . . . . . .  5
70	     4.2.  MPEG Surround Elementary Stream  . . . . . . . . . . . . .  6
71	       4.2.1.  Low Bit-rate MPEG Surround . . . . . . . . . . . . . .  7
72	       4.2.2.  High Bit-rate MPEG Surround  . . . . . . . . . . . . .  8
73	   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
74	     5.1.  Media Type registration  . . . . . . . . . . . . . . . . .  9
75	     5.2.  Registration of Mode Definitions with IANA . . . . . . . .  9
76	     5.3.  Usage of SDP . . . . . . . . . . . . . . . . . . . . . . . 10
77	   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
78	   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
79	     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
80	     7.2.  Informative References . . . . . . . . . . . . . . . . . . 12
81	   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12

83	1.  Introduction

85	   MPEG Surround (Spatial Audio Coding, SAC) [23003-1] is an
86	   International Standard that was finalized by MPEG in January 2007.
87	   It is capable of re-creating N channels based on M<N transmitted
88	   channels and additional control data.  In the preferred modes of
89	   operating the spatial audio coding system, the M channels can either
90	   be a single mono channel or a stereo channel pair.  The control data
91	   represents a significantly lower data rate than the data rate
92	   required for transmitting all N channels, making the coding very
93	   efficient while at the same time ensuring compatibility with M
94	   channel devices.

96	   The MPEG Surround standard incorporates a number of tools enabling
97	   features that allow for broad application of the standard.  A key
98	   feature is the ability to scale the spatial image quality gradually
99	   from very low spatial overhead towards transparency.  Another key
100	   feature is that the decoder input can be made compatible to existing
101	   matrixed surround technologies.

103	   As an example, for 5.1 multi-channel audio, the MPEG Surround encoder
104	   creates a stereo (or mono) downmix signal and spatial information
105	   describing the full 5.1 material in a highly efficient parameterised
106	   format.  The spatial information is transmitted alongside the
107	   downmix.

109	   By using MPEG Surround, existing services can easily be upgraded to
110	   provide surround sound in a backward compatible fashion.  While a
111	   stereo decoder in an existing legacy consumer device ignores the MPEG
112	   Surround data and plays back the stereo signal without any quality
113	   degradation, an MPEG Surround enabled decoder will deliver high
114	   quality multi-channel audio.

116	   The MPEG Surround decoder can operate in modes that render the multi-
117	   channel signal to multi-channel output, stereo output or operate in a
118	   two-channel headphone mode to produce a virtual surround output
119	   signal.

121	2.  Conventions

123	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
124	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
125	   document are to be interpreted as described in [RFC2119].

127	3.  Definitions and Abbreviations

129	3.1.  Definitions

131	   This memo makes use of the definitions specified in [14496-1],
132	   [14496-3], [23003-1] and [RFC3640].  Frequently used terms are summed
133	   up for convenience:

135	      Access Unit: An MPEG Access Unit is the smallest data entity to
136	      which timing information is attributed.  In the case of audio, an
137	      Access Unit is the smallest individually accessible portion of
138	      coded audio data within an elementary stream.

140	      AudioSpecificConfig(): Extends the class DecoderSpecificInfo(), as
141	      defined in [14496-1] when the objectType indication refers to a
142	      stream complying with [14496-3].  AudioSpecificConfig() is used as
143	      the configuration structure for MPEG-4 Audio as specified in
144	      [14496-3].  It contains the field audioObjectType that
145	      distinguishes between the different audio codecs defined in
146	      [14496-3], general audio information (e.g. the sampling frequency
147	      and number of channels) and further codec-dependent information
148	      structures.

150	      SpatialSpecificConfig(): Configuration structure for MPEG Surround
151	      audio coding as specified in [23003-1].  An AudioSpecificConfig()
152	      with an audioObjectType of value 30 contains a
153	      SpatialSpecificConfig() structure.

155	3.2.  Abbreviations

157	     AOT:    Audio Object Type
158	     AAC:    Advanced Audio Coding
159	     ASC:    AudioSpecificConfig() structure
160	     AU:     Access Unit
161	     HE AAC: High Efficiency AAC
162	     PLI:    Profile and Level Indication
163	     SSC:    SpatialSpecificConfig() structure

165	4.  Transport of MPEG Surround

167	   From a top-level perspective MPEG Surround data can be subdivided
168	   into configuration data contained in the SpatialSpecificConfig()
169	   (SSC) and the SpatialFrame() that contains the MPEG Surround payload.
170	   The configuration data can be signaled in-band or out-of-band.  In
171	   the case of in-band signaling the SSC is conveyed in a SacDataFrame()
172	   jointly with a SpatialFrame().  In the case of out-of-band signaling
173	   the SSC is transmitted to the decoder separately, e.g. by SDP
174	   [RFC4566] means.

176	   SpatialFrame()s may be transmitted either embedded into the downmix
177	   stream (Section 4.1) or as an individual elementary stream besides
178	   the downmix audio stream (Section 4.2).

180	   The buffer definition for AAC decoders limits the size of an AU as
181	   specified in [14496-3].  For high-bitrate applications that exceed
182	   this limit all MPEG Surround data MUST be put in a separate stream as
183	   defined in Section 4.2.

185	4.1.  Embedded spatial audio data in AAC payloads

187	   [14496-3] defines the extension_payload() as a mechanism for
188	   transport of extension data inside AAC payloads.  Typical extension
189	   data include SBR data and MPEG Surround data, i.e. a SacDataFrame()
190	   in extension_payload()s of type EXT_SAC_DATA. extension_payload()s
191	   reside inside the downmix AAC elementary stream.  The resulting
192	   single elementary stream is transported as specified in [RFC3640].
193	   As AAC decoders are required to skip unknown extension data, MPEG
194	   Surround data can be embedded in backwards compatible fashion and be
195	   transported with the mechanism already described in [RFC3640].

197	   The SacDataFrame() includes a SpatialFrame() and an optional header
198	   that contains an SSC.  Any SSC in a SacDataFrame() MUST be identical
199	   to the SSC conveyed via SDP for that stream.

201	   No new mode is introduced for SpatialFrame()s being embedded into AAC
202	   payloads.  Either the mode AAC-lbr or the mode AAC-hbr SHOULD be
203	   used.  The additional Media Type parameters as defined in Section 5.1
204	   SHOULD be present when SpatialFrame()s are embedded into AAC
205	   payloads.

207	   For example:

209	   m=audio 5000 RTP/AVP 96
210	   a=rtpmap:96 mpeg4-generic/48000/2
211	   a=fmtp:96 streamType=5; profile-level-id=44; mode=AAC-hbr; config=131
212	     056E598; sizeLength=13; indexLength=3; indexDeltaLength=3; constant
213	     Duration=2048; MPS-profile-level-id=55; MPS-config=F1B4CF920442029B
214	     501185B6DA00;

216	   In this example the stream specifies the HE AAC Profile at Level 2
217	   [Profile and Level Indication (PLI) 44] and the config string
218	   contains the hexadecimal representation of the HE AAC ASC
219	   [audioObjectType=2 (AAC LC); extensionAudioObjectType=5 (SBR);
220	   samplingFrequencyIndex=0x6 (24kHz);
221	   extensionSamplingFrequencyIndex=0x3 (48kHz); channelConfiguration=2
222	   (2.0 channels)] of the downmix AAC elementary stream using explicit
223	   backward compatible signaling.

225	   Furthermore, the stream specifies the MPEG Surround Baseline Profile
226	   at Level 3 (PLI55) and the MPS-config string contains the hexadecimal
227	   representation of the MPEG Surround ASC [audioObjectType=30 (MPEG
228	   Surround); samplingFrequencyIndex=0x3 (48kHz); channelConfiguration=6
229	   (5.1 channels); sacPayloadEmbedding=1; SSC=(48 kHz; 32 slots; 525
230	   tree; ResCoding=1; ResBands=[0,13,13,13])].

232	   Note that the a=fmtp line of the example above have been wrapped to
233	   fit the page; it would comprise a single line in the SDP file.

235	4.2.  MPEG Surround Elementary Stream

237	   MPEG Surround SpatialFrame()s can be present in an individual
238	   elementary stream.  This stream complements the stream containing the
239	   downmix audio data, which may be coded by an arbitrary coding scheme.
240	   MPEG Surround elementary streams are packetized as specified in
241	   [RFC3640].  The mode signaled and used for an MPEG Surround
242	   elementary stream MUST be either MPS-hbr or MPS-lbr.  The MPS-hbr
243	   mode SHALL be used when the frame size may exceed 63 bytes, e.g. when
244	   high-bitrate residual coding is in use.

246	   The dependency relationships between the MPEG Surround elementary
247	   stream and the downmix stream are signaled as specified in [RFC5583].

249	   The media clocks of the MPEG Surround elementary stream and the
250	   downmix stream SHALL operate in the same clock domain, i.e. the
251	   clocks are derived from a common clock and MUST NOT drift.  RTCP
252	   sender reports MUST indicate that the stream timestamps are not
253	   drifting, i.e. that a single sender report for each stream is
254	   sufficient to establish unambiguous timing.  The sampling rate of the
255	   MPEG Surround signal and the decoded downmix signal MUST be
256	   identical.

258	   If HE AAC is used as the coding scheme for the downmix, the RTP
259	   clock-rate of the downmix MAY be the sampling rate of the AAC core,
260	   i.e. the clock-rate of the MPEG Surround elementary stream is an
261	   integer multiple of the clock-rate of the downmix stream.

263	   Note that separate RTP streams have different random RTP timestamp
264	   offsets and therefore RTCP MUST be used to synchronize the coded
265	   downmix audio data and the MPEG surround elementary stream.

267	   For example:

269	   a=group:DDP L1 L2

271	   m=audio 5000 RTP/AVP 96
272	   a=rtpmap:96 mpeg4-generic/48000/2
273	   a=fmtp:96 streamType=5; profile-level-id=44; mode=AAC-hbr; config=2B1
274	     18800; sizeLength=13; indexLength=3; indexDeltaLength=3; constantDu
275	     ration=2048
276	   a=mid:L1

278	   m=audio 5002 RTP/AVP 97
279	   a=rtpmap:97 mpeg4-generic/48000/6
280	   a=fmtp:97 streamType=5; profile-level-id=55; mode=MPS-hbr; config=F1B
281	     0CF920460029B601189E79E70; sizeLength=13; indexLength=3;  indexDelt
282	     aLength=3; constantDuration=2048
283	   a=mid:L2
284	   a=depend:97 lay L1:96

286	   In this example the first stream specifies the HE AAC Profile at
287	   Level 2 (PLI44) and the config string contains the hexadecimal
288	   representation of the HE AAC ASC [audioObjectType=2 (AAC LC);
289	   extensionAudioObjectType=5 (SBR); samplingFrequencyIndex=0x6 (24kHz);
290	   extensionSamplingFrequencyIndex=0x3 (48kHz); channelConfiguration=2
291	   (2.0 channels)].

293	   The second stream specifies Baseline MPEG Surround Profile at Level 3
294	   (PLI55) and the config string contains the hexadecimal represenation
295	   of the ASC [AOT=30(MPEG Surround); 48 kHz; 5.1-ch;
296	   sacPayloadEmbedding=0; SSC=(48 kHz; 32 slots; 525 tree; ResCoding=1;
297	   ResBands=[7,7,7,7])]

299	   Note that the a=fmtp lines of the example above have been wrapped to
300	   fit the page; they would comprise each a single line in the SDP file.

302	4.2.1.  Low Bit-rate MPEG Surround

304	   This mode is signaled by mode=MPS-lbr.  This mode supports the
305	   transport of one or more complete Access Units, each consisting of a
306	   single MPEG Surround SpatialFrame().  The AUs can be variably sized
307	   and interleaved.  The maximum size of a SpatialFrame() is 63 bytes.
308	   Fragmentation MUST NOT be used in this mode.  Receivers MUST support
309	   de-interleaving.

311	   The payload configuration is the same as in the AAC-lbr mode.  It
312	   consists of the AU Header Section, followed by concatenated AUs.
313	   Note that Access Units are byte-aligned.  The Auxiliary Section MUST
314	   be empty in the MPS-lbr mode.  The one-octet AU-header MUST provide:

316	   1.  the size of each AAC frame encoded as 6 bits

318	   2.  2 bits index information for computing the sequence (and hence
319	       timing) of each SpatialFrame().

321	   The concatenated AU-header Section MUST be preceded by the 16-bit AU-
322	   header-length field.

324	   In addition to the required Media format parameters, the following
325	   parameters MUST be present with fixed values: sizeLength (fixed value
326	   6), indexLength (fixed value 2) and indexDeltaLength (fixed value 2).
327	   The parameter maxDisplacement MUST be present when interleaving.
328	   SpatialFrame()s always have a fixed duration per AU; the fixed
329	   duration MUST be signaled by the Media format parameter
330	   constantDuration.

332	   The value of the "config" parameter is the hexadecimal representation
333	   of the ASC, as defined in [14496-3] with an AOT of 30 and the
334	   sacPayloadEmbedding flag set to 0.

336	   The "profile-level-id" parameter SHALL contain a valid PLI for MPEG
337	   Surround as specified in [14496-3].

339	4.2.2.  High Bit-rate MPEG Surround

341	   This mode is signaled by mode=MPS-hbr.  This mode supports the
342	   transportation of either one fragment of an Access Unit or one
343	   complete AU or several complete AUs.  Each AU consists of a single
344	   MPEG Surround SpatialFrame().  The AUs can be variably sized and
345	   interleaved.  The maximum size of a SpatialFrame() is 8191 bytes.
346	   Receivers MUST support de-interleaving.

348	   The payload configuration is the same as in the AAC-hbr mode.  It
349	   consists of the AU Header Section, followed by either one
350	   SpatialFrame(), a fragment of a SpatialFrame() or several
351	   concatenated SpatialFrame()s.  Note that Access Units are byte-
352	   aligned.  The Auxiliary Section MUST be empty in the MPS-hbr mode.
353	   The two-octet AU-header MUST provide:

355	   1.  the size of each AAC frame encoded as 13 bits

357	   2.  3 bits index information for computing the sequence (and hence
358	       timing) of each SpatialFrame(), i.e. the AU-Index or AU-Index-
359	       delta field.

361	   Each AU-Index field MUST be coded with the value 0.  The concatenated
362	   AU-header Section MUST be preceded by the 16-bit AU-header-length
363	   field.

365	   In addition to the required Media format parameters, the following
366	   parameters MUST be present with fixed values: sizeLength (fixed value
367	   13), indexLength (fixed value 3) and indexDeltaLength (fixed value
368	   3).  The parameter maxDisplacement MUST be present when interleaving.
369	   SpatialFrame()s always have a fixed duration per AU; the fixed
370	   duration MUST be signaled by the Media format parameter
371	   constantDuration.

373	   The value of the "config" parameter is the hexadecimal representation
374	   of the ASC, as defined in [14496-3] with an AOT of 30 and the
375	   sacPayloadEmbedding flag set to 0.

377	   The "profile-level-id" parameter SHALL contain a valid PLI for MPEG
378	   Surround as specified in [14496-3].

380	5.  IANA Considerations

382	   This memo defines additional optional format parameters to the Media
383	   type "audio" and its subtype "mpeg4-generic".  These parameters SHALL
384	   only be used in combination with the AAC-lbr or AAC-hbr modes (cf.
385	   [RFC3640] section 3.3) of "mpeg4-generic".

387	5.1.  Media Type registration

389	   This memo defines the following additional optional parameters which
390	   SHALL be used if MPEG Surround data is present inside the payload of
391	   an AAC elementary stream.

393	      MPS-profile-level-id: A decimal representation of the MPEG
394	      Surround Profile Level indication as defined in [14496-3].  This
395	      parameter MUST be used in the capability exchange or session
396	      set-up procedure to indicate the MPEG Surround Profile and Level
397	      that the decoder must be capable of in order to decode the stream.

399	      MPS-config: A hexadecimal representation of an octet string that
400	      expresses the AudioSpecificConfig (ASC) as defined in [14496-3]
401	      for MPEG Surround.  The ASC is mapped onto the hexadecimal octet
402	      string in an MSB-first basis.  The AOT in this ASC SHALL have the
403	      value 30.  The SSC inside the ASC MUST have the
404	      sacPayloadEmbedding flag set to 1.

406	5.2.  Registration of Mode Definitions with IANA

408	   This section of this memo requests the registration of the "MPS-hbr"
409	   value and the "MPS-lbr" value for the "mode" parameter of the "mpeg4-
410	   generic" media subtype within the media type "audio".  The "mpeg4-
411	   generic" media subtype is defined in [RFC3640], and [RFC3640] defines
412	   a repository for the "mode" parameter.  This memo registers the modes
413	   "MPS-hbr" and "MPS-lbr" to support MPEG Surround elementary streams.

415	   Media type name:

417	      audio

419	   Subtype name:

421	      mpeg4-generic

423	   Required parameters:

425	      The "mode" parameter is required by [RFC3640].  This memo
426	      specifies the additional modes "MPS-hbr" and "MPS-lbr" in
427	      accordance with [RFC3640].

429	   Optional parameters:

431	      For the modes "AAC-hbr" and "AAC-lbr" this memo specifies the
432	      additional optional parameters "MPS-profile-level-id" and "MPS-
433	      config".  See Section 4.1 for usage details.

435	      Optional parameters for the modes "MPS-hbr" and "MPS-lbr" may be
436	      used as specified in [RFC3640].  The optional parameters "MPS-
437	      profile-level-id" and "MPS-config" SHALL NOT be used for the modes
438	      "MPS-hbr" and "MPS-lbr".

440	5.3.  Usage of SDP

442	   It is assumed that the Media format parameters are conveyed via an
443	   SDP message as specified in [RFC3640], section 4.4.

445	6.  Security Considerations

447	   RTP packets using the payload format defined in this specification
448	   are subject to the security considerations discussed in the RTP
449	   specification [RFC3550], the RTP payload format specification for
450	   MPEG-4 elementary streams [RFC3640] which is extended with this memo,
451	   and in any applicable RTP profile.  The main security considerations
452	   for the RTP packet carrying the RTP payload format defined within
453	   this memo are confidentiality, integrity, and source authenticity.
454	   Confidentiality is achieved by encryption of the RTP payload.
455	   Integrity of the RTP packets is achieved through a suitable
456	   cryptographic integrity protection mechanism.  Such a cryptographic
457	   system may also allow the authentication of the source of the
458	   payload.  A suitable security mechanism for this RTP payload format
459	   should provide confidentiality, integrity protection, and at least
460	   source authentication capable of determining if an RTP packet is from
461	   a member of the RTP session.

463	   The AAC audio codec includes an extension mechanism to transmit extra
464	   data within a stream that is gracefully skipped by decoders that do
465	   not support this extra data.  This covert channel may be used to
466	   transmit unauthorized data in an otherwise valid stream.

468	   Note that the appropriate mechanism to provide security to RTP and
469	   payloads following this memo may vary.  It is dependent on the
470	   application, the transport, and the signaling protocol employed.
471	   Therefore, a single mechanism is not sufficient, although if
472	   suitable, usage of the Secure Real-time Transport Protocol (SRTP)
473	   [RFC3711] is recommended.  Other mechanisms that may be used are
474	   IPsec [RFC4301] and Transport Layer Security (TLS) [RFC5246] (RTP
475	   over TCP); other alternatives may exist.

477	7.  References

479	7.1.  Normative References

481	   [14496-1]  MPEG, "ISO/IEC International Standard 14496-1 - Coding of
482	              audio-visual objects, Part 1 Systems", 2004.

484	   [14496-3]  MPEG, "ISO/IEC International Standard 14496-3 - Coding of
485	              audio-visual objects, Part 3 Audio", 2005.

487	   [23003-1]  MPEG, "ISO/IEC International Standard 23003-1 - MPEG
488	              Surround (MPEG D)", 2007.

490	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
491	              Requirement Levels", BCP 14, RFC 2119, March 1997.

493	   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
494	              Jacobson, "RTP: A Transport Protocol for Real-Time
495	              Applications", STD 64, RFC 3550, July 2003.

497	   [RFC3640]  van der Meer, J., Mackie, D., Swaminathan, V., Singer, D.,
498	              and P. Gentric, "RTP Payload Format for Transport of
499	              MPEG-4 Elementary Streams", RFC 3640, November 2003.

501	   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
502	              Description Protocol", RFC 4566, July 2006.

504	   [RFC5583]  Schierl, T. and S. Wenger, "Signaling Media Decoding
505	              Dependency in the Session Description Protocol (SDP)",
506	              RFC 5583, July 2009.

508	7.2.  Informative References

510	   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
511	              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
512	              RFC 3711, March 2004.

514	   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
515	              Internet Protocol", RFC 4301, December 2005.

517	   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
518	              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

520	Authors' Addresses

522	   Frans de Bont
523	   Philips Electronics
524	   High Tech Campus 5
525	   5656 AE Eindhoven,
526	   NL

528	   Phone: ++31 40 2740234
529	   Email: frans.de.bont@philips.com

531	   Stefan Doehla
532	   Fraunhofer IIS
533	   Am Wolfmantel 33
534	   91058 Erlangen,
535	   DE

537	   Phone: +49 9131 776 6042
538	   Email: stefan.doehla@iis.fraunhofer.de

540	   Malte Schmidt
541	   Dolby Laboratories
542	   Deutschherrnstr. 15-19
543	   90537 Nuernberg,
544	   DE

546	   Phone: +49 911 928 91 42
547	   Email: malte.schmidt@dolby.com
548	   Ralph Sperschneider
549	   Fraunhofer IIS
550	   Am Wolfmantel 33
551	   91058 Erlangen,
552	   DE

554	   Phone: +49 9131 776 6167
555	   Email: ralph.sperschneider@iis.fraunhofer.de