1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
|
<pre>Network Working Group S. Casner
Request for Comments: 4855 Packet Design
Obsoletes: <a href="./rfc3555">3555</a> February 2007
Category: Standards Track
<span class="h1">Media Type Registration of RTP Payload Formats</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document specifies the procedure to register RTP payload formats
as audio, video, or other media subtype names. This is useful in a
text-based format description or control protocol to identify the
type of an RTP transmission.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Terminology ................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Procedure For Registering Media Types for RTP Payload Types .....<a href="#page-2">2</a>
<a href="#section-2.1">2.1</a>. Example Media Type Registration ............................<a href="#page-4">4</a>
<a href="#section-2.2">2.2</a>. Restrictions on Sharing a Subtype Name .....................<a href="#page-5">5</a>
<a href="#section-3">3</a>. Mapping to SDP Parameters .......................................<a href="#page-6">6</a>
<a href="#section-4">4</a>. Changes from <a href="./rfc3555">RFC 3555</a> ...........................................<a href="#page-7">7</a>
<a href="#section-5">5</a>. Security Considerations .........................................<a href="#page-8">8</a>
<a href="#section-6">6</a>. IANA Considerations .............................................<a href="#page-9">9</a>
<a href="#section-7">7</a>. References .....................................................<a href="#page-10">10</a>
<a href="#section-7.1">7.1</a>. Normative References ......................................<a href="#page-10">10</a>
<a href="#section-7.2">7.2</a>. Informative References ....................................<a href="#page-10">10</a>
<span class="grey">Casner Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4855">RFC 4855</a> Media Type Reg. of RTP Payload Formats February 2007</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
<a href="./rfc4288">RFC 4288</a> [<a href="#ref-1" title=""Media Type Specifications and Registration Procedures"">1</a>] defines media type specification and registration
procedures that use the Internet Assigned Numbers Authority (IANA) as
a central registry. That document covers general requirements
independent of particular application environments and transport
modes. This document defines the specific requirements for
registration of media types for use with the Real-time Transport
Protocol (RTP), <a href="./rfc3550">RFC 3550</a> [<a href="#ref-2" title=""RTP: A Transport Protocol for Real-Time Applications"">2</a>], to identify RTP payload formats.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Terminology</span>
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 <a href="./rfc2119">RFC 2119</a> [<a href="#ref-3" title=""Key words for use in RFCs to Indicate Requirement Levels"">3</a>] and
indicate requirement levels for implementations compliant with this
specification.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Procedure For Registering Media Types for RTP Payload Types</span>
Registering an RTP payload type as a media type follows the same
procedures as described in <a href="./rfc4288">RFC 4288</a> [<a href="#ref-1" title=""Media Type Specifications and Registration Procedures"">1</a>] and uses the registration
template shown in <a href="#section-10">Section 10</a> of that RFC. To specify how the
particular payload format is transported over RTP, some additional
information is required in the following sections of that template:
Required parameters:
If the payload format does not have a fixed RTP timestamp
clock rate, then a "rate" parameter is required to specify the
RTP timestamp clock rate. A particular payload format may
have additional required parameters.
Optional parameters:
Most audio payload formats can have an optional "channels"
parameter to specify the number of audio channels included in
the transmission. The default channel order is as specified
in <a href="./rfc3551">RFC 3551</a> [<a href="#ref-4" title=""RTP Profile for Audio and Video Conferences with Minimal Control"">4</a>]. Any payload format, but most likely audio
formats, may also include the optional parameters "ptime" to
specify the recommended length of time in milliseconds
represented by the media in a packet, and/or "maxptime" to
specify the maximum amount of media that can be encapsulated
in each packet, expressed as time in milliseconds. The
"ptime" and "maxptime" parameters are defined in the Session
Description Protocol (SDP) [<a href="#ref-5" title=""SDP: Session Description Protocol"">5</a>].
A particular payload format may have additional optional
parameters. As allowed in Section 4.3 of [<a href="#ref-1" title=""Media Type Specifications and Registration Procedures"">1</a>], new parameters
MAY be added to RTP media types that have been previously
<span class="grey">Casner Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4855">RFC 4855</a> Media Type Reg. of RTP Payload Formats February 2007</span>
defined, but the new parameters MUST NOT change existing
functionality and it MUST be possible for existing
implementations to ignore the additional parameters without
impairing operation.
Encoding considerations:
Most RTP payload formats include binary or framed data as
described in Section 4.8 of [<a href="#ref-1" title=""Media Type Specifications and Registration Procedures"">1</a>]. The appropriate encoding
considerations MUST be noted.
Published specification:
A description of the media encoding and a specification of the
payload format must be provided, usually by reference to an
RTP payload format specification RFC. That RFC may be
separate, or the media type registration may be incorporated
into the payload format specification RFC. The payload format
specification MUST include the RTP timestamp clock rate (or
multiple rates for audio encodings with multiple sampling
rates).
A reference to a further description of the data compression
format itself should be provided, if available.
Restrictions on usage:
The fact that the media type is defined for transfer via RTP
MUST be noted, in particular, if the transfer depends on RTP
framing and hence the media type is only defined for transfer
via RTP.
Depending on whether or not the type has already been registered for
transfer with a non-RTP protocol (e.g., MIME mail or http), several
different cases can occur:
a) Not yet registered as a media type
A new registration should be constructed using the media type
registration template. The registration may specify transfer
via other means in addition to RTP if that is feasible and
desired. The appropriate encoding considerations must be
specified, and the restrictions on usage must specify whether
the type is only defined for transfer via RTP or via other
modes as well.
Optional parameters may be defined as needed, and it must be
clearly stated to which mode(s) of transfer the parameters
apply.
<span class="grey">Casner Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4855">RFC 4855</a> Media Type Reg. of RTP Payload Formats February 2007</span>
b) Media type exists for a non-RTP protocol
The restrictions on usage of the existing type should be
changed, if present, or added, if not, to indicate that the
type can also be transferred via RTP.
RTP-specific parameters may be added, and it must be clearly
stated that these are only to be used when the media type is
transmitted via RTP transport.
c) Update an existing media type for RTP to be used for a non-RTP
protocol
The restrictions on usage of the existing type should be
changed to indicate that the type can also be transferred via a
non-RTP protocol (e.g., SMTP, HTTP).
Non-RTP-specific parameters can be added, and it must be
clearly stated that these are only to be used when the media
type is transmitted via a non-RTP transport.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Example Media Type Registration</span>
The following sample registration of a fake media type audio/example
provides examples for some of the required text. References to RFC
nnnn would be replaced by references to the RFC that contains the
payload format specification and the media type registration.
Type name: audio
Subtype name: example
Required parameters:
rate: RTP timestamp clock rate, which is equal to the sampling
rate. The typical rate is 8000; other rates may be specified.
Optional parameters:
channels: number of interleaved audio streams, either 1 for
mono or 2 for stereo, and defaults to 1 if omitted.
Interleaving takes place between on a frame-by-frame basis,
with the left channel followed by the right channel.
ptime: recommended length of time in milliseconds represented
by the media in a packet (see <a href="./rfc4566">RFC 4566</a>).
maxptime: maximum amount of media that can be encapsulated in
each packet, expressed as time in milliseconds (see <a href="./rfc4566">RFC 4566</a>).
<span class="grey">Casner Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4855">RFC 4855</a> Media Type Reg. of RTP Payload Formats February 2007</span>
Encoding considerations:
This media type is framed binary data (see <a href="./rfc4288#section-4.8">RFC 4288, Section </a>
<a href="#section-4.8">4.8</a>).
Security considerations: See Section n of RFC nnnn
Interoperability considerations:
Some receivers may only be capable of receiving single-channel
audio.
Published specification: RFC nnnn
Applications that use this media type:
Audio and video streaming and conferencing tools.
Additional information: none
Person & email address to contact for further information:
Fred Audio <fred@example.com>
Intended usage: COMMON
Restrictions on usage:
This media type depends on RTP framing, and hence is only
defined for transfer via RTP (<a href="./rfc3550">RFC 3550</a>). Transfer within
other framing protocols is not defined at this time.
Author:
Fred Audio
Change controller:
IETF Audio/Video Transport working group delegated from the
IESG.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Restrictions on Sharing a Subtype Name</span>
The same media subtype name MUST NOT be shared for RTP and non-RTP
(file-based) transfer methods unless the data format is the same for
both methods. The data format is considered to be the same if the
file format is equivalent to a concatenated sequence of payloads from
RTP packets not including the RTP header or any RTP payload-format
header.
The file format MAY include a magic number or other header at the
start of the file that is not included when the data is transferred
via RTP.
<span class="grey">Casner Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4855">RFC 4855</a> Media Type Reg. of RTP Payload Formats February 2007</span>
A second requirement for sharing a media subtype name is that the
sets of required parameters must be the same for both methods.
For cases where the data format or required parameters cannot be the
same for RTP and non-RTP transfer methods, the data formats MUST be
registered as separate types. It is RECOMMENDED that the subtype
names be related, such as by using a common root plus a suffix. For
those cases where a suffix is applied in the subtype name for the RTP
transfer method, the suffix "+rtp" is suggested.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Mapping to SDP Parameters</span>
The representation of a media type is specified in the syntax of the
Content-Type header field in <a href="./rfc2045">RFC 2045</a> [<a href="#ref-6" title=""Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies"">6</a>] as follows:
type "/" subtype *(";" parameter)
Parameters may be required for a particular type or subtype or they
may be optional. For media types that represent RTP payload formats,
the parameters "rate", "channels", "ptime", and "maxptime" have
general definitions (given above) that may apply across types and
subtypes. The format for a parameter is specified in <a href="./rfc2045">RFC 2045</a> as
attribute "=" value
where attribute is the parameter name and the permissible values are
specified for each parameter. <a href="./rfc2045">RFC 2045</a> specifies that a value MUST
be present and that the value MUST be a quoted string if it contains
any of the special characters listed in that RFC.
The information carried in the media type string has a specific
mapping to fields in the Session Description Protocol (SDP) [<a href="#ref-5" title=""SDP: Session Description Protocol"">5</a>],
which is commonly used to describe RTP sessions. The mapping is as
follows:
o The media type (e.g., audio) goes in SDP "m=" as the media
name.
o The media subtype (payload format) goes in SDP "a=rtpmap" as
the encoding name.
o The general (possibly optional) parameters "rate" and
"channels" also go in "a=rtpmap" as clock rate and encoding
parameters, respectively.
o The general (and optional) parameters "ptime" and "maxptime" go
in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
<span class="grey">Casner Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4855">RFC 4855</a> Media Type Reg. of RTP Payload Formats February 2007</span>
o Any payload-format-specific parameters go in the SDP "a=fmtp"
attribute. The set of allowed parameters is defined by the RFC
that specifies the payload format and MUST NOT be extended by
the media type registration without a corresponding revision of
the payload format specification. The format and syntax of
these parameters may also be defined by the payload format
specification, but it is suggested that the parameters be
copied directly from the media type string as a semicolon
separated list of parameter=value pairs. For payload formats
that specify some other syntax for the fmtp parameters, the
registration of that payload format as a media type must
specify what the parameters are in MIME format and how to map
them to the "a=fmtp" attribute.
An example mapping is as follows:
audio/L16; rate=48000; channels=2; ptime=5; emphasis=50-15
m=audio 49170 RTP/AVP 97
a=rtpmap:97 L16/48000/2
a=fmtp:97 emphasis=50-15
a=ptime:5
Note that the payload format (encoding) names defined in the RTP
Profile [<a href="#ref-4" title=""RTP Profile for Audio and Video Conferences with Minimal Control"">4</a>] are commonly shown in upper case. Media subtype names
are commonly shown in lower case. These names are case-insensitive
in both places. Similarly, parameter names are case-insensitive both
in media type strings and in the default mapping to the SDP a=fmtp
attribute.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Changes from <a href="./rfc3555">RFC 3555</a></span>
This document updates <a href="./rfc3555">RFC 3555</a> to conform to the revised media type
registration procedures in <a href="./rfc4288">RFC 4288</a> [<a href="#ref-1" title=""Media Type Specifications and Registration Procedures"">1</a>]. Whereas <a href="./rfc3555">RFC 3555</a> required
the encoding considerations to specify transfer via RTP, that is now
specified under restrictions on usage. This document also specifies
the conditions under which new optional parameters may be added to a
previously defined RTP media type and adds a new <a href="#section-2.2">Section 2.2</a> to
clarify the requirements for sharing a media type among RTP and non-
RTP transfer methods.
<a href="./rfc3555">RFC 3555</a> included media type registrations for the RTP payload
formats defined in the RTP Profile for Audio and Video Conferences,
<a href="./rfc3551">RFC 3551</a> [<a href="#ref-4" title=""RTP Profile for Audio and Video Conferences with Minimal Control"">4</a>]. Those media type registrations have been removed from
this document. Some of them have been assembled into a separate
companion <a href="./rfc4856">RFC 4856</a> [<a href="#ref-8" title=""Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences"">8</a>], leaving out those that have been, or are
intended to be, registered in revisions of their own payload format
specification RFCs.
<span class="grey">Casner Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4855">RFC 4855</a> Media Type Reg. of RTP Payload Formats February 2007</span>
Philipp Hoschka is a co-author of <a href="./rfc3555">RFC 3555</a>; his contributions to the
foundation of this document are appreciated.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
The media type registration procedure specified in this memo does not
impose any security considerations on its own. Also, registrations
conforming to this procedure do not themselves impose security risks.
However, use of the media type being registered could very well
impose security risks:
o Any media type that contains "active content" imposes the risk
of malicious side-effects unless execution of that content is
adequately constrained.
o Several audio and video encodings are perfect for hiding data
using steganography.
o The RTP specification, <a href="./rfc3550">RFC 3550</a>, provides security
considerations for the transport of audio and video data over
RTP, including the use of encryption where confidentiality is
required.
Therefore, each media type registration is required to state any
security considerations that apply to the use of that type. The
remainder of this section is copied from <a href="./rfc4288">RFC 4288</a> [<a href="#ref-1" title=""Media Type Specifications and Registration Procedures"">1</a>], which
specifies media type registration procedures in general.
An analysis of security issues MUST be done for all types registered
in the standards tree. A similar analysis for media types registered
in the vendor or personal trees is encouraged but not required.
However, regardless of what security analysis has or has not been
done, all descriptions of security issues MUST be as accurate as
possible regardless of registration tree. In particular, a statement
that there are "no security issues associated with this type" MUST
NOT be confused with "the security issues associated with this type
have not been assessed".
There is absolutely no requirement that media types registered in any
tree be secure or completely free from risks. Nevertheless, all
known security risks MUST be identified in the registration of a
media type, again regardless of registration tree.
The security considerations section of all registrations is subject
to continuing evaluation and modification, and in particular MAY be
extended by use of the "comments on media types" mechanism described
in <a href="./rfc4288#section-6">RFC 4288, Section 6</a>.
<span class="grey">Casner Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4855">RFC 4855</a> Media Type Reg. of RTP Payload Formats February 2007</span>
Some of the issues that should be looked at in a security analysis of
a media type are:
o Complex media types may include provisions for directives that
institute actions on a recipient's files or other resources.
In many cases, provision is made for originators to specify
arbitrary actions in an unrestricted fashion that may then have
devastating effects. See the registration of the
application/postscript media type in <a href="./rfc2046">RFC 2046</a> [<a href="#ref-7" title=""Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types"">7</a>] for an
example of such directives and how they should be described in
a media type registration.
o All registrations MUST state whether or not they employ such
"active content", and if they do, they MUST state what steps
have been taken to protect users of the media type from harm.
o Complex media types may include provisions for directives that
institute actions that, while not directly harmful to the
recipient, may result in disclosure of information that either
facilitates a subsequent attack or else violates a recipient's
privacy in some way. Again, the registration of the
application/postscript media type illustrates how such
directives can be handled.
o A media type that employs compression may provide an
opportunity for sending a small amount of data that, when
received and evaluated, expands enormously to consume all of
the recipient's resources. All media types SHOULD state
whether or not they employ compression, and if they do they
should discuss what steps need to be taken to avoid such
attacks.
o A media type might be targeted for applications that require
some sort of security assurance but not provide the necessary
security mechanisms themselves. For example, a media type
could be defined for storage of confidential medical
information that in turn requires an external confidentiality
service or is designed for use only within a secure
environment.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
The purpose of this document is to specify the requirements and
procedures for registering RTP payload formats in the IANA media type
registry. No registrations are defined here.
<span class="grey">Casner Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4855">RFC 4855</a> Media Type Reg. of RTP Payload Formats February 2007</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-1">1</a>] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", <a href="https://www.rfc-editor.org/bcp/bcp13">BCP 13</a>, <a href="./rfc4288">RFC 4288</a>, December, 2005.
[<a id="ref-2">2</a>] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
A Transport Protocol for Real-Time Applications", <a href="./rfc3550">RFC 3550</a>, July
2003.
[<a id="ref-3">3</a>] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-4">4</a>] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", <a href="./rfc3551">RFC 3551</a>, July 2003.
[<a id="ref-5">5</a>] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", <a href="./rfc4566">RFC 4566</a>, July 2006.
[<a id="ref-6">6</a>] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
<a href="./rfc2045">RFC 2045</a>, November 1996.
[<a id="ref-7">7</a>] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", <a href="./rfc2046">RFC 2046</a>, November
1996.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-8">8</a>] Casner, S., "Media Type Registration of Payload Formats in the
RTP Profile for Audio and Video Conferences", <a href="./rfc4856">RFC 4856</a>, February
2007.
Author's Address
Stephen L. Casner
Packet Design
3400 Hillview Avenue, Building 3
Palo Alto, CA 94304
United States
Phone: +1 650 739-1843
EMail: casner@acm.org
<span class="grey">Casner Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4855">RFC 4855</a> Media Type Reg. of RTP Payload Formats February 2007</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Casner Standards Track [Page 11]
</pre>
|
