--- 1/draft-ietf-mmusic-media-loopback-24.txt 2012-12-17 20:34:21.655840633 +0100 +++ 2/draft-ietf-mmusic-media-loopback-25.txt 2012-12-17 20:34:21.715791334 +0100 @@ -1,25 +1,25 @@ MMUSIC Working Group H. Kaplan (ed.) Internet-Draft Acme Packet Intended status: Proposed Standard K. Hedayat -Expires: May 6, 2013 EXFO + Expires: June 17, 2013 EXFO N. Venna Saperix P. Jones Cisco Systems, Inc. N. Stratton BlinkMind, Inc. - November 6, 2012 + December 17, 2012 An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback - draft-ietf-mmusic-media-loopback-24 + draft-ietf-mmusic-media-loopback-25 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. @@ -29,21 +29,21 @@ 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/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 May 6, 2013. + This Internet-Draft will expire on June 17, 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 @@ -89,48 +89,48 @@ Table of Contents 1. Introduction..................................................3 1.1 Use Cases Supported.......................................4 2. Terminology...................................................6 3. Overview of Operation.........................................6 3.1 SDP Offerer Behavior......................................6 3.2 SDP Answerer Behavior.....................................7 4. New SDP Attributes............................................7 - 4.1 Loopback Type Attribute...................................7 + 4.1 Loopback Type Attribute...................................8 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 + mirror........................................................9 + 5. Rules for Generating the SDP offer/answer....................10 + 5.1 Generating the SDP Offer for Loopback Session............10 + 5.2 Generating the SDP Answer for Loopback Session...........11 + 5.3 Offerer Processing of the SDP Answer.....................13 + 5.4 Modifying the Session....................................13 + 5.5 Establishing Sessions Between Entities Behind NAT........13 6. RTP Requirements.............................................13 - 7. Payload formats for Packet loopback..........................13 + 7. Payload formats for Packet loopback..........................14 7.1 Encapsulated Payload format..............................14 - 7.2 Direct loopback RTP payload format.......................16 - 8. SRTP Behavior................................................17 + 7.2 Direct loopback RTP payload format.......................17 + 8. SRTP Behavior................................................18 9. RTCP Requirements............................................18 - 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 + 10. Congestion Control..........................................19 + 11. Examples....................................................19 + 11.1 Offer for specific media loopback type..................19 + 11.2 Offer for choice of media loopback type.................20 + 11.3 Answerer rejecting loopback media.......................21 12. Security Considerations.....................................21 13. Implementation Considerations...............................22 - 14. IANA Considerations.........................................22 - 14.1 SDP Attributes..........................................22 - 14.2 Media Types.............................................23 - 15. Acknowledgements............................................31 - 16. Normative References........................................31 - 17. Informative References......................................32 + 14. IANA Considerations.........................................23 + 14.1 SDP Attributes..........................................23 + 14.2 Media Types.............................................24 + 15. Acknowledgements............................................32 + 16. Normative References........................................32 + 17. Informative References......................................33 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 real-time VoIP, Text and Video over IP Services is through monitoring the quality of the media in an active @@ -258,36 +258,42 @@ format: whatever is indicated for normal media, since the "looping" is performed at the codec level. When packet-level looping is performed, however, the mirror can either send back RTP in an encapsulated format or direct-loopback format. The rest of this document describes these loopback types, roles, and encoding formats, and the SDP offer/answer rules for indicating them. 3.1 SDP Offerer Behavior An SDP offerer compliant to this specification and attempting to - establish a media session with media loopback MUST include + establish a media session with media loopback will include "loopback" media attributes for each individual media description - in the offer message. The offerer will look for the "loopback" - media attributes in the media description(s) of the response from - the answer for confirmation that the request is accepted. + in the offer message that it wishes to have looped back. Note that + the offerer may choose to only request loop back for some media + descriptions/streams but not others. For example it might wish to + request loopback for a video stream but not audio, or vice-versa. + + The offerer will look for the "loopback" media attributes in the + media description(s) of the response from the SDP answer for + confirmation that the request is accepted. 3.2 SDP Answerer Behavior If an SDP answerer compliant to this specification receives an offer containing media descriptions with the "loopback" media attributes and it wants to accept such for the purposes of media- - loopback, MUST acknowledge the request by including the received - "loopback" media attributes for each media description in its - answer. If the answerer does not want to do loopback or wants to - reject the "loopback" request for specific media descriptions, it - MUST do so as defined in this section. + loopback, it MUST acknowledge the request by including the received + "loopback" media attribute(s) for each media description in its + answer that it accepts looping back for. If the answerer does not + want to do loopback or wants to reject the "loopback" request for + specific media descriptions, it MUST do so as defined in this + section. An answerer can reject an offered stream (either with loopback- source or loopback-mirror) if the loopback-type is not specified, the specified loopback-type is not supported, or the endpoint cannot honor the offer for any other reason. The loopback request is rejected by setting the stream's media port number to zero in the answer as defined in RFC 3264 [RFC3264], or by rejecting the entire offer (i.e., by rejecting the session request entirely). Note that an answerer that is not compliant to this specification