--- 1/draft-ietf-mmusic-media-loopback-08.txt 2008-08-05 01:12:34.000000000 +0200 +++ 2/draft-ietf-mmusic-media-loopback-09.txt 2008-08-05 01:12:34.000000000 +0200 @@ -1,28 +1,28 @@ - K. Hedayat - Internet Draft Brix Networks - Expires: July 2008 P. Jones + Internet Draft K. Hedayat + Expires: January 28, 2009 Brix Networks + N. Venna + Brix Networks + P. Jones Cisco Systems, Inc. A. Roychowdhury Hughes Systique Corp. C. SivaChelvan Cisco Systems, Inc. N. Stratton BlinkMind, Inc. - N. Venna - Brix Networks - January 2008 + July 28, 2008 An Extension to the Session Description Protocol (SDP) for Media Loopback - draft-ietf-mmusic-media-loopback-08 + draft-ietf-mmusic-media-loopback-09 Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -90,22 +90,22 @@ 10.3 Offer for choice of media loopback type with rtp-start-loopback...........................................17 10.4 Response to INVITE request rejecting loopback media.....18 10.5 Response to INVITE request rejecting loopback media with rtp-start-loopback...........................................18 11. Security Considerations.....................................19 12. Implementation Considerations...............................20 13. IANA Considerations.........................................20 13.1 SDP Attributes..........................................20 13.2 MIME Types..............................................21 - 14. Acknowledgements............................................31 - 15. Normative References........................................31 + 14. Acknowledgements............................................30 + 15. Normative References........................................30 1. Introduction The overall quality, reliability, and performance of VoIP, 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 the delivered media there is a need to monitor the performance of the media transport. One method of monitoring and managing the overall quality of VoIP, Real-time Text and Video over IP Services is through monitoring the quality of the media in an active @@ -465,35 +465,35 @@ MUST be encapsulated in a different packet, the encapsulated packet MAY be fragmented only if required (for example: due to MTU limitations). 7.1.1 Usage of RTP Header fields Payload Type (PT): The assignment of an RTP payload type for this packet format is outside the scope of this document; it is either specified by the RTP profile under which this payload format is 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 multiple RTP packets, the M bit is set to 1 in the last packet, otherwise it is set to 0. Extension (X) bit: Defined by the RTP Profile used. Sequence Number: The RTP sequence number SHOULD be generated by the loopback-mirror in the usual manner with a constant random offset. Timestamp: The RTP timestamp denotes the sampling instant for when the loopback-mirror is transmitting this packet to the loopback- - source. The RTP timestamp MUST based on the same clock used by the - loopback-source. The initial value of the timestamp SHOULD be + source. The RTP timestamp MUST be based on the same clock used by + the loopback-source. The initial value of the timestamp SHOULD be random for security reasons (see Section 5.1 of RFC 3550 [RFC3550]). SSRC: set as described in RFC 3550 [RFC3550]. CC and CSRC fields are used as described in RFC 3550 [RFC3550]. 7.1.2 RTP Payload Structure The RTP header in the encapsulated packet MUST be followed by the @@ -573,32 +573,32 @@ 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 each received packet in a separate RTP packet. 7.2.1 Usage of RTP Header fields Payload Type (PT): The assignment of an RTP payload type for this packet format is outside the scope of this document; it is either specified by the RTP profile under which this payload format is 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. Extension (X) bit: Defined by the RTP Profile used. Sequence Number: The RTP sequence number SHOULD be generated by the loopback-mirror in the usual manner with a constant random offset. Timestamp: The RTP timestamp denotes the sampling instant for when 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 SHOULD be random for security reasons (see Section 5.1 of RFC 3550 [RFC3550]). SSRC: set as described in RFC 3550 [RFC3550]. CC and CSRC fields are used as described in RFC 3550 [RFC3550]. 7.2.2 RTP Payload Structure @@ -669,21 +669,21 @@ A server sends a response with SDP which looks like: v=0 o=user1 2890844526 2890842807 IN IP4 192.0.2.11 s=Example i=An example session e=user@example.com c=IN IP4 192.0.2.12/127 t=0 0 - m=audio 49170 RTP/AVP 0 + m=audio 49270 RTP/AVP 0 a=loopback:rtp-media-loopback a=loopback-mirror:0 The server is accepting to mirror the media from the client at the media level. 10.2 Offer for choice of media loopback type A client sends an INVITE request with SDP which looks like: @@ -705,21 +705,21 @@ A server sends a response with SDP which looks like: v=0 o=user1 2890844526 2890842807 IN IP4 192.0.2.11 s=Example i=An example session e=user@example.com c=IN IP4 192.0.2.12/127 t=0 0 - m=audio 49170 RTP/AVP 112 + m=audio 49270 RTP/AVP 112 a=loopback:rtp-pkt-loopback a=loopback-mirror:0 a=rtpmap:112 encaprtp/8000 The server is accepting to mirror the media from the client at the packet level using the encapsulated RTP payload format. 10.3 Offer for choice of media loopback type with rtp-start-loopback A client sends an INVITE request with SDP which looks like: @@ -746,25 +746,25 @@ A server sends a response with SDP which looks like: v=0 o=user1 2890844526 2890842807 IN IP4 192.0.2.11 s=Example i=An example session e=user@example.com c=IN IP4 192.0.2.12/127 t=0 0 - m=audio 49170 RTP/AVP 113 + m=audio 49270 RTP/AVP 113 a=loopback:rtp-pkt-loopback a=loopback-mirror:0 a=rtpmap:113 rtploopback/8000 - m=audio 49170 RTP/AVP 100 + m=audio 49270 RTP/AVP 100 a=rtpmap:100 pcmu/8000 a=loopback:rtp-start-loopback The server is accepting to mirror the media from the client at the packet level using the direct loopback RTP payload format. The server is also accepting to source media until it receives media packets from the client. 10.4 Response to INVITE request rejecting loopback media @@ -917,488 +917,437 @@ as defined in RFC 4566 Section 5.14. 13.2 MIME Types The IANA has registered the following MIME types: 13.2.1 audio/encaprtp To: ietf-types@iana.org - Subject: Registration of MIME media type audio/encaprtp + 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 - formats without a defined rate must define a rate - parameter as part of their MIME registration. The - payload format for Encapsulated RTP does not specify a - rate parameter. However, the rate for encapsulated - stream is equal to the rate of the stream being - mirrored. + rate:RTP timestamp clock rate, which is equal to the + sampling rate. The typical rate is 8000; other rates + may be specified. Optional parameters: none - Encoding considerations: This format is only defined for - transport within the Real Time Transport protocol (RTP) - [RFC 3550]. Its transport within RTP is fully - specified in this document. + Encoding considerations: This media type is framed + binary data. Security considerations: See Section 11 of this document. Interoperability considerations: none Published specification: This MIME type is described fully within this document. Applications which use this media type: Applications wishing to monitor and ensure the quality of transport to the edge of a given VoIP, Real-Time Text or Video Over IP Service. Additional information: none Person & email address to contact for further information: Kaynam Hedayat - Brix Networks - 285 Mill Road - Chelmsford, MA 01824 - US EMail: khedayat@brixnet.com Intended usage: COMMON - Author/Change controller: This registration is part of the - IETF registration tree. + Restrictions on usage: This media type depends on RTP + 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 - Session Description Protocol (SDP) are fully specified - in this document. + Author: + Kaynam Hedayat. + + Change controller: IETF Audio/Video Transport working + group delegated from the IESG. 13.2.2 video/encaprtp To: ietf-types@iana.org - Subject: Registration of MIME media type video/encaprtp - - MIME media type name: video + Subject: Registration of media type video/encaprtp - MIME subtype name: encaprtp + Type name: video - Required parameters: none + Subtype name: encaprtp - Note that RFC 4855 [RFC4855] mandates that RTP payload - formats without a defined rate must define a rate - parameter as part of their MIME registration. The - payload format for Encapsulated RTP does not specify a - rate parameter. + Required parameters: - However, the rate for encapsulated stream is equal to - the rate of the stream being mirrored. + rate:RTP timestamp clock rate, which is equal to the + sampling rate. The typical rate is 8000; other rates + may be specified. Optional parameters: none - Encoding considerations: This format is only defined for - transport within the Real Time Transport protocol (RTP) - [RFC 3550]. Its transport within RTP is fully - specified in this document. + Encoding considerations: This media type is framed + binary data. Security considerations: See Section 11 of this document. Interoperability considerations: none Published specification: This MIME type is described fully within this document. Applications which use this media type: Applications wishing to monitor and ensure the quality of transport to the edge of a given VoIP, Real-Time Text or Video Over IP Service. Additional information: none Person & email address to contact for further information: Kaynam Hedayat - Brix Networks - 285 Mill Road - Chelmsford, MA 01824 - US EMail: khedayat@brixnet.com Intended usage: COMMON - Author/Change controller: This registration is part of the - IETF registration tree. + Restrictions on usage: This media type depends on RTP + 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 - Session Description Protocol (SDP) are fully specified - in this document. + Author: + Kaynam Hedayat. + + Change controller: IETF Audio/Video Transport working + group delegated from the IESG. 13.2.3 text/encaprtp To: ietf-types@iana.org - Subject: Registration of MIME media type text/encaprtp - MIME media type name: text + Subject: Registration of media type text/encaprtp - MIME subtype name: encaprtp + Type name: text - Required parameters: none + Subtype name: encaprtp - Note that RFC 4855 [RFC4855] mandates that RTP payload - formats without a defined rate must define a rate - parameter as part of their MIME registration. The - payload format for Encapsulated RTP does not specify a - rate parameter. However, the rate for encapsulated - stream is equal to the rate of the stream being - mirrored. + Required parameters: + + rate:RTP timestamp clock rate, which is equal to the + sampling rate. The typical rate is 8000; other rates + may be specified. Optional parameters: none - Encoding considerations: This format is only defined for - transport within the Real Time Transport protocol (RTP) - [RFC 3550]. Its transport within RTP is fully - specified in this document. + Encoding considerations: This media type is framed + binary data. Security considerations: See Section 11 of this document. Interoperability considerations: none Published specification: This MIME type is described fully within this document. Applications which use this media type: Applications wishing to monitor and ensure the quality of transport to the edge of a given VoIP, Real-Time Text or Video Over IP Service. Additional information: none Person & email address to contact for further information: Kaynam Hedayat - Brix Networks - 285 Mill Road - Chelmsford, MA 01824 - US EMail: khedayat@brixnet.com Intended usage: COMMON - Author/Change controller: This registration is part of the - IETF registration tree. + Restrictions on usage: This media type depends on RTP + 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 - Session Description Protocol (SDP) are fully specified - in this document. + Author: + Kaynam Hedayat. + + Change controller: IETF Audio/Video Transport working + group delegated from the IESG. 13.2.4 application/encaprtp To: ietf-types@iana.org - Subject: Registration of MIME media type + Subject: Registration of media type application/encaprtp - MIME media type name: application - - MIME subtype name: encaprtp + Type name: application - Required parameters: none + Subtype name: encaprtp + Required parameters: - Note that RFC 4855 [RFC4855] mandates that RTP payload - formats without a defined rate must define a rate - parameter as part of their MIME registration. The - payload format for Encapsulated RTP does not specify a - rate parameter. However, the rate for encapsulated - stream is equal to the rate of the stream being - mirrored. + rate:RTP timestamp clock rate, which is equal to the + sampling rate. The typical rate is 8000; other rates + may be specified. Optional parameters: none - Encoding considerations: This format is only defined for - transport within the Real Time Transport protocol (RTP) - [RFC 3550]. Its transport within RTP is fully - specified in this document. + Encoding considerations: This media type is framed + binary data. Security considerations: See Section 11 of this document. Interoperability considerations: none Published specification: This MIME type is described fully within this document. Applications which use this media type: Applications wishing to monitor and ensure the quality of transport to the edge of a given VoIP, Real-Time Text or Video Over IP Service. Additional information: none Person & email address to contact for further information: Kaynam Hedayat - Brix Networks - 285 Mill Road - Chelmsford, MA 01824 - US EMail: khedayat@brixnet.com Intended usage: COMMON - Author/Change controller: This registration is part of the - IETF registration tree. + Restrictions on usage: This media type depends on RTP + 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 - Session Description Protocol (SDP) are fully specified - in this document. + Author: + Kaynam Hedayat. + + Change controller: IETF Audio/Video Transport working + group delegated from the IESG. 13.2.5 audio/rtploopback To: ietf-types@iana.org - Subject: Registration of MIME media type audio/rtploopback - - MIME media type name: audio + Subject: Registration of media type audio/rtploopback + Type name: audio - 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 - parameter as part of their MIME registration. The - payload format for Encapsulated RTP does not specify a - rate parameter. However, the rate for encapsulated - stream is equal to the rate of the stream being - mirrored. + rate:RTP timestamp clock rate, which is equal to the + sampling rate. The typical rate is 8000; other rates + may be specified. Optional parameters: none - Encoding considerations: This format is only defined for - transport within the Real Time Transport protocol (RTP) - [RFC 3550]. Its transport within RTP is fully - specified in this document. + Encoding considerations: This media type is framed + binary data. Security considerations: See Section 11 of this document. Interoperability considerations: none Published specification: This MIME type is described fully within this document. Applications which use this media type: Applications wishing to monitor and ensure the quality of transport to the edge of a given VoIP, Real-Time Text or Video Over IP Service. Additional information: none Person & email address to contact for further information: Kaynam Hedayat - Brix Networks - 285 Mill Road - Chelmsford, MA 01824 - US EMail: khedayat@brixnet.com Intended usage: COMMON - Author/Change controller: This registration is part of the - IETF registration tree. + Restrictions on usage: This media type depends on RTP + 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 - Session Description Protocol (SDP) are fully specified - in this document. + Author: + Kaynam Hedayat. - 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 - 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 - formats without a defined rate must define a rate - parameter as part of their MIME registration. The - payload format for Encapsulated RTP does not specify a - rate parameter. However, the rate for encapsulated - stream is equal to the rate of the stream being - mirrored. + rate:RTP timestamp clock rate, which is equal to the + sampling rate. The typical rate is 8000; other rates + may be specified. Optional parameters: none - Encoding considerations: This format is only defined for - transport within the Real Time Transport protocol (RTP) - [RFC 3550]. Its transport within RTP is fully - specified in this document. + Encoding considerations: This media type is framed + binary data. Security considerations: See Section 11 of this document. Interoperability considerations: none Published specification: This MIME type is described fully within this document. Applications which use this media type: Applications wishing to monitor and ensure the quality of transport to the edge of a given VoIP, Real-Time Text or Video Over IP Service. Additional information: none Person & email address to contact for further information: Kaynam Hedayat - Brix Networks - 285 Mill Road - Chelmsford, MA 01824 - US EMail: khedayat@brixnet.com Intended usage: COMMON - Author/Change controller: This registration is part of the - IETF registration tree. + Restrictions on usage: This media type depends on RTP + 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 - Session Description Protocol (SDP) [6] are fully - specified in this document. + Author: + Kaynam Hedayat. + + Change controller: IETF Audio/Video Transport working + group delegated from the IESG. 13.2.7 text/rtploopback 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 - Note that RFC 4855 [RFC4855] mandates that RTP payload - formats without a defined rate must define a rate - parameter as part of their MIME registration. The - payload format for Encapsulated RTP does not specify a - rate parameter. However, the rate for encapsulated - stream is equal to the rate of the stream being - mirrored. + Required parameters: + + rate:RTP timestamp clock rate, which is equal to the + sampling rate. The typical rate is 8000; other rates + may be specified. Optional parameters: none - Encoding considerations: This format is only defined for - transport within the Real Time Transport protocol (RTP) - [RFC 3550]. Its transport within RTP is fully - specified in this document. + Encoding considerations: This media type is framed + binary data. Security considerations: See Section 11 of this document. Interoperability considerations: none Published specification: This MIME type is described fully within this document. Applications which use this media type: Applications wishing to monitor and ensure the quality of transport to the edge of a given VoIP, Real-Time Text or Video Over IP Service. Additional information: none Person & email address to contact for further information: Kaynam Hedayat - Brix Networks - 285 Mill Road - Chelmsford, MA 01824 - US EMail: khedayat@brixnet.com Intended usage: COMMON - Author/Change controller: This registration is part of the - IETF registration tree. + Restrictions on usage: This media type depends on RTP + 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 - Session Description Protocol (SDP) [6] are fully - specified in this document. + Author: + Kaynam Hedayat. + + Change controller: IETF Audio/Video Transport working + group delegated from the IESG. 13.2.8 application/rtploopback To: ietf-types@iana.org - Subject: Registration of MIME media type + Subject: Registration of media type 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 - formats without a defined rate must define a rate - parameter as part of their MIME registration. The - payload format for Encapsulated RTP does not specify a - rate parameter. However, the rate for encapsulated - stream is equal to the rate of the stream being - mirrored. + rate:RTP timestamp clock rate, which is equal to the + sampling rate. The typical rate is 8000; other rates + may be specified. Optional parameters: none - Encoding considerations: This format is only defined for - transport within the Real Time Transport protocol (RTP) - [RFC 3550]. Its transport within RTP is fully - specified in this document. + Encoding considerations: This media type is framed + binary data. Security considerations: See Section 11 of this document. Interoperability considerations: none Published specification: This MIME type is described fully within this document. Applications which use this media type: Applications wishing to monitor and ensure the quality of transport to the edge of a given VoIP, Real-Time Text or Video Over IP Service. Additional information: none Person & email address to contact for further information: Kaynam Hedayat - Brix Networks - 285 Mill Road - Chelmsford, MA 01824 - US EMail: khedayat@brixnet.com - Intended usage: COMMON - Author/Change controller: This registration is part of the - IETF registration tree. + Restrictions on usage: This media type depends on RTP + 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 - Session Description Protocol (SDP) [6] are fully - specified in this document. + Author: + Kaynam Hedayat. + + Change controller: IETF Audio/Video Transport working + group delegated from the IESG. 14. Acknowledgements The authors wish to thank Nagarjuna Venna, Flemming Andreasen, Jeff Bernstein, Paul Kyzivat, and Dave Oran for their comments and suggestions. 15. Normative References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., @@ -1444,22 +1393,33 @@ Kaynam Hedayat Brix Networks 285 Mill Road Chelmsford, MA 01824 US Phone: +1 978 367 5611 EMail: khedayat@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 Cisco Systems, Inc. + 7025 Kit Creek Rd. Research Triangle Park, NC 27709 US Phone: +1 919 392 6948 EMail: paulej@packetizer.com URI: http://www.cisco.com/ Arjun Roychowdhury Hughes Systique Corp.