< draft-ietf-payload-flexible-fec-scheme-14.txt		draft-ietf-payload-flexible-fec-scheme-15.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: July 7, 2019 callstats.io		Expires: July 17, 2019 callstats.io
	A. Begen		A. Begen
	Networked Media		Networked Media
	G. Mandyam		G. Mandyam
	Qualcomm Inc.		Qualcomm Inc.
	January 3, 2019		January 13, 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-14		draft-ietf-payload-flexible-fec-scheme-15
	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, where a number of FEC repair
	packets are generated from a set of source packets from one or more		packets are generated from a set of source packets from one or more
	source RTP streams. These FEC repair packets are sent in a		source RTP streams. These FEC repair packets are sent in a
	redundancy RTP stream separate from the source RTP stream(s) that		redundancy RTP stream separate from the source RTP stream(s) that
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 7 ¶
	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 July 7, 2019.		This Internet-Draft will expire on July 17, 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 17, line 12 ¶		skipping to change at page 17, line 12 ¶
	Timestamp (TS): The timestamp SHALL be set to a time corresponding		Timestamp (TS): The timestamp SHALL be set to a time corresponding
	to the repair packet's transmission time. Note that the timestamp		to the repair packet's transmission time. Note that the timestamp
	value has no use in the actual FEC protection process and is		value has no use in the actual FEC protection process and is
	usually useful for jitter calculations.		usually useful for jitter calculations.
	Synchronization Source (SSRC): The SSRC value for each repair		Synchronization Source (SSRC): The SSRC value for each repair
	stream SHALL be randomly assigned as per the guidelines provided		stream SHALL be randomly assigned as per the guidelines provided
	in Section 8 of [RFC3550]. This allows the sender to multiplex		in Section 8 of [RFC3550]. This allows the sender to multiplex
	the source and repair RTP streams in the same RTP session, or		the source and repair RTP streams in the same RTP session, or
	multiplex multiple repair streams in an RTP session. The repair		multiplex multiple repair streams in an RTP session. The repair
	streams' SSRC's CNAME MUST be identical to the CNAME of the source		streams' SSRC's CNAME SHOULD be identical to the CNAME of the
	RTP stream(s) that this repair stream protects. In cases when the		source RTP stream(s) that this repair stream protects. An FEC
	repair stream covers packets from multiple source RTP streams with		stream that protects multiple source RTP streams with different
	different CNAME values, any of these CNAME values MAY be used.		CNAME's uses the CNAME associated with the entity generating the
			FEC stream or the CNAME of the entity on whose behalf it performs
			the protection operation. In cases when the repair stream covers
			packets from multiple source RTP streams with different CNAME
			values, any of these CNAME values MAY be used.
	In some networks, the RTP Source, which produces the source		In some networks, the RTP Source, which produces the source
	packets and the FEC Source, which generates the repair packets		packets and the FEC Source, which generates the repair packets
	from the source packets may not be the same host. In such		from the source packets may not be the same host. In such
	scenarios, using the same CNAME for the source and repair RTP		scenarios, using the same CNAME for the source and repair RTP
	streams means that the RTP Source and the FEC Source will share		streams means that the RTP Source and the FEC Source will share
	the same CNAME (for this specific source-repair stream		the same CNAME (for this specific source-repair stream
	association). A common CNAME may be produced based on an		association). A common CNAME may be produced based on an
	algorithm that is known both to the RTP and FEC Source [RFC7022].		algorithm that is known both to the RTP and FEC Source [RFC7022].
	This usage is compliant with [RFC3550].		This usage is compliant with [RFC3550].
	skipping to change at page 26, line 28 ¶		skipping to change at page 26, line 28 ¶
	Published specification: [RFCXXXX].		Published specification: [RFCXXXX].
	Applications that use this media type: Multimedia applications that		Applications that use this media type: Multimedia applications that
	want to improve resiliency against packet loss by sending redundant		want to improve resiliency against packet loss by sending redundant
	data in addition to the source media.		data in addition to the source media.
	Fragment identifier considerations: None.		Fragment identifier considerations: None.
	Additional information: None.		Additional information: None.
	Person & email address to contact for further information: IESG		Person & email address to contact for further information: Varun
	<varun@callstats.io> and IETF Audio/Video Transport Payloads Working		Singh <iesg@ietf.org> and IETF Audio/Video Transport Payloads Working
	Group (or it's successor as delegated by the IESG).		Group (or it's successor as delegated by the IESG).
	Intended usage: COMMON.		Intended usage: COMMON.
	Restriction on usage: This media type depends on RTP framing, and		Restriction on usage: This media type depends on RTP framing, and
	hence, is only defined for transport via RTP [RFC3550].		hence, is only defined for transport via RTP [RFC3550].
	Author: IESG <iesg@ietf.org>.		Author: Varun Singh <iesg@ietf.org>.
	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.1.2. Registration of video/flexfec		5.1.2. Registration of video/flexfec
	Type name: video		Type name: video
	Subtype name: flexfec		Subtype name: flexfec
	skipping to change at page 27, line 49 ¶		skipping to change at page 27, line 49 ¶
	Published specification: [RFCXXXX].		Published specification: [RFCXXXX].
	Applications that use this media type: Multimedia applications that		Applications that use this media type: Multimedia applications that
	want to improve resiliency against packet loss by sending redundant		want to improve resiliency against packet loss by sending redundant
	data in addition to the source media.		data in addition to the source media.
	Fragment identifier considerations: None.		Fragment identifier considerations: None.
	Additional information: None.		Additional information: None.
	Person & email address to contact for further information: IESG		Person & email address to contact for further information: Varun
	<iesg@ietf.org> and IETF Audio/Video Transport Payloads Working Group		Singh <iesg@ietf.org> and IETF Audio/Video Transport Payloads Working
	(or it's successor as delegated by the IESG).		Group (or it's successor as delegated by the IESG).
	Intended usage: COMMON.		Intended usage: COMMON.
	Restriction on usage: This media type depends on RTP framing, and		Restriction on usage: This media type depends on RTP framing, and
	hence, is only defined for transport via RTP [RFC3550].		hence, is only defined for transport via RTP [RFC3550].
	Author: IESG <iesg@ietf.org>.		Author: Varun Singh <iesg@ietf.org>.
	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.1.3. Registration of text/flexfec		5.1.3. Registration of text/flexfec
	Type name: text		Type name: text
	Subtype name: flexfec		Subtype name: flexfec
	skipping to change at page 29, line 22 ¶		skipping to change at page 29, line 22 ¶
	Published specification: [RFCXXXX].		Published specification: [RFCXXXX].
	Applications that use this media type: Multimedia applications that		Applications that use this media type: Multimedia applications that
	want to improve resiliency against packet loss by sending redundant		want to improve resiliency against packet loss by sending redundant
	data in addition to the source media.		data in addition to the source media.
	Fragment identifier considerations: None.		Fragment identifier considerations: None.
	Additional information: None.		Additional information: None.
	Person & email address to contact for further information: IESG		Person & email address to contact for further information: Varun
	<viesg@ietf.org> and IETF Audio/Video Transport Payloads Working		Singh <iesg@ietf.org> and IETF Audio/Video Transport Payloads Working
	Group (or it's successor as delegated by the IESG).		Group (or it's successor as delegated by the IESG).
	Intended usage: COMMON.		Intended usage: COMMON.
	Restriction on usage: This media type depends on RTP framing, and		Restriction on usage: This media type depends on RTP framing, and
	hence, is only defined for transport via RTP [RFC3550].		hence, is only defined for transport via RTP [RFC3550].
	Author: IESG <iesg@ietf.org>.		Author: Varun Singh <iesg@ietf.org>.
	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.1.4. Registration of application/flexfec		5.1.4. Registration of application/flexfec
	Type name: application		Type name: application
	Subtype name: flexfec		Subtype name: flexfec
	skipping to change at page 30, line 42 ¶		skipping to change at page 30, line 42 ¶
	Published specification: [RFCXXXX].		Published specification: [RFCXXXX].
	Applications that use this media type: Multimedia applications that		Applications that use this media type: Multimedia applications that
	want to improve resiliency against packet loss by sending redundant		want to improve resiliency against packet loss by sending redundant
	data in addition to the source media.		data in addition to the source media.
	Fragment identifier considerations: None.		Fragment identifier considerations: None.
	Additional information: None.		Additional information: None.
	Person & email address to contact for further information: IESG		Person & email address to contact for further information: Varun
	<iesg@ietf.org> and IETF Audio/Video Transport Payloads Working Group		Singh <iesg@ietf.org> and IETF Audio/Video Transport Payloads Working
	(or it's successor as delegated by the IESG).		Group (or it's successor as delegated by the IESG).
	Intended usage: COMMON.		Intended usage: COMMON.
	Restriction on usage: This media type depends on RTP framing, and		Restriction on usage: This media type depends on RTP framing, and
	hence, is only defined for transport via RTP [RFC3550].		hence, is only defined for transport via RTP [RFC3550].
	Author: IESG <iesg@ietf.org>.		Author: Varun Singh <iesg@ietf.org>.
	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.
End of changes. 13 change blocks.
	22 lines changed or deleted		26 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/