draft-ietf-avtext-rtp-duplication-04.txt		draft-ietf-avtext-rtp-duplication-05.txt
	AVTEXT A. Begen		AVTEXT A. Begen
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Standards Track C. Perkins		Intended status: Standards Track C. Perkins
	Expires: April 05, 2014 University of Glasgow		Expires: August 11, 2014 University of Glasgow
	October 02, 2013		February 7, 2014
	Duplicating RTP Streams		Duplicating RTP Streams
	draft-ietf-avtext-rtp-duplication-04		draft-ietf-avtext-rtp-duplication-05
	Abstract		Abstract
	Packet loss is undesirable for real-time multimedia sessions, but can		Packet loss is undesirable for real-time multimedia sessions, but can
	occur due to congestion, or other unplanned network outages. This is		occur due to congestion, or other unplanned network outages. This is
	especially true for IP multicast networks, where packet loss patterns		especially true for IP multicast networks, where packet loss patterns
	can vary greatly between receivers. One technique that can be used		can vary greatly between receivers. One technique that can be used
	to recover from packet loss without incurring unbounded delay for all		to recover from packet loss without incurring unbounded delay for all
	the receivers is to duplicate the packets and send them in separate		the receivers is to duplicate the packets and send them in separate
	redundant streams. This document explains how Real-time Transport		redundant streams. This document explains how Real-time Transport
	skipping to change at page 1, line 39		skipping to change at page 1, line 39
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 April 05, 2014.		This Internet-Draft will expire on August 11, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 21		skipping to change at page 2, line 21
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology and Requirements Notation . . . . . . . . . . . . 3		2. Terminology and Requirements Notation . . . . . . . . . . . . 3
	3. Dual Streaming Use Cases . . . . . . . . . . . . . . . . . . 3		3. Dual Streaming Use Cases . . . . . . . . . . . . . . . . . . 3
	3.1. Temporal Redundancy . . . . . . . . . . . . . . . . . . . 3		3.1. Temporal Redundancy . . . . . . . . . . . . . . . . . . . 3
	3.2. Spatial Redundancy . . . . . . . . . . . . . . . . . . . 4		3.2. Spatial Redundancy . . . . . . . . . . . . . . . . . . . 4
	3.3. Dual Streaming over a Single Path or Multiple Paths . . . 4		3.3. Dual Streaming over a Single Path or Multiple Paths . . . 4
	3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 5		3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 5
	4. Use of RTP and RTCP with Temporal Redundancy . . . . . . . . 6		4. Use of RTP and RTCP with Temporal Redundancy . . . . . . . . 6
	4.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 6		4.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 6
	4.2. Signaling Considerations . . . . . . . . . . . . . . . . 6		4.2. Signaling Considerations . . . . . . . . . . . . . . . . 7
	5. Use of RTP and RTCP with Spatial Redundancy . . . . . . . . . 8		5. Use of RTP and RTCP with Spatial Redundancy . . . . . . . . . 7
	5.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 8		5.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 8
	5.2. Signaling Considerations . . . . . . . . . . . . . . . . 8		5.2. Signaling Considerations . . . . . . . . . . . . . . . . 8
	6. Use of RTP and RTCP with Temporal and Spatial Redundancy . . 9		6. Use of RTP and RTCP with Temporal and Spatial Redundancy . . 9
	7. Congestion Control Considerations . . . . . . . . . . . . . . 9		7. Congestion Control Considerations . . . . . . . . . . . . . . 9
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 10		8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	11.1. Normative References . . . . . . . . . . . . . . . . . . 11		11.1. Normative References . . . . . . . . . . . . . . . . . . 11
	11.2. Informative References . . . . . . . . . . . . . . . . . 11		11.2. Informative References . . . . . . . . . . . . . . . . . 11
	skipping to change at page 4, line 39		skipping to change at page 4, line 39
	the receiving end, the node responsible for duplicate suppression can		the receiving end, the node responsible for duplicate suppression can
	look into various RTP header fields, for example SSRC and sequence		look into various RTP header fields, for example SSRC and sequence
	number, to identify and suppress the duplicate packets.		number, to identify and suppress the duplicate packets.
	If source-specific multicast (SSM) transport is used to carry such		If source-specific multicast (SSM) transport is used to carry such
	redundant streams, there will be a separate SSM session for each		redundant streams, there will be a separate SSM session for each
	redundant stream since the streams are sourced from different		redundant stream since the streams are sourced from different
	interfaces (i.e., IP addresses). Thus, the receiving host has to		interfaces (i.e., IP addresses). Thus, the receiving host has to
	join each SSM session separately.		join each SSM session separately.
	Alternatively, an RTP source might send the redundant streams to		Alternatively, destination host could also have multiple IP addresses
	separate IP destination addresses.		for an RTP source to send the redundant streams to.
	3.3. Dual Streaming over a Single Path or Multiple Paths		3.3. Dual Streaming over a Single Path or Multiple Paths
	Having described the characteristics of the streams, one can reach		Having described the characteristics of the streams, one can reach
	the following conclusions:		the following conclusions:
	1. When two routing-plane identical streams are used, the two		1. When two routing-plane identical streams are used, the two
	streams will have identical IP headers. This makes it		streams will have identical IP headers. This makes it
	impractical to forward the packets onto different paths. In		impractical to forward the packets onto different paths. In
	order to minimize packet loss, the packets belonging to one		order to minimize packet loss, the packets belonging to one
	skipping to change at page 5, line 43		skipping to change at page 5, line 43
	To summarize, dual streaming allows an application and a network to		To summarize, dual streaming allows an application and a network to
	work together to provide a near zero-loss transport with a bounded or		work together to provide a near zero-loss transport with a bounded or
	minimum delay. The additional advantage includes a predictable		minimum delay. The additional advantage includes a predictable
	bandwidth overhead that is proportional to the minimum bandwidth		bandwidth overhead that is proportional to the minimum bandwidth
	needed for the multimedia session, but independent of the number of		needed for the multimedia session, but independent of the number of
	receivers experiencing a packet loss and requesting a retransmission.		receivers experiencing a packet loss and requesting a retransmission.
	For a survey and comparison of similar approaches, refer to [IC2011].		For a survey and comparison of similar approaches, refer to [IC2011].
	3.4. Requirements		3.4. Requirements
	One of the following conditions is REQUIRED to hold in applications		One of the following conditions is currently REQUIRED to hold in
	using this specification:		applications using this specification:
	o The original and duplicate RTP streams are carried (with their own		o The original and duplicate RTP streams are carried (with their own
	SSRCs) in the same "m" line (There could be other RTP streams		SSRCs) in the same "m" line (There could be other RTP streams
	listed in the same "m" line)		listed in the same "m" line).
	o The original and duplicate RTP streams are carried in separate "m"		o The original and duplicate RTP streams are carried in separate "m"
	lines and there is no other RTP stream listed in either "m" line.		lines and there is no other RTP stream listed in either "m" line.
	When the original and duplicate RTP streams are carried in separate		When the original and duplicate RTP streams are carried in separate
	"m" lines in an SDP description and if the SDP description has one or		"m" lines in a Session Description Protocol (SDP) description and if
	more other RTP streams listed in either "m" line, duplication		the SDP description has one or more other RTP streams listed in
	grouping is not trivial and further signaling will be needed, which		either "m" line, duplication grouping is not trivial and further
	is left for future standardization.		signaling will be needed, which is left for future standardization.
	4. Use of RTP and RTCP with Temporal Redundancy		4. Use of RTP and RTCP with Temporal Redundancy
	To achieve temporal redundancy, the main and duplicate RTP streams		To achieve temporal redundancy, the main and duplicate RTP streams
	SHOULD be sent using the sample 5-tuple of transport protocol, source		SHOULD be sent using the sample 5-tuple of transport protocol, source
	and destination IP addresses, and source and destination transport		and destination IP addresses, and source and destination transport
	ports. Due to the possible presence of network address and port		ports. Due to the possible presence of network address and port
	translation (NAPT) devices, load balancers, or other middleboxes, use		translation (NAPT) devices, load balancers, or other middleboxes, use
	of anything other than an identical 5-tuple might also cause spatial		of anything other than an identical 5-tuple might also cause spatial
	redundancy (which might introduce an additional delay due to the		redundancy (which might introduce an additional delay due to the
	skipping to change at page 7, line 4		skipping to change at page 7, line 6
	between their timelines. However, the RTP timestamps and sequence		between their timelines. However, the RTP timestamps and sequence
	numbers MUST be identical in the main and duplicate streams, making		numbers MUST be identical in the main and duplicate streams, making
	the mapping quite trivial.		the mapping quite trivial.
	Both the main and duplicate RTP streams, and their corresponding RTCP		Both the main and duplicate RTP streams, and their corresponding RTCP
	reports, will be received. If RTCP is used, receivers MUST generate		reports, will be received. If RTCP is used, receivers MUST generate
	RTCP reports for both the main and duplicate streams in the usual		RTCP reports for both the main and duplicate streams in the usual
	way, treating them as entirely separate media streams.		way, treating them as entirely separate media streams.
	4.2. Signaling Considerations		4.2. Signaling Considerations
	Signaling is needed to allow the receiver to determine that an RTP		Signaling is needed to allow the receiver to determine that an RTP
	stream is a duplicate of another, rather than a separate stream that		stream is a duplicate of another, rather than a separate stream that
	needs to be rendered in parallel. There are two parts to this: an		needs to be rendered in parallel. There are two parts to this: an
	SDP extension is needed in the offer/answer exchange to negotiate		SDP extension is needed in the offer/answer exchange to negotiate
	support for temporal redundancy; and signaling is needed to indicate		support for temporal redundancy; and signaling is needed to indicate
	which stream is the duplicate (the latter can be done in-band using		which stream is the duplicate (the latter can be done in-band using
	an RTCP extension, or out-of-band in the SDP description).		an RTCP extension, or out-of-band in the SDP description).
	We require out-of-band signaling for both features. The required SDP		Out-of-band signalling is needed for both features. The SDP
	attribute to signal duplication in the SDP offer/answer exchange		attribute to signal duplication in the SDP offer/answer exchange
	('duplication-delay') is defined in		('duplication-delay') is defined in
	[I-D.ietf-mmusic-delayed-duplication]. The required SDP grouping		[I-D.ietf-mmusic-delayed-duplication]. The required SDP grouping
	semantics are defined in [I-D.ietf-mmusic-duplication-grouping].		semantics are defined in [RFC7104].
	In the following SDP example, a video stream is duplicated, and the		In the following SDP example, a video stream is duplicated, and the
	main and duplicate streams are transmitted in two separate SSRCs		main and duplicate streams are transmitted in two separate SSRCs
	(1000 and 1010):		(1000 and 1010):
	v=0		v=0
	o=ali 1122334455 1122334466 IN IP4 dup.example.com		o=ali 1122334455 1122334466 IN IP4 dup.example.com
	s=Delayed Duplication		s=Delayed Duplication
	t=0 0		t=0 0
	m=video 30000 RTP/AVP 100		m=video 30000 RTP/AVP 100
	c=IN IP4 233.252.0.1/127		c=IN IP4 233.252.0.1/127
	a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1		a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
	a=rtpmap:100 MP2T/90000		a=rtpmap:100 MP2T/90000
	a=ssrc:1000 cname:ch1a@example.com		a=ssrc:1000 cname:ch1a@example.com
	a=ssrc:1010 cname:ch1a@example.com		a=ssrc:1010 cname:ch1a@example.com
	a=ssrc-group:DUP 1000 1010		a=ssrc-group:DUP 1000 1010
	a=duplication-delay:50		a=duplication-delay:50
	a=mid:Ch1		a=mid:Ch1
	As specified in Section 3.2 of		As specified in Section 3.2 of [RFC7104], it is advisable that the
	[I-D.ietf-mmusic-duplication-grouping], it is advisable that the SSRC		SSRC listed first in the "a=ssrc-group:" line (i.e., SSRC of 1000) is
	listed first in the "a=ssrc-group:" line (i.e., SSRC of 1000) is sent		sent first, with the other SSRC (i.e., SSRC of 1010) being the time-
	first, with the other SSRC (i.e., SSRC of 1010) being the time-
	delayed duplicate. This is not critical, however, and a receiving		delayed duplicate. This is not critical, however, and a receiving
	host should size its playout buffer based on the 'duplication-delay'		host should size its playout buffer based on the 'duplication-delay'
	attribute, and play the stream that arrives first in preference, with		attribute, and play the stream that arrives first in preference, with
	the other stream acting as a repair stream, irrespective of the order		the other stream acting as a repair stream, irrespective of the order
	in which they are signaled.		in which they are signaled.
	5. Use of RTP and RTCP with Spatial Redundancy		5. Use of RTP and RTCP with Spatial Redundancy
	When using spatial redundancy, the duplicate RTP stream is sent using		When using spatial redundancy, the duplicate RTP stream is sent using
	a different source and/or destination address/port pair. This will		a different source and/or destination address/port pair. This will
	skipping to change at page 8, line 42		skipping to change at page 8, line 36
	numbers MUST be identical in the main and duplicate streams, making		numbers MUST be identical in the main and duplicate streams, making
	the mapping quite trivial.		the mapping quite trivial.
	Both the main and duplicate RTP streams, and their corresponding RTCP		Both the main and duplicate RTP streams, and their corresponding RTCP
	reports, will be received. If RTCP is used, receivers MUST generate		reports, will be received. If RTCP is used, receivers MUST generate
	RTCP reports for both the main and duplicate streams in the usual		RTCP reports for both the main and duplicate streams in the usual
	way, treating them as entirely separate media streams.		way, treating them as entirely separate media streams.
	5.2. Signaling Considerations		5.2. Signaling Considerations
	The required SDP grouping semantics have been defined in		The required SDP grouping semantics have been defined in [RFC7104].
	[I-D.ietf-mmusic-duplication-grouping]. In the following example,		In the following example, the redundant streams have different IP
	the redundant streams have different IP destination addresses. The		destination addresses. The example shows the same UDP port number
	example shows the same UDP port number and IP source address for each		and IP source address for each stream, but either or both could have
	stream, but either or both could have been different for the two		been different for the two streams.
	streams.
	v=0		v=0
	o=ali 1122334455 1122334466 IN IP4 dup.example.com		o=ali 1122334455 1122334466 IN IP4 dup.example.com
	s=DUP Grouping Semantics		s=DUP Grouping Semantics
	t=0 0		t=0 0
	a=group:DUP S1a S1b		a=group:DUP S1a S1b
	m=video 30000 RTP/AVP 100		m=video 30000 RTP/AVP 100
	c=IN IP4 233.252.0.1/127		c=IN IP4 233.252.0.1/127
	a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1		a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
	a=rtpmap:100 MP2T/90000		a=rtpmap:100 MP2T/90000
	a=mid:S1a		a=mid:S1a
	m=video 30000 RTP/AVP 101		m=video 30000 RTP/AVP 101
	c=IN IP4 233.252.0.2/127		c=IN IP4 233.252.0.2/127
	a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1		a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
	a=rtpmap:101 MP2T/90000		a=rtpmap:101 MP2T/90000
	a=mid:S1b		a=mid:S1b
	6. Use of RTP and RTCP with Temporal and Spatial Redundancy		6. Use of RTP and RTCP with Temporal and Spatial Redundancy
	This uses the same RTP/RTCP mechanisms from Sections Section 4 and		This uses the same RTP/RTCP mechanisms from Sections Section 4 and
	Section 5, plus a combination of both sets of signaling.		Section 5, plus a combination of both sets of signaling.
	7. Congestion Control Considerations		7. Congestion Control Considerations
	Duplicating RTP streams has several considerations in the context of		Duplicating RTP streams has several considerations in the context of
	congestion control. First of all, RTP duplication MUST NOT be used		congestion control. First of all, RTP duplication MUST NOT be used
	skipping to change at page 10, line 11		skipping to change at page 10, line 14
	points. Thus, these end-points will apply any congestion control, if		points. Thus, these end-points will apply any congestion control, if
	applicable, on the de-duplicated RTP stream. This output stream will		applicable, on the de-duplicated RTP stream. This output stream will
	have less losses than either of the original and duplicated stream,		have less losses than either of the original and duplicated stream,
	and the end-point will make congestion control decisions accordingly.		and the end-point will make congestion control decisions accordingly.
	However, if de-duplication takes place at the ultimate end-point,		However, if de-duplication takes place at the ultimate end-point,
	this end-point MUST consider the aggregate of the original and		this end-point MUST consider the aggregate of the original and
	duplicated RTP stream in any congestion control it wants to apply.		duplicated RTP stream in any congestion control it wants to apply.
	The end-point will observe the losses in each stream separately, and		The end-point will observe the losses in each stream separately, and
	this information can be used to fine-tune the duplication process.		this information can be used to fine-tune the duplication process.
	For example, the duplication interval can be adjusted based on the		For example, the duplication interval can be adjusted based on the
	duration of a common packet loss in both streams.		duration of a common packet loss in both streams. In these
			scenarios, the RTP Monitoring Framework[RFC6792] can be used to
			monitor the duplicated streams in the same way an ordinary RTP would
			be monitored.
	8. Security Considerations		8. Security Considerations
	The security considerations of [RFC3550],		The security considerations of [RFC3550],
	[I-D.ietf-mmusic-delayed-duplication],		[I-D.ietf-mmusic-delayed-duplication], [RFC7104], and any RTP
	[I-D.ietf-mmusic-duplication-grouping], and any RTP profiles and		profiles and payload formats in use apply.
	payload formats in use apply.
	Duplication can be performed end-to-end, with the media sender		Duplication can be performed end-to-end, with the media sender
	generating a duplicate RTP stream, and the receiver(s) performing de-		generating a duplicate RTP stream, and the receiver(s) performing de-
	duplication. In such cases, if the original media stream is to be		duplication. In such cases, if the original media stream is to be
	authenticated (e.g., using SRTP [RFC3711]) then the duplicate stream		authenticated (e.g., using SRTP [RFC3711]) then the duplicate stream
	also needs to be authenticated, and duplicate packets that fail the		also needs to be authenticated, and duplicate packets that fail the
	authentication check need to be discarded.		authentication check need to be discarded.
	Stream duplication and de-duplication can also be performed by in-		Stream duplication and de-duplication can also be performed by in-
	network middleboxes. Such middleboxes will need to rewrite the RTP		network middleboxes. Such middleboxes will need to rewrite the RTP
	skipping to change at page 11, line 30		skipping to change at page 11, line 33
	[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.		[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
	Jacobson, "RTP: A Transport Protocol for Real-Time		Jacobson, "RTP: A Transport Protocol for Real-Time
	Applications", STD 64, RFC 3550, July 2003.		Applications", STD 64, RFC 3550, July 2003.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[I-D.ietf-mmusic-delayed-duplication]		[I-D.ietf-mmusic-delayed-duplication]
	Begen, A., Cai, Y., and H. Ou, "Delayed Duplication		Begen, A., Cai, Y., and H. Ou, "Delayed Duplication
	Attribute in the Session Description Protocol", draft-		Attribute in the Session Description Protocol", draft-
	ietf-mmusic-delayed-duplication-02 (work in progress), May		ietf-mmusic-delayed-duplication-03 (work in progress),
	2013.		December 2013.
	[I-D.ietf-mmusic-duplication-grouping]		[RFC7104] Begen, A., Cai, Y., and H. Ou, "Duplication Grouping
	Begen, A., Cai, Y., and H. Ou, "Duplication Grouping		Semantics in the Session Description Protocol", RFC 7104,
	Semantics in the Session Description Protocol", draft-		January 2014.
	ietf-mmusic-duplication-grouping-03 (work in progress),
	July 2013.
	[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.		[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
	Norrman, "The Secure Real-time Transport Protocol (SRTP)",		Norrman, "The Secure Real-time Transport Protocol (SRTP)",
	RFC 3711, March 2004.		RFC 3711, March 2004.
	11.2. Informative References		11.2. Informative References
	[RFC2354] Perkins, C. and O. Hodson, "Options for Repair of		[RFC2354] Perkins, C. and O. Hodson, "Options for Repair of
	Streaming Media", RFC 2354, June 1998.		Streaming Media", RFC 2354, June 1998.
	[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.		[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
	Hakenberg, "RTP Retransmission Payload Format", RFC 4588,		Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
	July 2006.		July 2006.
	[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error		[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error
	Correction (FEC) Framework", RFC 6363, October 2011.		Correction (FEC) Framework", RFC 6363, October 2011.
			[RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the
			RTP Monitoring Framework", RFC 6792, November 2012.
	[IC2011] Evans, J., Begen, A., Greengrass, J., and C. Filsfils,		[IC2011] Evans, J., Begen, A., Greengrass, J., and C. Filsfils,
	"Toward Lossless Video Transport (to appear in IEEE		"Toward Lossless Video Transport (to appear in IEEE
	Internet Computing)", November 2011.		Internet Computing)", November 2011.
	Authors' Addresses		Authors' Addresses
	Ali Begen		Ali Begen
	Cisco		Cisco
	181 Bay Street		181 Bay Street
	Toronto, ON M5J 2T3		Toronto, ON M5J 2T3
End of changes. 21 change blocks.
	67 lines changed or deleted		69 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/