draft-ietf-mmusic-media-loopback-01.txt		draft-ietf-mmusic-media-loopback-02.txt
	K. Hedayat		K. Hedayat
	Internet Draft Brix Networks		Internet Draft Brix Networks
	Expires: December 27,2005 P. Jones		Expires: May 11, 2006 P. Jones
	Cisco Systems, Inc.		Cisco Systems, Inc.
	A. Roychowdhury		A. Roychowdhury
	Flextronics Software Systems		Flextronics Software Systems
	C. SivaChelvan		C. SivaChelvan
	Cisco Systems, Inc.		Cisco Systems, Inc.
	N. Stratton		N. Stratton
	BroadVoice		BroadVoice
	June 27, 2005		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-01.txt		draft-ietf-mmusic-media-loopback-02
	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 5, line 31		skipping to change at page 5, line 31
	to the analog interface and after the decoder so that the RTP		to the analog interface and after the decoder so that the RTP
	packets are subsequently re-encoded prior to transmission back to		packets are subsequently re-encoded prior to transmission back to
	the sender.		the sender.
	rtp-start-loopback: In certain scenarios it is possible that the		rtp-start-loopback: In certain scenarios it is possible that the
	media transmitted by the offering entity is blocked by a network		media transmitted by the offering entity is blocked by a network
	element until the answering entity starts transmitting packets.		element until the answering entity starts transmitting packets.
	One example of this scenario is the presence of an RTP relay in the		One example of this scenario is the presence of an RTP relay in the
	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. After the first media
	packet is received from the offering entity, the answering entity		packet is received from the offering entity, the answering entity
	MUST terminate the transmission of rtp-start-loopback media and		MUST terminate the transmission of rtp-start-loopback media and
	skipping to change at page 6, line 31		skipping to change at page 6, line 31
	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 reciver for
	transmission in the mirrored stream.		transmission in the mirrored stream.
	The loopback mode attribute does not apply to rtp-start-loopback		The loopback mode attribute does not apply to rtp-start-loopback
	attribute and MAY be omitted. If the loopback mode attribute is		attribute and MUST be ignored if received by the answering entityt.
	present with the rtp-start-loopback attribute it MUST be ignored 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
	skipping to change at page 8, line 6		skipping to change at page 8, line 6
	a=loopback:rtp-media-loopback rtp-pkt-loopback		a=loopback:rtp-media-loopback rtp-pkt-loopback
	a=loopback-source		a=loopback-source
	The answer that is capable of supporting the offer and chooses to		The answer that is capable of supporting the offer and chooses to
	loopback the media using the rtp-media-loopback type MUST contain:		loopback the media using the rtp-media-loopback type MUST contain:
	a=loopback:rtp-media-loopback		a=loopback:rtp-media-loopback
	a=loopback-mirror		a=loopback-mirror
	5.4.1 Rejecting the Loopback Offer		5.4.1 Rejecting the Loopback Offer
	An offered stream with loopback-source MAY be rejected, if the		An offered stream with loopback-source MAY be rejected if the
	loopback-type is not specified, the specified loopback-type is not		loopback-type is not specified, the specified loopback-type is not
	supported, or the endpoint cannot honor the offer for any other		supported, or the endpoint cannot honor the offer for any other
	reason. The Loopback request may be rejected by setting the media		reason. The Loopback request may be rejected by setting the media
	port number to zero, according to RFC 3264 [RFC3264], in the		port number to zero in the answer as per RFC 3264 [RFC3264].
	answer.
	5.5 Offerer Processing of the Answer		5.5 Offerer Processing of the Answer
	The answer to a loopback-source MUST be loopback-mirror. The		The answer to a loopback-source MUST be loopback-mirror. The
	answer to a loopback-mirror MUST be loopback-source. In addition,		answer to a loopback-mirror MUST be loopback-source. In addition,
	the "m=" line MUST contain at least one codec that the answerer is		the "m=" line MUST contain at least one codec that the answerer is
	willing to both send and receive.		willing to both send and receive.
	If the answer does not contain a=loopback-mirror or		If the answer does not contain a=loopback-mirror or
	a=loopback-source or contains any other standard mode attributes,		a=loopback-source or contains any other standard mode attributes,
	skipping to change at page 9, line 4		skipping to change at page 8, line 43
	An answering entitity that is compliant to this specification and		An answering entitity 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
	re-generate all of the RTP header fields as it does when		re-generate all of the RTP header fields as it does when
	transmitting other media. However, the answering entity MUST		transmitting other media. However, the answering entity MUST
	maintain the timing information of the received RTP packets when		maintain the timing information of the received RTP packets when
	generating the RTP timestamp for the transmit packets. Maintaining		generating the RTP timestamp for the transmit packets. Maintaining
	the timing information of the RTP packets enables the offerer to		the timing information of the RTP packets enables the offerer to
	re-construct the incoming media and take account for impairments		re-construct the incoming media and take account for impairments
	from gaps in the media due to packet loss. Note that RTP Sequence		from gaps in the media due to packet loss. Note that RTP Sequence
	numbers are re-generated by the UAS and will not provide packet		numbers are re-generated by the answering entity and will not
	loss information to the receiver of the loopback media.		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 UAS MAY choose to encode the loopback media		transmitting media. The answering entity MAY choose to encode the
	according to any of the media descriptions supported by the UAC.		loopback media according to any of the media descriptions supported
	Furthermore, in cases where the same media type is looped back, the		by the offering entity. Furthermore, in cases where the same media
	UAS MAY choose to preserve number of frames/packet and bitrate of		type is looped back, the answering entity MAY choose to preserve
	the encoded media according to the received media.		number of frames/packet and bitrate of the encoded media according
			to the received media.
	7. RTCP Requirements		7. RTCP Requirements
	The use of the loopback attribute is intended for monitoring of		The use of the loopback attribute is intended for monitoring of
	media quality of the session. Consequently the media performance		media quality of the session. Consequently the media performance
	information should be exchanged between the offering and the		information should be exchanged between the offering and the
	answering entities. An offering or answering entity that is		answering entities. An offering or answering entity that is
	compliant to this specification SHOULD support RTCP per [RFC3550]		compliant to this specification SHOULD support RTCP per [RFC3550]
	and RTCP-XR per RFC 3611 [RFC3611]. Furthermore, if the client or		and RTCP-XR per RFC 3611 [RFC3611]. Furthermore, if the client or
	the server choose to support RTCP-XR, they SHOULD support RTCP-XR		the server choose to support RTCP-XR, they SHOULD support RTCP-XR
	Statistics Summary Report Block and VoIP Metric Reports Block per		Loss RLE report block, Duplicate RLE report block, Statistics
	sections 4.6 and 4.7 of RFC 3611 [RFC3611]. The client and the		Summary report block, and VoIP Metric Reports Block per sections
			4.1, 4.2, 4.6, and 4.7 of RFC 3611 [RFC3611]. The client and the
	server MAY support other RTCP-XR reporting blocks as defined by RFC		server MAY support other RTCP-XR reporting blocks as defined by RFC
	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
	skipping to change at page 15, line 6		skipping to change at page 15, line 6
	[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", RFC 3550, STD 1, July 2003.		Applications", RFC 3550, STD 1, 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, STD 1, November 2003.		Reports (RTCP XR)", RFC 3611, STD 1, November 2003.
	[RFC2234] Crocker, P. Overell, "Augmented ABNF for Syntax		[RFC2234] Crocker, P. Overell, "Augmented ABNF for Syntax
	Specification: ABNFö, RFC 3611, STD 1, November 1997.		Specification: ABNF”, RFC 3611, STD 1, November 1997.
	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
	skipping to change at page 16, line 13		skipping to change at page 16, line 13
	EMail: chelliah@cisco.com		EMail: chelliah@cisco.com
	URI: http://www.cisco.com/		URI: http://www.cisco.com/
	Nathan Stratton		Nathan Stratton
	BroadVoice		BroadVoice
	900 Chelmsford Street		900 Chelmsford Street
	Tower Three		Tower Three
	Lowell, MA 01851		Lowell, MA 01851
	US		US
	Phone: +1 978 418 7320		Phone: +1 410 908 7587
	EMail: nstratton@broadvoice.com		EMail: nathan@robotics.net
	URI: http://www.broadvoice.com/		URI: http://www.broadvoice.com/
	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.
End of changes. 13 change blocks.
	23 lines changed or deleted		23 lines changed or added
This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/