draft-ietf-mmusic-media-loopback-07.txt		draft-ietf-mmusic-media-loopback-08.txt
	K. Hedayat		K. Hedayat
	Internet Draft Brix Networks		Internet Draft Brix Networks
	Expires: June 2008 P. Jones		Expires: July 2008 P. Jones
	Cisco Systems, Inc.		Cisco Systems, Inc.
	A. Roychowdhury		A. Roychowdhury
	Hughes		Hughes Systique Corp.
	C. SivaChelvan		C. SivaChelvan
	Cisco Systems, Inc.		Cisco Systems, Inc.
	N. Stratton		N. Stratton
			BlinkMind, Inc.
	November 2007		N. Venna
			Brix Networks
			January 2008
	An Extension to the Session Description Protocol (SDP) for Media		An Extension to the Session Description Protocol (SDP) for Media
	Loopback		Loopback
	draft-ietf-mmusic-media-loopback-07		draft-ietf-mmusic-media-loopback-08
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 43		skipping to change at page 2, line 4
	documents at any time. It is inappropriate to use Internet-Drafts		documents at any time. It is inappropriate to use Internet-Drafts
	as reference material or to cite them other than as "work in		as reference material or to cite them other than as "work in
	progress."		progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Copyright Notice		Copyright Notice
			Copyright (C) The IETF Trust (2008).
	Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	The wide deployment of Voice over IP (VoIP), Real-time Text and		The wide deployment of Voice over IP (VoIP), Real-time Text and
	Video over IP services has introduced new challenges in managing		Video over IP services has introduced new challenges in managing
	and maintaining voice/real-time Text/video quality, reliability,		and maintaining voice/real-time Text/video quality, reliability,
	and overall performance. In particular, media delivery is an area		and overall performance. In particular, media delivery is an area
	that needs attention. One method of meeting these challenges is		that needs attention. One method of meeting these challenges is
	monitoring the media delivery performance by looping media back to		monitoring the media delivery performance by looping media back to
	the transmitter. This is typically referred to as "active		the transmitter. This is typically referred to as "active
	skipping to change at page 3, line 10		skipping to change at page 3, line 12
	10.1 Offer for specific media loopback type..................15		10.1 Offer for specific media loopback type..................15
	10.2 Offer for choice of media loopback type.................16		10.2 Offer for choice of media loopback type.................16
	10.3 Offer for choice of media loopback type with		10.3 Offer for choice of media loopback type with
	rtp-start-loopback...........................................17		rtp-start-loopback...........................................17
	10.4 Response to INVITE request rejecting loopback media.....18		10.4 Response to INVITE request rejecting loopback media.....18
	10.5 Response to INVITE request rejecting loopback media with		10.5 Response to INVITE request rejecting loopback media with
	rtp-start-loopback...........................................18		rtp-start-loopback...........................................18
	11. Security Considerations.....................................19		11. Security Considerations.....................................19
	12. Implementation Considerations...............................20		12. Implementation Considerations...............................20
	13. IANA Considerations.........................................20		13. IANA Considerations.........................................20
	14. Acknowledgements............................................20		13.1 SDP Attributes..........................................20
	15. Normative References........................................20		13.2 MIME Types..............................................21
			14. Acknowledgements............................................31
			15. Normative References........................................31
	1. Introduction		1. Introduction
	The overall quality, reliability, and performance of VoIP,		The overall quality, reliability, and performance of VoIP,
	Real-time Text and Video over IP services rely on the performance		Real-time Text and Video over IP services rely on the performance
	and quality of the media path. In order to assure the quality of		and quality of the media path. In order to assure the quality of
	the delivered media there is a need to monitor the performance of		the delivered media there is a need to monitor the performance of
	the media transport. One method of monitoring and managing the		the media transport. One method of monitoring and managing the
	overall quality of VoIP, Real-time Text and Video over IP Services		overall quality of VoIP, Real-time Text and Video over IP Services
	is through monitoring the quality of the media in an active		is through monitoring the quality of the media in an active
	skipping to change at page 5, line 7		skipping to change at page 5, line 7
	Two new media attributes are defined: one indicates the type of		Two new media attributes are defined: one indicates the type of
	loopback and one indicates the mode of the loopback.		loopback and one indicates the mode of the loopback.
	5.1 Loopback Type Attribute		5.1 Loopback Type Attribute
	The loopback type is a property media attribute with the following		The loopback type is a property media attribute with the following
	syntax:		syntax:
	a=loopback:<loopback-type>		a=loopback:<loopback-type>
	Following is the Augmented BNF [RFC2234] for loopback-type:		Following is the Augmented BNF [RFC4234] for loopback-type:
	loopback-type = loopback-type-choices | loopback-type-choice-3		loopback-type = loopback-type-choices | loopback-type-choice-3
	loopback-choices = loopback-type-choice-1 | loopback-type-choice-2		loopback-choices = loopback-type-choice-1 | loopback-type-choice-2
	| loopback-type-choice-1 1*space loopback-type-choice-2 |		| loopback-type-choice-1 1*space loopback-type-choice-2 |
	loopback-type-choice-2 1*space loopback-type-choice-1		loopback-type-choice-2 1*space loopback-type-choice-1
	loopback-type-choice-1 = "rtp-pkt-loopback"		loopback-type-choice-1 = "rtp-pkt-loopback"
	loopback-type-choice-2 = "rtp-media-loopback"		loopback-type-choice-2 = "rtp-media-loopback"
	loopback-type-choice-3 = "rtp-start-loopback"		loopback-type-choice-3 = "rtp-start-loopback"
	The loopback type is used to indicate the type of loopback. The		The loopback type is used to indicate the type of loopback. The
	skipping to change at page 6, line 48		skipping to change at page 6, line 48
	loopback-source: This attribute specifies that the sender is the		loopback-source: This attribute specifies that the sender is the
	media source and expects the receiver to act as a loopback-mirror.		media source and expects the receiver to act as a loopback-mirror.
	loopback-mirror: This attribute specifies that the receiver will		loopback-mirror: This attribute specifies that the receiver will
	mirror (echo) all received media back to the sender of the RTP		mirror (echo) all received media back to the sender of the RTP
	stream. No media is generated locally by the receiver for		stream. No media is generated locally by the receiver for
	transmission in the mirrored stream unless rtp-start-loopback is		transmission in the mirrored stream unless rtp-start-loopback is
	requested.		requested.
	<fmt> is a media format description. The format descrption has the		<fmt> is a media format description. The format descrption has the
	semantics as defined in section 5.14 of RFC 4566 [RFC2234]. When		semantics as defined in section 5.14 of RFC 4566[RFC4566]. When
	loopback-mode is specified as loopback-source, the media format		loopback-mode is specified as loopback-source, the media format
	corresponds to the RTP payload types the source is willing to send.		corresponds to the RTP payload types the source is willing to send.
	When loopback-mode is specified as loopback-mirror, the media		When loopback-mode is specified as loopback-mirror, the media
	format corresponds to the RTP payload types the mirror is willing		format corresponds to the RTP payload types the mirror is willing
	to receive. The payload types specified in m= line for a		to receive. The payload types specified in m= line for a
	loopback-source specify the payloads the source is willing to		loopback-source specify the payloads the source is willing to
	receive. Similarly, for the loopback-mirror these payload types		receive. Similarly, for the loopback-mirror these payload types
	specify the payloads it is willing to send.		specify the payloads it is willing to send.
	skipping to change at page 20, line 26		skipping to change at page 20, line 26
	loopback-type attribute. In addition, for the loopback-mode		loopback-type attribute. In addition, for the loopback-mode
	attribute, all implementations of an offerer MUST at a minimum be		attribute, all implementations of an offerer MUST at a minimum be
	able to act as a loopback-source. All implementation MUST also at a		able to act as a loopback-source. All implementation MUST also at a
	minimum support the direct media loopback payload type. Remaining		minimum support the direct media loopback payload type. Remaining
	attribute values including rtp-media-loopback and		attribute values including rtp-media-loopback and
	rtp-start-loopback MAY be implemented in complete implementations		rtp-start-loopback MAY be implemented in complete implementations
	of this draft.		of this draft.
	13. IANA Considerations		13. IANA Considerations
	There are no IANA considerations associated with this		13.1 SDP Attributes
	specification.
			This document defines three new media-level SDP attributes. IANA
			has registered the following attributes:
			Contact name: Kaynam Hedayat <khedayat@brixnet.com>.
			Attribute name: "loopback".
			Type of attribute: Media level.
			Subject to charset: No.
			Purpose of attribute: The 'loopback' attribute is used to
			indicate the type of media loopback.
			Allowed attribute values: The parameters to 'loopback' may be
			one or more of "rtp-pkt-loopback,"
			"rtp-media-loopback," and
			"rtp-start-loopback". See section 5
			of this document for syntax.
			Contact name: Kaynam Hedayat <khedayat@brixnet.com>.
			Attribute name: "loopback-source".
			Type of attribute: Media level.
			Subject to charset: No.
			Purpose of attribute: The 'loopback-source' attribute
			specifies that the sender is the media
			source and expects the receiver to act
			as a loopback-mirror.
			Allowed attribute values: The parameter to 'loopback-source' is
			a media format ("<fmt>") description
			as defined in RFC 4566 Section 5.14.
			Contact name: Kaynam Hedayat <khedayat@brixnet.com>.
			Attribute name: "loopback-mirror".
			Type of attribute: Media level.
			Subject to charset: No.
			Purpose of attribute: The 'loopback-mirror' attribute
			specifies that the receiver will
			mirror (echo) all received media back
			to the sender of the RTP stream.
			Allowed attribute values: The parameter to 'loopback-mirror' is
			a media format ("<fmt>") description
			as defined in RFC 4566 Section 5.14.
			13.2 MIME Types
			The IANA has registered the following MIME types:
			13.2.1 audio/encaprtp
			To: ietf-types@iana.org
			Subject: Registration of MIME media type audio/encaprtp
			MIME media type name: audio
			MIME subtype name: encaprtp
			Required parameters: none
			Note that RFC 4855 [RFC4855] mandates that RTP payload
			formats without a defined rate must define a rate
			parameter as part of their MIME registration. The
			payload format for Encapsulated RTP does not specify a
			rate parameter. However, the rate for encapsulated
			stream is equal to the rate of the stream being
			mirrored.
			Optional parameters: none
			Encoding considerations: This format is only defined for
			transport within the Real Time Transport protocol (RTP)
			[RFC 3550]. Its transport within RTP is fully
			specified in this document.
			Security considerations: See Section 11 of this document.
			Interoperability considerations: none
			Published specification: This MIME type is described fully
			within this document.
			Applications which use this media type: Applications wishing
			to monitor and ensure the quality of transport to the
			edge of a given VoIP, Real-Time Text or Video Over IP
			Service.
			Additional information: none
			Person & email address to contact for further information:
			Kaynam Hedayat
			Brix Networks
			285 Mill Road
			Chelmsford, MA 01824
			US
			EMail: khedayat@brixnet.com
			Intended usage: COMMON
			Author/Change controller: This registration is part of the
			IETF registration tree.
			RTP and SDP Issues: Usage of this format within RTP and the
			Session Description Protocol (SDP) are fully specified
			in this document.
			13.2.2 video/encaprtp
			To: ietf-types@iana.org
			Subject: Registration of MIME media type video/encaprtp
			MIME media type name: video
			MIME subtype name: encaprtp
			Required parameters: none
			Note that RFC 4855 [RFC4855] mandates that RTP payload
			formats without a defined rate must define a rate
			parameter as part of their MIME registration. The
			payload format for Encapsulated RTP does not specify a
			rate parameter.
			However, the rate for encapsulated stream is equal to
			the rate of the stream being mirrored.
			Optional parameters: none
			Encoding considerations: This format is only defined for
			transport within the Real Time Transport protocol (RTP)
			[RFC 3550]. Its transport within RTP is fully
			specified in this document.
			Security considerations: See Section 11 of this document.
			Interoperability considerations: none
			Published specification: This MIME type is described fully
			within this document.
			Applications which use this media type: Applications wishing
			to monitor and ensure the quality of transport to the
			edge of a given VoIP, Real-Time Text or Video Over IP
			Service.
			Additional information: none
			Person & email address to contact for further information:
			Kaynam Hedayat
			Brix Networks
			285 Mill Road
			Chelmsford, MA 01824
			US
			EMail: khedayat@brixnet.com
			Intended usage: COMMON
			Author/Change controller: This registration is part of the
			IETF registration tree.
			RTP and SDP Issues: Usage of this format within RTP and the
			Session Description Protocol (SDP) are fully specified
			in this document.
			13.2.3 text/encaprtp
			To: ietf-types@iana.org
			Subject: Registration of MIME media type text/encaprtp
			MIME media type name: text
			MIME subtype name: encaprtp
			Required parameters: none
			Note that RFC 4855 [RFC4855] mandates that RTP payload
			formats without a defined rate must define a rate
			parameter as part of their MIME registration. The
			payload format for Encapsulated RTP does not specify a
			rate parameter. However, the rate for encapsulated
			stream is equal to the rate of the stream being
			mirrored.
			Optional parameters: none
			Encoding considerations: This format is only defined for
			transport within the Real Time Transport protocol (RTP)
			[RFC 3550]. Its transport within RTP is fully
			specified in this document.
			Security considerations: See Section 11 of this document.
			Interoperability considerations: none
			Published specification: This MIME type is described fully
			within this document.
			Applications which use this media type: Applications wishing
			to monitor and ensure the quality of transport to the
			edge of a given VoIP, Real-Time Text or Video Over IP
			Service.
			Additional information: none
			Person & email address to contact for further information:
			Kaynam Hedayat
			Brix Networks
			285 Mill Road
			Chelmsford, MA 01824
			US
			EMail: khedayat@brixnet.com
			Intended usage: COMMON
			Author/Change controller: This registration is part of the
			IETF registration tree.
			RTP and SDP Issues: Usage of this format within RTP and the
			Session Description Protocol (SDP) are fully specified
			in this document.
			13.2.4 application/encaprtp
			To: ietf-types@iana.org
			Subject: Registration of MIME media type
			application/encaprtp
			MIME media type name: application
			MIME subtype name: encaprtp
			Required parameters: none
			Note that RFC 4855 [RFC4855] mandates that RTP payload
			formats without a defined rate must define a rate
			parameter as part of their MIME registration. The
			payload format for Encapsulated RTP does not specify a
			rate parameter. However, the rate for encapsulated
			stream is equal to the rate of the stream being
			mirrored.
			Optional parameters: none
			Encoding considerations: This format is only defined for
			transport within the Real Time Transport protocol (RTP)
			[RFC 3550]. Its transport within RTP is fully
			specified in this document.
			Security considerations: See Section 11 of this document.
			Interoperability considerations: none
			Published specification: This MIME type is described fully
			within this document.
			Applications which use this media type: Applications wishing
			to monitor and ensure the quality of transport to the
			edge of a given VoIP, Real-Time Text or Video Over IP
			Service.
			Additional information: none
			Person & email address to contact for further information:
			Kaynam Hedayat
			Brix Networks
			285 Mill Road
			Chelmsford, MA 01824
			US
			EMail: khedayat@brixnet.com
			Intended usage: COMMON
			Author/Change controller: This registration is part of the
			IETF registration tree.
			RTP and SDP Issues: Usage of this format within RTP and the
			Session Description Protocol (SDP) are fully specified
			in this document.
			13.2.5 audio/rtploopback
			To: ietf-types@iana.org
			Subject: Registration of MIME media type audio/rtploopback
			MIME media type name: audio
			MIME subtype name: rtploopback
			Required parameters: none
			Note that RFC 4855 [RFC4855] mandates that RTP payload
			formats without a defined rate must define a rate
			parameter as part of their MIME registration. The
			payload format for Encapsulated RTP does not specify a
			rate parameter. However, the rate for encapsulated
			stream is equal to the rate of the stream being
			mirrored.
			Optional parameters: none
			Encoding considerations: This format is only defined for
			transport within the Real Time Transport protocol (RTP)
			[RFC 3550]. Its transport within RTP is fully
			specified in this document.
			Security considerations: See Section 11 of this document.
			Interoperability considerations: none
			Published specification: This MIME type is described fully
			within this document.
			Applications which use this media type: Applications wishing
			to monitor and ensure the quality of transport to the
			edge of a given VoIP, Real-Time Text or Video Over IP
			Service.
			Additional information: none
			Person & email address to contact for further information:
			Kaynam Hedayat
			Brix Networks
			285 Mill Road
			Chelmsford, MA 01824
			US
			EMail: khedayat@brixnet.com
			Intended usage: COMMON
			Author/Change controller: This registration is part of the
			IETF registration tree.
			RTP and SDP Issues: Usage of this format within RTP and the
			Session Description Protocol (SDP) are fully specified
			in this document.
			13.2.6 video/rtploopback
			To: ietf-types@iana.org
			Subject: Registration of MIME media type video/rtploopback
			MIME media type name: video
			MIME subtype name: rtploopback
			Required parameters: none
			Note that RFC 4855 [RFC4855] mandates that RTP payload
			formats without a defined rate must define a rate
			parameter as part of their MIME registration. The
			payload format for Encapsulated RTP does not specify a
			rate parameter. However, the rate for encapsulated
			stream is equal to the rate of the stream being
			mirrored.
			Optional parameters: none
			Encoding considerations: This format is only defined for
			transport within the Real Time Transport protocol (RTP)
			[RFC 3550]. Its transport within RTP is fully
			specified in this document.
			Security considerations: See Section 11 of this document.
			Interoperability considerations: none
			Published specification: This MIME type is described fully
			within this document.
			Applications which use this media type: Applications wishing
			to monitor and ensure the quality of transport to the
			edge of a given VoIP, Real-Time Text or Video Over IP
			Service.
			Additional information: none
			Person & email address to contact for further information:
			Kaynam Hedayat
			Brix Networks
			285 Mill Road
			Chelmsford, MA 01824
			US
			EMail: khedayat@brixnet.com
			Intended usage: COMMON
			Author/Change controller: This registration is part of the
			IETF registration tree.
			RTP and SDP Issues: Usage of this format within RTP and the
			Session Description Protocol (SDP) [6] are fully
			specified in this document.
			13.2.7 text/rtploopback
			To: ietf-types@iana.org
			Subject: Registration of MIME media type text/rtploopback
			MIME media type name: text
			MIME subtype name: rtploopback
			Required parameters: none
			Note that RFC 4855 [RFC4855] mandates that RTP payload
			formats without a defined rate must define a rate
			parameter as part of their MIME registration. The
			payload format for Encapsulated RTP does not specify a
			rate parameter. However, the rate for encapsulated
			stream is equal to the rate of the stream being
			mirrored.
			Optional parameters: none
			Encoding considerations: This format is only defined for
			transport within the Real Time Transport protocol (RTP)
			[RFC 3550]. Its transport within RTP is fully
			specified in this document.
			Security considerations: See Section 11 of this document.
			Interoperability considerations: none
			Published specification: This MIME type is described fully
			within this document.
			Applications which use this media type: Applications wishing
			to monitor and ensure the quality of transport to the
			edge of a given VoIP, Real-Time Text or Video Over IP
			Service.
			Additional information: none
			Person & email address to contact for further information:
			Kaynam Hedayat
			Brix Networks
			285 Mill Road
			Chelmsford, MA 01824
			US
			EMail: khedayat@brixnet.com
			Intended usage: COMMON
			Author/Change controller: This registration is part of the
			IETF registration tree.
			RTP and SDP Issues: Usage of this format within RTP and the
			Session Description Protocol (SDP) [6] are fully
			specified in this document.
			13.2.8 application/rtploopback
			To: ietf-types@iana.org
			Subject: Registration of MIME media type
			application/rtploopback
			MIME media type name: application
			MIME subtype name: rtploopback
			Required parameters: none
			Note that RFC 4855 [RFC4855] mandates that RTP payload
			formats without a defined rate must define a rate
			parameter as part of their MIME registration. The
			payload format for Encapsulated RTP does not specify a
			rate parameter. However, the rate for encapsulated
			stream is equal to the rate of the stream being
			mirrored.
			Optional parameters: none
			Encoding considerations: This format is only defined for
			transport within the Real Time Transport protocol (RTP)
			[RFC 3550]. Its transport within RTP is fully
			specified in this document.
			Security considerations: See Section 11 of this document.
			Interoperability considerations: none
			Published specification: This MIME type is described fully
			within this document.
			Applications which use this media type: Applications wishing
			to monitor and ensure the quality of transport to the
			edge of a given VoIP, Real-Time Text or Video Over IP
			Service.
			Additional information: none
			Person & email address to contact for further information:
			Kaynam Hedayat
			Brix Networks
			285 Mill Road
			Chelmsford, MA 01824
			US
			EMail: khedayat@brixnet.com
			Intended usage: COMMON
			Author/Change controller: This registration is part of the
			IETF registration tree.
			RTP and SDP Issues: Usage of this format within RTP and the
			Session Description Protocol (SDP) [6] are fully
			specified in this document.
	14. Acknowledgements		14. Acknowledgements
	The authors wish to thank Nagarjuna Venna, Flemming Andreasen, Jeff		The authors wish to thank Nagarjuna Venna, Flemming Andreasen, Jeff
	Bernstein, Paul Kyzivat, and Dave Oran for their comments and		Bernstein, Paul Kyzivat, and Dave Oran for their comments and
	suggestions.		suggestions.
	15. Normative References		15. Normative References
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
	skipping to change at page 21, line 14		skipping to change at page 31, line 41
	[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.
	[RFC3611] Almeroth, K., Caceres, R., Clark, A., Cole, R.,		[RFC3611] Almeroth, K., Caceres, R., Clark, A., Cole, R.,
	Duffield, N., Friedman, T., Hedayat, K., Sarac, K.		Duffield, N., Friedman, T., Hedayat, K., Sarac, K.
	and M. Westerlund, "RTP Control Protocol Extended		and M. Westerlund, "RTP Control Protocol Extended
	Reports (RTCP XR)", RFC 3611, November 2003.		Reports (RTCP XR)", RFC 3611, November 2003.
	[RFC2234] Crocker, P. Overell, "Augmented ABNF for Syntax		[RFC4234] Crocker, P. Overell, "Augmented ABNF for Syntax
	Specification: ABNF", RFC 2234, November 1997.		Specification: ABNF", RFC 4234, October 2005.
	[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.
	[RFC2736] Handley, M., Perkins, C., "Guidelines for Writers of		[RFC2736] Handley, M., Perkins, C., "Guidelines for Writers of
	RTP Payload Format Specifications", RFC 2736, BCP		RTP Payload Format Specifications", RFC 2736, BCP
	0036, December 1999.		0036, December 1999.
	[RFC3551] Schulzrinne, H., Casner, S., "RTP Profile for Audio		[RFC3551] Schulzrinne, H., Casner, S., "RTP Profile for Audio
	and Video Conferences with Minimial Control", STD 65,		and Video Conferences with Minimial Control", STD 65,
	RFC 3551, July 2003.		RFC 3551, July 2003.
	[RFC4566] Handley, M., Jacobson, V., Perkins, C., "SDP: Session		[RFC4566] Handley, M., Jacobson, V., Perkins, C., "SDP: Session
	Description Protocol", RFC 4566, July 2006.		Description Protocol", RFC 4566, July 2006.
			[RFC4855] Casner, S., "Media Type Registration of RTP Payload
			Formats", RFC 4855, February 2007.
	Authors' Addresses		Authors' Addresses
	Kaynam Hedayat		Kaynam Hedayat
	Brix Networks		Brix Networks
	285 Mill Road		285 Mill Road
	Chelmsford, MA 01824		Chelmsford, MA 01824
	US		US
	Phone: +1 978 367 5611		Phone: +1 978 367 5611
	EMail: khedayat@brixnet.com		EMail: khedayat@brixnet.com
	skipping to change at page 22, line 31		skipping to change at page 33, line 24
	Cisco Systems, Inc.		Cisco Systems, Inc.
	2200 East President George Bush Turnpike		2200 East President George Bush Turnpike
	Richardson, TX 75082		Richardson, TX 75082
	US		US
	Phone: +1 972 813 5224		Phone: +1 972 813 5224
	EMail: chelliah@cisco.com		EMail: chelliah@cisco.com
	URI: http://www.cisco.com/		URI: http://www.cisco.com/
	Nathan Stratton		Nathan Stratton
			BlinkMind, Inc.
			2027 Briarchester Dr.
			Katy, TX 77450
	663 Salem St.		Phone: +1 832 330 3810
	Lynnfield, MA 01940
	Phone: +1 410 908 7587
	EMail: nathan@robotics.net		EMail: nathan@robotics.net
	URI: http://www.robotics.net/		URI: http://www.robotics.net/
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on		This document and the information contained herein are provided on
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
	IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL		IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
	WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY		WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
End of changes. 14 change blocks.
	20 lines changed or deleted		542 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/