draft-ietf-mmusic-media-loopback-08.txt		draft-ietf-mmusic-media-loopback-09.txt
	K. Hedayat		Internet Draft K. Hedayat
	Internet Draft Brix Networks		Expires: January 28, 2009 Brix Networks
	Expires: July 2008 P. Jones		N. Venna
			Brix Networks
			P. Jones
	Cisco Systems, Inc.		Cisco Systems, Inc.
	A. Roychowdhury		A. Roychowdhury
	Hughes Systique Corp.		Hughes Systique Corp.
	C. SivaChelvan		C. SivaChelvan
	Cisco Systems, Inc.		Cisco Systems, Inc.
	N. Stratton		N. Stratton
	BlinkMind, Inc.		BlinkMind, Inc.
	N. Venna		July 28, 2008
	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-08		draft-ietf-mmusic-media-loopback-09
	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 3, line 14		skipping to change at page 3, line 14
	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
	13.1 SDP Attributes..........................................20		13.1 SDP Attributes..........................................20
	13.2 MIME Types..............................................21		13.2 MIME Types..............................................21
	14. Acknowledgements............................................31		14. Acknowledgements............................................30
	15. Normative References........................................31		15. Normative References........................................30
	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 11, line 26		skipping to change at page 11, line 26
	MUST be encapsulated in a different packet, the encapsulated packet		MUST be encapsulated in a different packet, the encapsulated packet
	MAY be fragmented only if required (for example: due to MTU		MAY be fragmented only if required (for example: due to MTU
	limitations).		limitations).
	7.1.1 Usage of RTP Header fields		7.1.1 Usage of RTP Header fields
	Payload Type (PT): The assignment of an RTP payload type for this		Payload Type (PT): The assignment of an RTP payload type for this
	packet format is outside the scope of this document; it is either		packet format is outside the scope of this document; it is either
	specified by the RTP profile under which this payload format is		specified by the RTP profile under which this payload format is
	used or more likely signaled dynamically out-of-band (e.g., using		used or more likely signaled dynamically out-of-band (e.g., using
	SDP; section 7.3 defines the name binding).		SDP; section 7.1.3 defines the name binding).
	Marker (M) bit: If the received RTP packet is looped back in		Marker (M) bit: If the received RTP packet is looped back in
	multiple RTP packets, the M bit is set to 1 in the last packet,		multiple RTP packets, the M bit is set to 1 in the last packet,
	otherwise it is set to 0.		otherwise it is set to 0.
	Extension (X) bit: Defined by the RTP Profile used.		Extension (X) bit: Defined by the RTP Profile used.
	Sequence Number: The RTP sequence number SHOULD be generated by the		Sequence Number: The RTP sequence number SHOULD be generated by the
	loopback-mirror in the usual manner with a constant random offset.		loopback-mirror in the usual manner with a constant random offset.
	Timestamp: The RTP timestamp denotes the sampling instant for when		Timestamp: The RTP timestamp denotes the sampling instant for when
	the loopback-mirror is transmitting this packet to the loopback-		the loopback-mirror is transmitting this packet to the loopback-
	source. The RTP timestamp MUST based on the same clock used by the		source. The RTP timestamp MUST be based on the same clock used by
	loopback-source. The initial value of the timestamp SHOULD be		the loopback-source. The initial value of the timestamp SHOULD be
	random for security reasons (see Section 5.1 of RFC 3550		random for security reasons (see Section 5.1 of RFC 3550
	[RFC3550]).		[RFC3550]).
	SSRC: set as described in RFC 3550 [RFC3550].		SSRC: set as described in RFC 3550 [RFC3550].
	CC and CSRC fields are used as described in RFC 3550 [RFC3550].		CC and CSRC fields are used as described in RFC 3550 [RFC3550].
	7.1.2 RTP Payload Structure		7.1.2 RTP Payload Structure
	The RTP header in the encapsulated packet MUST be followed by the		The RTP header in the encapsulated packet MUST be followed by the
	skipping to change at page 13, line 43		skipping to change at page 13, line 43
	the MTU on the loopback path is less than the MTU on the transmit		the MTU on the loopback path is less than the MTU on the transmit
	path. When using this payload format, the receiver MUST loop back		path. When using this payload format, the receiver MUST loop back
	each received packet in a separate RTP packet.		each received packet in a separate RTP packet.
	7.2.1 Usage of RTP Header fields		7.2.1 Usage of RTP Header fields
	Payload Type (PT): The assignment of an RTP payload type for this		Payload Type (PT): The assignment of an RTP payload type for this
	packet format is outside the scope of this document; it is either		packet format is outside the scope of this document; it is either
	specified by the RTP profile under which this payload format is		specified by the RTP profile under which this payload format is
	used or more likely signaled dynamically out-of-band (e.g., using		used or more likely signaled dynamically out-of-band (e.g., using
	SDP; section 7.3 defines the name binding).		SDP; section 7.2.3 defines the name binding).
	Marker (M) bit: Set to the value in the received packet.		Marker (M) bit: Set to the value in the received packet.
	Extension (X) bit: Defined by the RTP Profile used.		Extension (X) bit: Defined by the RTP Profile used.
	Sequence Number: The RTP sequence number SHOULD be generated by the		Sequence Number: The RTP sequence number SHOULD be generated by the
	loopback-mirror in the usual manner with a constant random offset.		loopback-mirror in the usual manner with a constant random offset.
	Timestamp: The RTP timestamp denotes the sampling instant for when		Timestamp: The RTP timestamp denotes the sampling instant for when
	the loopback-mirror is transmitting this packet to the		the loopback-mirror is transmitting this packet to the
	loopback-source. The RTP timestamp MUST based on the same clock		loopback-source. The RTP timestamp MUST be based on the same clock
	used by the loopback-source. The initial value of the timestamp		used by the loopback-source. The initial value of the timestamp
	SHOULD be random for security reasons (see Section 5.1 of RFC 3550		SHOULD be random for security reasons (see Section 5.1 of RFC 3550
	[RFC3550]).		[RFC3550]).
	SSRC: set as described in RFC 3550 [RFC3550].		SSRC: set as described in RFC 3550 [RFC3550].
	CC and CSRC fields are used as described in RFC 3550 [RFC3550].		CC and CSRC fields are used as described in RFC 3550 [RFC3550].
	7.2.2 RTP Payload Structure		7.2.2 RTP Payload Structure
	skipping to change at page 16, line 8		skipping to change at page 16, line 8
	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 192.0.2.11		o=user1 2890844526 2890842807 IN IP4 192.0.2.11
	s=Example		s=Example
	i=An example session		i=An example session
	e=user@example.com		e=user@example.com
	c=IN IP4 192.0.2.12/127		c=IN IP4 192.0.2.12/127
	t=0 0		t=0 0
	m=audio 49170 RTP/AVP 0		m=audio 49270 RTP/AVP 0
	a=loopback:rtp-media-loopback		a=loopback:rtp-media-loopback
	a=loopback-mirror:0		a=loopback-mirror:0
	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.
	10.2 Offer for choice of media loopback type		10.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:
	skipping to change at page 16, line 44		skipping to change at page 16, line 44
	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 192.0.2.11		o=user1 2890844526 2890842807 IN IP4 192.0.2.11
	s=Example		s=Example
	i=An example session		i=An example session
	e=user@example.com		e=user@example.com
	c=IN IP4 192.0.2.12/127		c=IN IP4 192.0.2.12/127
	t=0 0		t=0 0
	m=audio 49170 RTP/AVP 112		m=audio 49270 RTP/AVP 112
	a=loopback:rtp-pkt-loopback		a=loopback:rtp-pkt-loopback
	a=loopback-mirror:0		a=loopback-mirror:0
	a=rtpmap:112 encaprtp/8000		a=rtpmap:112 encaprtp/8000
	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 using the encapsulated RTP payload format.		packet level using the encapsulated RTP payload format.
	10.3 Offer for choice of media loopback type with rtp-start-loopback		10.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:
	skipping to change at page 17, line 41		skipping to change at page 17, line 41
	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 192.0.2.11		o=user1 2890844526 2890842807 IN IP4 192.0.2.11
	s=Example		s=Example
	i=An example session		i=An example session
	e=user@example.com		e=user@example.com
	c=IN IP4 192.0.2.12/127		c=IN IP4 192.0.2.12/127
	t=0 0		t=0 0
	m=audio 49170 RTP/AVP 113		m=audio 49270 RTP/AVP 113
	a=loopback:rtp-pkt-loopback		a=loopback:rtp-pkt-loopback
	a=loopback-mirror:0		a=loopback-mirror:0
	a=rtpmap:113 rtploopback/8000		a=rtpmap:113 rtploopback/8000
	m=audio 49170 RTP/AVP 100		m=audio 49270 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 using the direct loopback RTP payload format. The		packet level using the direct loopback RTP payload format. The
	server is also accepting to source media until it receives media		server is also accepting to source media until it receives media
	packets from the client.		packets from the client.
	10.4 Response to INVITE request rejecting loopback media		10.4 Response to INVITE request rejecting loopback media
	skipping to change at page 21, line 29		skipping to change at page 21, line 29
	as defined in RFC 4566 Section 5.14.		as defined in RFC 4566 Section 5.14.
	13.2 MIME Types		13.2 MIME Types
	The IANA has registered the following MIME types:		The IANA has registered the following MIME types:
	13.2.1 audio/encaprtp		13.2.1 audio/encaprtp
	To: ietf-types@iana.org		To: ietf-types@iana.org
	Subject: Registration of MIME media type audio/encaprtp		Subject: Registration of media type audio/encaprtp
	MIME media type name: audio		Type name: audio
	MIME subtype name: encaprtp		Subtype name: encaprtp
	Required parameters: none		Required parameters:
	Note that RFC 4855 [RFC4855] mandates that RTP payload		rate:RTP timestamp clock rate, which is equal to the
	formats without a defined rate must define a rate		sampling rate. The typical rate is 8000; other rates
	parameter as part of their MIME registration. The		may be specified.
	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		Optional parameters: none
	Encoding considerations: This format is only defined for		Encoding considerations: This media type is framed
	transport within the Real Time Transport protocol (RTP)		binary data.
	[RFC 3550]. Its transport within RTP is fully
	specified in this document.
	Security considerations: See Section 11 of this document.		Security considerations: See Section 11 of this document.
	Interoperability considerations: none		Interoperability considerations: none
	Published specification: This MIME type is described fully		Published specification: This MIME type is described fully
	within this document.		within this document.
	Applications which use this media type: Applications wishing		Applications which use this media type: Applications wishing
	to monitor and ensure the quality of transport to the		to monitor and ensure the quality of transport to the
	edge of a given VoIP, Real-Time Text or Video Over IP		edge of a given VoIP, Real-Time Text or Video Over IP
	Service.		Service.
	Additional information: none		Additional information: none
	Person & email address to contact for further information:		Person & email address to contact for further information:
	Kaynam Hedayat		Kaynam Hedayat
	Brix Networks
	285 Mill Road
	Chelmsford, MA 01824
	US
	EMail: khedayat@brixnet.com		EMail: khedayat@brixnet.com
	Intended usage: COMMON		Intended usage: COMMON
	Author/Change controller: This registration is part of the		Restrictions on usage: This media type depends on RTP
	IETF registration tree.		framing, and hence is only defined for transfer via
			RTP. Transfer within other framing protocols is not
			defined at this time.
	RTP and SDP Issues: Usage of this format within RTP and the		Author:
	Session Description Protocol (SDP) are fully specified		Kaynam Hedayat.
	in this document.
			Change controller: IETF Audio/Video Transport working
			group delegated from the IESG.
	13.2.2 video/encaprtp		13.2.2 video/encaprtp
	To: ietf-types@iana.org		To: ietf-types@iana.org
	Subject: Registration of MIME media type video/encaprtp		Subject: Registration of media type video/encaprtp
	MIME media type name: video
	MIME subtype name: encaprtp		Type name: video
	Required parameters: none		Subtype name: encaprtp
	Note that RFC 4855 [RFC4855] mandates that RTP payload		Required parameters:
	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		rate:RTP timestamp clock rate, which is equal to the
	the rate of the stream being mirrored.		sampling rate. The typical rate is 8000; other rates
			may be specified.
	Optional parameters: none		Optional parameters: none
	Encoding considerations: This format is only defined for		Encoding considerations: This media type is framed
	transport within the Real Time Transport protocol (RTP)		binary data.
	[RFC 3550]. Its transport within RTP is fully
	specified in this document.
	Security considerations: See Section 11 of this document.		Security considerations: See Section 11 of this document.
	Interoperability considerations: none		Interoperability considerations: none
	Published specification: This MIME type is described fully		Published specification: This MIME type is described fully
	within this document.		within this document.
	Applications which use this media type: Applications wishing		Applications which use this media type: Applications wishing
	to monitor and ensure the quality of transport to the		to monitor and ensure the quality of transport to the
	edge of a given VoIP, Real-Time Text or Video Over IP		edge of a given VoIP, Real-Time Text or Video Over IP
	Service.		Service.
	Additional information: none		Additional information: none
	Person & email address to contact for further information:		Person & email address to contact for further information:
	Kaynam Hedayat		Kaynam Hedayat
	Brix Networks
	285 Mill Road
	Chelmsford, MA 01824
	US
	EMail: khedayat@brixnet.com		EMail: khedayat@brixnet.com
	Intended usage: COMMON		Intended usage: COMMON
	Author/Change controller: This registration is part of the		Restrictions on usage: This media type depends on RTP
	IETF registration tree.		framing, and hence is only defined for transfer via
			RTP. Transfer within other framing protocols is not
			defined at this time.
	RTP and SDP Issues: Usage of this format within RTP and the		Author:
	Session Description Protocol (SDP) are fully specified		Kaynam Hedayat.
	in this document.
			Change controller: IETF Audio/Video Transport working
			group delegated from the IESG.
	13.2.3 text/encaprtp		13.2.3 text/encaprtp
	To: ietf-types@iana.org		To: ietf-types@iana.org
	Subject: Registration of MIME media type text/encaprtp		Subject: Registration of media type text/encaprtp
	MIME media type name: text
	MIME subtype name: encaprtp		Type name: text
	Required parameters: none		Subtype name: encaprtp
	Note that RFC 4855 [RFC4855] mandates that RTP payload		Required parameters:
	formats without a defined rate must define a rate
	parameter as part of their MIME registration. The		rate:RTP timestamp clock rate, which is equal to the
	payload format for Encapsulated RTP does not specify a		sampling rate. The typical rate is 8000; other rates
	rate parameter. However, the rate for encapsulated		may be specified.
	stream is equal to the rate of the stream being
	mirrored.
	Optional parameters: none		Optional parameters: none
	Encoding considerations: This format is only defined for		Encoding considerations: This media type is framed
	transport within the Real Time Transport protocol (RTP)		binary data.
	[RFC 3550]. Its transport within RTP is fully
	specified in this document.
	Security considerations: See Section 11 of this document.		Security considerations: See Section 11 of this document.
	Interoperability considerations: none		Interoperability considerations: none
	Published specification: This MIME type is described fully		Published specification: This MIME type is described fully
	within this document.		within this document.
	Applications which use this media type: Applications wishing		Applications which use this media type: Applications wishing
	to monitor and ensure the quality of transport to the		to monitor and ensure the quality of transport to the
	edge of a given VoIP, Real-Time Text or Video Over IP		edge of a given VoIP, Real-Time Text or Video Over IP
	Service.		Service.
	Additional information: none		Additional information: none
	Person & email address to contact for further information:		Person & email address to contact for further information:
	Kaynam Hedayat		Kaynam Hedayat
	Brix Networks
	285 Mill Road
	Chelmsford, MA 01824
	US
	EMail: khedayat@brixnet.com		EMail: khedayat@brixnet.com
	Intended usage: COMMON		Intended usage: COMMON
	Author/Change controller: This registration is part of the		Restrictions on usage: This media type depends on RTP
	IETF registration tree.		framing, and hence is only defined for transfer via
			RTP. Transfer within other framing protocols is not
			defined at this time.
	RTP and SDP Issues: Usage of this format within RTP and the		Author:
	Session Description Protocol (SDP) are fully specified		Kaynam Hedayat.
	in this document.
			Change controller: IETF Audio/Video Transport working
			group delegated from the IESG.
	13.2.4 application/encaprtp		13.2.4 application/encaprtp
	To: ietf-types@iana.org		To: ietf-types@iana.org
	Subject: Registration of MIME media type		Subject: Registration of media type
	application/encaprtp		application/encaprtp
	MIME media type name: application		Type name: application
	MIME subtype name: encaprtp
	Required parameters: none		Subtype name: encaprtp
			Required parameters:
	Note that RFC 4855 [RFC4855] mandates that RTP payload		rate:RTP timestamp clock rate, which is equal to the
	formats without a defined rate must define a rate		sampling rate. The typical rate is 8000; other rates
	parameter as part of their MIME registration. The		may be specified.
	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		Optional parameters: none
	Encoding considerations: This format is only defined for		Encoding considerations: This media type is framed
	transport within the Real Time Transport protocol (RTP)		binary data.
	[RFC 3550]. Its transport within RTP is fully
	specified in this document.
	Security considerations: See Section 11 of this document.		Security considerations: See Section 11 of this document.
	Interoperability considerations: none		Interoperability considerations: none
	Published specification: This MIME type is described fully		Published specification: This MIME type is described fully
	within this document.		within this document.
	Applications which use this media type: Applications wishing		Applications which use this media type: Applications wishing
	to monitor and ensure the quality of transport to the		to monitor and ensure the quality of transport to the
	edge of a given VoIP, Real-Time Text or Video Over IP		edge of a given VoIP, Real-Time Text or Video Over IP
	Service.		Service.
	Additional information: none		Additional information: none
	Person & email address to contact for further information:		Person & email address to contact for further information:
	Kaynam Hedayat		Kaynam Hedayat
	Brix Networks
	285 Mill Road
	Chelmsford, MA 01824
	US
	EMail: khedayat@brixnet.com		EMail: khedayat@brixnet.com
	Intended usage: COMMON		Intended usage: COMMON
	Author/Change controller: This registration is part of the		Restrictions on usage: This media type depends on RTP
	IETF registration tree.		framing, and hence is only defined for transfer via
			RTP. Transfer within other framing protocols is not
			defined at this time.
	RTP and SDP Issues: Usage of this format within RTP and the		Author:
	Session Description Protocol (SDP) are fully specified		Kaynam Hedayat.
	in this document.
			Change controller: IETF Audio/Video Transport working
			group delegated from the IESG.
	13.2.5 audio/rtploopback		13.2.5 audio/rtploopback
	To: ietf-types@iana.org		To: ietf-types@iana.org
	Subject: Registration of MIME media type audio/rtploopback		Subject: Registration of media type audio/rtploopback
			Type name: audio
	MIME media type name: audio
	MIME subtype name: rtploopback		Subtype name: rtploopback
	Required parameters: none		Required parameters:
	Note that RFC 4855 [RFC4855] mandates that RTP payload		rate:RTP timestamp clock rate, which is equal to the
	formats without a defined rate must define a rate		sampling rate. The typical rate is 8000; other rates
	parameter as part of their MIME registration. The		may be specified.
	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		Optional parameters: none
	Encoding considerations: This format is only defined for		Encoding considerations: This media type is framed
	transport within the Real Time Transport protocol (RTP)		binary data.
	[RFC 3550]. Its transport within RTP is fully
	specified in this document.
	Security considerations: See Section 11 of this document.		Security considerations: See Section 11 of this document.
	Interoperability considerations: none		Interoperability considerations: none
	Published specification: This MIME type is described fully		Published specification: This MIME type is described fully
	within this document.		within this document.
	Applications which use this media type: Applications wishing		Applications which use this media type: Applications wishing
	to monitor and ensure the quality of transport to the		to monitor and ensure the quality of transport to the
	edge of a given VoIP, Real-Time Text or Video Over IP		edge of a given VoIP, Real-Time Text or Video Over IP
	Service.		Service.
	Additional information: none		Additional information: none
	Person & email address to contact for further information:		Person & email address to contact for further information:
	Kaynam Hedayat		Kaynam Hedayat
	Brix Networks
	285 Mill Road
	Chelmsford, MA 01824
	US
	EMail: khedayat@brixnet.com		EMail: khedayat@brixnet.com
	Intended usage: COMMON		Intended usage: COMMON
	Author/Change controller: This registration is part of the		Restrictions on usage: This media type depends on RTP
	IETF registration tree.		framing, and hence is only defined for transfer via
			RTP. Transfer within other framing protocols is not
			defined at this time.
	RTP and SDP Issues: Usage of this format within RTP and the		Author:
	Session Description Protocol (SDP) are fully specified		Kaynam Hedayat.
	in this document.
	13.2.6 video/rtploopback		Change controller: IETF Audio/Video Transport working
			group delegated from the IESG.
			13.2.6 video/rtploopback
	To: ietf-types@iana.org		To: ietf-types@iana.org
	Subject: Registration of MIME media type video/rtploopback		Subject: Registration of media type video/rtploopback
	MIME media type name: video		Type name: video
	MIME subtype name: rtploopback		Subtype name: rtploopback
	Required parameters: none		Required parameters:
	Note that RFC 4855 [RFC4855] mandates that RTP payload		rate:RTP timestamp clock rate, which is equal to the
	formats without a defined rate must define a rate		sampling rate. The typical rate is 8000; other rates
	parameter as part of their MIME registration. The		may be specified.
	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		Optional parameters: none
	Encoding considerations: This format is only defined for		Encoding considerations: This media type is framed
	transport within the Real Time Transport protocol (RTP)		binary data.
	[RFC 3550]. Its transport within RTP is fully
	specified in this document.
	Security considerations: See Section 11 of this document.		Security considerations: See Section 11 of this document.
	Interoperability considerations: none		Interoperability considerations: none
	Published specification: This MIME type is described fully		Published specification: This MIME type is described fully
	within this document.		within this document.
	Applications which use this media type: Applications wishing		Applications which use this media type: Applications wishing
	to monitor and ensure the quality of transport to the		to monitor and ensure the quality of transport to the
	edge of a given VoIP, Real-Time Text or Video Over IP		edge of a given VoIP, Real-Time Text or Video Over IP
	Service.		Service.
	Additional information: none		Additional information: none
	Person & email address to contact for further information:		Person & email address to contact for further information:
	Kaynam Hedayat		Kaynam Hedayat
	Brix Networks
	285 Mill Road
	Chelmsford, MA 01824
	US
	EMail: khedayat@brixnet.com		EMail: khedayat@brixnet.com
	Intended usage: COMMON		Intended usage: COMMON
	Author/Change controller: This registration is part of the		Restrictions on usage: This media type depends on RTP
	IETF registration tree.		framing, and hence is only defined for transfer via
			RTP. Transfer within other framing protocols is not
			defined at this time.
	RTP and SDP Issues: Usage of this format within RTP and the		Author:
	Session Description Protocol (SDP) [6] are fully		Kaynam Hedayat.
	specified in this document.
			Change controller: IETF Audio/Video Transport working
			group delegated from the IESG.
	13.2.7 text/rtploopback		13.2.7 text/rtploopback
	To: ietf-types@iana.org		To: ietf-types@iana.org
	Subject: Registration of MIME media type text/rtploopback		Subject: Registration of media type text/rtploopback
	MIME media type name: text		Type name: text
	MIME subtype name: rtploopback		Subtype name: rtploopback
	Required parameters: none		Required parameters:
	Note that RFC 4855 [RFC4855] mandates that RTP payload
	formats without a defined rate must define a rate		rate:RTP timestamp clock rate, which is equal to the
	parameter as part of their MIME registration. The		sampling rate. The typical rate is 8000; other rates
	payload format for Encapsulated RTP does not specify a		may be specified.
	rate parameter. However, the rate for encapsulated
	stream is equal to the rate of the stream being
	mirrored.
	Optional parameters: none		Optional parameters: none
	Encoding considerations: This format is only defined for		Encoding considerations: This media type is framed
	transport within the Real Time Transport protocol (RTP)		binary data.
	[RFC 3550]. Its transport within RTP is fully
	specified in this document.
	Security considerations: See Section 11 of this document.		Security considerations: See Section 11 of this document.
	Interoperability considerations: none		Interoperability considerations: none
	Published specification: This MIME type is described fully		Published specification: This MIME type is described fully
	within this document.		within this document.
	Applications which use this media type: Applications wishing		Applications which use this media type: Applications wishing
	to monitor and ensure the quality of transport to the		to monitor and ensure the quality of transport to the
	edge of a given VoIP, Real-Time Text or Video Over IP		edge of a given VoIP, Real-Time Text or Video Over IP
	Service.		Service.
	Additional information: none		Additional information: none
	Person & email address to contact for further information:		Person & email address to contact for further information:
	Kaynam Hedayat		Kaynam Hedayat
	Brix Networks
	285 Mill Road
	Chelmsford, MA 01824
	US
	EMail: khedayat@brixnet.com		EMail: khedayat@brixnet.com
	Intended usage: COMMON		Intended usage: COMMON
	Author/Change controller: This registration is part of the		Restrictions on usage: This media type depends on RTP
	IETF registration tree.		framing, and hence is only defined for transfer via
			RTP. Transfer within other framing protocols is not
			defined at this time.
	RTP and SDP Issues: Usage of this format within RTP and the		Author:
	Session Description Protocol (SDP) [6] are fully		Kaynam Hedayat.
	specified in this document.
			Change controller: IETF Audio/Video Transport working
			group delegated from the IESG.
	13.2.8 application/rtploopback		13.2.8 application/rtploopback
	To: ietf-types@iana.org		To: ietf-types@iana.org
	Subject: Registration of MIME media type		Subject: Registration of media type
	application/rtploopback		application/rtploopback
	MIME media type name: application		Type name: application
	MIME subtype name: rtploopback		Subtype name: rtploopback
	Required parameters: none		Required parameters:
	Note that RFC 4855 [RFC4855] mandates that RTP payload		rate:RTP timestamp clock rate, which is equal to the
	formats without a defined rate must define a rate		sampling rate. The typical rate is 8000; other rates
	parameter as part of their MIME registration. The		may be specified.
	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		Optional parameters: none
	Encoding considerations: This format is only defined for		Encoding considerations: This media type is framed
	transport within the Real Time Transport protocol (RTP)		binary data.
	[RFC 3550]. Its transport within RTP is fully
	specified in this document.
	Security considerations: See Section 11 of this document.		Security considerations: See Section 11 of this document.
	Interoperability considerations: none		Interoperability considerations: none
	Published specification: This MIME type is described fully		Published specification: This MIME type is described fully
	within this document.		within this document.
	Applications which use this media type: Applications wishing		Applications which use this media type: Applications wishing
	to monitor and ensure the quality of transport to the		to monitor and ensure the quality of transport to the
	edge of a given VoIP, Real-Time Text or Video Over IP		edge of a given VoIP, Real-Time Text or Video Over IP
	Service.		Service.
	Additional information: none		Additional information: none
	Person & email address to contact for further information:		Person & email address to contact for further information:
	Kaynam Hedayat		Kaynam Hedayat
	Brix Networks
	285 Mill Road
	Chelmsford, MA 01824
	US
	EMail: khedayat@brixnet.com		EMail: khedayat@brixnet.com
	Intended usage: COMMON		Intended usage: COMMON
	Author/Change controller: This registration is part of the		Restrictions on usage: This media type depends on RTP
	IETF registration tree.		framing, and hence is only defined for transfer via
			RTP. Transfer within other framing protocols is not
			defined at this time.
	RTP and SDP Issues: Usage of this format within RTP and the		Author:
	Session Description Protocol (SDP) [6] are fully		Kaynam Hedayat.
	specified in this document.
			Change controller: IETF Audio/Video Transport working
			group delegated from the IESG.
	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 32, line 34		skipping to change at page 31, line 34
	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
	URI: http://www.brixnet.com/		URI: http://www.brixnet.com/
			Nagarjuna Venna
			Brix Networks
			285 Mill Road
			Chelmsford, MA 01824
			US
			Phone: +1 978 367 5703
			EMail: nvenna@brixnet.com
			URI: http://www.brixnet.com/
	Paul E. Jones		Paul E. Jones
	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
	Hughes Systique Corp.		Hughes Systique Corp.
End of changes. 85 change blocks.
	215 lines changed or deleted		175 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/