1 2 3 4 5 6 7 Network Working Group L. Barbato 8 Request for Comments: 5215 Xiph 9 Category: Standards Track August 2008 10 11 12 RTP Payload Format for Vorbis Encoded Audio 13 14 Status of This Memo 15 16 This document specifies an Internet standards track protocol for the 17 Internet community, and requests discussion and suggestions for 18 improvements. Please refer to the current edition of the "Internet 19 Official Protocol Standards" (STD 1) for the standardization state 20 and status of this protocol. Distribution of this memo is unlimited. 21 22 Abstract 23 24 This document describes an RTP payload format for transporting Vorbis 25 encoded audio. It details the RTP encapsulation mechanism for raw 26 Vorbis data and the delivery mechanisms for the decoder probability 27 model (referred to as a codebook), as well as other setup 28 information. 29 30 Also included within this memo are media type registrations and the 31 details necessary for the use of Vorbis with the Session Description 32 Protocol (SDP). 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 Barbato Standards Track [Page 1] 59 61 RFC 5215 Vorbis RTP Payload Format August 2008 62 63 64 Table of Contents 65 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Conformance and Document Conventions . . . . . . . . . . . 3 68 2. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2.1. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 5 71 2.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6 72 2.4. Example RTP Packet . . . . . . . . . . . . . . . . . . . . 8 73 3. Configuration Headers . . . . . . . . . . . . . . . . . . . . 8 74 3.1. In-band Header Transmission . . . . . . . . . . . . . . . 9 75 3.1.1. Packed Configuration . . . . . . . . . . . . . . . . . 10 76 3.2. Out of Band Transmission . . . . . . . . . . . . . . . . . 12 77 3.2.1. Packed Headers . . . . . . . . . . . . . . . . . . . . 12 78 3.3. Loss of Configuration Headers . . . . . . . . . . . . . . 13 79 4. Comment Headers . . . . . . . . . . . . . . . . . . . . . . . 13 80 5. Frame Packetization . . . . . . . . . . . . . . . . . . . . . 14 81 5.1. Example Fragmented Vorbis Packet . . . . . . . . . . . . . 15 82 5.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 17 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 84 6.1. Packed Headers IANA Considerations . . . . . . . . . . . . 19 85 7. SDP Related Considerations . . . . . . . . . . . . . . . . . . 20 86 7.1. Mapping Media Type Parameters into SDP . . . . . . . . . . 20 87 7.1.1. SDP Example . . . . . . . . . . . . . . . . . . . . . 21 88 7.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 22 89 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 22 90 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 9.1. Stream Radio . . . . . . . . . . . . . . . . . . . . . . . 22 92 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 93 11. Copying Conditions . . . . . . . . . . . . . . . . . . . . . . 23 94 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 95 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 13.1. Normative References . . . . . . . . . . . . . . . . . . . 24 97 13.2. Informative References . . . . . . . . . . . . . . . . . . 25 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 Barbato Standards Track [Page 2] 116 118 RFC 5215 Vorbis RTP Payload Format August 2008 119 120 121 1. Introduction 122 123 Vorbis is a general purpose perceptual audio codec intended to allow 124 maximum encoder flexibility, thus allowing it to scale competitively 125 over an exceptionally wide range of bit rates. At the high quality/ 126 bitrate end of the scale (CD or DAT rate stereo, 16/24 bits), it is 127 in the same league as MPEG-4 AAC. Vorbis is also intended for lower 128 and higher sample rates (from 8kHz telephony to 192kHz digital 129 masters) and a range of channel representations (monaural, 130 polyphonic, stereo, quadraphonic, 5.1, ambisonic, or up to 255 131 discrete channels). 132 133 Vorbis encoded audio is generally encapsulated within an Ogg format 134 bitstream [RFC3533], which provides framing and synchronization. For 135 the purposes of RTP transport, this layer is unnecessary, and so raw 136 Vorbis packets are used in the payload. 137 138 1.1. Conformance and Document Conventions 139 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in BCP 14, [RFC2119] and 143 indicate requirement levels for compliant implementations. 144 Requirements apply to all implementations unless otherwise stated. 145 146 An implementation is a software module that supports one of the media 147 types defined in this document. Software modules may support 148 multiple media types, but conformance is considered individually for 149 each type. 150 151 Implementations that fail to satisfy one or more "MUST" requirements 152 are considered non-compliant. Implementations that satisfy all 153 "MUST" requirements, but fail to satisfy one or more "SHOULD" 154 requirements, are said to be "conditionally compliant". All other 155 implementations are "unconditionally compliant". 156 157 2. Payload Format 158 159 For RTP-based transport of Vorbis-encoded audio, the standard RTP 160 header is followed by a 4-octet payload header, and then the payload 161 data. The payload headers are used to associate the Vorbis data with 162 its associated decoding codebooks as well as indicate if the 163 following packet contains fragmented Vorbis data and/or the number of 164 whole Vorbis data frames. The payload data contains the raw Vorbis 165 bitstream information. There are 3 types of Vorbis data; an RTP 166 payload MUST contain just one of them at a time. 167 168 169 170 171 172 Barbato Standards Track [Page 3] 173 175 RFC 5215 Vorbis RTP Payload Format August 2008 176 177 178 2.1. RTP Header 179 180 The format of the RTP header is specified in [RFC3550] and shown in 181 Figure 1. This payload format uses the fields of the header in a 182 manner consistent with that specification. 183 184 0 1 2 3 185 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 |V=2|P|X| CC |M| PT | sequence number | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | timestamp | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | synchronization source (SSRC) identifier | 192 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 193 | contributing source (CSRC) identifiers | 194 | ... | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 197 Figure 1: RTP Header 198 199 The RTP header begins with an octet of fields (V, P, X, and CC) to 200 support specialized RTP uses (see [RFC3550] and [RFC3551] for 201 details). For Vorbis RTP, the following values are used. 202 203 Version (V): 2 bits 204 205 This field identifies the version of RTP. The version used by this 206 specification is two (2). 207 208 Padding (P): 1 bit 209 210 Padding MAY be used with this payload format according to Section 5.1 211 of [RFC3550]. 212 213 Extension (X): 1 bit 214 215 The Extension bit is used in accordance with [RFC3550]. 216 217 CSRC count (CC): 4 bits 218 219 The CSRC count is used in accordance with [RFC3550]. 220 221 Marker (M): 1 bit 222 223 Set to zero. Audio silence suppression is not used. This conforms 224 to Section 4.1 of [VORBIS-SPEC-REF]. 225 226 227 228 229 Barbato Standards Track [Page 4] 230 232 RFC 5215 Vorbis RTP Payload Format August 2008 233 234 235 Payload Type (PT): 7 bits 236 237 An RTP profile for a class of applications is expected to assign a 238 payload type for this format, or a dynamically allocated payload type 239 SHOULD be chosen that designates the payload as Vorbis. 240 241 Sequence number: 16 bits 242 243 The sequence number increments by one for each RTP data packet sent, 244 and may be used by the receiver to detect packet loss and to restore 245 the packet sequence. This field is detailed further in [RFC3550]. 246 247 Timestamp: 32 bits 248 249 A timestamp representing the sampling time of the first sample of the 250 first Vorbis packet in the RTP payload. The clock frequency MUST be 251 set to the sample rate of the encoded audio data and is conveyed out- 252 of-band (e.g., as an SDP parameter). 253 254 SSRC/CSRC identifiers: 255 256 These two fields, 32 bits each with one SSRC field and a maximum of 257 16 CSRC fields, are as defined in [RFC3550]. 258 259 2.2. Payload Header 260 261 The 4 octets following the RTP Header section are the Payload Header. 262 This header is split into a number of bit fields detailing the format 263 of the following payload data packets. 264 265 0 1 2 3 266 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Ident | F |VDT|# pkts.| 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 271 Figure 2: Payload Header 272 273 Ident: 24 bits 274 275 This 24-bit field is used to associate the Vorbis data to a decoding 276 Configuration. It is stored as a network byte order integer. 277 278 Fragment type (F): 2 bits 279 280 281 282 283 284 285 286 Barbato Standards Track [Page 5] 287 289 RFC 5215 Vorbis RTP Payload Format August 2008 290 291 292 This field is set according to the following list: 293 294 0 = Not Fragmented 295 296 1 = Start Fragment 297 298 2 = Continuation Fragment 299 300 3 = End Fragment 301 302 Vorbis Data Type (VDT): 2 bits 303 304 This field specifies the kind of Vorbis data stored in this RTP 305 packet. There are currently three different types of Vorbis 306 payloads. Each packet MUST contain only a single type of Vorbis 307 packet (e.g., you must not aggregate configuration and comment 308 packets in the same RTP payload). 309 310 0 = Raw Vorbis payload 311 312 1 = Vorbis Packed Configuration payload 313 314 2 = Legacy Vorbis Comment payload 315 316 3 = Reserved 317 318 The packets with a VDT of value 3 MUST be ignored. 319 320 The last 4 bits represent the number of complete packets in this 321 payload. This provides for a maximum number of 15 Vorbis packets in 322 the payload. If the payload contains fragmented data, the number of 323 packets MUST be set to 0. 324 325 2.3. Payload Data 326 327 Raw Vorbis packets are currently unbounded in length; application 328 profiles will likely define a practical limit. Typical Vorbis packet 329 sizes range from very small (2-3 bytes) to quite large (8-12 330 kilobytes). The reference implementation [LIBVORBIS] typically 331 produces packets less than ~800 bytes, except for the setup header 332 packets, which are ~4-12 kilobytes. Within an RTP context, to avoid 333 fragmentation, the Vorbis data packet size SHOULD be kept 334 sufficiently small so that after adding the RTP and payload headers, 335 the complete RTP packet is smaller than the path MTU. 336 337 338 339 340 341 342 343 Barbato Standards Track [Page 6] 344 346 RFC 5215 Vorbis RTP Payload Format August 2008 347 348 349 0 1 2 3 350 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | length | vorbis packet data .. 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 355 Figure 3: Payload Data Header 356 357 Each Vorbis payload packet starts with a two octet length header, 358 which is used to represent the size in bytes of the following data 359 payload, and is followed by the raw Vorbis data padded to the nearest 360 byte boundary, as explained by the Vorbis I Specification 361 [VORBIS-SPEC-REF]. The length value is stored as a network byte 362 order integer. 363 364 For payloads that consist of multiple Vorbis packets, the payload 365 data consists of the packet length followed by the packet data for 366 each of the Vorbis packets in the payload. 367 368 The Vorbis packet length header is the length of the Vorbis data 369 block only and does not include the length field. 370 371 The payload packing of the Vorbis data packets MUST follow the 372 guidelines set out in [RFC3551], where the oldest Vorbis packet 373 occurs immediately after the RTP packet header. Subsequent Vorbis 374 packets, if any, MUST follow in temporal order. 375 376 Audio channel mapping is in accordance with the Vorbis I 377 Specification [VORBIS-SPEC-REF]. 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 Barbato Standards Track [Page 7] 401 403 RFC 5215 Vorbis RTP Payload Format August 2008 404 405 406 2.4. Example RTP Packet 407 408 Here is an example RTP payload containing two Vorbis packets. 409 410 0 1 2 3 411 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | 2 |0|0| 0 |0| PT | sequence number | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | timestamp (in sample rate units) | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | synchronisation source (SSRC) identifier | 418 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 419 | contributing source (CSRC) identifiers | 420 | ... | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Ident | 0 | 0 | 2 pks | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | length | vorbis data .. 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 .. vorbis data | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | length | next vorbis packet data .. 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 .. vorbis data .. 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 .. vorbis data | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 436 Figure 4: Example Raw Vorbis Packet 437 438 The payload data section of the RTP packet begins with the 24-bit 439 Ident field followed by the one octet bit field header, which has the 440 number of Vorbis frames set to 2. Each of the Vorbis data frames is 441 prefixed by the two octets length field. The Packet Type and 442 Fragment Type are set to 0. The Configuration that will be used to 443 decode the packets is the one indexed by the ident value. 444 445 3. Configuration Headers 446 447 Unlike other mainstream audio codecs, Vorbis has no statically 448 configured probability model. Instead, it packs all entropy decoding 449 configuration, Vector Quantization and Huffman models into a data 450 block that must be transmitted to the decoder with the compressed 451 data. A decoder also requires information detailing the number of 452 audio channels, bitrates, and similar information to configure itself 453 for a particular compressed data stream. These two blocks of 454 455 456 457 Barbato Standards Track [Page 8] 458 460 RFC 5215 Vorbis RTP Payload Format August 2008 461 462 463 information are often referred to collectively as the "codebooks" for 464 a Vorbis stream, and are included as special "header" packets at the 465 start of the compressed data. In addition, the Vorbis I 466 specification [VORBIS-SPEC-REF] requires the presence of a comment 467 header packet that gives simple metadata about the stream, but this 468 information is not required for decoding the frame sequence. 469 470 Thus, these two codebook header packets must be received by the 471 decoder before any audio data can be interpreted. These requirements 472 pose problems in RTP, which is often used over unreliable transports. 473 474 Since this information must be transmitted reliably and, as the RTP 475 stream may change certain configuration data mid-session, there are 476 different methods for delivering this configuration data to a client, 477 both in-band and out-of-band, which are detailed below. In order to 478 set up an initial state for the client application, the configuration 479 MUST be conveyed via the signalling channel used to set up the 480 session. One example of such signalling is SDP [RFC4566] with the 481 Offer/Answer Model [RFC3264]. Changes to the configuration MAY be 482 communicated via a re-invite, conveying a new SDP, or sent in-band in 483 the RTP channel. Implementations MUST support an in-band delivery of 484 updated codebooks, and SHOULD support out-of-band codebook update 485 using a new SDP file. The changes may be due to different codebooks 486 as well as different bitrates of the RTP stream. 487 488 For non-chained streams, the recommended Configuration delivery 489 method is inside the Packed Configuration (Section 3.1.1) in the SDP 490 as explained the Mapping Media Type Parameters into SDP 491 (Section 7.1). 492 493 The 24-bit Ident field is used to map which Configuration will be 494 used to decode a packet. When the Ident field changes, it indicates 495 that a change in the stream has taken place. The client application 496 MUST have in advance the correct configuration. If the client 497 detects a change in the Ident value and does not have this 498 information, it MUST NOT decode the raw associated Vorbis data until 499 it fetches the correct Configuration. 500 501 3.1. In-band Header Transmission 502 503 The Packed Configuration (Section 3.1.1) Payload is sent in-band with 504 the packet type bits set to match the Vorbis Data Type. Clients MUST 505 be capable of dealing with fragmentation and periodic re-transmission 506 of [RFC4588] the configuration headers. The RTP timestamp value MUST 507 reflect the transmission time of the first data packet for which this 508 configuration applies. 509 510 511 512 513 514 Barbato Standards Track [Page 9] 515 517 RFC 5215 Vorbis RTP Payload Format August 2008 518 519 520 3.1.1. Packed Configuration 521 522 A Vorbis Packed Configuration is indicated with the Vorbis Data Type 523 field set to 1. Of the three headers defined in the Vorbis I 524 specification [VORBIS-SPEC-REF], the Identification and the Setup 525 MUST be packed as they are, while the Comment header MAY be replaced 526 with a dummy one. 527 528 The packed configuration stores Xiph codec configurations in a 529 generic way: the first field stores the number of the following 530 packets minus one (count field), the next ones represent the size of 531 the headers (length fields), and the headers immediately follow the 532 list of length fields. The size of the last header is implicit. 533 534 The count and the length fields are encoded using the following 535 logic: the data is in network byte order; every byte has the most 536 significant bit used as a flag, and the following 7 bits are used to 537 store the value. The first 7 most significant bits are stored in the 538 first byte. If there are remaining bits, the flag bit is set to 1 539 and the subsequent 7 bits are stored in the following byte. If there 540 are remaining bits, set the flag to 1 and the same procedure is 541 repeated. The ending byte has the flag bit set to 0. To decode, 542 simply iterate over the bytes until the flag bit is set to 0. For 543 every byte, the data is added to the accumulated value multiplied by 544 128. 545 546 The headers are packed in the same order as they are present in Ogg 547 [VORBIS-SPEC-REF]: Identification, Comment, Setup. 548 549 The 2 byte length tag defines the length of the packed headers as the 550 sum of the Configuration, Comment, and Setup lengths. 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 Barbato Standards Track [Page 10] 572 574 RFC 5215 Vorbis RTP Payload Format August 2008 575 576 577 0 1 2 3 578 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 |V=2|P|X| CC |M| PT | xxxx | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | xxxxx | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | synchronization source (SSRC) identifier | 585 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 586 | contributing source (CSRC) identifiers | 587 | ... | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Ident | 0 | 1 | 1| 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | length | n. of headers | length1 | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | length2 | Identification .. 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 .. Identification .. 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 .. Identification .. 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 .. Identification .. 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 .. Identification | Comment .. 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 .. Comment .. 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 .. Comment .. 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 .. Comment .. 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 .. Comment | Setup .. 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 .. Setup .. 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 .. Setup .. 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 617 Figure 5: Packed Configuration Figure 618 619 The Ident field is set with the value that will be used by the Raw 620 Payload Packets to address this Configuration. The Fragment type is 621 set to 0 because the packet bears the full Packed configuration. The 622 number of the packet is set to 1. 623 624 625 626 627 628 Barbato Standards Track [Page 11] 629 631 RFC 5215 Vorbis RTP Payload Format August 2008 632 633 634 3.2. Out of Band Transmission 635 636 The following packet definition MUST be used when Configuration is 637 inside in the SDP. 638 639 3.2.1. Packed Headers 640 641 As mentioned above, the RECOMMENDED delivery vector for Vorbis 642 configuration data is via a retrieval method that can be performed 643 using a reliable transport protocol. As the RTP headers are not 644 required for this method of delivery, the structure of the 645 configuration data is slightly different. The packed header starts 646 with a 32-bit (network-byte ordered) count field, which details the 647 number of packed headers that are contained in the bundle. The 648 following shows the Packed header payload for each chained Vorbis 649 stream. 650 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Number of packed headers | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Packed header | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | Packed header | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 661 Figure 6: Packed Headers Overview 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 Barbato Standards Track [Page 12] 686 688 RFC 5215 Vorbis RTP Payload Format August 2008 689 690 691 0 1 2 3 692 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Ident | length .. 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 .. | n. of headers | length1 | length2 .. 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 .. | Identification Header .. 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 ................................................................. 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 .. | Comment Header .. 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 ................................................................. 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 .. Comment Header | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Setup Header .. 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 ................................................................. 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 .. Setup Header | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 715 Figure 7: Packed Headers Detail 716 717 The key difference between the in-band format and this one is that 718 there is no need for the payload header octet. In this figure, the 719 comment has a size bigger than 127 bytes. 720 721 3.3. Loss of Configuration Headers 722 723 Unlike the loss of raw Vorbis payload data, loss of a configuration 724 header leads to a situation where it will not be possible to 725 successfully decode the stream. Implementations MAY try to recover 726 from an error by requesting again the missing Configuration or, if 727 the delivery method is in-band, by buffering the payloads waiting for 728 the Configuration needed to decode them. The baseline reaction 729 SHOULD either be reset or end the RTP session. 730 731 4. Comment Headers 732 733 Vorbis Data Type flag set to 2 indicates that the packet contains the 734 comment metadata, such as artist name, track title, and so on. These 735 metadata messages are not intended to be fully descriptive but rather 736 to offer basic track/song information. Clients MAY ignore it 737 completely. The details on the format of the comments can be found 738 in the Vorbis I Specification [VORBIS-SPEC-REF]. 739 740 741 742 Barbato Standards Track [Page 13] 743 745 RFC 5215 Vorbis RTP Payload Format August 2008 746 747 748 0 1 2 3 749 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 |V=2|P|X| CC |M| PT | xxxx | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | xxxxx | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | synchronization source (SSRC) identifier | 756 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 757 | contributing source (CSRC) identifiers | 758 | ... | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Ident | 0 | 2 | 1| 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | length | Comment .. 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 .. Comment .. 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 .. Comment | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 770 Figure 8: Comment Packet 771 772 The 2-byte length field is necessary since this packet could be 773 fragmented. 774 775 5. Frame Packetization 776 777 Each RTP payload contains either one Vorbis packet fragment or an 778 integer number of complete Vorbis packets (up to a maximum of 15 779 packets, since the number of packets is defined by a 4-bit value). 780 781 Any Vorbis data packet that is less than path MTU SHOULD be bundled 782 in the RTP payload with as many Vorbis packets as will fit, up to a 783 maximum of 15, except when such bundling would exceed an 784 application's desired transmission latency. Path MTU is detailed in 785 [RFC1191] and [RFC1981]. 786 787 A fragmented packet has a zero in the last four bits of the payload 788 header. The first fragment will set the Fragment type to 1. Each 789 fragment after the first will set the Fragment type to 2 in the 790 payload header. The consecutive fragments MUST be sent without any 791 other payload being sent between the first and the last fragment. 792 The RTP payload containing the last fragment of the Vorbis packet 793 will have the Fragment type set to 3. To maintain the correct 794 sequence for fragmented packet reception, the timestamp field of 795 fragmented packets MUST be the same as the first packet sent, with 796 797 798 799 Barbato Standards Track [Page 14] 800 802 RFC 5215 Vorbis RTP Payload Format August 2008 803 804 805 the sequence number incremented as normal for the subsequent RTP 806 payloads; this will affect the RTCP jitter measurement. The length 807 field shows the fragment length. 808 809 5.1. Example Fragmented Vorbis Packet 810 811 Here is an example of a fragmented Vorbis packet split over three RTP 812 payloads. Each of them contains the standard RTP headers as well as 813 the 4-octet Vorbis headers. 814 815 Packet 1: 816 817 0 1 2 3 818 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 |V=2|P|X| CC |M| PT | 1000 | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | 12345 | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | synchronization source (SSRC) identifier | 825 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 826 | contributing source (CSRC) identifiers | 827 | ... | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | Ident | 1 | 0 | 0| 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | length | vorbis data .. 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 .. vorbis data | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 837 Figure 9: Example Fragmented Packet (Packet 1) 838 839 In this payload, the initial sequence number is 1000 and the 840 timestamp is 12345. The Fragment type is set to 1, the number of 841 packets field is set to 0, and as the payload is raw Vorbis data, the 842 VDT field is set to 0. 843 844 845 846 847 848 849 850 851 852 853 854 855 856 Barbato Standards Track [Page 15] 857 859 RFC 5215 Vorbis RTP Payload Format August 2008 860 861 862 Packet 2: 863 864 0 1 2 3 865 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 |V=2|P|X| CC |M| PT | 1001 | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | 12345 | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | synchronization source (SSRC) identifier | 872 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 873 | contributing source (CSRC) identifiers | 874 | ... | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Ident | 2 | 0 | 0| 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | length | vorbis data .. 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 .. vorbis data | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 884 Figure 10: Example Fragmented Packet (Packet 2) 885 886 The Fragment type field is set to 2, and the number of packets field 887 is set to 0. For large Vorbis fragments, there can be several of 888 these types of payloads. The maximum packet size SHOULD be no 889 greater than the path MTU, including all RTP and payload headers. 890 The sequence number has been incremented by one, but the timestamp 891 field remains the same as the initial payload. 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 Barbato Standards Track [Page 16] 914 916 RFC 5215 Vorbis RTP Payload Format August 2008 917 918 919 Packet 3: 920 921 0 1 2 3 922 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 |V=2|P|X| CC |M| PT | 1002 | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | 12345 | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | synchronization source (SSRC) identifier | 929 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 930 | contributing source (CSRC) identifiers | 931 | ... | 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Ident | 3 | 0 | 0| 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | length | vorbis data .. 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 .. vorbis data | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 941 Figure 11: Example Fragmented Packet (Packet 3) 942 943 This is the last Vorbis fragment payload. The Fragment type is set 944 to 3 and the packet count remains set to 0. As in the previous 945 payloads, the timestamp remains set to the first payload timestamp in 946 the sequence and the sequence number has been incremented. 947 948 5.2. Packet Loss 949 950 As there is no error correction within the Vorbis stream, packet loss 951 will result in a loss of signal. Packet loss is more of an issue for 952 fragmented Vorbis packets as the client will have to cope with the 953 handling of the Fragment Type. In case of loss of fragments, the 954 client MUST discard all the remaining Vorbis fragments and decode the 955 incomplete packet. If we use the fragmented Vorbis packet example 956 above and the first RTP payload is lost, the client MUST detect that 957 the next RTP payload has the packet count field set to 0 and the 958 Fragment type 2 and MUST drop it. The next RTP payload, which is the 959 final fragmented packet, MUST be dropped in the same manner. If the 960 missing RTP payload is the last, the two fragments received will be 961 kept and the incomplete Vorbis packet decoded. 962 963 Loss of any of the Configuration fragment will result in the loss of 964 the full Configuration packet with the result detailed in the Loss of 965 Configuration Headers (Section 3.3) section. 966 967 968 969 970 Barbato Standards Track [Page 17] 971 973 RFC 5215 Vorbis RTP Payload Format August 2008 974 975 976 6. IANA Considerations 977 978 Type name: audio 979 980 Subtype name: vorbis 981 982 Required parameters: 983 984 rate: indicates the RTP timestamp clock rate as described in RTP 985 Profile for Audio and Video Conferences with Minimal Control 986 [RFC3551]. 987 988 channels: indicates the number of audio channels as described in 989 RTP Profile for Audio and Video Conferences with Minimal 990 Control [RFC3551]. 991 992 configuration: the base64 [RFC4648] representation of the Packed 993 Headers (Section 3.2.1). 994 995 Encoding considerations: 996 997 This media type is framed and contains binary data. 998 999 Security considerations: 1000 1001 See Section 10 of RFC 5215. 1002 1003 Interoperability considerations: 1004 1005 None 1006 1007 Published specification: 1008 1009 RFC 5215 1010 1011 Ogg Vorbis I specification: Codec setup and packet decode. 1012 Available from the Xiph website, http://xiph.org/ 1013 1014 Applications which use this media type: 1015 1016 Audio streaming and conferencing tools 1017 1018 Additional information: 1019 1020 None 1021 1022 1023 1024 1025 1026 1027 Barbato Standards Track [Page 18] 1028 1030 RFC 5215 Vorbis RTP Payload Format August 2008 1031 1032 1033 Person & email address to contact for further information: 1034 1035 Luca Barbato: <lu_zero (a] gentoo.org> 1036 IETF Audio/Video Transport Working Group 1037 1038 Intended usage: 1039 1040 COMMON 1041 1042 Restriction on usage: 1043 1044 This media type depends on RTP framing, hence is only defined for 1045 transfer via RTP [RFC3550]. 1046 1047 Author: 1048 1049 Luca Barbato 1050 1051 Change controller: 1052 1053 IETF AVT Working Group delegated from the IESG 1054 1055 6.1. Packed Headers IANA Considerations 1056 1057 The following IANA considerations refers to the split configuration 1058 Packed Headers (Section 3.2.1) used within RFC 5215. 1059 1060 Type name: audio 1061 1062 Subtype name: vorbis-config 1063 1064 Required parameters: 1065 1066 None 1067 1068 Optional parameters: 1069 1070 None 1071 1072 Encoding considerations: 1073 1074 This media type contains binary data. 1075 1076 Security considerations: 1077 1078 See Section 10 of RFC 5215. 1079 1080 1081 1082 1083 1084 Barbato Standards Track [Page 19] 1085 1087 RFC 5215 Vorbis RTP Payload Format August 2008 1088 1089 1090 Interoperability considerations: 1091 1092 None 1093 1094 Published specification: 1095 1096 RFC 5215 1097 1098 Applications which use this media type: 1099 1100 Vorbis encoded audio, configuration data 1101 1102 Additional information: 1103 1104 None 1105 1106 Person & email address to contact for further information: 1107 1108 Luca Barbato: <lu_zero (a] gentoo.org> 1109 IETF Audio/Video Transport Working Group 1110 1111 Intended usage: COMMON 1112 1113 Restriction on usage: 1114 1115 This media type doesn't depend on the transport. 1116 1117 Author: 1118 1119 Luca Barbato 1120 1121 Change controller: 1122 1123 IETF AVT Working Group delegated from the IESG 1124 1125 7. SDP Related Considerations 1126 1127 The following paragraphs define the mapping of the parameters 1128 described in the IANA considerations section and their usage in the 1129 Offer/Answer Model [RFC3264]. In order to be forward compatible, the 1130 implementation MUST ignore unknown parameters. 1131 1132 7.1. Mapping Media Type Parameters into SDP 1133 1134 The information carried in the Media Type specification has a 1135 specific mapping to fields in the Session Description Protocol (SDP) 1136 [RFC4566], which is commonly used to describe RTP sessions. When SDP 1137 is used to specify sessions, the mapping are as follows: 1138 1139 1140 1141 Barbato Standards Track [Page 20] 1142 1144 RFC 5215 Vorbis RTP Payload Format August 2008 1145 1146 1147 o The type name ("audio") goes in SDP "m=" as the media name. 1148 1149 o The subtype name ("vorbis") goes in SDP "a=rtpmap" as the encoding 1150 name. 1151 1152 o The parameter "rate" also goes in "a=rtpmap" as the clock rate. 1153 1154 o The parameter "channels" also goes in "a=rtpmap" as the channel 1155 count. 1156 1157 o The mandated parameters "configuration" MUST be included in the 1158 SDP "a=fmtp" attribute. 1159 1160 If the stream comprises chained Vorbis files and all of them are 1161 known in advance, the Configuration Packet for each file SHOULD be 1162 passed to the client using the configuration attribute. 1163 1164 The port value is specified by the server application bound to the 1165 address specified in the c= line. The channel count value specified 1166 in the rtpmap attribute SHOULD match the current Vorbis stream or 1167 should be considered the maximum number of channels to be expected. 1168 The timestamp clock rate MUST be a multiple of the sample rate; a 1169 different payload number MUST be used if the clock rate changes. The 1170 Configuration payload delivers the exact information, thus the SDP 1171 information SHOULD be considered a hint. An example is found below. 1172 1173 7.1.1. SDP Example 1174 1175 The following example shows a basic SDP single stream. The first 1176 configuration packet is inside the SDP; other configurations could be 1177 fetched at any time from the URIs provided. The following base64 1178 [RFC4648] configuration string is folded in this example due to RFC 1179 line length limitations. 1180 1181 c=IN IP4 192.0.2.1 1182 1183 m=audio RTP/AVP 98 1184 1185 a=rtpmap:98 vorbis/44100/2 1186 1187 a=fmtp:98 configuration=AAAAAZ2f4g9NAh4aAXZvcmJpcwA...; 1188 1189 Note that the payload format (encoding) names are commonly shown in 1190 uppercase. Media Type subtypes are commonly shown in lowercase. 1191 These names are case-insensitive in both places. Similarly, 1192 parameter names are case-insensitive both in Media Type types and in 1193 the default mapping to the SDP a=fmtp attribute. The a=fmtp line is 1194 1195 1196 1197 1198 Barbato Standards Track [Page 21] 1199 1201 RFC 5215 Vorbis RTP Payload Format August 2008 1202 1203 1204 a single line, even if it is shown as multiple lines in this document 1205 for clarity. 1206 1207 7.2. Usage with the SDP Offer/Answer Model 1208 1209 There are no negotiable parameters. All of them are declarative. 1210 1211 8. Congestion Control 1212 1213 The general congestion control considerations for transporting RTP 1214 data apply to Vorbis audio over RTP as well. See the RTP 1215 specification [RFC3550] and any applicable RTP profile (e.g., 1216 [RFC3551]). Audio data can be encoded using a range of different bit 1217 rates, so it is possible to adapt network bandwidth by adjusting the 1218 encoder bit rate in real time or by having multiple copies of content 1219 encoded at different bit rates. 1220 1221 9. Example 1222 1223 The following example shows a common usage pattern that MAY be 1224 applied in such a situation. The main scope of this section is to 1225 explain better usage of the transmission vectors. 1226 1227 9.1. Stream Radio 1228 1229 This is one of the most common situations: there is one single server 1230 streaming content in multicast, and the clients may start a session 1231 at a random time. The content itself could be a mix of a live stream 1232 (as the webjockey's voice) and stored streams (as the music she 1233 plays). 1234 1235 In this situation, we don't know in advance how many codebooks we 1236 will use. The clients can join anytime and users expect to start 1237 listening to the content in a short time. 1238 1239 Upon joining, the client will receive the current Configuration 1240 necessary to decode the current stream inside the SDP so that the 1241 decoding will start immediately after. 1242 1243 When the streamed content changes, the new Configuration is sent in- 1244 band before the actual stream, and the Configuration that has to be 1245 sent inside the SDP is updated. Since the in-band method is 1246 unreliable, an out-of-band fallback is provided. 1247 1248 The client may choose to fetch the Configuration from the alternate 1249 source as soon as it discovers a Configuration packet got lost in- 1250 band, or use selective retransmission [RFC3611] if the server 1251 supports this feature. 1252 1253 1254 1255 Barbato Standards Track [Page 22] 1256 1258 RFC 5215 Vorbis RTP Payload Format August 2008 1259 1260 1261 A server-side optimization would be to keep a hash list of the 1262 Configurations per session, which avoids packing all of them and 1263 sending the same Configuration with different Ident tags. 1264 1265 A client-side optimization would be to keep a tag list of the 1266 Configurations per session and not process configuration packets that 1267 are already known. 1268 1269 10. Security Considerations 1270 1271 RTP packets using this payload format are subject to the security 1272 considerations discussed in the RTP specification [RFC3550], the 1273 base64 specification [RFC4648], and the URI Generic syntax 1274 specification [RFC3986]. Among other considerations, this implies 1275 that the confidentiality of the media stream is achieved by using 1276 encryption. Because the data compression used with this payload 1277 format is applied end-to-end, encryption may be performed on the 1278 compressed data. 1279 1280 11. Copying Conditions 1281 1282 The authors agree to grant third parties the irrevocable right to 1283 copy, use, and distribute the work, with or without modification, in 1284 any medium, without royalty, provided that, unless separate 1285 permission is granted, redistributed modified works do not contain 1286 misleading author, version, name of work, or endorsement information. 1287 1288 12. Acknowledgments 1289 1290 This document is a continuation of the following documents: 1291 1292 Moffitt, J., "RTP Payload Format for Vorbis Encoded Audio", February 1293 2001. 1294 1295 Kerr, R., "RTP Payload Format for Vorbis Encoded Audio", December 1296 2004. 1297 1298 The Media Type declaration is a continuation of the following 1299 document: 1300 1301 Short, B., "The audio/rtp-vorbis MIME Type", January 2008. 1302 1303 Thanks to the AVT, Vorbis Communities / Xiph.Org Foundation including 1304 Steve Casner, Aaron Colwell, Ross Finlayson, Fluendo, Ramon Garcia, 1305 Pascal Hennequin, Ralph Giles, Tor-Einar Jarnbjo, Colin Law, John 1306 Lazzaro, Jack Moffitt, Christopher Montgomery, Colin Perkins, Barry 1307 Short, Mike Smith, Phil Kerr, Michael Sparks, Magnus Westerlund, 1308 David Barrett, Silvia Pfeiffer, Stefan Ehmann, Gianni Ceccarelli, and 1309 1310 1311 1312 Barbato Standards Track [Page 23] 1313 1315 RFC 5215 Vorbis RTP Payload Format August 2008 1316 1317 1318 Alessandro Salvatori. Thanks to the LScube Group, in particular 1319 Federico Ridolfo, Francesco Varano, Giampaolo Mancini, Dario 1320 Gallucci, and Juan Carlos De Martin. 1321 1322 13. References 1323 1324 13.1. Normative References 1325 1326 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", 1327 RFC 1191, November 1990. 1328 1329 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU 1330 Discovery for IP version 6", RFC 1981, 1331 August 1996. 1332 1333 [RFC2119] Bradner, S., "Key words for use in RFCs to 1334 Indicate Requirement Levels", BCP 14, RFC 2119, 1335 March 1997. 1336 1337 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer 1338 Model with Session Description Protocol (SDP)", 1339 RFC 3264, June 2002. 1340 1341 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1342 Jacobson, "RTP: A Transport Protocol for Real-Time 1343 Applications", STD 64, RFC 3550, July 2003. 1344 1345 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for 1346 Audio and Video Conferences with Minimal Control", 1347 STD 65, RFC 3551, July 2003. 1348 1349 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, 1350 "Uniform Resource Identifier (URI): Generic 1351 Syntax", STD 66, RFC 3986, January 2005. 1352 1353 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: 1354 Session Description Protocol", RFC 4566, 1355 July 2006. 1356 1357 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 1358 Data Encodings", RFC 4648, October 2006. 1359 1360 [VORBIS-SPEC-REF] "Ogg Vorbis I specification: Codec setup and 1361 packet decode. Available from the Xiph website, 1362 http://xiph.org/vorbis/doc/Vorbis_I_spec.html". 1363 1364 1365 1366 1367 1368 1369 Barbato Standards Track [Page 24] 1370 1372 RFC 5215 Vorbis RTP Payload Format August 2008 1373 1374 1375 13.2. Informative References 1376 1377 [LIBVORBIS] "libvorbis: Available from the dedicated website, 1378 http://vorbis.com/". 1379 1380 [RFC3533] Pfeiffer, S., "The Ogg Encapsulation Format 1381 Version 0", RFC 3533, May 2003. 1382 1383 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP 1384 Control Protocol Extended Reports (RTCP XR)", 1385 RFC 3611, November 2003. 1386 1387 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1388 Hakenberg, "RTP Retransmission Payload Format", 1389 RFC 4588, July 2006. 1390 1391 Author's Address 1392 1393 Luca Barbato 1394 Xiph.Org Foundation 1395 1396 EMail: lu_zero (a] gentoo.org 1397 URI: http://xiph.org/ 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 Barbato Standards Track [Page 25] 1427 1429 RFC 5215 Vorbis RTP Payload Format August 2008 1430 1431 1432 Full Copyright Statement 1433 1434 Copyright (C) The IETF Trust (2008). 1435 1436 This document is subject to the rights, licenses and restrictions 1437 contained in BCP 78, and except as set forth therein, the authors 1438 retain all their rights. 1439 1440 This document and the information contained herein are provided on an 1441 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1442 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1443 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1444 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1445 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1446 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1447 1448 Intellectual Property 1449 1450 The IETF takes no position regarding the validity or scope of any 1451 Intellectual Property Rights or other rights that might be claimed to 1452 pertain to the implementation or use of the technology described in 1453 this document or the extent to which any license under such rights 1454 might or might not be available; nor does it represent that it has 1455 made any independent effort to identify any such rights. Information 1456 on the procedures with respect to rights in RFC documents can be 1457 found in BCP 78 and BCP 79. 1458 1459 Copies of IPR disclosures made to the IETF Secretariat and any 1460 assurances of licenses to be made available, or the result of an 1461 attempt made to obtain a general license or permission for the use of 1462 such proprietary rights by implementers or users of this 1463 specification can be obtained from the IETF on-line IPR repository at 1464 http://www.ietf.org/ipr. 1465 1466 The IETF invites any interested party to bring to its attention any 1467 copyrights, patents or patent applications, or other proprietary 1468 rights that may cover technology that may be required to implement 1469 this standard. Please address the information to the IETF at 1470 ietf-ipr (a] ietf.org. 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 Barbato Standards Track [Page 26] 1484 1486
