< draft-ietf-payload-flexible-fec-scheme-18.txt		draft-ietf-payload-flexible-fec-scheme-19.txt >
	PAYLOAD M. Zanaty		PAYLOAD M. Zanaty
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Standards Track V. Singh		Intended status: Standards Track V. Singh
	Expires: September 6, 2019 callstats.io		Expires: September 29, 2019 callstats.io
	A. Begen		A. Begen
	Networked Media		Networked Media
	G. Mandyam		G. Mandyam
	Qualcomm Inc.		Qualcomm Inc.
	March 5, 2019		March 28, 2019
	RTP Payload Format for Flexible Forward Error Correction (FEC)		RTP Payload Format for Flexible Forward Error Correction (FEC)
	draft-ietf-payload-flexible-fec-scheme-18		draft-ietf-payload-flexible-fec-scheme-19
	Abstract		Abstract
	This document defines new RTP payload formats for the Forward Error		This document defines new RTP payload formats for the Forward Error
	Correction (FEC) packets that are generated by the non-interleaved		Correction (FEC) packets that are generated by the non-interleaved
	and interleaved parity codes from source media encapsulated in RTP.		and interleaved parity codes from source media encapsulated in RTP.
	These parity codes are systematic codes, where a number of FEC repair		These parity codes are systematic codes (Flexible FEC, or "FLEX
	packets are generated from a set of source packets from one or more		FEC"), where a number of FEC repair packets are generated from a set
	source RTP streams. These FEC repair packets are sent in a		of source packets from one or more source RTP streams. These FEC
	redundancy RTP stream separate from the source RTP stream(s) that		repair packets are sent in a redundancy RTP stream separate from the
	carries the source packets. RTP source packets that were lost in		source RTP stream(s) that carries the source packets. RTP source
	transmission can be reconstructed using the source and repair packets		packets that were lost in transmission can be reconstructed using the
	that were received. The non-interleaved and interleaved parity codes		source and repair packets that were received. The non-interleaved
	which are defined in this specification offer a good protection		and interleaved parity codes which are defined in this specification
	against random and bursty packet losses, respectively, at a cost of		offer a good protection against random and bursty packet losses,
	complexity. The RTP payload formats that are defined in this		respectively, at a cost of complexity. The RTP payload formats that
	document address scalability issues experienced with the earlier		are defined in this document address scalability issues experienced
	specifications, and offer several improvements. Due to these		with the earlier specifications, and offer several improvements. Due
	changes, the new payload formats are not backward compatible with		to these changes, the new payload formats are not backward compatible
	earlier specifications, but endpoints that do not implement this		with earlier specifications, but endpoints that do not implement this
	specification can still work by simply ignoring the FEC repair		specification can still work by simply ignoring the FEC repair
	packets.		packets.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 6, 2019.		This Internet-Draft will expire on September 29, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 35 ¶		skipping to change at page 2, line 35 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Parity Codes . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Parity Codes . . . . . . . . . . . . . . . . . . . . . . 4
	1.1.1. One-Dimensional (1-D) Non-interleaved (Row) FEC		1.1.1. One-Dimensional (1-D) Non-interleaved (Row) FEC
	Protection . . . . . . . . . . . . . . . . . . . . . 5		Protection . . . . . . . . . . . . . . . . . . . . . 5
	1.1.2. 1-D Interleaved (Column) FEC Protection . . . . . . . 6		1.1.2. 1-D Interleaved (Column) FEC Protection . . . . . . . 6
	1.1.3. Use Cases for 1-D FEC Protection . . . . . . . . . . 7		1.1.3. Use Cases for 1-D FEC Protection . . . . . . . . . . 7
	1.1.4. Two-Dimensional (2-D) (Row and Column) FEC Protection 8		1.1.4. Two-Dimensional (2-D) (Row and Column) FEC Protection 8
	1.1.5. FEC Protection with Flexible Mask . . . . . . . . . . 10		1.1.5. FEC Protection with Flexible Mask . . . . . . . . . . 10
	1.1.6. FEC Overhead Considerations . . . . . . . . . . . . . 10		1.1.6. FEC Overhead Considerations . . . . . . . . . . . . . 10
	1.1.7. Repair Window Considerations . . . . . . . . . . . . 10		1.1.7. FEC Protection with Retransmission . . . . . . . . . 10
			1.1.8. Repair Window Considerations . . . . . . . . . . . . 10
	2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 11		2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 11
	3. Definitions and Notations . . . . . . . . . . . . . . . . . . 11		3. Definitions and Notations . . . . . . . . . . . . . . . . . . 11
	3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 11		3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 11
	3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 11		3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 12
	4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 12		4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 12
	4.1. Source Packets . . . . . . . . . . . . . . . . . . . . . 12		4.1. Source Packets . . . . . . . . . . . . . . . . . . . . . 12
	4.2. FEC Repair Packets . . . . . . . . . . . . . . . . . . . 12		4.2. FEC Repair Packets . . . . . . . . . . . . . . . . . . . 13
	4.2.1. RTP Header of FEC Repair Packets . . . . . . . . . . 13		4.2.1. RTP Header of FEC Repair Packets . . . . . . . . . . 13
	4.2.2. FEC Header of FEC Repair Packets . . . . . . . . . . 15		4.2.2. FEC Header of FEC Repair Packets . . . . . . . . . . 15
	5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 20		5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 20
	5.1. Media Type Registration - Parity Codes . . . . . . . . . 20		5.1. Media Type Registration - Parity Codes . . . . . . . . . 20
	5.1.1. Registration of audio/flexfec . . . . . . . . . . . . 21		5.1.1. Registration of audio/flexfec . . . . . . . . . . . . 21
	5.1.2. Registration of video/flexfec . . . . . . . . . . . . 22		5.1.2. Registration of video/flexfec . . . . . . . . . . . . 22
	5.1.3. Registration of text/flexfec . . . . . . . . . . . . 24		5.1.3. Registration of text/flexfec . . . . . . . . . . . . 23
	5.1.4. Registration of application/flexfec . . . . . . . . . 25		5.1.4. Registration of application/flexfec . . . . . . . . . 24
	5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 26
	5.2.1. Offer-Answer Model Considerations . . . . . . . . . . 27		5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 25
	5.2.2. Declarative Considerations . . . . . . . . . . . . . 28		5.2.1. Offer-Answer Model Considerations . . . . . . . . . . 25
	6. Protection and Recovery Procedures - Parity Codes . . . . . . 28		5.2.2. Declarative Considerations . . . . . . . . . . . . . 26
	6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 28		6. Protection and Recovery Procedures - Parity Codes . . . . . . 26
	6.2. Repair Packet Construction . . . . . . . . . . . . . . . 28		6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 26
	6.3. Source Packet Reconstruction . . . . . . . . . . . . . . 30		6.2. Repair Packet Construction . . . . . . . . . . . . . . . 26
	6.3.1. Associating the Source and Repair Packets . . . . . . 30		6.3. Source Packet Reconstruction . . . . . . . . . . . . . . 28
	6.3.2. Recovering the RTP Header . . . . . . . . . . . . . . 32		6.3.1. Associating the Source and Repair Packets . . . . . . 28
	6.3.3. Recovering the RTP Payload . . . . . . . . . . . . . 33		6.3.2. Recovering the RTP Header . . . . . . . . . . . . . . 30
			6.3.3. Recovering the RTP Payload . . . . . . . . . . . . . 31
	6.3.4. Iterative Decoding Algorithm for the 2-D Parity FEC		6.3.4. Iterative Decoding Algorithm for the 2-D Parity FEC
	Protection . . . . . . . . . . . . . . . . . . . . . 34		Protection . . . . . . . . . . . . . . . . . . . . . 31
	7. Signaling Requirements . . . . . . . . . . . . . . . . . . . 36		7. Signaling Requirements . . . . . . . . . . . . . . . . . . . 34
	7.1. SDP Examples . . . . . . . . . . . . . . . . . . . . . . 37		7.1. SDP Examples . . . . . . . . . . . . . . . . . . . . . . 35
	7.1.1. Example SDP for Flexible FEC Protection with in-band		7.1.1. Example SDP for Flexible FEC Protection with in-band
	SSRC mapping . . . . . . . . . . . . . . . . . . . . 37		SSRC mapping . . . . . . . . . . . . . . . . . . . . 35
	7.1.2. Example SDP for Flexible FEC Protection with explicit		7.1.2. Example SDP for Flexible FEC Protection with explicit
	signalling in the SDP . . . . . . . . . . . . . . . . 38		signalling in the SDP . . . . . . . . . . . . . . . . 35
	7.2. On the Use of the RTP Stream Identifier Source		7.2. On the Use of the RTP Stream Identifier Source
	Description . . . . . . . . . . . . . . . . . . . . . . . 38		Description . . . . . . . . . . . . . . . . . . . . . . . 36
	8. Congestion Control Considerations . . . . . . . . . . . . . . 38		8. Congestion Control Considerations . . . . . . . . . . . . . . 36
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 39		9. Security Considerations . . . . . . . . . . . . . . . . . . . 37
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 40		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
	12.1. Normative References . . . . . . . . . . . . . . . . . . 40		12.1. Normative References . . . . . . . . . . . . . . . . . . 38
	12.2. Informative References . . . . . . . . . . . . . . . . . 41		12.2. Informative References . . . . . . . . . . . . . . . . . 39
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
	1. Introduction		1. Introduction
	This document defines new RTP payload formats for the Forward Error		This document defines new RTP payload formats for the Forward Error
	Correction (FEC) that is generated by the non-interleaved and		Correction (FEC) that is generated by the non-interleaved and
	interleaved parity codes from a source media encapsulated in RTP		interleaved parity codes from a source media encapsulated in RTP
	[RFC3550]. The type of the source media protected by these parity		[RFC3550]. The type of the source media protected by these parity
	codes can be audio, video, text or application. The FEC data are		codes can be audio, video, text or application. The FEC data are
	generated according to the media type parameters, which are		generated according to the media type parameters, which are
	communicated out-of-band (e.g., in SDP). Furthermore, the		communicated out-of-band (e.g., in SDP). Furthermore, the
	skipping to change at page 10, line 38 ¶		skipping to change at page 10, line 38 ¶
	o 1-D Non-interleaved FEC Protection: Overhead = 1/L		o 1-D Non-interleaved FEC Protection: Overhead = 1/L
	o 1-D Interleaved FEC Protection: Overhead = 1/D		o 1-D Interleaved FEC Protection: Overhead = 1/D
	o 2-D Parity FEC Protection: Overhead = 1/L + 1/D		o 2-D Parity FEC Protection: Overhead = 1/L + 1/D
	where L and D are the number of columns and rows in the source block,		where L and D are the number of columns and rows in the source block,
	respectively.		respectively.
	1.1.7. Repair Window Considerations		1.1.7. FEC Protection with Retransmission
	The value for the repair window duration depends on the L and D		This specification supports both forward error correction, i.e.
	values and cannot be chosen arbitrarily. More specifically, L and D		before any loss is reported, as well as retransmission of source
	values determine the lower limit for the repair window duration. The		packets after loss is reported. The retransmission includes the RTP
	upper limit of the repair window duration does not depend on the L		header of the source packet in addition to the payload. Therefore,
	and D values. The rate of the source streams should also be		endpoints supporting other RTP retransmission methods (see [RFC4588])
	considered, as the repair window duration should ideally span several		in addition to FLEX FEC MUST only use the FLEX FEC retransmission
	packetization intervals in order to leverage the error correction		method.
	capabilities of the parity code.
			1.1.8. Repair Window Considerations
			The value for the repair window duration is related to the maximum L
			and D values that are expected during a FLEX FEC session and
			therefore cannot be chosen arbitrarily. Repair packets that include
			L and D values larger than the repair window MUST not be sent. The
			rate of the source streams should also be considered, as the repair
			window duration should ideally span several packetization intervals
			in order to leverage the error correction capabilities of the parity
			code.
			Since the FEC configuration can change with each repair packet (see
			Section 4.2.2), for any given repair packet the FLEX FEC receiver
			MUST support all possible L and D combinations (both 1-D and 2-D
			interleaved over all source flows) and all flexible mask
			configurations (over all source flows) within the repair window to
			which it has agreed (e.g. through SDP or out-of-band signaling) for a
			FLEX FEC RTP session. In addition, the FLEX FEC receiver MUST
			support receipt of a retransmission of any source flow packet within
			the repair window to which it has agreed.
	2. Requirements Notation		2. Requirements Notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. Definitions and Notations		3. Definitions and Notations
	skipping to change at page 16, line 5 ¶		skipping to change at page 16, line 5 ¶
	: :		: :
	Figure 10: FEC Header		Figure 10: FEC Header
	The Repair "Payload", which follows the FEC Header, includes repair		The Repair "Payload", which follows the FEC Header, includes repair
	of everything following the fixed 12-byte RTP header of each source		of everything following the fixed 12-byte RTP header of each source
	packet, including any CSRC identifier list and header extensions if		packet, including any CSRC identifier list and header extensions if
	present. An overview on how the repair payload can be used to		present. An overview on how the repair payload can be used to
	recover source packets is provided Section 6.		recover source packets is provided Section 6.
	+---+---+----------------------------------------------------------+		+---+---+-----------------------------------------------------+
	| R | F | FEC Header variant |		| R | F | FEC Header variant |
	+---+---+----------------------------------------------------------+		+---+---+-----------------------------------------------------+
	| 0 | 0 | Flexible FEC Mask fields indicate source packets |		| 0 | 0 | Flexible FEC Mask fields indicate source packets |
	| 0 | 1 | Fixed FEC L/D (cols/rows) fields indicate source packets |		| 0 | 1 | Fixed FEC L/D (cols/rows) indicate source packets |
	| 1 | 0 | Retransmission of a single source packet |		| 1 | 0 | Retransmission of a single source packet |
	| 1 | 1 | Invalid, MUST NOT send, MUST ignore if received |		| 1 | 1 | Reserved for future use, MUST NOT send, MUST ignore |
	+---+---+----------------------------------------------------------+		+---+---+-----------------------------------------------------+
	Figure 11: R and F bit values for FEC Header variants		Figure 11: R and F bit values for FEC Header variants
	The first variant, when R=0 and F=0, has a mask to signal protected		The first variant, when R=0 and F=0, has a mask to signal protected
	source packets, as shown in Figure 12.		source packets, as shown in Figure 12.
	The second variant, when R=0 and F=1, has a number of columns (L) and		The second variant, when R=0 and F=1, has a number of columns (L) and
	rows (D) to signal protected source packets, as shown in Figure 13.		rows (D) to signal protected source packets, as shown in Figure 13.
	The final variant, when R=1 and F=0, is a retransmission format as		The final variant, when R=1 and F=0, is a retransmission format as
	shown in Figure 15.		shown in Figure 15.
	No variant uses R=1 and F=1, which is invalid, and MUST NOT be sent		No variant presently uses R=1 and F=1, which is reserved for future
	by senders, and MUST be ignored by receivers.		use. Current FLEX FEC implementations MUST NOT send packets with
			this variant, and receivers MUST ignore these packets. Future FLEX
			FEC implementations may use this by updating the media type
			registration.
	The FEC header for all variants consists of the following common		The FEC header for all variants consists of the following common
	fields:		fields:
	o The R bit MUST be set to 1 to indicate a retransmission packet,		o The R bit MUST be set to 1 to indicate a retransmission packet,
	and MUST be set to 0 for FEC repair packets.		and MUST be set to 0 for FEC repair packets.
	o The F bit indicates the type of FEC repair packets, as shown in		o The F bit indicates the type of FEC repair packets, as shown in
	Figure 11, when the R bit is 0. The F bit MUST be set to 0 when		Figure 11, when the R bit is 0. The F bit MUST be set to 0 when
	the R bit is 1 for retransmission packets.		the R bit is 1 for retransmission packets.
	skipping to change at page 19, line 5 ¶		skipping to change at page 19, line 5 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ... next SN base and L/D for CSRC_i in CSRC list ... |		| ... next SN base and L/D for CSRC_i in CSRC list ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	: Repair "Payload" follows FEC Header :		: Repair "Payload" follows FEC Header :
	: :		: :
	Figure 13: FEC Header for F=1		Figure 13: FEC Header for F=1
	Consequently, the following conditions occur for L and D values:		Consequently, the following conditions occur for L and D values:
	If L=0, D=0, use the optional payload format parameters for L and D.		If L=0, D=0, reserved for future use,
			MUST NOT send, MUST ignore if received.
	If L>0, D=0, indicates Row FEC, and no column FEC will follow.		If L>0, D=0, indicates row FEC, and no column FEC will follow (1D).
	Hence, FEC = SN, SN+1, SN+2, ... , SN+(L-1), SN+L.		Source packets for each row: SN, SN+1, ..., SN+(L-1)
	If L>0, D=1, indicates Row FEC, and column FEC will follow.		If L>0, D=1, indicates row FEC, and column FEC will follow (2D).
	Hence, FEC = SN, SN+1, SN+2, ... , SN+(L-1), SN+L will be		Source packets for each row: SN, SN+1, ..., SN+(L-1)
	produced for each row.		Source packets for each col: SN, SN+L, ..., SN+(D-1)*L
	Then FEC = SN, SN+L, SN+2L, ..., SN+(D-1)L will be produced		After all row FEC packets have been sent,
	for each column.		then the column FEC packets will be sent.
	After all row FEC's have been sent, then the column FEC's
	will be sent.
	If L>0, D>1, indicates column FEC of every L packet		If L>0, D>1, indicates column FEC of every L packet, D times.
	in a group of D packets starting at SN base.		Source packets for each col: SN, SN+L, ..., SN+(D-1)*L
	Hence, FEC = SN+(Lx0), SN+(Lx1), ... , SN+(LxD).
	Figure 14: Interpreting the L and D field values		Figure 14: Interpreting the L and D field values
	Given the 8-bit limit on L and D (as depicted in Figure 13), the		Given the 8-bit limit on L and D (as depicted in Figure 13), the
	maximum value of either parameter is 255. The "optional payload		maximum value of either parameter is 255. If L=0 and D=0 are in a
	format parameters" (Figure 14) to be used when L=0 and D=0 can be		packet, then the repair packet MUST be ignored by the receiver. In
	determined through out-of-band signaling (see Section 5). If L=0 and		addition when L=1 and D=0, the repair packet becomes a retransmission
	D=0 and cannot be determined through out-of-band signaling, then the		of a corresponding source packet.
	repair packet MUST be ignored by the receiver. In addition when L=1
	and D=0, the repair packet becomes a retransmission of a
	corresponding source packet.
	The values of L and D for a given block of recovery data will		The values of L and D for a given block of recovery data will
	correspond to the type of recovery in use for that block of data. In		correspond to the type of recovery in use for that block of data. In
	particular, for 2-D repair, the (L,D) values may not be constant		particular, for 2-D repair, the (L,D) values may not be constant
	across all packets for a given SSRC being repaired. Similarly, the L		across all packets for a given SSRC being repaired. Similarly, the L
	and D values can differ across different blocks of repair data		and D values can differ across different blocks of repair data
	(repairing different SSRCs) in a single packet.		(repairing different SSRCs) in a single packet. If the values of L
			and D result in a repair packet that exceed the repair window of the
			FLEX FEC session, then the repair packet MUST be ignored.
	It should be noted that the flexible mask-based approach may be		It should be noted that the flexible mask-based approach may be
	inefficient for protecting a large number of source packets, or		inefficient for protecting a large number of source packets, or
	impossible to signal if larger than the largest mask size. In such		impossible to signal if larger than the largest mask size. In such
	cases, the fixed columns and rows variant may be more useful.		cases, the fixed columns and rows variant may be more useful.
	4.2.2.3. FEC Header for Retransmissions		4.2.2.3. FEC Header for Retransmissions
	When R=1 and F=0, the FEC packet is a retransmission of a single		When R=1 and F=0, the FEC packet is a retransmission of a single
	source packet. Note that the layout of this retransmission packet is		source packet. Note that the layout of this retransmission packet is
	skipping to change at page 21, line 26 ¶		skipping to change at page 21, line 22 ¶
	o rate: The RTP timestamp (clock) rate. The rate SHALL be larger		o rate: The RTP timestamp (clock) rate. The rate SHALL be larger
	than 1000 Hz to provide sufficient resolution to RTCP operations.		than 1000 Hz to provide sufficient resolution to RTCP operations.
	However, it is RECOMMENDED to select the rate that matches the		However, it is RECOMMENDED to select the rate that matches the
	rate of the protected source RTP stream.		rate of the protected source RTP stream.
	o repair-window: The time that spans the source packets and the		o repair-window: The time that spans the source packets and the
	corresponding repair packets. The size of the repair window is		corresponding repair packets. The size of the repair window is
	specified in microseconds.		specified in microseconds.
	Optional parameters:
	o L: indicates the number of columns of the source block that are
	protected by this FEC block and it applies to all the source
	SSRCs. L is a positive integer.
	o D: indicates the number of rows of the source block that are
	protected by this FEC block and it applies to all the source
	SSRCs. D is a positive integer.
	o ToP: indicates the type of protection applied by the sender: 0 for
	1-D interleaved FEC protection, 1 for 1-D non-interleaved FEC
	protection, 2 for 2-D parity FEC protection, and 3 for
	retransmission. There can only be one value listed for ToP. The
	absence of the ToP field means that all protection types are
	allowed. An offer that lists more than one ToP value MUST be
	rejected.
	Note that both L and D in the optional parameters should follow the
	value pairings stated in Section 4.2.2.2 if included.
	Encoding considerations: This media type is framed (See Section 4.8		Encoding considerations: This media type is framed (See Section 4.8
	in the template document [RFC6838]) and contains binary data.		in the template document [RFC6838]) and contains binary data.
	Security considerations: See Section 9 of [RFCXXXX].		Security considerations: See Section 9 of [RFCXXXX].
	Interoperability considerations: None.		Interoperability considerations: None.
	Published specification: [RFCXXXX].		Published specification: [RFCXXXX].
	Applications that use this media type: Multimedia applications that		Applications that use this media type: Multimedia applications that
	skipping to change at page 22, line 46 ¶		skipping to change at page 22, line 22 ¶
	o rate: The RTP timestamp (clock) rate. The rate SHALL be larger		o rate: The RTP timestamp (clock) rate. The rate SHALL be larger
	than 1000 Hz to provide sufficient resolution to RTCP operations.		than 1000 Hz to provide sufficient resolution to RTCP operations.
	However, it is RECOMMENDED to select the rate that matches the		However, it is RECOMMENDED to select the rate that matches the
	rate of the protected source RTP stream.		rate of the protected source RTP stream.
	o repair-window: The time that spans the source packets and the		o repair-window: The time that spans the source packets and the
	corresponding repair packets. The size of the repair window is		corresponding repair packets. The size of the repair window is
	specified in microseconds.		specified in microseconds.
	Optional parameters:
	o L: indicates the number of columns of the source block that are
	protected by this FEC block and it applies to all the source
	SSRCs. L is a positive integer.
	o D: indicates the number of rows of the source block that are
	protected by this FEC block and it applies to all the source
	SSRCs. D is a positive integer.
	o ToP: indicates the type of protection applied by the sender: 0 for
	1-D interleaved FEC protection, 1 for 1-D non-interleaved FEC
	protection, 2 for 2-D parity FEC protection, and 3 for
	retransmission. There can only be one value listed for ToP. The
	absence of the ToP field means that all protection types are
	allowed. An offer that lists more than one ToP value MUST be
	rejected.
	Note that both L and D in the optional parameters should follow the
	value pairings stated in Section 4.2.2.2 if included.
	Encoding considerations: This media type is framed (See Section 4.8		Encoding considerations: This media type is framed (See Section 4.8
	in the template document [RFC6838]) and contains binary data.		in the template document [RFC6838]) and contains binary data.
	Security considerations: See Section 9 of [RFCXXXX].		Security considerations: See Section 9 of [RFCXXXX].
	Interoperability considerations: None.		Interoperability considerations: None.
	Published specification: [RFCXXXX].		Published specification: [RFCXXXX].
	Applications that use this media type: Multimedia applications that		Applications that use this media type: Multimedia applications that
	skipping to change at page 24, line 22 ¶		skipping to change at page 23, line 22 ¶
	o rate: The RTP timestamp (clock) rate. The rate SHALL be larger		o rate: The RTP timestamp (clock) rate. The rate SHALL be larger
	than 1000 Hz to provide sufficient resolution to RTCP operations.		than 1000 Hz to provide sufficient resolution to RTCP operations.
	However, it is RECOMMENDED to select the rate that matches the		However, it is RECOMMENDED to select the rate that matches the
	rate of the protected source RTP stream.		rate of the protected source RTP stream.
	o repair-window: The time that spans the source packets and the		o repair-window: The time that spans the source packets and the
	corresponding repair packets. The size of the repair window is		corresponding repair packets. The size of the repair window is
	specified in microseconds.		specified in microseconds.
	Optional parameters:
	o L: indicates the number of columns of the source block that are
	protected by this FEC block and it applies to all the source
	SSRCs. L is a positive integer.
	o D: indicates the number of rows of the source block that are
	protected by this FEC block and it applies to all the source
	SSRCs. D is a positive integer.
	o ToP: indicates the type of protection applied by the sender: 0 for
	1-D interleaved FEC protection, 1 for 1-D non-interleaved FEC
	protection, 2 for 2-D parity FEC protection, and 3 for
	retransmission. There can only be one value listed for ToP. The
	absence of the ToP field means that all protection types are
	allowed. An offer that lists more than one ToP value MUST be
	rejected.
	Note that both L and D in the optional parameters should follow the
	value pairings stated in Section 4.2.2.2 if included.
	Encoding considerations: This media type is framed (See Section 4.8		Encoding considerations: This media type is framed (See Section 4.8
	in the template document [RFC6838]) and contains binary data.		in the template document [RFC6838]) and contains binary data.
	Security considerations: See Section 9 of [RFCXXXX].		Security considerations: See Section 9 of [RFCXXXX].
	Interoperability considerations: None.		Interoperability considerations: None.
	Published specification: [RFCXXXX].		Published specification: [RFCXXXX].
	Applications that use this media type: Multimedia applications that		Applications that use this media type: Multimedia applications that
	skipping to change at page 25, line 44 ¶		skipping to change at page 24, line 22 ¶
	o rate: The RTP timestamp (clock) rate. The rate SHALL be larger		o rate: The RTP timestamp (clock) rate. The rate SHALL be larger
	than 1000 Hz to provide sufficient resolution to RTCP operations.		than 1000 Hz to provide sufficient resolution to RTCP operations.
	However, it is RECOMMENDED to select the rate that matches the		However, it is RECOMMENDED to select the rate that matches the
	rate of the protected source RTP stream.		rate of the protected source RTP stream.
	o repair-window: The time that spans the source packets and the		o repair-window: The time that spans the source packets and the
	corresponding repair packets. The size of the repair window is		corresponding repair packets. The size of the repair window is
	specified in microseconds.		specified in microseconds.
	Optional parameters:
	o L: indicates the number of columns of the source block that are
	protected by this FEC block and it applies to all the source
	SSRCs. L is a positive integer.
	o D: indicates the number of rows of the source block that are
	protected by this FEC block and it applies to all the source
	SSRCs. D is a positive integer.
	o ToP: indicates the type of protection applied by the sender: 0 for
	1-D interleaved FEC protection, 1 for 1-D non-interleaved FEC
	protection, 2 for 2-D parity FEC protection, and 3 for
	retransmission. There can only be one value listed for ToP. The
	absence of the ToP field means that all protection types are
	allowed. An offer that lists more than one ToP value MUST be
	rejected.
	Note that both L and D in the optional parameters should follow the
	value pairings stated in Section 4.2.2.2 if included.
	Encoding considerations: This media type is framed (See Section 4.8		Encoding considerations: This media type is framed (See Section 4.8
	in the template document [RFC6838]) and contains binary data.		in the template document [RFC6838]) and contains binary data.
	Security considerations: See Section 9 of [RFCXXXX].		Security considerations: See Section 9 of [RFCXXXX].
	Interoperability considerations: None.		Interoperability considerations: None.
	Published specification: [RFCXXXX].		Published specification: [RFCXXXX].
	Applications that use this media type: Multimedia applications that		Applications that use this media type: Multimedia applications that
	skipping to change at page 27, line 4 ¶		skipping to change at page 25, line 11 ¶
	Change controller: IETF Audio/Video Transport Payloads Working Group		Change controller: IETF Audio/Video Transport Payloads Working Group
	delegated from the IESG (or it's successor as delegated by the IESG).		delegated from the IESG (or it's successor as delegated by the IESG).
	5.2. Mapping to SDP Parameters		5.2. Mapping to SDP Parameters
	Applications that use the RTP transport commonly use Session		Applications that use the RTP transport commonly use Session
	Description Protocol (SDP) [RFC4566] to describe their RTP sessions.		Description Protocol (SDP) [RFC4566] to describe their RTP sessions.
	The information that is used to specify the media types in an RTP		The information that is used to specify the media types in an RTP
	session has specific mappings to the fields in an SDP description.		session has specific mappings to the fields in an SDP description.
	This section provides these mappings for the media subtypes		This section provides these mappings for the media subtypes
	registered by this document. Note that if an application does not		registered by this document. Note that if an application does not
	use SDP to describe the RTP sessions, an appropriate mapping must be		use SDP to describe the RTP sessions, an appropriate mapping must be
	defined and used to specify the media types and their parameters for		defined and used to specify the media types and their parameters for
	the control/description protocol employed by the application.		the control/description protocol employed by the application.
	The mapping of the media type specification for "non-interleaved-		The mapping of the media type specification for "flexfec" and its
	parityfec" and "interleaved-parityfec" and their parameters in SDP is		associated parameters in SDP is as follows:
	as follows:
	o The media type (e.g., "application") goes into the "m=" line as		o The media type (e.g., "application") goes into the "m=" line as
	the media name.		the media name.
	o The media subtype goes into the "a=rtpmap" line as the encoding		o The media subtype goes into the "a=rtpmap" line as the encoding
	name. The RTP clock rate parameter ("rate") also goes into the		name. The RTP clock rate parameter ("rate") also goes into the
	"a=rtpmap" line as the clock rate.		"a=rtpmap" line as the clock rate.
	o The remaining required payload-format-specific parameters go into		o The remaining required payload-format-specific parameters go into
	the "a=fmtp" line by copying them directly from the media type		the "a=fmtp" line by copying them directly from the media type
	string as a semicolon-separated list of parameter=value pairs.		string as a semicolon-separated list of parameter=value pairs.
	SDP examples are provided in Section 7.1.		SDP examples are provided in Section 7.1.
	5.2.1. Offer-Answer Model Considerations		5.2.1. Offer-Answer Model Considerations
	When offering 1-D interleaved parity FEC over RTP using SDP in an		When offering parity FEC over RTP using SDP in an Offer/Answer model
	Offer/Answer model [RFC3264], the following considerations apply:		[RFC3264], the following considerations apply:
	o Each combination of the L and D parameters produces a different
	FEC data and is not compatible with any other combination. A
	sender application may desire to offer multiple offers with
	different sets of L and D values as long as the parameter values
	are valid. The receiver SHOULD choose the offer that has a
	sufficient amount of interleaving. If multiple such offers exist,
	the receiver may choose the offer that has the lowest overhead or
	the one that requires the smallest amount of buffering. The
	selection depends on the application requirements.
	o The value for the repair-window parameter depends on the L and D
	values. Based on the values of L and D, a lower bound on the
	repair-window can be inferred (see Section 1.1.7).
	o Although combinations with the same L and D values but with		o A sender application will indicate a repair window consistent with
	different repair-window sizes produce the same FEC data, such		the desired amount of protection. Note that since the sender can
	combinations are still considered different offers. The size of		change the FEC configuration on a packet-by-packet basis, the
	the repair-window is related to the maximum delay between the		receiver must support any valid FLEX FEC configuration within the
	transmission of a source packet and the associated repair packet.		repair window associated with the offer (see Section 4.2.2). If
			the receiver cannot support the offered repair window it MUST
			reject the offer.
	This directly impacts the buffering requirement on the receiver		o The size of the repair-window is related to the maximum delay
	side and the receiver must consider this when choosing an offer.		between the transmission of a source packet and the associated
			repair packet. This directly impacts the buffering requirement on
			the receiver side and the receiver must consider this when
			choosing an offer.
	o Any unknown option in the offer must be ignored and deleted from		o Any unknown option in the offer must be ignored and deleted from
	the answer (see Section 6 of [RFC3264]). If FEC is not desired by		the answer (see Section 6 of [RFC3264]). If FEC is not desired by
	the receiver, it can be deleted from the answer.		the receiver, it can be deleted from the answer.
	5.2.2. Declarative Considerations		5.2.2. Declarative Considerations
	In declarative usage, like SDP in the Real-time Streaming Protocol		In declarative usage, like SDP in the Real-time Streaming Protocol
	(RTSP, for RTSP 1.0 see [RFC2326] and for RTSP 2.0 see [RFC7826]) or		(RTSP, for RTSP 1.0 see [RFC2326] and for RTSP 2.0 see [RFC7826]) or
	the Session Announcement Protocol (SAP) [RFC2974], the following		the Session Announcement Protocol (SAP) [RFC2974], the following
	skipping to change at page 31, line 42 ¶		skipping to change at page 29, line 40 ¶
	source packets missing per column or row in set T, 1-D FEC protection		source packets missing per column or row in set T, 1-D FEC protection
	may fail to recover all the missing information.		may fail to recover all the missing information.
	When value of L is non-zero, the 8-bit fields indicate the offset of		When value of L is non-zero, the 8-bit fields indicate the offset of
	packets protected by an interleaved (D>0) or non-interleaved (D=0)		packets protected by an interleaved (D>0) or non-interleaved (D=0)
	FEC packet. Using a combination of interleaved and non-interleaved		FEC packet. Using a combination of interleaved and non-interleaved
	FEC repair packets can form 2-D protection patterns.		FEC repair packets can form 2-D protection patterns.
	Mathematically, for any received repair packet, p*, the sequence		Mathematically, for any received repair packet, p*, the sequence
	numbers of the source packets that are protected by this repair		numbers of the source packets that are protected by this repair
	packet are determined as follows, where p*_snb is the sequence number		packet are determined as follows, where SN is the sequence number
	base in the FEC header:		base in the FEC header:
	When D = 0:		For each SSRC (in CSRC list):
	p*_snb, p*_snb+1,..., p*_snb+L		When D <= 1: Source packets for each row: SN, SN+1, ..., SN+(L-1)
	When D > 0:		When D > 1: Source packets for each col: SN, SN+L, ..., SN+(D-1)*L
	p*_snb, p*_snb+(Lx1), p*_snb+(Lx2),..., p*_snb+(LxD)
	6.3.1.3. Signaled in SDP
	If the endpoint relies entirely on out-of-band signaling (R=0, F=1,
	L=0, D=0 in the FEC header), then this information may be inferred
	from the media type parameters specified in the SDP description.
	Furthermore, the payload type field in the RTP header assists the
	receiver to distinguish an interleaved or non-interleaved FEC packet.
	Mathematically, for any received repair packet, p*, the sequence
	numbers of the source packets that are protected by this repair
	packet are determined as follows:
	p*_snb + i * X_1 (modulo 65536)
	where p*_snb denotes the value in the SN base field of p*'s FEC
	header, X_1 is set to L and 1 for the interleaved and non-interleaved
	FEC repair packets, respectively, and
	0 <= i < X_2
	where X_2 is set to D and L for the interleaved and non-interleaved
	FEC repair packets, respectively.
	6.3.2. Recovering the RTP Header		6.3.2. Recovering the RTP Header
	For a given set T, the procedure for the recovery of the RTP header		For a given set T, the procedure for the recovery of the RTP header
	of the missing packet, whose sequence number is denoted by SEQNUM, is		of the missing packet, whose sequence number is denoted by SEQNUM, is
	as follows:		as follows:
	1. For each of the source packets that are successfully received in		1. For each of the source packets that are successfully received in
	T, compute the 80-bit string by concatenating the first 64 bits		T, compute the 80-bit string by concatenating the first 64 bits
	of their RTP header and the unsigned network-ordered 16-bit		of their RTP header and the unsigned network-ordered 16-bit
	skipping to change at page 37, line 43 ¶		skipping to change at page 35, line 25 ¶
	SSRCs. The repair window is set to 200 ms.		SSRCs. The repair window is set to 200 ms.
	v=0		v=0
	o=mo 1122334455 1122334466 IN IP4 fec.example.com		o=mo 1122334455 1122334466 IN IP4 fec.example.com
	s=FlexFEC minimal SDP signalling Example		s=FlexFEC minimal SDP signalling Example
	t=0 0		t=0 0
	m=video 30000 RTP/AVP 96 98		m=video 30000 RTP/AVP 96 98
	c=IN IP4 233.252.0.1/127		c=IN IP4 233.252.0.1/127
	a=rtpmap:96 VP8/90000		a=rtpmap:96 VP8/90000
	a=rtpmap:98 flexfec/90000		a=rtpmap:98 flexfec/90000
	a=fmtp:98; repair-window=200ms		a=fmtp:98; repair-window=200000
	7.1.2. Example SDP for Flexible FEC Protection with explicit signalling		7.1.2. Example SDP for Flexible FEC Protection with explicit signalling
	in the SDP		in the SDP
	This example shows one source video stream (ssrc:1234) and one FEC		This example shows one source video stream (ssrc:1234) and one FEC
	repair streams (ssrc:2345). One FEC group is formed with the		repair streams (ssrc:2345). One FEC group is formed with the
	"a=ssrc-group:FEC-FR 1234 2345" line. The source and repair streams		"a=ssrc-group:FEC-FR 1234 2345" line. The source and repair streams
	are multiplexed on different SSRCs. The repair window is set to 200		are multiplexed on different SSRCs. The repair window is set to 200
	ms.		ms.
	v=0		v=0
	o=ali 1122334455 1122334466 IN IP4 fec.example.com		o=ali 1122334455 1122334466 IN IP4 fec.example.com
	s=2-D Parity FEC with no in band signalling Example		s=2-D Parity FEC with no in band signalling Example
	t=0 0		t=0 0
	m=video 30000 RTP/AVP 100 110		m=video 30000 RTP/AVP 100 110
	c=IN IP4 192.0.2.0/24		c=IN IP4 192.0.2.0/24
	a=rtpmap:100 MP2T/90000		a=rtpmap:100 MP2T/90000
	a=rtpmap:110 flexfec/90000		a=rtpmap:110 flexfec/90000
	a=fmtp:110 L:5; D:10; ToP:2; repair-window:200000		a=fmtp:110; repair-window:200000
	a=ssrc:1234		a=ssrc:1234
	a=ssrc:2345		a=ssrc:2345
	a=ssrc-group:FEC-FR 1234 2345		a=ssrc-group:FEC-FR 1234 2345
	7.2. On the Use of the RTP Stream Identifier Source Description		7.2. On the Use of the RTP Stream Identifier Source Description
	The RTP Stream Identifier Source Description [I-D.ietf-avtext-rid] is		The RTP Stream Identifier Source Description [I-D.ietf-avtext-rid] is
	a format that can be used to identify a single RTP source stream		a format that can be used to identify a single RTP source stream
	along with an associated repair stream. However, this specification		along with an associated repair stream. However, this specification
	already defines a method of source and repair stream identification		already defines a method of source and repair stream identification
	skipping to change at page 42, line 34 ¶		skipping to change at page 40, line 11 ¶
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,		Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
	December 2005, <https://www.rfc-editor.org/info/rfc4301>.		December 2005, <https://www.rfc-editor.org/info/rfc4301>.
	[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,		[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
	"Extended RTP Profile for Real-time Transport Control		"Extended RTP Profile for Real-time Transport Control
	Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,		Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
	DOI 10.17487/RFC4585, July 2006,		DOI 10.17487/RFC4585, July 2006,
	<https://www.rfc-editor.org/info/rfc4585>.		<https://www.rfc-editor.org/info/rfc4585>.
			[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
			Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
			DOI 10.17487/RFC4588, July 2006,
			<https://www.rfc-editor.org/info/rfc4588>.
	[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error		[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error
	Correction", RFC 5109, DOI 10.17487/RFC5109, December		Correction", RFC 5109, DOI 10.17487/RFC5109, December
	2007, <https://www.rfc-editor.org/info/rfc5109>.		2007, <https://www.rfc-editor.org/info/rfc5109>.
	[RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE		[RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE
	Report Block Type for RTP Control Protocol (RTCP) Extended		Report Block Type for RTP Control Protocol (RTCP) Extended
	Reports (XRs)", RFC 5725, DOI 10.17487/RFC5725, February		Reports (XRs)", RFC 5725, DOI 10.17487/RFC5725, February
	2010, <https://www.rfc-editor.org/info/rfc5725>.		2010, <https://www.rfc-editor.org/info/rfc5725>.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
End of changes. 37 change blocks.
	228 lines changed or deleted		136 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/