--- 1/draft-ietf-mmusic-media-loopback-20.txt 2012-08-07 03:14:09.797343929 +0200 +++ 2/draft-ietf-mmusic-media-loopback-21.txt 2012-08-07 03:14:09.857343057 +0200 @@ -1,50 +1,44 @@ - Internet Draft H. Kaplan (ed.) - Expires: January 30, 2012 Acme Packet - K. Hedayat - EXFO + MMUSIC Working Group H. Kaplan (ed.) + Internet-Draft Acme Packet + Intended status: Proposed Standard K. Hedayat + Expires: February 6, 2013 EXFO N. Venna Saperix P. Jones Cisco Systems, Inc. N. Stratton BlinkMind, Inc. - July 30, 2012 + August 6, 2012 An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback - draft-ietf-mmusic-media-loopback-20 + draft-ietf-mmusic-media-loopback-21 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current + Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on January 30, 2012. + This Internet-Draft will expire on February 6, 2013 Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -73,38 +67,39 @@ attributes, which enable establishment of media sessions where the media is looped back to the transmitter. Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP, Real-time Text and Video over IP performance metrics. Table of Contents 1. Introduction..................................................3 1.1 Use Cases Supported.......................................4 - 2. Terminology...................................................6 + 2. Terminology...................................................5 3. Overview of Operation.........................................6 3.1 SDP Offerer Behavior......................................6 3.2 SDP Answerer Behavior.....................................6 4. New SDP Attributes............................................7 4.1 Loopback Type Attribute...................................7 4.2 Loopback Role Attributes: loopback-source and loopback- mirror........................................................8 5. Rules for Generating the SDP offer/answer.....................9 5.1 Generating the SDP Offer for Loopback Session.............9 5.2 Generating the SDP Answer for Loopback Session...........10 - 5.3 Offerer Processing of the SDP Answer.....................11 + 5.3 Offerer Processing of the SDP Answer.....................12 5.4 Modifying the Session....................................12 5.5 Establishing Sessions Between Entities Behind NAT........12 6. RTP Requirements.............................................12 7. Payload formats for Packet loopback..........................13 7.1 Encapsulated Payload format..............................13 7.2 Direct loopback RTP payload format.......................16 + 8. SRTP Behavior................................................17 9. RTCP Requirements............................................17 10. Congestion Control..........................................18 11. Examples....................................................18 11.1 Offer for specific media loopback type..................18 11.2 Offer for choice of media loopback type.................19 11.3 Answerer rejecting loopback media.......................20 12. Security Considerations.....................................20 13. Implementation Considerations...............................21 14. IANA Considerations.........................................22 @@ -101,22 +96,24 @@ 8. SRTP Behavior................................................17 9. RTCP Requirements............................................17 10. Congestion Control..........................................18 11. Examples....................................................18 11.1 Offer for specific media loopback type..................18 11.2 Offer for choice of media loopback type.................19 11.3 Answerer rejecting loopback media.......................20 12. Security Considerations.....................................20 13. Implementation Considerations...............................21 14. IANA Considerations.........................................22 + [Note to RFC Editor: Please replace "XXXX" with the appropriate RFC + number on publication]..........................................22 14.1 SDP Attributes..........................................22 - 14.2 Media Types.............................................22 + 14.2 Media Types.............................................23 15. Acknowledgements............................................31 16. Normative References........................................31 17. Informative References......................................32 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 @@ -293,21 +290,24 @@ This specification defines a new 'loopback' attribute, which indicates that the agent wishes to perform loopback, and the type of loopack that the agent is able to do. The loopback-type is a value media attribute [RFC4566] with the following syntax: a=loopback: Following is the Augmented BNF [RFC5234] for loopback-type: - loopback-attr = "a=loopback:" SP loopback-type + attribute /= loopback-attr + ; attribute defined in RFC 4566 + + loopback-attr = "loopback:" SP loopback-type loopback-type = loopback-choice [1*SP loopback-choice] loopback-choice = loopback-type-pkt / loopback-type-media loopback-type-pkt = "rtp-pkt-loopback" loopback-type-media = "rtp-media-loopback" The loopback-type is used to indicate the type of loopback. The loopback-type values are rtp-pkt-loopback, and rtp-media-loopback. rtp-pkt-loopback: In this mode, the RTP packets are looped back to the sender at a point before the encoder/decoder function in the @@ -334,20 +334,27 @@ that are used to indicate the role of the agent generating the SDP offer or answer. The syntax of the two loopback role media attributes are as follows: a=loopback-source and a=loopback-mirror + Following is the Augmented BNF [RFC5234] for loopback-type: + + attribute /= loopback-source / loopback-mirror + ; attribute defined in RFC 4566 + loopback-source = "loopback-source" + loopback-mirror = "loopback-mirror" + loopback-source: This attribute specifies that the entity that generated the SDP is the media source and expects the receiver of the SDP message to act as a loopback-mirror. loopback-mirror: This attribute specifies that the entity that generated the SDP will mirror (echo) all received media back to the sender of the RTP stream. No media is generated locally by the looping back entity for transmission in the mirrored stream. The "m=" line in the SDP MUST include all the payload types that @@ -948,50 +956,56 @@ implemented for all implementations and which features MAY be deferred if the complete solution is not desired. All implementations MUST at least support the rtp-pkt-loopback mode for loopback-type, with direct media loopback payload encoding. In addition, for the loopback role, all implementations of an SDP offerer MUST at least be able to act as a loopback-source. 14. IANA Considerations + [Note to RFC Editor: Please replace "XXXX" with the appropriate RFC + number on publication] + 14.1 SDP Attributes This document defines three new media-level SDP attributes. IANA has registered the following attributes: Contact name: Kaynam Hedayat - . + Email address: kaynam.hedayat@exfo.com + Telephone number: +1-978-367-5611 Attribute name: loopback Type of attribute: Media level. Subject to charset: No. Purpose of attribute: The 'loopback' attribute is used to indicate the type of media loopback. Allowed attribute values: The parameters to 'loopback' may be one or more of "rtp-pkt-loopback" and "rtp-media-loopback". See section 5 - of this document for syntax. + of RFC XXXX for syntax. Contact name: Kaynam Hedayat - . + Email address: kaynam.hedayat@exfo.com + Telephone number: +1-978-367-5611 Attribute name: loopback-source Type of attribute: Media level. Subject to charset: No. Purpose of attribute: The 'loopback-source' attribute specifies that the sender is the media source and expects the receiver to act as a loopback-mirror. Allowed attribute values: None. Contact name: Kaynam Hedayat - . + Email address: kaynam.hedayat@exfo.com + Telephone number: +1-978-367-5611 Attribute name: loopback-mirror Type of attribute: Media level. Subject to charset: No. Purpose of attribute: The 'loopback-mirror' attribute specifies that the receiver will mirror (echo) all received media back to the sender of the RTP stream. Allowed attribute values: None. 14.2 Media Types @@ -1012,45 +1026,45 @@ rate: RTP timestamp clock rate, which is equal to the sampling rate. The typical rate is 8000; other rates may be specified. This is specified by the loop back source, and reflected by the mirror. Optional parameters: none Encoding considerations: This media type is framed. - Security considerations: See Section 12 of this document. + Security considerations: See Section 12 of RFC XXXX. Interoperability considerations: none - Published specification: This document. + Published specification: RFC XXXX. Applications which use this media type: Applications wishing to monitor and ensure the quality of transport to the edge of a given VoIP Service. Additional information: none - Contact: the authors of this document. + Contact: the authors of RFC XXXX. Intended usage: LIMITED USE 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. Author: Kaynam Hedayat. - Change controller: IETF Audio/Video Transport working + Change controller: IETF PAYLOAD working group delegated from the IESG. 14.2.2 video/encaprtp To: ietf-types@iana.org Subject: Registration of media type video/encaprtp Type name: video @@ -1059,45 +1073,46 @@ Required parameters: rate: RTP timestamp clock rate, which is equal to the sampling rate. This is specified by the loop back source, and reflected by the mirror. Optional parameters: none Encoding considerations: This media type is framed. - Security considerations: See Section 12 of this document. + Security considerations: See Section 12 of RFC XXXX. Interoperability considerations: none - Published specification: This document. + Published specification: RFC XXXX. Applications which use this media type: Applications wishing to monitor and ensure the quality of transport to the edge of a given Video Over IP Service. Additional information: none - Contact: the authors of this document. + Contact: the authors of RFC XXXX. Intended usage: LIMITED USE 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. Author: + Kaynam Hedayat. - Change controller: IETF Audio/Video Transport working + Change controller: IETF PAYLOAD working group delegated from the IESG. 14.2.3 text/encaprtp To: ietf-types@iana.org Subject: Registration of media type text/encaprtp Type name: text @@ -1106,45 +1121,45 @@ Required parameters: rate: RTP timestamp clock rate, which is equal to the sampling rate. This is specified by the loop back source, and reflected by the mirror. Optional parameters: none Encoding considerations: This media type is framed. - Security considerations: See Section 12 of this document. + Security considerations: See Section 12 of RFC XXXX. Interoperability considerations: none - Published specification: This document. + Published specification: RFC XXXX. Applications which use this media type: Applications wishing to monitor and ensure the quality of transport to the edge of a given Real-Time Text Service. Additional information: none - Contact: the authors of this document. + Contact: the authors of RFC XXXX. Intended usage: LIMITED USE 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. Author: Kaynam Hedayat. - Change controller: IETF Audio/Video Transport working + Change controller: IETF PAYLOAD working group delegated from the IESG. 14.2.4 application/encaprtp To: ietf-types@iana.org Subject: Registration of media type application/encaprtp Type name: application @@ -1154,45 +1169,45 @@ Required parameters: rate: RTP timestamp clock rate, which is equal to the sampling rate. This is specified by the loop back source, and reflected by the mirror. Optional parameters: none Encoding considerations: This media type is framed. - Security considerations: See Section 12 of this document. + Security considerations: See Section 12 of RFC XXXX. Interoperability considerations: none - Published specification: This document. + Published specification: RFC XXXX. Applications which use this media type: Applications wishing to monitor and ensure the quality of transport to the edge of a given Real-Time Application Service. Additional information: none - Contact: the authors of this document. + Contact: the authors of RFC XXXX. Intended usage: LIMITED USE 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. Author: Kaynam Hedayat. - Change controller: IETF Audio/Video Transport working + Change controller: IETF PAYLOAD working group delegated from the IESG. 14.2.5 audio/rtploopback To: ietf-types@iana.org Subject: Registration of media type audio/rtploopback Type name: audio @@ -1202,45 +1217,45 @@ rate:RTP timestamp clock rate, which is equal to the sampling rate. The typical rate is 8000; other rates may be specified. This is specified by the loop back source, and reflected by the mirror. Optional parameters: none Encoding considerations: This media type is framed. - Security considerations: See Section 12 of this document. + Security considerations: See Section 12 of RFC XXXX. Interoperability considerations: none - Published specification: This document. + Published specification: RFC XXXX. Applications which use this media type: Applications wishing to monitor and ensure the quality of transport to the edge of a given VoIP Service. Additional information: none - Contact: the authors of this document. + Contact: the authors of RFC XXXX. Intended usage: LIMITED USE 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. Author: Kaynam Hedayat. - Change controller: IETF Audio/Video Transport working + Change controller: IETF PAYLOAD working group delegated from the IESG. 14.2.6 video/rtploopback To: ietf-types@iana.org Subject: Registration of media type video/rtploopback Type name: video @@ -1249,45 +1264,45 @@ Required parameters: rate:RTP timestamp clock rate, which is equal to the sampling rate. This is specified by the loop back source, and reflected by the mirror. Optional parameters: none Encoding considerations: This media type is framed. - Security considerations: See Section 12 of this document. + Security considerations: See Section 12 of RFC XXXX. Interoperability considerations: none - Published specification: This document. + Published specification: RFC XXXX. Applications which use this media type: Applications wishing to monitor and ensure the quality of transport to the edge of a given Video Over IP Service. Additional information: none - Contact: the authors of this document. + Contact: the authors of RFC XXXX. Intended usage: LIMITED USE 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. Author: Kaynam Hedayat. - Change controller: IETF Audio/Video Transport working + Change controller: IETF PAYLOAD working group delegated from the IESG. 14.2.7 text/rtploopback To: ietf-types@iana.org Subject: Registration of media type text/rtploopback Type name: text @@ -1296,45 +1311,45 @@ Required parameters: rate:RTP timestamp clock rate, which is equal to the sampling rate. This is specified by the loop back source, and reflected by the mirror. Optional parameters: none Encoding considerations: This media type is framed. - Security considerations: See Section 12 of this document. + Security considerations: See Section 12 of RFC XXXX. Interoperability considerations: none - Published specification: This document. + Published specification: RFC XXXX. Applications which use this media type: Applications wishing to monitor and ensure the quality of transport to the edge of a given Real-Time Text Service. Additional information: none - Contact: the authors of this document. + Contact: the authors of RFC XXXX. Intended usage: LIMITED USE 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. Author: Kaynam Hedayat. - Change controller: IETF Audio/Video Transport working + Change controller: IETF PAYLOAD working group delegated from the IESG. 14.2.8 application/rtploopback To: ietf-types@iana.org Subject: Registration of media type application/rtploopback Type name: application @@ -1344,57 +1359,57 @@ Required parameters: rate:RTP timestamp clock rate, which is equal to the sampling rate. This is specified by the loop back source, and reflected by the mirror. Optional parameters: none Encoding considerations: This media type is framed. - Security considerations: See Section 12 of this document. + Security considerations: See Section 12 of RFC XXXX. Interoperability considerations: none - Published specification: This document. + Published specification: RFC XXXX. Applications which use this media type: Applications wishing to monitor and ensure the quality of transport to the edge of a given Real-Time Application Service. Additional information: none - Contact: the authors of this document. + Contact: the authors of RFC XXXX. Intended usage: LIMITED USE 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. Author: Kaynam Hedayat. - Change controller: IETF Audio/Video Transport working + Change controller: IETF PAYLOAD working group delegated from the IESG. 15. Acknowledgements This document's editor would like to thank the original authors of the document: Kaynam Hedayat, Nagarjuna Venna, Paul E. Jones, Arjun Roychowdhury, Chelliah SivaChelvan, and Nathan Stratton. The editor has made fairly insignificant changes in the end. Also, - we'd like to thank Magnus Westerlund, Miguel Garcia, Muthu - Arul Mozhi Perumal, Jeff Bernstein, Paul Kyzivat, Dave Oran, - Flemming Andreasen, Gunnar Hellstrom, Emil Ivov and Dan Wing for - their feedback, comments and suggestions. + we'd like to thank Magnus Westerlund, Miguel Garcia, Muthu Arul + Mozhi Perumal, Jeff Bernstein, Paul Kyzivat, Dave Oran, Flemming + Andreasen, Gunnar Hellstrom, Emil Ivov and Dan Wing for their + feedback, comments and suggestions. 16. Normative References [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.