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/