--- 1/draft-ietf-mmusic-media-loopback-22.txt 2012-09-10 04:14:31.217675216 +0200 +++ 2/draft-ietf-mmusic-media-loopback-23.txt 2012-09-10 04:14:31.273677133 +0200 @@ -1,26 +1,25 @@ - MMUSIC Working Group H. Kaplan (ed.) Internet-Draft Acme Packet Intended status: Proposed Standard K. Hedayat - Expires: February 7, 2013 EXFO + Expires: March 9, 2013 EXFO N. Venna Saperix P. Jones Cisco Systems, Inc. N. Stratton BlinkMind, Inc. - August 7, 2012 + September 9, 2012 An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback - draft-ietf-mmusic-media-loopback-22 + draft-ietf-mmusic-media-loopback-23 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. @@ -30,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 February 7, 2013. + This Internet-Draft will expire on March 9, 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 @@ -104,27 +103,27 @@ 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.............................................13 7. Payload formats for Packet loopback..........................13 7.1 Encapsulated Payload format..............................14 7.2 Direct loopback RTP payload format.......................16 8. SRTP Behavior................................................17 - 9. RTCP Requirements............................................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.....................................20 + 12. Security Considerations.....................................21 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.............................................23 15. Acknowledgements............................................31 16. Normative References........................................31 17. Informative References......................................32 @@ -137,35 +136,36 @@ 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 session. This type of "active monitoring" of services is a method of proactively managing the performance and quality of VoIP based services. The goal of active monitoring is to measure the media quality of a VoIP, Text or Video over IP session. A way to achieve this goal is to request an endpoint to loop media back to the other endpoint and - to provide media statistics (e.g., RTCP and RTCP XR information). + to provide media statistics (e.g., RTCP and RTCP-XR information). Another method involves deployment of special endpoints that always - loop incoming media back for sessions. Although the latter method - has been used and is functional, it does not scale to support large - networks and introduces new network management challenges. - Further, it does not offer the granularity of testing a specific - endpoint that may be exhibiting problems. + loop incoming media back for all sessions. Although the latter + method has been used and is functional, it does not scale to + support large networks and introduces new network management + challenges. Further, it does not offer the granularity of testing + a specific endpoint that may be exhibiting problems. The extension defined in this document introduces new SDP media types and attributes that enable establishment of media sessions where the media is looped back to the transmitter. The SDP offer/answer model [RFC3264] is used to establish a loopback connection. Furthermore, this extension provides guidelines on - handling RTP [RFC3550], as well as usage of RTCP [RFC3550] and RTCP - XR [RFC3611] for reporting media related measurements. + handling RTP [RFC3550], as well as usage of RTP Control Protocol + (RTCP) [RFC3550] and RTCP Extended Reports (RTCP-XR) [RFC3611] for + reporting media related measurements. 1.1 Use Cases Supported As a matter of terminology in this document, packets flow from one peer acting as a "loopback source", to the other peer acting as a "loopback mirror", which in turn returns packets to the loopback source. In advance of the session, the peers negotiate to determine which one acts in which role, using the SDP offer/answer exchange. The negotiation also includes details such as the type of loopback to be used. @@ -183,27 +183,27 @@ encapsulated packet is returned to the loopback source. The loopback source can generate statistics for one-way path performance up to the RTP level for each direction of travel by examining sequence numbers and timestamps in the encapsulating outer RTP header and the encapsulated RTP packet payload. The loopback source can also play back the returned media content for evaluation. Because the encapsulating RTP packet header extends the packet size, it could encounter difficulties in an environment where the - original RTP packet size is close to the path MTU size. The - encapsulating payload format therefore offers the possibility of - RTP-level fragmentation of the returned packets. The use of this - facility could affect statistics derived for the return path. In - addition, the increased bit rate required in the return direction - may affect these statistics more directly in a restricted-bandwidth - situation. + original RTP packet size is close to the path Maximum Transmission + Unit (MTU) size. The encapsulating payload format therefore offers + the possibility of RTP-level fragmentation of the returned packets. + The use of this facility could affect statistics derived for the + return path. In addition, the increased bit rate required in the + return direction may affect these statistics more directly in a + restricted-bandwidth situation. 1.1.2 Direct Loopback In the direct loopback case, the loopback mirror copies the payload of the incoming RTP packet into a new RTP packet, using a payload format specific to this use case and specified in Section 7.2. The loopback mirror returns the new packet to the packet source. There is no provision in this case for RTP-level fragmentation. This use case has the advantage of keeping the packet size the same @@ -259,26 +259,26 @@ there is no further choice of encoding format - there is only one 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 memo 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" media attributes - in the media description(s) of the response from the answer for - confirmation that the request is accepted. + 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" + 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 offer containing media descriptions with the "loopback" media attributes 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 @@ -299,21 +299,21 @@ "normal" RTP session, it would need to terminate the session upon receiving such an answer. 4. New SDP Attributes Three new SDP media-level attributes are defined: one indicates the type of loopback, and the other two define the role of the agent. 4.1 Loopback Type Attribute - This specification defines a new 'loopback' attribute, which + 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: attribute /= loopback-attr ; attribute defined in RFC 4566 @@ -391,21 +391,21 @@ Example: m=audio 41352 RTP/AVP 0 8 100 a=loopback:rtp-media-loopback a=loopback-source a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:100 G7221/16000/1 Since media loopback requires bidirectional RTP, its normal direction mode is "sendrecv"; the "sendrecv" direction attribute - MAY be encoded in SDP or not, as per section 5.1 of [RFC3264], + MAY be encoded in SDP or not, as per Section 5.1 of [RFC3264], since it is implied by default. If either the loopback source or mirror wish to disable loopback use during a session, the direction mode attribute "inactive" MUST be used as per [RFC3264]. The direction mode attributes "recvonly" and "sendonly" are incompatible with the loopback mechanism and MUST NOT be indicated when generating an SDP Offer or Answer. When receiving an SDP Offer or Answer, if "recvonly" or "sendonly" is indicated for loopback, the SDP-receiving agent SHOULD treat it as a protocol failure of the loopback negotiation and terminate the session through its normal means (e.g., by sending a SIP BYE if SIP is @@ -415,29 +415,29 @@ The port number and the address in the offer (m/c= lines) indicate where the offerer would like to receive the media stream(s). The payload type numbers indicate the value of the payload the offerer expects to receive. However, the answer might indicate a subset of payload type numbers from those given in the offer. In that case, the offerer MUST only send the payload types received in the answer, per normal SDP offer/answer rules. If the offer indicates rtp-pkt-loopback support, the offer MUST also contain either an encapsulated or direct loopback encoding - format encoding name, or both, as defined in later sections of this - document. If the offer only indicates rtp-media-loopback support, - then neither encapsulated nor direct loopback encoding formats - apply and they MUST NOT be in the offer. + format encoding name, or both, as defined in Sections 7.1 and 7.2 + of this document. If the offer only indicates rtp-media-loopback + support, then neither encapsulated nor direct loopback encoding + formats apply and they MUST NOT be in the offer. If loopback-type is rtp-pkt-loopback, the loopback-mirror MUST send and the loopback-source MUST receive the looped back packets encoded in one of the two payload formats (encapsulated RTP or - direct loopback) as defined in section 7. + direct loopback) as defined in Section 7. Example: m=audio 41352 RTP/AVP 0 8 112 a=loopback:rtp-pkt-loopback a=loopback-source a=rtpmap:112 encaprtp/8000 Example: m=audio 41352 RTP/AVP 0 8 112 a=loopback:rtp-pkt-loopback a=loopback-source a=rtpmap:112 rtploopback/8000 @@ -486,21 +486,21 @@ a=loopback-source a=rtpmap:112 encaprtp/8000 The answer that is capable of supporting the offer and chooses to loopback the media using the rtp-media-loopback type must contain: m=audio 12345 RTP/AVP 0 8 a=loopback:rtp-media-loopback a=loopback-mirror - As specified in section 7, if the loopback-type is + As specified in Section 7, if the loopback-type is rtp-pkt-loopback, either the encapsulated RTP payload format or direct loopback RTP payload format MUST be used for looped back packets. For example, if the offer contains: m=audio 41352 RTP/AVP 0 8 112 113 a=loopback:rtp-pkt-loopback a=loopback-source a=rtpmap:112 encaprtp/8000 @@ -513,116 +513,119 @@ a=loopback:rtp-pkt-loopback a=loopback-mirror a=rtpmap:112 encaprtp/8000 m=audio 12345 RTP/AVP 0 8 113 a=loopback:rtp-pkt-loopback a=loopback-mirror a=rtpmap:113 rtploopback/8000 The previous examples used the 'encaprtp' and 'rtploopback' - encoding names, which will be defined in sections 7.1.3 and 7.2.3. + encoding names, which will be defined in Sections 7.1.3 and 7.2.3. 5.3 Offerer Processing of the SDP Answer If the received SDP answer does not contain an a=loopback-mirror or a=loopback-source attribute, it is assumed that the loopback extensions are not supported by the remote agent. This is not a protocol failure, and instead merely completes the SDP offer/answer exchange with whatever normal rules apply; the offerer MAY decide to end the established RTP session (if any) through normal means of the upper-layer signaling protocol (e.g., by sending a SIP BYE). 5.4 Modifying the Session At any point during the loopback session, either participant MAY issue a new offer to modify the characteristics of the previous - session, as defined in section 8 of RFC 3264 [RFC3264]. This also + session, as defined in Section 8 of RFC 3264 [RFC3264]. This also includes transitioning from a normal media processing mode to loopback mode, and vice versa. 5.5 Establishing Sessions Between Entities Behind NAT ICE/STUN/TURN provide a general solution to establishing media - sessions between entities that are behind NATs, as defined in - [RFC5245]. Loopback sessions that involve one or more endpoints - behind NATs SHOULD use these general solutions wherever possible. + sessions between entities that are behind Network Address + Translators (NATs), as defined in [RFC5245]. Loopback sessions that + involve one or more endpoints behind NATs SHOULD use these general + solutions wherever possible. Furthermore, if the mirroring entity is behind a NAT, it MUST send some packets to the identified address/port(s) of the peer, in - order to open the NAT pinhole. Using ICE this would be - accomplished with the STUN connectivity check process, or through a - TURN server connection. If ICE is not supported, either [RFC6263] - or Section 10 of ICE [RFC5245] SHOULD be followed to open the - pinhole and keep the NAT binding alive/refreshed. + order to open the NAT pinhole. Using Interactive Connectivity + Establishment (ICE) [RFC5245] this would be accomplished with the + STUN connectivity check process, or through a TURN server + connection. If ICE is not supported, either [RFC6263] or Section + 10 of ICE [RFC5245] SHOULD be followed to open the pinhole and keep + the NAT binding alive/refreshed. Note that for any form of NAT traversal to function, symmetric RTP/RTCP [RFC4961] MUST be used. In other words both agents MUST 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 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. + 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 (e.g. the - media stream MAY receive treatment from 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 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. 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 + 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 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). + SDP; Section 7.1.3 defines the name binding). Marker (M) bit: If the received RTP packet is looped back in multiple encapsulating RTP packets, the M bit is set to 1 in every fragment except 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 as described in RFC 3550 [RFC3550]. @@ -658,35 +660,36 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F | R | CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | transmit timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Figure 1: Encapsulating RTP Packet Payload Header The 12 octets after the receive timestamp are identical to the encapsulated RTP header of the received packet except for the first 2 bits of the first octet. In effect, the received RTP packet is encapsulated by creating a new outer RTP header followed by 4 new bytes of a receive timestamp, followed by the original received RTP header and payload, except that the first two bits of the received RTP header are overwritten as defined here. Receive Timestamp: 32 bits The Receive timestamp denotes the sampling instant for when the last octet of the received media packet that is being encapsulated by the loopback-mirror is received from the loopback-source. The - same clock rate MUST used by the loopback-source. The initial + same clock rate MUST be 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]). Fragmentation (F): 2 bits First Fragment (00) /Last Fragment (01) /No Fragmentation(10)/ Intermediate Fragment (11). This field identifies how much of the received packet is encapsulated in this packet by the loopback- mirror. If the received packet is not fragmented, this field is set to 10; otherwise the packet that contains the first fragments @@ -719,21 +722,21 @@ 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 encapsulating 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.2.3 defines the name binding). + (e.g., using 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, as per [RFC3550]. Timestamp: The RTP timestamp denotes the sampling instant for when @@ -783,25 +786,25 @@ 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 RLE report block, Duplicate RLE report block, Statistics - Summary report block, and VoIP Metric Reports Block per sections - 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]. + Loss Run Length Encoding (RLE) report block, Duplicate RLE report + block, Statistics Summary report block, and VoIP Metric Reports + Block per Sections 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 [RFC3551]. For packet-level loopback types, the loopback source SHOULD @@ -992,21 +996,21 @@ 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 + "rtp-media-loopback". See Section 5 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