Project: OGG Vorbis

Revision: 15227

Author: ivo

Date: 31 Aug 2008 18:35:03

• /trunk/vorbis/doc/rfc5215.txt

  ......	@@ -0,0 +1,1459 @@
  	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
  	60	RFC 5215 Vorbis RTP Payload Format August 2008
  	61
  	62
  	63	Table of Contents
  	64
  	65	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
  	66	1.1. Conformance and Document Conventions . . . . . . . . . . . 3
  	67	2. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 3
  	68	2.1. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 4
  	69	2.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 5
  	70	2.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6
  	71	2.4. Example RTP Packet . . . . . . . . . . . . . . . . . . . . 8
  	72	3. Configuration Headers . . . . . . . . . . . . . . . . . . . . 8
  	73	3.1. In-band Header Transmission . . . . . . . . . . . . . . . 9
  	74	3.1.1. Packed Configuration . . . . . . . . . . . . . . . . . 10
  	75	3.2. Out of Band Transmission . . . . . . . . . . . . . . . . . 12
  	76	3.2.1. Packed Headers . . . . . . . . . . . . . . . . . . . . 12
  	77	3.3. Loss of Configuration Headers . . . . . . . . . . . . . . 13
  	78	4. Comment Headers . . . . . . . . . . . . . . . . . . . . . . . 13
  	79	5. Frame Packetization . . . . . . . . . . . . . . . . . . . . . 14
  	80	5.1. Example Fragmented Vorbis Packet . . . . . . . . . . . . . 15
  	81	5.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 17
  	82	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
  	83	6.1. Packed Headers IANA Considerations . . . . . . . . . . . . 19
  	84	7. SDP Related Considerations . . . . . . . . . . . . . . . . . . 20
  	85	7.1. Mapping Media Type Parameters into SDP . . . . . . . . . . 20
  	86	7.1.1. SDP Example . . . . . . . . . . . . . . . . . . . . . 21
  	87	7.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 22
  	88	8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 22
  	89	9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
  	90	9.1. Stream Radio . . . . . . . . . . . . . . . . . . . . . . . 22
  	91	10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
  	92	11. Copying Conditions . . . . . . . . . . . . . . . . . . . . . . 23
  	93	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
  	94	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
  	95	13.1. Normative References . . . . . . . . . . . . . . . . . . . 24
  	96	13.2. Informative References . . . . . . . . . . . . . . . . . . 25
  	97
  	98
  	99
  	100
  	101
  	102
  	103
  	104
  	105
  	106
  	107
  	108
  	109
  	110
  	111
  	112
  	113
  	114	Barbato Standards Track [Page 2]
  	115
  	116	RFC 5215 Vorbis RTP Payload Format August 2008
  	117
  	118
  	119	1. Introduction
  	120
  	121	Vorbis is a general purpose perceptual audio codec intended to allow
  	122	maximum encoder flexibility, thus allowing it to scale competitively
  	123	over an exceptionally wide range of bit rates. At the high quality/
  	124	bitrate end of the scale (CD or DAT rate stereo, 16/24 bits), it is
  	125	in the same league as MPEG-4 AAC. Vorbis is also intended for lower
  	126	and higher sample rates (from 8kHz telephony to 192kHz digital
  	127	masters) and a range of channel representations (monaural,
  	128	polyphonic, stereo, quadraphonic, 5.1, ambisonic, or up to 255
  	129	discrete channels).
  	130
  	131	Vorbis encoded audio is generally encapsulated within an Ogg format
  	132	bitstream [RFC3533], which provides framing and synchronization. For
  	133	the purposes of RTP transport, this layer is unnecessary, and so raw
  	134	Vorbis packets are used in the payload.
  	135
  	136	1.1. Conformance and Document Conventions
  	137
  	138	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  	139	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  	140	document are to be interpreted as described in BCP 14, [RFC2119] and
  	141	indicate requirement levels for compliant implementations.
  	142	Requirements apply to all implementations unless otherwise stated.
  	143
  	144	An implementation is a software module that supports one of the media
  	145	types defined in this document. Software modules may support
  	146	multiple media types, but conformance is considered individually for
  	147	each type.
  	148
  	149	Implementations that fail to satisfy one or more "MUST" requirements
  	150	are considered non-compliant. Implementations that satisfy all
  	151	"MUST" requirements, but fail to satisfy one or more "SHOULD"
  	152	requirements, are said to be "conditionally compliant". All other
  	153	implementations are "unconditionally compliant".
  	154
  	155	2. Payload Format
  	156
  	157	For RTP-based transport of Vorbis-encoded audio, the standard RTP
  	158	header is followed by a 4-octet payload header, and then the payload
  	159	data. The payload headers are used to associate the Vorbis data with
  	160	its associated decoding codebooks as well as indicate if the
  	161	following packet contains fragmented Vorbis data and/or the number of
  	162	whole Vorbis data frames. The payload data contains the raw Vorbis
  	163	bitstream information. There are 3 types of Vorbis data; an RTP
  	164	payload MUST contain just one of them at a time.
  	165
  	166
  	167
  	168
  	169
  	170	Barbato Standards Track [Page 3]
  	171
  	172	RFC 5215 Vorbis RTP Payload Format August 2008
  	173
  	174
  	175	2.1. RTP Header
  	176
  	177	The format of the RTP header is specified in [RFC3550] and shown in
  	178	Figure 1. This payload format uses the fields of the header in a
  	179	manner consistent with that specification.
  	180
  	181	0 1 2 3
  	182	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
  	183	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	184	|V=2|P|X| CC |M| PT | sequence number |
  	185	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	186	| timestamp |
  	187	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	188	| synchronization source (SSRC) identifier |
  	189	+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
  	190	| contributing source (CSRC) identifiers |
  	191	| ... |
  	192	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	193
  	194	Figure 1: RTP Header
  	195
  	196	The RTP header begins with an octet of fields (V, P, X, and CC) to
  	197	support specialized RTP uses (see [RFC3550] and [RFC3551] for
  	198	details). For Vorbis RTP, the following values are used.
  	199
  	200	Version (V): 2 bits
  	201
  	202	This field identifies the version of RTP. The version used by this
  	203	specification is two (2).
  	204
  	205	Padding (P): 1 bit
  	206
  	207	Padding MAY be used with this payload format according to Section 5.1
  	208	of [RFC3550].
  	209
  	210	Extension (X): 1 bit
  	211
  	212	The Extension bit is used in accordance with [RFC3550].
  	213
  	214	CSRC count (CC): 4 bits
  	215
  	216	The CSRC count is used in accordance with [RFC3550].
  	217
  	218	Marker (M): 1 bit
  	219
  	220	Set to zero. Audio silence suppression is not used. This conforms
  	221	to Section 4.1 of [VORBIS-SPEC-REF].
  	222
  	223
  	224
  	225
  	226	Barbato Standards Track [Page 4]
  	227
  	228	RFC 5215 Vorbis RTP Payload Format August 2008
  	229
  	230
  	231	Payload Type (PT): 7 bits
  	232
  	233	An RTP profile for a class of applications is expected to assign a
  	234	payload type for this format, or a dynamically allocated payload type
  	235	SHOULD be chosen that designates the payload as Vorbis.
  	236
  	237	Sequence number: 16 bits
  	238
  	239	The sequence number increments by one for each RTP data packet sent,
  	240	and may be used by the receiver to detect packet loss and to restore
  	241	the packet sequence. This field is detailed further in [RFC3550].
  	242
  	243	Timestamp: 32 bits
  	244
  	245	A timestamp representing the sampling time of the first sample of the
  	246	first Vorbis packet in the RTP payload. The clock frequency MUST be
  	247	set to the sample rate of the encoded audio data and is conveyed out-
  	248	of-band (e.g., as an SDP parameter).
  	249
  	250	SSRC/CSRC identifiers:
  	251
  	252	These two fields, 32 bits each with one SSRC field and a maximum of
  	253	16 CSRC fields, are as defined in [RFC3550].
  	254
  	255	2.2. Payload Header
  	256
  	257	The 4 octets following the RTP Header section are the Payload Header.
  	258	This header is split into a number of bit fields detailing the format
  	259	of the following payload data packets.
  	260
  	261	0 1 2 3
  	262	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
  	263	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	264	| Ident | F |VDT|# pkts.|
  	265	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	266
  	267	Figure 2: Payload Header
  	268
  	269	Ident: 24 bits
  	270
  	271	This 24-bit field is used to associate the Vorbis data to a decoding
  	272	Configuration. It is stored as a network byte order integer.
  	273
  	274	Fragment type (F): 2 bits
  	275
  	276
  	277
  	278
  	279
  	280
  	281
  	282	Barbato Standards Track [Page 5]
  	283
  	284	RFC 5215 Vorbis RTP Payload Format August 2008
  	285
  	286
  	287	This field is set according to the following list:
  	288
  	289	0 = Not Fragmented
  	290
  	291	1 = Start Fragment
  	292
  	293	2 = Continuation Fragment
  	294
  	295	3 = End Fragment
  	296
  	297	Vorbis Data Type (VDT): 2 bits
  	298
  	299	This field specifies the kind of Vorbis data stored in this RTP
  	300	packet. There are currently three different types of Vorbis
  	301	payloads. Each packet MUST contain only a single type of Vorbis
  	302	packet (e.g., you must not aggregate configuration and comment
  	303	packets in the same RTP payload).
  	304
  	305	0 = Raw Vorbis payload
  	306
  	307	1 = Vorbis Packed Configuration payload
  	308
  	309	2 = Legacy Vorbis Comment payload
  	310
  	311	3 = Reserved
  	312
  	313	The packets with a VDT of value 3 MUST be ignored.
  	314
  	315	The last 4 bits represent the number of complete packets in this
  	316	payload. This provides for a maximum number of 15 Vorbis packets in
  	317	the payload. If the payload contains fragmented data, the number of
  	318	packets MUST be set to 0.
  	319
  	320	2.3. Payload Data
  	321
  	322	Raw Vorbis packets are currently unbounded in length; application
  	323	profiles will likely define a practical limit. Typical Vorbis packet
  	324	sizes range from very small (2-3 bytes) to quite large (8-12
  	325	kilobytes). The reference implementation [LIBVORBIS] typically
  	326	produces packets less than ~800 bytes, except for the setup header
  	327	packets, which are ~4-12 kilobytes. Within an RTP context, to avoid
  	328	fragmentation, the Vorbis data packet size SHOULD be kept
  	329	sufficiently small so that after adding the RTP and payload headers,
  	330	the complete RTP packet is smaller than the path MTU.
  	331
  	332
  	333
  	334
  	335
  	336
  	337
  	338	Barbato Standards Track [Page 6]
  	339
  	340	RFC 5215 Vorbis RTP Payload Format August 2008
  	341
  	342
  	343	0 1 2 3
  	344	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
  	345	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	346	| length | vorbis packet data ..
  	347	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	348
  	349	Figure 3: Payload Data Header
  	350
  	351	Each Vorbis payload packet starts with a two octet length header,
  	352	which is used to represent the size in bytes of the following data
  	353	payload, and is followed by the raw Vorbis data padded to the nearest
  	354	byte boundary, as explained by the Vorbis I Specification
  	355	[VORBIS-SPEC-REF]. The length value is stored as a network byte
  	356	order integer.
  	357
  	358	For payloads that consist of multiple Vorbis packets, the payload
  	359	data consists of the packet length followed by the packet data for
  	360	each of the Vorbis packets in the payload.
  	361
  	362	The Vorbis packet length header is the length of the Vorbis data
  	363	block only and does not include the length field.
  	364
  	365	The payload packing of the Vorbis data packets MUST follow the
  	366	guidelines set out in [RFC3551], where the oldest Vorbis packet
  	367	occurs immediately after the RTP packet header. Subsequent Vorbis
  	368	packets, if any, MUST follow in temporal order.
  	369
  	370	Audio channel mapping is in accordance with the Vorbis I
  	371	Specification [VORBIS-SPEC-REF].
  	372
  	373
  	374
  	375
  	376
  	377
  	378
  	379
  	380
  	381
  	382
  	383
  	384
  	385
  	386
  	387
  	388
  	389
  	390
  	391
  	392
  	393
  	394	Barbato Standards Track [Page 7]
  	395
  	396	RFC 5215 Vorbis RTP Payload Format August 2008
  	397
  	398
  	399	2.4. Example RTP Packet
  	400
  	401	Here is an example RTP payload containing two Vorbis packets.
  	402
  	403	0 1 2 3
  	404	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
  	405	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	406	| 2 |0|0| 0 |0| PT | sequence number |
  	407	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	408	| timestamp (in sample rate units) |
  	409	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	410	| synchronisation source (SSRC) identifier |
  	411	+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
  	412	| contributing source (CSRC) identifiers |
  	413	| ... |
  	414	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	415	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	416	| Ident | 0 | 0 | 2 pks |
  	417	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	418	| length | vorbis data ..
  	419	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	420	.. vorbis data |
  	421	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	422	| length | next vorbis packet data ..
  	423	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	424	.. vorbis data ..
  	425	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	426	.. vorbis data |
  	427	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	428
  	429	Figure 4: Example Raw Vorbis Packet
  	430
  	431	The payload data section of the RTP packet begins with the 24-bit
  	432	Ident field followed by the one octet bit field header, which has the
  	433	number of Vorbis frames set to 2. Each of the Vorbis data frames is
  	434	prefixed by the two octets length field. The Packet Type and
  	435	Fragment Type are set to 0. The Configuration that will be used to
  	436	decode the packets is the one indexed by the ident value.
  	437
  	438	3. Configuration Headers
  	439
  	440	Unlike other mainstream audio codecs, Vorbis has no statically
  	441	configured probability model. Instead, it packs all entropy decoding
  	442	configuration, Vector Quantization and Huffman models into a data
  	443	block that must be transmitted to the decoder with the compressed
  	444	data. A decoder also requires information detailing the number of
  	445	audio channels, bitrates, and similar information to configure itself
  	446	for a particular compressed data stream. These two blocks of
  	447
  	448
  	449
  	450	Barbato Standards Track [Page 8]
  	451
  	452	RFC 5215 Vorbis RTP Payload Format August 2008
  	453
  	454
  	455	information are often referred to collectively as the "codebooks" for
  	456	a Vorbis stream, and are included as special "header" packets at the
  	457	start of the compressed data. In addition, the Vorbis I
  	458	specification [VORBIS-SPEC-REF] requires the presence of a comment
  	459	header packet that gives simple metadata about the stream, but this
  	460	information is not required for decoding the frame sequence.
  	461
  	462	Thus, these two codebook header packets must be received by the
  	463	decoder before any audio data can be interpreted. These requirements
  	464	pose problems in RTP, which is often used over unreliable transports.
  	465
  	466	Since this information must be transmitted reliably and, as the RTP
  	467	stream may change certain configuration data mid-session, there are
  	468	different methods for delivering this configuration data to a client,
  	469	both in-band and out-of-band, which are detailed below. In order to
  	470	set up an initial state for the client application, the configuration
  	471	MUST be conveyed via the signalling channel used to set up the
  	472	session. One example of such signalling is SDP [RFC4566] with the
  	473	Offer/Answer Model [RFC3264]. Changes to the configuration MAY be
  	474	communicated via a re-invite, conveying a new SDP, or sent in-band in
  	475	the RTP channel. Implementations MUST support an in-band delivery of
  	476	updated codebooks, and SHOULD support out-of-band codebook update
  	477	using a new SDP file. The changes may be due to different codebooks
  	478	as well as different bitrates of the RTP stream.
  	479
  	480	For non-chained streams, the recommended Configuration delivery
  	481	method is inside the Packed Configuration (Section 3.1.1) in the SDP
  	482	as explained the Mapping Media Type Parameters into SDP
  	483	(Section 7.1).
  	484
  	485	The 24-bit Ident field is used to map which Configuration will be
  	486	used to decode a packet. When the Ident field changes, it indicates
  	487	that a change in the stream has taken place. The client application
  	488	MUST have in advance the correct configuration. If the client
  	489	detects a change in the Ident value and does not have this
  	490	information, it MUST NOT decode the raw associated Vorbis data until
  	491	it fetches the correct Configuration.
  	492
  	493	3.1. In-band Header Transmission
  	494
  	495	The Packed Configuration (Section 3.1.1) Payload is sent in-band with
  	496	the packet type bits set to match the Vorbis Data Type. Clients MUST
  	497	be capable of dealing with fragmentation and periodic re-transmission
  	498	of [RFC4588] the configuration headers. The RTP timestamp value MUST
  	499	reflect the transmission time of the first data packet for which this
  	500	configuration applies.
  	501
  	502
  	503
  	504
  	505
  	506	Barbato Standards Track [Page 9]
  	507
  	508	RFC 5215 Vorbis RTP Payload Format August 2008
  	509
  	510
  	511	3.1.1. Packed Configuration
  	512
  	513	A Vorbis Packed Configuration is indicated with the Vorbis Data Type
  	514	field set to 1. Of the three headers defined in the Vorbis I
  	515	specification [VORBIS-SPEC-REF], the Identification and the Setup
  	516	MUST be packed as they are, while the Comment header MAY be replaced
  	517	with a dummy one.
  	518
  	519	The packed configuration stores Xiph codec configurations in a
  	520	generic way: the first field stores the number of the following
  	521	packets minus one (count field), the next ones represent the size of
  	522	the headers (length fields), and the headers immediately follow the
  	523	list of length fields. The size of the last header is implicit.
  	524
  	525	The count and the length fields are encoded using the following
  	526	logic: the data is in network byte order; every byte has the most
  	527	significant bit used as a flag, and the following 7 bits are used to
  	528	store the value. The first 7 most significant bits are stored in the
  	529	first byte. If there are remaining bits, the flag bit is set to 1
  	530	and the subsequent 7 bits are stored in the following byte. If there
  	531	are remaining bits, set the flag to 1 and the same procedure is
  	532	repeated. The ending byte has the flag bit set to 0. To decode,
  	533	simply iterate over the bytes until the flag bit is set to 0. For
  	534	every byte, the data is added to the accumulated value multiplied by
  	535	128.
  	536
  	537	The headers are packed in the same order as they are present in Ogg
  	538	[VORBIS-SPEC-REF]: Identification, Comment, Setup.
  	539
  	540	The 2 byte length tag defines the length of the packed headers as the
  	541	sum of the Configuration, Comment, and Setup lengths.
  	542
  	543
  	544
  	545
  	546
  	547
  	548
  	549
  	550
  	551
  	552
  	553
  	554
  	555
  	556
  	557
  	558
  	559
  	560
  	561
  	562	Barbato Standards Track [Page 10]
  	563
  	564	RFC 5215 Vorbis RTP Payload Format August 2008
  	565
  	566
  	567	0 1 2 3
  	568	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
  	569	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	570	|V=2|P|X| CC |M| PT | xxxx |
  	571	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	572	| xxxxx |
  	573	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	574	| synchronization source (SSRC) identifier |
  	575	+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
  	576	| contributing source (CSRC) identifiers |
  	577	| ... |
  	578	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	579	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	580	| Ident | 0 | 1 | 1|
  	581	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	582	| length | n. of headers | length1 |
  	583	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	584	| length2 | Identification ..
  	585	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	586	.. Identification ..
  	587	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	588	.. Identification ..
  	589	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	590	.. Identification ..
  	591	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	592	.. Identification | Comment ..
  	593	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	594	.. Comment ..
  	595	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	596	.. Comment ..
  	597	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	598	.. Comment ..
  	599	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	600	.. Comment | Setup ..
  	601	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	602	.. Setup ..
  	603	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	604	.. Setup ..
  	605	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	606
  	607	Figure 5: Packed Configuration Figure
  	608
  	609	The Ident field is set with the value that will be used by the Raw
  	610	Payload Packets to address this Configuration. The Fragment type is
  	611	set to 0 because the packet bears the full Packed configuration. The
  	612	number of the packet is set to 1.
  	613
  	614
  	615
  	616
  	617
  	618	Barbato Standards Track [Page 11]
  	619
  	620	RFC 5215 Vorbis RTP Payload Format August 2008
  	621
  	622
  	623	3.2. Out of Band Transmission
  	624
  	625	The following packet definition MUST be used when Configuration is
  	626	inside in the SDP.
  	627
  	628	3.2.1. Packed Headers
  	629
  	630	As mentioned above, the RECOMMENDED delivery vector for Vorbis
  	631	configuration data is via a retrieval method that can be performed
  	632	using a reliable transport protocol. As the RTP headers are not
  	633	required for this method of delivery, the structure of the
  	634	configuration data is slightly different. The packed header starts
  	635	with a 32-bit (network-byte ordered) count field, which details the
  	636	number of packed headers that are contained in the bundle. The
  	637	following shows the Packed header payload for each chained Vorbis
  	638	stream.
  	639
  	640	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	641	| Number of packed headers |
  	642	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	643	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	644	| Packed header |
  	645	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	646	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	647	| Packed header |
  	648	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	649
  	650	Figure 6: Packed Headers Overview
  	651
  	652
  	653
  	654
  	655
  	656
  	657
  	658
  	659
  	660
  	661
  	662
  	663
  	664
  	665
  	666
  	667
  	668
  	669
  	670
  	671
  	672
  	673
  	674	Barbato Standards Track [Page 12]
  	675
  	676	RFC 5215 Vorbis RTP Payload Format August 2008
  	677
  	678
  	679	0 1 2 3
  	680	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
  	681	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	682	| Ident | length ..
  	683	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	684	.. | n. of headers | length1 | length2 ..
  	685	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	686	.. | Identification Header ..
  	687	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	688	.................................................................
  	689	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	690	.. | Comment Header ..
  	691	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	692	.................................................................
  	693	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	694	.. Comment Header |
  	695	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	696	| Setup Header ..
  	697	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	698	.................................................................
  	699	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	700	.. Setup Header |
  	701	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	702
  	703	Figure 7: Packed Headers Detail
  	704
  	705	The key difference between the in-band format and this one is that
  	706	there is no need for the payload header octet. In this figure, the
  	707	comment has a size bigger than 127 bytes.
  	708
  	709	3.3. Loss of Configuration Headers
  	710
  	711	Unlike the loss of raw Vorbis payload data, loss of a configuration
  	712	header leads to a situation where it will not be possible to
  	713	successfully decode the stream. Implementations MAY try to recover
  	714	from an error by requesting again the missing Configuration or, if
  	715	the delivery method is in-band, by buffering the payloads waiting for
  	716	the Configuration needed to decode them. The baseline reaction
  	717	SHOULD either be reset or end the RTP session.
  	718
  	719	4. Comment Headers
  	720
  	721	Vorbis Data Type flag set to 2 indicates that the packet contains the
  	722	comment metadata, such as artist name, track title, and so on. These
  	723	metadata messages are not intended to be fully descriptive but rather
  	724	to offer basic track/song information. Clients MAY ignore it
  	725	completely. The details on the format of the comments can be found
  	726	in the Vorbis I Specification [VORBIS-SPEC-REF].
  	727
  	728
  	729
  	730	Barbato Standards Track [Page 13]
  	731
  	732	RFC 5215 Vorbis RTP Payload Format August 2008
  	733
  	734
  	735	0 1 2 3
  	736	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
  	737	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	738	|V=2|P|X| CC |M| PT | xxxx |
  	739	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	740	| xxxxx |
  	741	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	742	| synchronization source (SSRC) identifier |
  	743	+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
  	744	| contributing source (CSRC) identifiers |
  	745	| ... |
  	746	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	747	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	748	| Ident | 0 | 2 | 1|
  	749	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	750	| length | Comment ..
  	751	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	752	.. Comment ..
  	753	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	754	.. Comment |
  	755	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	756
  	757	Figure 8: Comment Packet
  	758
  	759	The 2-byte length field is necessary since this packet could be
  	760	fragmented.
  	761
  	762	5. Frame Packetization
  	763
  	764	Each RTP payload contains either one Vorbis packet fragment or an
  	765	integer number of complete Vorbis packets (up to a maximum of 15
  	766	packets, since the number of packets is defined by a 4-bit value).
  	767
  	768	Any Vorbis data packet that is less than path MTU SHOULD be bundled
  	769	in the RTP payload with as many Vorbis packets as will fit, up to a
  	770	maximum of 15, except when such bundling would exceed an
  	771	application's desired transmission latency. Path MTU is detailed in
  	772	[RFC1191] and [RFC1981].
  	773
  	774	A fragmented packet has a zero in the last four bits of the payload
  	775	header. The first fragment will set the Fragment type to 1. Each
  	776	fragment after the first will set the Fragment type to 2 in the
  	777	payload header. The consecutive fragments MUST be sent without any
  	778	other payload being sent between the first and the last fragment.
  	779	The RTP payload containing the last fragment of the Vorbis packet
  	780	will have the Fragment type set to 3. To maintain the correct
  	781	sequence for fragmented packet reception, the timestamp field of
  	782	fragmented packets MUST be the same as the first packet sent, with
  	783
  	784
  	785
  	786	Barbato Standards Track [Page 14]
  	787
  	788	RFC 5215 Vorbis RTP Payload Format August 2008
  	789
  	790
  	791	the sequence number incremented as normal for the subsequent RTP
  	792	payloads; this will affect the RTCP jitter measurement. The length
  	793	field shows the fragment length.
  	794
  	795	5.1. Example Fragmented Vorbis Packet
  	796
  	797	Here is an example of a fragmented Vorbis packet split over three RTP
  	798	payloads. Each of them contains the standard RTP headers as well as
  	799	the 4-octet Vorbis headers.
  	800
  	801	Packet 1:
  	802
  	803	0 1 2 3
  	804	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
  	805	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	806	|V=2|P|X| CC |M| PT | 1000 |
  	807	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	808	| 12345 |
  	809	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	810	| synchronization source (SSRC) identifier |
  	811	+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
  	812	| contributing source (CSRC) identifiers |
  	813	| ... |
  	814	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	815	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	816	| Ident | 1 | 0 | 0|
  	817	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	818	| length | vorbis data ..
  	819	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	820	.. vorbis data |
  	821	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	822
  	823	Figure 9: Example Fragmented Packet (Packet 1)
  	824
  	825	In this payload, the initial sequence number is 1000 and the
  	826	timestamp is 12345. The Fragment type is set to 1, the number of
  	827	packets field is set to 0, and as the payload is raw Vorbis data, the
  	828	VDT field is set to 0.
  	829
  	830
  	831
  	832
  	833
  	834
  	835
  	836
  	837
  	838
  	839
  	840
  	841
  	842	Barbato Standards Track [Page 15]
  	843
  	844	RFC 5215 Vorbis RTP Payload Format August 2008
  	845
  	846
  	847	Packet 2:
  	848
  	849	0 1 2 3
  	850	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
  	851	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	852	|V=2|P|X| CC