--- 1/draft-ietf-mmusic-media-loopback-21.txt 2012-08-07 18:14:11.337342309 +0200 +++ 2/draft-ietf-mmusic-media-loopback-22.txt 2012-08-07 18:14:11.393342993 +0200 @@ -1,60 +1,78 @@ MMUSIC Working Group H. Kaplan (ed.) Internet-Draft Acme Packet Intended status: Proposed Standard K. Hedayat - Expires: February 6, 2013 EXFO + Expires: February 7, 2013 EXFO N. Venna Saperix P. Jones Cisco Systems, Inc. N. Stratton BlinkMind, Inc. - August 6, 2012 + August 7, 2012 An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback - draft-ietf-mmusic-media-loopback-21 + draft-ietf-mmusic-media-loopback-22 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). 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/. + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. 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." + progress". - This Internet-Draft will expire on February 6, 2013 + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on February 7, 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) + controlling the copyright in such materials, this document may not + be modified outside the IETF Standards Process, and derivative + works of it may not be created outside the IETF Standards Process, + except to format it for publication as an RFC or to translate it + into languages other than English. + Abstract The wide deployment of Voice over IP (VoIP), Text and Video over IP services has introduced new challenges in managing and maintaining real-time voice/text/video quality, reliability, and overall performance. In particular, media delivery is an area that needs attention. One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter. This is typically referred to as "active monitoring" of services. Media loopback is especially popular in ensuring the @@ -67,39 +85,38 @@ 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...................................................5 + 2. Terminology...................................................6 3. Overview of Operation.........................................6 3.1 SDP Offerer Behavior......................................6 - 3.2 SDP Answerer Behavior.....................................6 + 3.2 SDP Answerer Behavior.....................................7 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.....................12 5.4 Modifying the Session....................................12 5.5 Establishing Sessions Between Entities Behind NAT........12 - 6. RTP Requirements.............................................12 + 6. RTP Requirements.............................................13 7. Payload formats for Packet loopback..........................13 - 7.1 Encapsulated Payload format..............................13 + 7.1 Encapsulated Payload format..............................14 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 @@ -213,21 +230,22 @@ reencoding format. This usage allows trouble-shooting at the codec level. The capability for path statistics is limited to what is available from RTCP reports. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in - this document are to be interpreted as described in RFC 2119. + this document are to be interpreted as described in RFC 2119 + [RFC2119]. SDP: Session Description Protocol, as defined in [RFC4566]. This document assumes the SDP offer/answer model is followed, per [RFC3264], but does not assume any specific signaling protocol for carrying the SDP. The following terms are borrowed from [RFC3264] definitions: offer, offerer, answer, answerer, and agent. 3. Overview of Operation @@ -777,21 +795,21 @@ 4.1, 4.2, 4.6, and 4.7 of RFC 3611 [RFC3611]. The offerer and the answerer MAY support other RTCP-XR reporting blocks as defined by RFC 3611 [RFC3611]. 10. Congestion Control All the participants in a media-level loopback session SHOULD implement congestion control mechanisms as defined by the RTP profile under which the loopback mechanism is implemented. For audio video profiles, implementations SHOULD conform to the - mechanism defined in Section 2 of RFC 3551. + mechanism defined in Section 2 of RFC 3551 [RFC3551]. For packet-level loopback types, the loopback source SHOULD implement congestion control. The mirror will simply reflect back the RTP packets it receives (either in encapsulated or direct modes), therefore the source needs to control the congestion of both forward and reverse paths by reducing its sending rate to the mirror. This keeps the loopback mirror implementation simpler, and provides more flexibility for the source performing a loopback test. @@ -1399,52 +1415,51 @@ 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. 16. Normative References + [RFC2119] Bradner, S.,"Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + [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. + [RFC3551] Schulzrinne, H., Casner, S., "RTP Profile for Audio + and Video Conferences with Minimial Control", STD 65, + RFC 3551, July 2003. + [RFC3611] Almeroth, K., Caceres, R., Clark, A., Cole, R., Duffield, N., Friedman, T., Hedayat, K., Sarac, K. and M. Westerlund, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003. - [RFC5234] Crocker, P. Overell, "Augmented ABNF for Syntax - Specification: ABNF", RFC 5234, October 2005. - - [RFC2119] Bradner, S.,"Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2736] Handley, M., Perkins, C., "Guidelines for Writers of - RTP Payload Format Specifications", RFC 2736, BCP - 0036, December 1999. - - [RFC3551] Schulzrinne, H., Casner, S., "RTP Profile for Audio - and Video Conferences with Minimial Control", STD 65, - RFC 3551, July 2003. + [RFC3711] Baugher, M., et al, "The Secure Real-time Transport + Protocol (SRTP)", RFC 3711, March 2004. [RFC4566] Handley, M., Jacobson, V., Perkins, C., "SDP: Session Description Protocol", RFC 4566, July 2006. - [RFC4855] Casner, S., "Media Type Registration of RTP Payload - Formats", RFC 4855, February 2007. + [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol + (RTCP)", RFC 4961, July 2007. + + [RFC5234] Crocker, P. Overell, "Augmented ABNF for Syntax + Specification: ABNF", RFC 5234, October 2005. 17. Informative References [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC6263] Marjou, X., Sollaud, A., "Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP /