--- 1/draft-ietf-mmusic-media-loopback-23.txt 2012-11-07 00:14:13.493675342 +0100 +++ 2/draft-ietf-mmusic-media-loopback-24.txt 2012-11-07 00:14:13.545675273 +0100 @@ -1,25 +1,25 @@ MMUSIC Working Group H. Kaplan (ed.) Internet-Draft Acme Packet Intended status: Proposed Standard K. Hedayat - Expires: March 9, 2013 EXFO +Expires: May 6, 2013 EXFO N. Venna Saperix P. Jones Cisco Systems, Inc. N. Stratton BlinkMind, Inc. - September 9, 2012 + November 6, 2012 An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback - draft-ietf-mmusic-media-loopback-23 + draft-ietf-mmusic-media-loopback-24 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 March 9, 2013. + This Internet-Draft will expire on May 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 @@ -110,24 +110,22 @@ 7.1 Encapsulated Payload format..............................14 7.2 Direct loopback RTP payload format.......................16 8. SRTP Behavior................................................17 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 12. Security Considerations.....................................21 - 13. Implementation Considerations...............................21 + 13. Implementation Considerations...............................22 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.............................................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 @@ -262,41 +260,41 @@ 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 "loopback" media attributes for each individual media description - in the offer message. The offerer MUST look for the "loopback" + 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. 3.2 SDP Answerer Behavior - An SDP answerer compliant to this specification and receiving an + If an SDP answerer compliant to this specification receives an offer containing media descriptions with the "loopback" media - attributes MUST acknowledge the request by including the received + 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 it agrees to do the loopback. 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. + 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. - An answerer MAY reject an offered stream (either with loopback- + 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 - MUST be rejected by setting the stream's media port number to zero - in the answer as defined in RFC 3264 [RFC3264], or by rejecting the + 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 and which receives an offer with the "loopback" media attributes would ignore the attributes and treat the incoming offer as a normal request. If the offerer does not wish to establish a "normal" RTP session, it would need to terminate the session upon receiving such an answer. 4. New SDP Attributes @@ -329,23 +327,23 @@ 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 receive direction to a point after the encoder/decoder function in the send direction. This effectively re-encapsulates the RTP payload with the RTP/UDP/IP headers appropriate for sending it in the reverse direction. Any type of encoding related functions, such as packet loss concealment, MUST NOT be part of this type of loopback path. In this mode the RTP packets are looped back with a new payload type and format. Section 7 describes the payload - formats that MUST be used for this type of loopback. This type of - loopback applies to the encapsulated and direct loopback use-cases - described in Section 1.1. + formats that are to be used for this type of loopback. This type + of loopback applies to the encapsulated and direct loopback use- + cases described in Section 1.1. rtp-media-loopback: This loopback is activated as close as possible to the analog interface and after the decoder so that the RTP packets are subsequently re-encoded prior to transmission back to the sender. This type of loopback applies to the media loopback use-case described in Section 1.1.3. 4.2 Loopback Role Attributes: loopback-source and loopback-mirror The loopback role defines two property media attributes [RFC4566] @@ -562,61 +559,60 @@ send packets from the source address and port they receive packets on. 6. RTP Requirements A loopback source MUST NOT send multiple source streams on the same 5-tuple, since there is no means for the mirror to indicate which is which in its mirrored RTP packets. A loopback mirror that is compliant to this specification and - accepts media with rtp-pkt-loopback loopback type MUST loopback the + accepts media with rtp-pkt-loopback loopback type loops back the incoming RTP packets using either the encapsulated RTP payload format or the direct loopback RTP payload format as defined in Section 7 of this specification. A device that is compliant to this specification and performing the mirroring using the loopback type rtp-media-loopback MUST transmit all received media back to the sender, unless congestion feedback or other lower-layer constraints prevent it from doing so. The - incoming media MUST be treated as if it were to be played; for - example, the media stream MAY receive treatment from Packet Loss - Concealment (PLC) algorithms. The mirroring entity MUST re- - generate all the RTP header fields as it would when transmitting - media. The mirroring entity MAY choose to encode the loopback media - according to any of the media descriptions supported by the - offering entity. Furthermore, in cases where the same media type is - looped back, the mirroring entity MAY choose to preserve number of - frames/packet and bitrate of the encoded media according to the - received media. + incoming media is treated as if it were to be played; for example, + the media stream may receive treatment from Packet Loss Concealment + (PLC) algorithms. The mirroring entity re-generates all the RTP + header fields as it would when transmitting media. The mirroring + entity MAY choose to encode the loopback media according to any of + the media descriptions supported by the offering entity. + Furthermore, in cases where the same media type is looped back, the + mirroring entity can choose to preserve number of frames/packet and + bitrate of the encoded media according to the received media. 7. Payload formats for Packet loopback The payload formats described in this section MUST be used by a loopback-mirror when 'rtp-pkt-loopback' is the specified loopback-type. Two different formats are specified here - an encapsulated RTP payload format and a direct loopback RTP payload format. The encapsulated RTP payload format should be used when the incoming RTP header information needs to be preserved during the loopback operation. This is useful in cases where loopback source needs to measure performance metrics in both directions. However, this comes at the expense of increased packet size as described in Section 7.1. The direct loopback RTP payload format should be used when bandwidth requirements prevent the use of encapsulated RTP payload format. 7.1 Encapsulated Payload format A received RTP packet is encapsulated in the payload section of the - RTP packet generated by a loopback-mirror. Each received packet - MUST be encapsulated in a separate encapsulating RTP packet; the - encapsulated packet MUST be fragmented only if required (for + RTP packet generated by a loopback-mirror. Each received packet is + encapsulated in a separate encapsulating RTP packet; the + encapsulated packet would 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.1.3 defines the name binding). @@ -635,28 +631,29 @@ source. The RTP timestamp MUST use the same clock rate as that of the encapsulated packet. 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 outer RTP header of the encapsulating packet MUST be followed - by the payload header defined in this section, after any header + + The outer RTP header of the encapsulating packet is followed by the + payload header defined in this section, after any header extension(s). If the received RTP packet has to be looped back in multiple encapsulating packets due to fragmentation, the - encapsulating RTP header in each packet MUST be followed by the - payload header defined in this section. The header is devised so - that the loopback-source can decode looped back packets in the - presence of moderate packet loss [RFC3550]. The RTP payload of the + encapsulating RTP header in each packet is followed by the payload + header defined in this section. The header is devised so that the + loopback-source can decode looped back packets in the presence of + moderate packet loss [RFC3550]. The RTP payload of the encapsulating RTP packet starts with the payload header defined in this section. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | receive timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F | R | CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -707,22 +704,22 @@ The following is an example SDP fragment for encapsulated RTP. m=audio 41352 RTP/AVP 112 a=rtpmap:112 encaprtp/8000 7.2 Direct loopback RTP payload format The direct loopback RTP payload format can be used in scenarios where the 16 byte overhead of the encapsulated payload format is of concern, or simply due to local policy. When using this payload - format, the receiver MUST loop back each received RTP packet - payload (not header) in a separate RTP packet. + format, the receiver loops back each received RTP packet payload + (not header) in a separate RTP packet. Because a direct loopback format does not retain the original RTP headers, there will be no indication of the original payload-type sent to the mirror, in looped-back packets. Therefore, the loopback source SHOULD only send one payload type per loopback RTP session, if direct mode is used. 7.2.1 Usage of RTP Header fields Payload Type (PT): The assignment of an RTP payload type for the @@ -777,20 +774,24 @@ operates at a lower logical layer than RTP, and thus if both sides negotiate to use SRTP, each side uses its own key, performs encryption/decryption, authentication, etc. Therefore the loopback function on the mirror occurs after the SRTP packet has been decrypted and authenticated, as a normal cleartext RTP packet without an MKI or authentication tag; once the cleartext RTP packet or payload is mirrored - either at the media-layer, direct packet- layer, or encapsulated packet-layer - it is encrypted by the mirror using its own key. + In order to provide the same level of protection to both forward + and reverse media flows (media to and from the mirror), if SRTP is + used it MUST be used in both directions with the same properties. + 9. RTCP Requirements The use of the loopback attribute is intended for monitoring of media quality of the session. Consequently the media performance information should be exchanged between the offering and the answering entities. An offering or answering agent that is compliant to this specification SHOULD support RTCP per [RFC3550] and RTCP-XR per RFC 3611 [RFC3611]. Furthermore, if the offerer or answerer choose to support RTCP-XR, they SHOULD support RTCP-XR Loss Run Length Encoding (RLE) report block, Duplicate RLE report