draft-ietf-mmusic-media-loopback-02.txt		draft-ietf-mmusic-media-loopback-03.txt
	K. Hedayat		K. Hedayat
	Internet Draft Brix Networks		Internet Draft Brix Networks
	Expires: May 11, 2006 P. Jones		Expires: December 2006 P. Jones
	Cisco Systems, Inc.		Cisco Systems, Inc.
	A. Roychowdhury		A. Roychowdhury
	Flextronics Software Systems		Hughes
	C. SivaChelvan		C. SivaChelvan
	Cisco Systems, Inc.		Cisco Systems, Inc.
	N. Stratton		N. Stratton
	BroadVoice
	November 7, 2005
	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-02		draft-ietf-mmusic-media-loopback-03
	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 44		skipping to change at page 1, line 41
	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 Internet Society (2005).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	The wide deployment of VoIP and Video over IP services has		The wide deployment of Voice over IP (VoIP), Real-time Text and
	introduced new challenges in managing and maintaining voice/video		Video over IP services has introduced new challenges in managing
	quality, reliability, and overall performance. In particular,		and maintaining voice/real-time Text/video quality, reliability,
	media delivery is an area that needs attention. One method of		and overall performance. In particular, media delivery is an area
	meeting these challenges is monitoring the media delivery		that needs attention. One method of meeting these challenges is
	performance by looping media back to the transmitter. This is		monitoring the media delivery performance by looping media back to
	typically referred to as "active monitoring" of services. Media		the transmitter. This is typically referred to as "active
	loopback is especially popular in ensuring the quality of transport		monitoring" of services. Media loopback is especially popular in
	to the edge of a given VoIP or Video over IP service. Today in		ensuring the quality of transport to the edge of a given VoIP,
	networks that deliver real-time media, short of running 'ping' and		Real-time Text or Video over IP service. Today in networks that
	'traceroute' to the edge, service providers are left without the		deliver real-time media, short of running 'ping' and 'traceroute'
	necessary tools to actively monitor, manage, and diagnose quality		to the edge, service providers are left without the necessary tools
	issues with their service. The extension defined herein adds new		to actively monitor, manage, and diagnose quality issues with their
	SDP media attributes which enables establishment of media sessions		service. The extension defined herein adds new SDP media
	where the media is looped back to the transmitter. Such media		attributes which enables establishment of media sessions where the
	sessions will serve as monitoring and troubleshooting tools by		media is looped back to the transmitter. Such media sessions will
	providing the means for measurement of more advanced VoIP and Video		serve as monitoring and troubleshooting tools by providing the
	Over IP performance metrics.		means for measurement of more advanced VoIP, Real-time Text and
			Video Over IP performance metrics.
	Table of Contents		Table of Contents
	1. Introduction..................................................3		1. Introduction..................................................3
	2. Terminology...................................................3		2. Terminology...................................................3
	3. Offering Entity Behavior......................................4		3. Offering Entity Behavior......................................4
	4. Answering Entity Behavior.....................................4		4. Answering Entity Behavior.....................................4
	5. SDP Constructs Syntax.........................................4		5. SDP Constructs Syntax.........................................4
	5.1 Loopback Type Attribute...................................4		5.1 Loopback Type Attribute...................................4
	5.2 Loopback Mode Attribute...................................6		5.2 Loopback Mode Attribute...................................6
	skipping to change at page 2, line 49		skipping to change at page 2, line 50
	6. RTP Requirements..............................................8		6. RTP Requirements..............................................8
	7. RTCP Requirements.............................................9		7. RTCP Requirements.............................................9
	8. Examples......................................................9		8. Examples......................................................9
	8.1 Offer for specific media loopback type....................9		8.1 Offer for specific media loopback type....................9
	8.2 Offer for choice of media loopback type..................10		8.2 Offer for choice of media loopback type..................10
	8.3 Offer for choice of media loopback type with		8.3 Offer for choice of media loopback type with
	rtp-start-loopback...........................................11		rtp-start-loopback...........................................11
	8.4 Response to INVITE request rejecting loopback media......12		8.4 Response to INVITE request rejecting loopback media......12
	8.5 Response to INVITE request rejecting loopback media with		8.5 Response to INVITE request rejecting loopback media with
	rtp-start-loopback...........................................13		rtp-start-loopback...........................................13
	9. Security Considerations......................................13		9. Security Considerations......................................14
	10. IANA Considerations.........................................14		10. IANA Considerations.........................................14
	11. Acknowledgements............................................14		11. Acknowledgements............................................14
	12. References..................................................14		12. References..................................................14
	12.1 Normative References....................................14
	1. Introduction		1. Introduction
	The overall quality, reliability, and performance of VoIP and Video		The overall quality, reliability, and performance of VoIP,
	over IP services relies on the performance and quality of the media		Real-time Text and Video over IP services rely on the performance
	path. In order to assure the quality of the delivered media there		and quality of the media path. In order to assure the quality of
	is a need to monitor the performance of the media transport. One		the delivered media there is a need to monitor the performance of
	method of monitoring and managing the overall quality of VoIP and		the media transport. One method of monitoring and managing the
	Video over IP Services is through monitoring the quality of the		overall quality of VoIP, Real-time Text and Video over IP Services
	media in an active session. This type of "active monitoring" of		is through monitoring the quality of the media in an active
	services is a method of pro-actively managing the performance and		session. This type of "active monitoring" of services is a method
	quality of VoIP based services.		of pro-actively managing the performance and quality of VoIP based
			services.
	The goal of active monitoring is to measure the media quality of a		The goal of active monitoring is to measure the media quality of a
	VoIP or Video over IP session. A way to achieve this goal is to		VoIP, Real-time Text or Video over IP session. A way to achieve
	request an endpoint to loop media back to the other endpoint and to		this goal is to request an endpoint to loop media back to the other
	provide media statistics (e.g., RTCP and RTCP XR information).		endpoint and to provide media statistics (e.g., RTCP and RTCP XR
	Another method involves deployment of special endpoints that always		information). Another method involves deployment of special
	loop incoming media back for sessions. Although the latter method		endpoints that always loop incoming media back for sessions.
	has been used and is functional, it does not scale to support large		Although the latter method has been used and is functional, it does
	networks and introduces new network management challenges.		not scale to support large networks and introduces new network
	Further, it does not offer the granularity of testing a specific		management challenges. Further, it does not offer the granularity
	endpoint that may be exhibiting problems.		of testing a specific endpoint that may be exhibiting problems.
	The extension defined in this memo introduces new SDP media		The extension defined in this memo introduces new SDP media
	attributes that enable establishment of media sessions where the		attributes that enable establishment of media sessions where the
	media is looped back to the transmitter. The offer/answer model		media is looped back to the transmitter. The offer/answer model
	per RFC 3264 [RFC3264] is used to establish a loopback connection.		[RFC3264] is used to establish a loopback connection. Furthermore,
	Furthermore, this extension provides guidelines on handling RTP		this extension provides guidelines on handling RTP [RFC3550], as
	(RFC 3550) [RFC3550], as well as usage of RTCP (RFC 3550) [RFC3550]		well as usage of RTCP [RFC3550] and RTCP XR [RFC3611] for reporting
	and RTCP XR (RFC 3611) [RFC3611] for reporting media related		media related measurements.
	measurements.
	2. Terminology		2. Terminology
	In this document, the key words "MUST", "MUST NOT", "REQUIRED",		In this document, the key words "MUST", "MUST NOT", "REQUIRED",
	"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",		"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	and "OPTIONAL" are to be interpreted as described in RFC 2119		and "OPTIONAL" are to be interpreted as described in RFC 2119
	[RFC3264] and indicate requirement levels for compliant		[RFC3264] and indicate requirement levels for compliant
	implementations.		implementations.
	3. Offering Entity Behavior		3. Offering Entity Behavior
	skipping to change at page 4, line 25		skipping to change at page 4, line 25
	4. Answering Entity Behavior		4. Answering Entity Behavior
	An answering entity compliant to this specification and receiving		An answering entity compliant to this specification and receiving
	an offer containing media descriptions with the "loopback" media		an offer containing media descriptions with the "loopback" media
	attributes, MUST acknowledge the request by including the received		attributes, MUST acknowledge the request by including the received
	"loopback" media attributes for each media description in its		"loopback" media attributes for each media description in its
	response. The server MAY reject the "loopback" request for		response. The server MAY reject the "loopback" request for
	specific media types as defined in section 5.4.1 of this		specific media types as defined in section 5.4.1 of this
	specification.		specification.
	An answering entity that is not compliant to this specification		An answering entity that is not compliant to this specification and
	and which receives an offer with the "loopback" media attributes		which receives an offer with the "loopback" media attributes MAY
	MAY safely ignore the attribute and treat the incoming offer as a		ignore the attribute and treat the incoming offer as a normal
	normal request.		request.
	5. SDP Constructs Syntax		5. SDP Constructs Syntax
	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 (RFC 2234) [RFC2234] for		Following is the Augmented BNF [RFC2234] for loopback-type:
	loopback-type:
	loopback-type = loopback-type-choice [ space loopback-type-choice ]		loopback-type = 1*2(loopback-type-choice) [ space "rtp-start-
	loopback-type-choice = "rtp-pkt-loopback" | "rtp-media-loopback |		loopback" ]
	rtp-start-loopback"		loopback-type-choice = "rtp-pkt-loopback" | "rtp-media-loopback” |
			“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
	loopback-type values are rtp-pkt-loopback, rtp-media-loopback, and		loopback-type values are rtp-pkt-loopback, rtp-media-loopback, and
	rtp-start-loopback.		rtp-start-loopback.
	rtp-pkt-loopback: In this mode, the RTP packets are looped back to		rtp-pkt-loopback: In this mode, the RTP packets are looped back to
	the sender at a point before the encoder/decoder function in the		the sender at a point before the encoder/decoder function in the
	receive direction to a point after the encoder/decoder function in		receive direction to a point after the encoder/decoder function in
	the send direction. This effectively re-encapsulates the RTP		the send direction. This effectively re-encapsulates the RTP
	payload with the RTP/UDP/IP overheads appropriate for sending it in		payload with the RTP/UDP/IP overheads appropriate for sending it in
	skipping to change at page 5, line 39		skipping to change at page 5, line 39
	path of the media. RTP relays exist in VoIP networks for purpose		path of the media. RTP relays exist in VoIP networks for purpose
	of NAT and Firewall traversal. If an RTP relay is present the		of NAT and Firewall traversal. If an RTP relay is present the
	offering entity’s packets are dropped by the RTP relay until the		offering entity’s packets are dropped by the RTP relay until the
	answering entity has started transmitting media and the media state		answering entity has started transmitting media and the media state
	within the RTP relay is established. This loopback attribute is		within the RTP relay is established. This loopback attribute is
	used to specify the media type for transmitting media packets by		used to specify the media type for transmitting media packets by
	the answering entity prior to the loopback process for the purpose		the answering entity prior to the loopback process for the purpose
	of setting media state within the network. In the presence of this		of setting media state within the network. In the presence of this
	loopback attribute the answering entity will transmit media,		loopback attribute the answering entity will transmit media,
	according to the description that contains this attribute, until it		according to the description that contains this attribute, until it
	receives media from the offering entity. After the first media		receives media from the offering entity. The answering entity MAY
	packet is received from the offering entity, the answering entity		include this attribute in the answer if it is not present in the
	MUST terminate the transmission of rtp-start-loopback media and		offer. This may be necessary if the answering entity is aware of
	MUST start looping back media as defined by the other loopback		NAT’s, firewalls, or RTP relays on the path of the call. In this
			case the offering entity MUST accept media according to
			rtp-start-loopback attribute. After the first media packet is
			received from the offering entity, the answering entity MUST
			terminate the transmission of rtp-start-loopback media and MUST
			start looping back media as defined by the other loopback
	attributes present in the offer. If an offer includes the		attributes present in the offer. If an offer includes the
	rtp-start-loopback attribute it MUST also include at least one		rtp-start-loopback attribute it MUST also include at least one
	other attribute as defined in this section. The offering entity is		other attribute as defined in this section. The offering entity is
	able to filter rtp-start-loopback packets from other types of		able to filter rtp-start-loopback packets from other types of
	loopback with the payload type of the packet. The media port number		loopback with the payload type of the packet. The media port number
	for rtp-start-loopback MUST be the same as the corresponding		for rtp-start-loopback MUST be the same as the corresponding
	loopback attribute that will take over after the reception of first		loopback attribute that will take over after the reception of first
	media packet from the offering entity.		media packet from the offering entity.
	It is recommended that an offering entity specifying media with		It is recommended that an offering entity specifying media with
	skipping to change at page 6, line 27		skipping to change at page 6, line 30
	a=<loopback-mode>		a=<loopback-mode>
	The loopback-mode values are loopback-source and loopback-mirror.		The loopback-mode values are loopback-source and loopback-mirror.
	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 reciver for		stream. No media is generated locally by the receiver for
	transmission in the mirrored stream.		transmission in the mirrored stream unless rtp-start-loopback is
			requested
	The loopback mode attribute does not apply to rtp-start-loopback		The loopback mode attribute does not apply to rtp-start-loopback
	attribute and MUST be ignored if received by the answering entityt.		attribute and MUST be ignored if received by the answering entity.
	5.3 Generating the Offer for Loopback Session		5.3 Generating the Offer for Loopback Session
	If an offerer wishes to make a loopback request, it MUST include		If an offerer wishes to make a loopback request, it MUST include
	both the loopback-type and loopback-mode attribute in a valid SDP		both the loopback-type and loopback-mode attribute in a valid SDP
	offer:		offer:
	Example: a=loopback:rtp-media-loopback		Example: a=loopback:rtp-media-loopback
	a=loopback-source		a=loopback-source
	Note: A loopback offer in a given media description MUST NOT		Note: A loopback offer in a given media description MUST NOT
	contain the standard mode attributes sendonly, recvonly, sendrecv		contain the standard mode attributes sendonly, recvonly, sendrecv
	or inactive.		or inactive.
	The offerer may offer more than one loopback-type in the SDP offer.		The offerer may offer more than one loopback-type in the SDP offer.
	In this case the answer MUST include only one of the loopback types		In this case the answer MUST include only one of the loopback types
	that is accepted by the answerer. The answerer SHOULD give		that are accepted by the answerer. The answerer SHOULD give
	preference to the first loopback-type in the SDP offer.		preference to the first loopback-type in the SDP offer.
	For loopback-source media (e.g. audio) streams, the port number and		For loopback-source media (e.g. audio) streams, the port number and
	the address in the offer indicates where the offerer would like to		the address in the offer indicate where the offerer would like to
	receive the media stream. The payload type numbers indicate the		receive the media stream. The payload type numbers indicate the
	value of the payload the offerer expects to receive, and would		value of the payload the offerer expects to receive, and would
	prefer to send. However, the answer might indicate a different		prefer to send. However, the answer might indicate a different
	payload type number for the same codec. In that case, the offerer		payload type number for the same codec. In that case, the offerer
	MUST send the payload type received in the answer.		MUST send the payload type received in the answer.
			Note: NAT devices may change the actual port number that is used
			for transmission and the expected receive port.
	5.4 Generating the Answer for Loopback Session		5.4 Generating the Answer for Loopback Session
	If an answerer wishes to accept the loopback request it MUST		If an answerer wishes to accept the loopback request it MUST
	include both the loopback mode and loopback type attribute in the		include both the loopback mode and loopback type attribute in the
	answer. If a stream is offered with loopback-source or		answer. If a stream is offered with loopback-source or
	loopback-mirror attributes, the corresponding stream MUST be		loopback-mirror attributes, the corresponding stream MUST be
	loopback-mirror or loopback-source respectively, provided that		loopback-mirror or loopback-source respectively, provided that
	answerer is capable of supporting the requested loopback-type.		answerer is capable of supporting the requested loopback-type.
	For example, if the offer contains:		For example, if the offer contains:
	skipping to change at page 8, line 34		skipping to change at page 8, line 40
	5.6 Modifying the Session		5.6 Modifying the Session
	At any point during the loopback session, either participant may		At any point during the loopback session, either participant may
	issue a new offer to modify the characteristics of the previous		issue a new offer to modify the characteristics of the previous
	session. In case of SIP this is defined in section 8 of RFC 3264		session. In case of SIP this is defined in section 8 of RFC 3264
	[RFC3264]. This also includes transitioning from a normal media		[RFC3264]. This also includes transitioning from a normal media
	processing mode to loopback mode, and vice a versa.		processing mode to loopback mode, and vice a versa.
	6. RTP Requirements		6. RTP Requirements
	An answering entitity that is compliant to this specification and		An answering entity that is compliant to this specification and
	accepting a media with rtp-pkt-loopback loopback-type MUST		accepting a media with rtp-pkt-loopback loopback-type MUST loopback
	re-generate all of the RTP header fields as it does when		the incoming RTP packets while re-generating only the SSRC field of
	transmitting other media. However, the answering entity MUST		the RTP header. Note that during the rtp-pkt-loopback mode the
	maintain the timing information of the received RTP packets when		answering entity does not have control over the encoding of the
	generating the RTP timestamp for the transmit packets. Maintaining		media and cannot perform certain functions including congestion
	the timing information of the RTP packets enables the offerer to		control on the looped back media. However, since the purpose of the
	re-construct the incoming media and take account for impairments		loopback is to characterize the round-trip path at the RTP level,
	from gaps in the media due to packet loss. Note that RTP Sequence		this limitation is acceptable.
	numbers are re-generated by the answering entity and will not
	provide packet loss information to the receiver of the loopback
	media.
	An answering entity that is compliant to this specification and		An answering entity that is compliant to this specification and
	accepting a media with rtp-media-loopback loopback-type MUST		accepting a media with rtp-media-loopback loopback-type MUST
	transmit all received media back to the sender . The incoming media		transmit all received media back to the sender . The incoming media
	MUST be treated as if it were to be played (e.g. the media stream		MUST be treated as if it were to be played (e.g. the media stream
	MAY receive treatment from PLC algorithms). The answering entity		MAY receive treatment from PLC algorithms). The answering entity
	MUST re-generate all the RTP header fields as it would when		MUST re-generate all the RTP header fields as it would when
	transmitting media. The answering entity MAY choose to encode the		transmitting media. The answering entity MAY choose to encode the
	loopback media according to any of the media descriptions supported		loopback media according to any of the media descriptions supported
	by the offering entity. Furthermore, in cases where the same media		by the offering entity. Furthermore, in cases where the same media
	skipping to change at page 9, line 41		skipping to change at page 10, line 4
	3611 [RFC3611].		3611 [RFC3611].
	8. Examples		8. Examples
	This section provides examples for media descriptions using SDP for		This section provides examples for media descriptions using SDP for
	different scenarios. The examples are given for SIP-based		different scenarios. The examples are given for SIP-based
	transactions and are abbreviated and do not show the complete		transactions and are abbreviated and do not show the complete
	signaling for convenience.		signaling for convenience.
	8.1 Offer for specific media loopback type		8.1 Offer for specific media loopback type
	A client sends an INVITE request with SDP which looks like:		A client sends an INVITE request with SDP which looks like:
	v=0		v=0
	o=user1 2890844526 2890842807 IN IP4 126.16.64.4		o=user1 2890844526 2890842807 IN IP4 126.16.64.4
	s=Example		s=Example
	i=An example session		i=An example session
	e=user@example.com		e=user@example.com
	c=IN IP4 224.2.17.12/127		c=IN IP4 192.168.0.12/127
	t=0 0		t=0 0
	m=audio 49170 RTP/AVP 0		m=audio 49170 RTP/AVP 0
	a=loopback:rtp-media-loopback		a=loopback:rtp-media-loopback
	a=loopback-source		a=loopback-source
	The client is offering to source the media and expects the server		The client is offering to source the media and expects the server
	to mirror the RTP stream per rtp-media-loopback loopback type.		to mirror the RTP stream per rtp-media-loopback loopback type.
	A server sends a response with SDP which looks like:		A server sends a response with SDP which looks like:
	v=0		v=0
	o=user1 2890844526 2890842807 IN IP4 126.16.64.4		o=user1 2890844526 2890842807 IN IP4 126.16.64.4
	s=Example		s=Example
	i=An example session		i=An example session
	e=user@example.com		e=user@example.com
	c=IN IP4 224.2.17.12/127		c=IN IP4 192.168.0.12/127
	t=0 0		t=0 0
	m=audio 49170 RTP/AVP 0		m=audio 49170 RTP/AVP 0
	a=loopback:rtp-media-loopback		a=loopback:rtp-media-loopback
	a=loopback-mirror		a=loopback-mirror
	The server is accepting to mirror the media from the client at the		The server is accepting to mirror the media from the client at the
	media level.		media level.
	8.2 Offer for choice of media loopback type		8.2 Offer for choice of media loopback type
	A client sends an INVITE request with SDP which looks like:		A client sends an INVITE request with SDP which looks like:
	v=0		v=0
	o=user1 2890844526 2890842807 IN IP4 126.16.64.4		o=user1 2890844526 2890842807 IN IP4 126.16.64.4
	s=Example		s=Example
	i=An example session		i=An example session
	e=user@example.com		e=user@example.com
	c=IN IP4 224.2.17.12/127		c=IN IP4 192.168.0.12/127
	t=0 0		t=0 0
	m=audio 49170 RTP/AVP 0		m=audio 49170 RTP/AVP 0
	a=loopback:rtp-media-loopback rtp-pkt-loopback		a=loopback:rtp-media-loopback rtp-pkt-loopback
	a=loopback-source		a=loopback-source
	The client is offering to source the media and expects the server		The client is offering to source the media and expects the server
	to mirror the RTP stream at either the media or rtp level.		to mirror the RTP stream at either the media or rtp level.
	A server sends a response with SDP which looks like:		A server sends a response with SDP which looks like:
	v=0		v=0
	o=user1 2890844526 2890842807 IN IP4 126.16.64.4		o=user1 2890844526 2890842807 IN IP4 126.16.64.4
	s=Example		s=Example
	i=An example session		i=An example session
	e=user@example.com		e=user@example.com
	skipping to change at page 11, line 10		skipping to change at page 11, line 14
	The client is offering to source the media and expects the server		The client is offering to source the media and expects the server
	to mirror the RTP stream at either the media or rtp level.		to mirror the RTP stream at either the media or rtp level.
	A server sends a response with SDP which looks like:		A server sends a response with SDP which looks like:
	v=0		v=0
	o=user1 2890844526 2890842807 IN IP4 126.16.64.4		o=user1 2890844526 2890842807 IN IP4 126.16.64.4
	s=Example		s=Example
	i=An example session		i=An example session
	e=user@example.com		e=user@example.com
	c=IN IP4 224.2.17.12/127		c=IN IP4 192.168.0.12/127
	t=0 0		t=0 0
	m=audio 49170 RTP/AVP 0		m=audio 49170 RTP/AVP 0
	a=loopback:rtp-pkt-loopback		a=loopback:rtp-pkt-loopback
	a=loopback-mirror		a=loopback-mirror
	The server is accepting to mirror the media from the client at the		The server is accepting to mirror the media from the client at the
	packet level.		packet level.
	8.3 Offer for choice of media loopback type with rtp-start-loopback		8.3 Offer for choice of media loopback type with rtp-start-loopback
	A client sends an INVITE request with SDP which looks like:		A client sends an INVITE request with SDP which looks like:
	v=0		v=0
	o=user1 2890844526 2890842807 IN IP4 126.16.64.4		o=user1 2890844526 2890842807 IN IP4 126.16.64.4
	s=Example		s=Example
	i=An example session		i=An example session
	e=user@example.com		e=user@example.com
	c=IN IP4 224.2.17.12/127		c=IN IP4 192.168.0.12/127
	t=0 0		t=0 0
	m=audio 49170 RTP/AVP 0		m=audio 49170 RTP/AVP 0
	a=loopback:rtp-media-loopback rtp-pkt-loopback		a=loopback:rtp-media-loopback rtp-pkt-loopback
	a=loopback-source		a=loopback-source
	m=audio 49170 RTP/AVP 100		m=audio 49170 RTP/AVP 100
	a=loopback:rtp-start-loopback		a=loopback:rtp-start-loopback
	The client is offering to source the media and expects the server		The client is offering to source the media and expects the server
	to mirror the RTP stream at either the media or rtp level. The		to mirror the RTP stream at either the media or rtp level. The
	client also expects the server to source media until it receives		client also expects the server to source media until it receives
	packets from the server per media described with the		packets from the server per media described with the
	rtp-start-loopback attribute.		rtp-start-loopback attribute.
	A server sends a response with SDP which looks like:		A server sends a response with SDP which looks like:
	v=0		v=0
	o=user1 2890844526 2890842807 IN IP4 126.16.64.4		o=user1 2890844526 2890842807 IN IP4 126.16.64.4
	s=Example		s=Example
	i=An example session		i=An example session
	e=user@example.com		e=user@example.com
	c=IN IP4 224.2.17.12/127		c=IN IP4 192.168.0.12/127
	t=0 0		t=0 0
	m=audio 49170 RTP/AVP 0		m=audio 49170 RTP/AVP 0
	a=loopback:rtp-pkt-loopback		a=loopback:rtp-pkt-loopback
	a=loopback-mirror		a=loopback-mirror
	m=audio 49170 RTP/AVP 100		m=audio 49170 RTP/AVP 100
	a=rtpmap:100 pcmu/8000		a=rtpmap:100 pcmu/8000
	a=loopback:rtp-start-loopback		a=loopback:rtp-start-loopback
	The server is accepting to mirror the media from the client at the		The server is accepting to mirror the media from the client at the
	packet level. The server is also accepting to source media until		packet level. The server is also accepting to source media until
	skipping to change at page 12, line 23		skipping to change at page 12, line 28
	8.4 Response to INVITE request rejecting loopback media		8.4 Response to INVITE request rejecting loopback media
	A client sends an INVITE request with SDP which looks like:		A client sends an INVITE request with SDP which looks like:
	v=0		v=0
	o=user1 2890844526 2890842807 IN IP4 126.16.64.4		o=user1 2890844526 2890842807 IN IP4 126.16.64.4
	s=Example		s=Example
	i=An example session		i=An example session
	e=user@example.com		e=user@example.com
	c=IN IP4 224.2.17.12/127		c=IN IP4 192.168.0.12/127
	t=0 0		t=0 0
	m=audio 49170 RTP/AVP 0		m=audio 49170 RTP/AVP 0
	a=loopback:rtp-media-loopback		a=loopback:rtp-media-loopback
	a=loopback-source		a=loopback-source
	The client is offering to source the media and expects the server		The client is offering to source the media and expects the server
	to mirror the RTP stream at the media level.		to mirror the RTP stream at the media level.
	A server sends a response with SDP which looks like:		A server sends a response with SDP which looks like:
	v=0		v=0
	o=user1 2890844526 2890842807 IN IP4 126.16.64.4		o=user1 2890844526 2890842807 IN IP4 126.16.64.4
	s=Example		s=Example
	i=An example session		i=An example session
	e=user@example.com		e=user@example.com
	c=IN IP4 224.2.17.12/127		c=IN IP4 192.168.0.12/127
	t=0 0		t=0 0
	m=audio 0 RTP/AVP 0		m=audio 0 RTP/AVP 0
	a=loopback:rtp-media-loopback		a=loopback:rtp-media-loopback
	a=loopback-mirror		a=loopback-mirror
	NOTE: Loopback request may be rejected by either not including the		NOTE: Loopback request may be rejected by either not including the
	loopback mode attribute (for backward compatibility) or setting the		loopback mode attribute (for backward compatibility) or setting the
	media port number to zero, or both, in the response.		media port number to zero, or both, in the response.
	8.5 Response to INVITE request rejecting loopback media with		8.5 Response to INVITE request rejecting loopback media with
	rtp-start-loopback		rtp-start-loopback
	A client sends an INVITE request with SDP which looks like:		A client sends an INVITE request with SDP which looks like:
	v=0		v=0
	skipping to change at page 13, line 15		skipping to change at page 13, line 18
	8.5 Response to INVITE request rejecting loopback media with		8.5 Response to INVITE request rejecting loopback media with
	rtp-start-loopback		rtp-start-loopback
	A client sends an INVITE request with SDP which looks like:		A client sends an INVITE request with SDP which looks like:
	v=0		v=0
	o=user1 2890844526 2890842807 IN IP4 126.16.64.4		o=user1 2890844526 2890842807 IN IP4 126.16.64.4
	s=Example		s=Example
	i=An example session		i=An example session
	e=user@example.com		e=user@example.com
	c=IN IP4 224.2.17.12/127		c=IN IP4 192.168.0.12/127
	t=0 0		t=0 0
	m=audio 49170 RTP/AVP 0		m=audio 49170 RTP/AVP 0
	a=loopback:rtp-media-loopback		a=loopback:rtp-media-loopback
	a=loopback-source		a=loopback-source
	m=audio 49170 RTP/AVP 100		m=audio 49170 RTP/AVP 100
	a=loopback:rtp-start-loopback		a=loopback:rtp-start-loopback
	The client is offering to source the media and expects the server		The client is offering to source the media and expects the server
	to mirror the RTP stream at the media level. The client also		to mirror the RTP stream at the media level. The client also
	expects the server to source media until it receives packets from		expects the server to source media until it receives packets from
	the server per media described with the rtp-start-loopback		the server per media described with the rtp-start-loopback
	attribute.		attribute.
	A server sends a response with SDP which looks like:		A server sends a response with SDP which looks like:
	v=0		v=0
	o=user1 2890844526 2890842807 IN IP4 126.16.64.4		o=user1 2890844526 2890842807 IN IP4 126.16.64.4
	s=Example		s=Example
	i=An example session		i=An example session
	e=user@example.com		e=user@example.com
	c=IN IP4 224.2.17.12/127		c=IN IP4 192.168.0.12/127
	t=0 0		t=0 0
	m=audio 0 RTP/AVP 0		m=audio 0 RTP/AVP 0
	a=loopback:rtp-media-loopback		a=loopback:rtp-media-loopback
	a=loopback-mirror		a=loopback-mirror
	m=audio 0 RTP/AVP 0		m=audio 0 RTP/AVP 0
	a=loopback:rtp-start-loopback		a=loopback:rtp-start-loopback
	NOTE: Loopback request may be rejected by either not including the		NOTE: Loopback request may be rejected by either not including the
	loopback mode attribute(for backward compatibility) or setting the		loopback mode attribute(for backward compatibility) or setting the
	media port number to zero, or both, in the response.		media port number to zero, or both, in the response.
	skipping to change at page 14, line 4		skipping to change at page 14, line 6
	a=loopback:rtp-media-loopback		a=loopback:rtp-media-loopback
	a=loopback-mirror		a=loopback-mirror
	m=audio 0 RTP/AVP 0		m=audio 0 RTP/AVP 0
	a=loopback:rtp-start-loopback		a=loopback:rtp-start-loopback
	NOTE: Loopback request may be rejected by either not including the		NOTE: Loopback request may be rejected by either not including the
	loopback mode attribute(for backward compatibility) or setting the		loopback mode attribute(for backward compatibility) or setting the
	media port number to zero, or both, in the response.		media port number to zero, or both, in the response.
	9. Security Considerations		9. Security Considerations
	The security considerations of [RFC3261] apply. Furthermore, given		The security considerations of [RFC3261] apply. Furthermore, given
	that media loopback may be automated without the end user's		that media loopback may be automated without the end user's
	knowledge, the server of the media loopback should be aware of		knowledge, the server of the media loopback should be aware of
	denial of service attacks. It is recommended that sessions with		denial of service attacks. It is recommended that sessions with
	media loopback are authenticated and the frequency of such sessions		media loopback are authenticated and the frequency of such sessions
	are limited by the server.		is limited by the server.
	10. IANA Considerations		10. IANA Considerations
	There are no IANA considerations associated with this		There are no IANA considerations associated with this
	specification.		specification.
	11. Acknowledgements		11. Acknowledgements
	The authors wish to thank Flemming Andreasen, Jeff Bernstein, Paul		The authors wish to thank Nagarjuna Venna, Flemming Andreasen, Jeff
	Kyzivat, and Dave Oran for their comments and suggestions.		Bernstein, Paul Kyzivat, and Dave Oran for their comments and
			suggestions.
	12. References		12. References
	12.1 Normative References
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
	Johnston, A., Peterson, J., Sparks, R., Handley, M.		Johnston, A., Peterson, J., Sparks, R., Handley, M.
	and E. Schooler, "SIP: Session Initiation Protocol",		and E. Schooler, "SIP: Session Initiation Protocol",
	RFC 3261, STD 1, June 2002.		RFC 3261, STD 1, June 2002.
	[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer		[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer
	Model with the Session Description Protocol (SDP)",		Model with the Session Description Protocol (SDP)",
	RFC 3264, STD 1, June 2002.		RFC 3264, STD 1, June 2002.
	[RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V.		[RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V.
	skipping to change at page 15, line 31		skipping to change at page 15, line 34
	Cisco Systems, Inc.		Cisco Systems, Inc.
	7025 Kit Creek Rd.		7025 Kit Creek Rd.
	Research Triangle Park, NC 27709		Research Triangle Park, NC 27709
	US		US
	Phone: +1 919 392 6948		Phone: +1 919 392 6948
	EMail: paulej@packetizer.com		EMail: paulej@packetizer.com
	URI: http://www.cisco.com/		URI: http://www.cisco.com/
	Arjun Roychowdhury		Arjun Roychowdhury
	Flextronics Software Systems		Hughes Systique Corp.
	11717 Exploration Lane		15245 Shady Grove Rd, Ste 330
	Germantown, MD 20876		Rockville MD 20850
	US		US
	Phone: +1 301 212 7860		Phone: +1 301 527 1629
	EMail: arjun.roy@flextronicssoftware.com		EMail: arjun@hsc.com
	URI: http://www.flextronicssoftware.com/		URI: http://www. hsc.com/
	Chelliah SivaChelvan		Chelliah SivaChelvan
	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
	BroadVoice
	900 Chelmsford Street		663 Salem St.
	Tower Three		Lynnfield, MA 01940
	Lowell, MA 01851
	US
	Phone: +1 410 908 7587		Phone: +1 410 908 7587
	EMail: nathan@robotics.net		EMail: nathan@robotics.net
	URI: http://www.broadvoice.com/		URI: http://www.robotics.net/
	IPR Disclosure Acknowledgement		IPR Disclosure Acknowledgement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed		Intellectual Property Rights or other rights that might be claimed
	to pertain to the implementation or use of the technology described		to pertain to the implementation or use of the technology described
	in this document or the extent to which any license under such		in this document or the extent to which any license under such
	rights might or might not be available; nor does it represent that		rights might or might not be available; nor does it represent that
	it has made any independent effort to identify any such rights.		it has made any independent effort to identify any such rights.
	Information on the procedures with respect to rights in RFC		Information on the procedures with respect to rights in RFC
	skipping to change at page 17, line 11		skipping to change at page 17, line 13
	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 AND		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
	EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT		EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
	THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR		THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
	ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A		ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
	PARTICULAR PURPOSE.		PARTICULAR PURPOSE.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2006).
	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.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 44 change blocks.
	112 lines changed or deleted		109 lines changed or added
This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/