doc: Add RFC documents

1 files changed, 1851 insertions, 0 deletions

diff --git a/doc/rfc/rfc6849.txt b/doc/rfc/rfc6849.txt
new file mode 100644
index 0000000..6064abc
--- /dev/null
+++ b/doc/rfc/rfc6849.txt
@@ -0,0 +1,1851 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                    H. Kaplan, Ed.
+Request for Comments: 6849                                   Acme Packet
+Category: Standards Track                                     K. Hedayat
+ISSN: 2070-1721                                                     EXFO
+                                                                N. Venna
+                                                                 Saperix
+                                                                P. Jones
+                                                     Cisco Systems, Inc.
+                                                             N. Stratton
+                                                         BlinkMind, Inc.
+                                                           February 2013
+
+
+         An Extension to the Session Description Protocol (SDP)
+       and Real-time Transport Protocol (RTP) for Media Loopback
+
+Abstract
+
+   The wide deployment of Voice over IP (VoIP), real-time 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 quality of transport to the edge of a given VoIP, real-
+   time text, or Video over IP service.  Today, in networks that deliver
+   real-time media, short of running 'ping' and 'traceroute' to the
+   edge, administrators are left without the necessary tools to actively
+   monitor, manage, and diagnose quality issues with their service.  The
+   extension defined herein adds new Session Description Protocol (SDP)
+   media types and attributes that 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kaplan, et al.               Standards Track                    [Page 1]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6849.
+
+Copyright Notice
+
+   Copyright (c) 2013 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.
+
+
+
+
+
+
+
+
+
+
+
+Kaplan, et al.               Standards Track                    [Page 2]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+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.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 NATs ........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 ..............................................18
+   10. Congestion Control ............................................18
+   11. Examples ......................................................18
+      11.1. Offer for Specific Media Loopback Type ...................19
+      11.2. Offer for Choice of Media Loopback Type ..................19
+      11.3. Answerer Rejecting Loopback Media ........................20
+   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. References ....................................................31
+      16.1. Normative References .....................................31
+      16.2. 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 the media
+   transport.  One method of monitoring and managing the overall quality
+   of real-time VoIP, real-time text, and Video over IP services is
+
+
+
+
+Kaplan, et al.               Standards Track                    [Page 3]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+   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, real-time 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., RTP Control Protocol
+   (RTCP) [RFC3550] and RTCP Extended Reports (RTCP-XR) [RFC3611]
+   information).  Another method involves deployment of special
+   endpoints that always 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.
+
+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.
+
+   This specification supports three use cases: "encapsulated packet
+   loopback", "direct loopback", and "media loopback".  These are
+   distinguished by the treatment of incoming RTP packets at the
+   loopback mirror.
+
+1.1.1.  Encapsulated Packet Loopback
+
+   In the encapsulated packet loopback case, the entire incoming RTP
+   packet is encapsulated as payload within an outer RTP packet that is
+   specific to this use case and specified in Section 7.1.  The
+   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
+
+
+
+Kaplan, et al.               Standards Track                    [Page 4]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+   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 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
+   in both directions.  The packet source can compute only two-way path
+   statistics from the direct loopback packet header but can play back
+   the returned media content.
+
+   It has been suggested that the loopback source, knowing that the
+   incoming packet will never be passed to a decoder, can store a
+   timestamp and sequence number inside the payload of the packet it
+   sends to the mirror, then extract that information from the returned
+   direct loopback packet and compute one-way path statistics as in the
+   previous case.  Obviously, playout of returned content is no longer
+   possible if this is done.
+
+1.1.3.  Media Loopback
+
+   In the media loopback case, the loopback mirror submits the incoming
+   packet to a decoder appropriate to the incoming payload type.  The
+   packet is taken as close as possible to the analog level, then
+   re-encoded according to an outgoing format determined by SDP
+   negotiation.  The re-encoded content is returned to the loopback
+   source as an RTP packet with payload type corresponding to the
+   re-encoding format.
+
+   This usage allows troubleshooting at the codec level.  The capability
+   for path statistics is limited to what is available from RTCP
+   reports.
+
+
+
+Kaplan, et al.               Standards Track                    [Page 5]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+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 [RFC2119].
+
+   SDP: Session Description Protocol, as defined in [RFC4566].  This
+        document assumes that 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
+
+   This document defines two loopback 'types', two 'roles', and two
+   encoding formats for loopback.  For any given SDP offerer or answerer
+   pair, one side is the source of RTP packets, while the other is the
+   mirror looping packets/media back.  Those define the two loopback
+   roles.  As the mirror, two 'types' of loopback can be performed:
+   packet-level or media-level.  When media-level is used, 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 specification and attempting to
+   establish a media session with media loopback will include "loopback"
+   media attributes for each individual media description in the offer
+   message that it wishes to have looped back.  Note that the offerer
+   may choose to only request loopback 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.
+
+
+
+
+
+
+
+
+Kaplan, et al.               Standards Track                    [Page 6]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+3.2.  SDP Answerer Behavior
+
+   In order to accept a loopback offer (that is, an offer containing
+   "loopback" in the media description), an SDP answerer includes the
+   "loopback" media attribute in each media description for which it
+   desires 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 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
+   that 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
+
+   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
+   indicates that the agent wishes to perform loopback, and the type of
+   loopback that the agent is able to do.  The loopback-type is a value
+   media attribute [RFC4566] with the following syntax:
+
+      a=loopback:<loopback-type>
+
+   Following is the Augmented BNF [RFC5234] for 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"
+
+
+
+
+
+Kaplan, et al.               Standards Track                    [Page 7]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+   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
+      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 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]
+   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 is as follows:
+
+      a=loopback-source
+
+   and
+
+      a=loopback-mirror
+
+   Following is the Augmented BNF [RFC5234] for loopback-source and
+   loopback-mirror:
+
+   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.
+
+
+
+
+
+Kaplan, et al.               Standards Track                    [Page 8]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+   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 includes all the payload types that will be
+   used during the loopback session.  The complete payload space for the
+   session is specified in the "m=" line, and the rtpmap attribute is
+   used to map from the payload type number to an encoding name denoting
+   the payload format to be used.
+
+5.  Rules for Generating the SDP Offer/Answer
+
+5.1.  Generating the SDP Offer for Loopback Session
+
+   If an offerer wishes to make a loopback request, it includes both the
+   loopback-type and loopback-role attributes in a valid SDP offer:
+
+   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], since it is implied
+   by default.  If either the loopback source or mirror wishes 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 used) or reject the offending media
+   stream.
+
+   The offerer may offer more than one loopback-type in the SDP offer.
+   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.
+
+
+
+Kaplan, et al.               Standards Track                    [Page 9]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+   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 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.
+
+   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
+
+5.2.  Generating the SDP Answer for Loopback Session
+
+   As with the offer, an SDP answer for loopback follows SDP
+   offer/answer rules for the direction attribute, but directions of
+   "sendonly" or "recvonly" do not apply for loopback operation.
+
+   The port number and the address in the answer (m/c= lines) indicate
+   where the answerer would like to receive the media stream.  The
+   payload type numbers indicate the value of the payload types the
+   answerer expects to send and receive.
+
+   An answerer includes both the loopback-role and loopback-type
+   attributes in the answer to indicate that it will accept the loopback
+   request.  When a stream is offered with the loopback-source
+   attribute, the corresponding stream in the response will be
+   loopback-mirror and vice versa, provided the answerer is capable of
+   supporting the requested loopback-type.
+
+   For example, if the offer contains the loopback-source attribute:
+
+      m=audio 41352 RTP/AVP 0 8
+      a=loopback:rtp-media-loopback
+      a=loopback-source
+
+
+
+
+
+
+Kaplan, et al.               Standards Track                   [Page 10]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+   The answer that is capable of supporting the offer must contain the
+   loopback-mirror attribute:
+
+      m=audio 12345 RTP/AVP 0 8
+      a=loopback:rtp-media-loopback
+      a=loopback-mirror
+
+   If a stream is offered with multiple loopback-type attributes, the
+   answer MUST include only one of the loopback types that are accepted
+   by the answerer.  The answerer SHOULD give preference to the first
+   loopback-type in the SDP offer.
+
+   For example, if the offer contains:
+
+      m=audio 41352 RTP/AVP 0 8 112
+      a=loopback:rtp-media-loopback rtp-pkt-loopback
+      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 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
+      a=rtpmap:113 rtploopback/8000
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kaplan, et al.               Standards Track                   [Page 11]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+   The answer that is capable of supporting the offer must contain one
+   of the following:
+
+      m=audio 12345 RTP/AVP 0 8 112
+      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.
+
+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
+   includes transitioning from a normal media processing mode to
+   loopback mode, and vice versa.
+
+5.5.  Establishing Sessions between Entities behind NATs
+
+   Interactive Connectivity Establishment (ICE) [RFC5245], Traversal
+   Using Relays around NAT (TURN) [RFC5766], and Session Traversal
+   Utilities for NAT (STUN) [RFC5389] provide a general solution to
+   establishing media sessions between entities that are behind Network
+   Address Translators (NATs).  Loopback sessions that involve one or
+   more endpoints behind NATs can also use these general solutions
+   wherever possible.
+
+   If ICE is not supported, then in the case of loopback, the mirroring
+   entity will not send RTP packets and therefore will not automatically
+   create the NAT pinhole in the way that other SIP sessions do.
+   Therefore, if the mirroring entity is behind a NAT, it MUST send some
+
+
+
+Kaplan, et al.               Standards Track                   [Page 12]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+   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] can 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, unless the mirror can control the
+   NAT(s) in its path to create explicit pinholes.  In other words, both
+   agents MUST send packets from the source address and port they
+   receive packets on, unless some mechanism is used to avoid that need
+   (e.g., by using the Port Control Protocol).
+
+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 the loopback type rtp-pkt-loopback 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 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 the number of frames/packets and the bit rate 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
+
+
+
+Kaplan, et al.               Standards Track                   [Page 13]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+   loopback operation.  This is useful in cases where the 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 the
+   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 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).
+
+   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: This bit is 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].
+
+   Timestamp: The RTP timestamp denotes the sampling instant for when
+      the loopback mirror is transmitting this packet to the loopback
+      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]).
+
+   Synchronization source (SSRC): This field is set as described in
+      RFC 3550 [RFC3550].
+
+   The CSRC count (CC) and contributing source (CSRC) fields are used as
+   described in RFC 3550 [RFC3550].
+
+
+
+
+
+
+Kaplan, et al.               Standards Track                   [Page 14]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+7.1.2.  RTP Payload Structure
+
+   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 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         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           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 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]).
+
+
+
+
+
+
+Kaplan, et al.               Standards Track                   [Page 15]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+   Fragmentation (F): 2 bits
+
+   Possible values are First Fragment (00), Last Fragment (01),
+   No Fragmentation (10), or 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 sets this field to 00.  The packet that
+   contains the last fragment sets this field to 01, and all other
+   packets set this field to 11.
+
+7.1.3.  Usage of SDP
+
+   The payload type number for the encapsulated stream can be negotiated
+   using SDP.  There is no static payload type assignment for the
+   encapsulating stream, so dynamic payload type numbers MUST be used.
+   The binding to the name is indicated by an rtpmap attribute.  The
+   name used in this binding is "encaprtp".
+
+   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 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
+      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).
+
+   Marker (M) bit: This bit is set to the value in the received packet.
+
+
+
+
+Kaplan, et al.               Standards Track                   [Page 16]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+   Extension (X) bit: This bit is 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
+      the loopback mirror is transmitting this packet to the loopback
+      source.  The same clock rate MUST be used as that of the received
+      RTP packet.  The initial value of the timestamp SHOULD be random
+      for security reasons (see Section 5.1 of RFC 3550 [RFC3550]).
+
+   SSRC: This field is set as described in RFC 3550 [RFC3550].
+
+   The CC and CSRC fields are used as described in RFC 3550 [RFC3550].
+
+7.2.2.  RTP Payload Structure
+
+   This payload format does not define any payload-specific headers.
+   The loopback mirror simply copies the RTP payload data from the
+   payload portion of the RTP packet received from the loopback source.
+
+7.2.3.  Usage of SDP
+
+   The payload type number for the payload loopback stream can be
+   negotiated using a mechanism like SDP.  There is no static payload
+   type assignment for the stream, so dynamic payload type numbers MUST
+   be used.  The binding to the name is indicated by an rtpmap
+   attribute.  The name used in this binding is "rtploopback".
+
+   The following is an example SDP fragment for the direct loopback RTP
+   format.
+
+   m=audio 41352 RTP/AVP 112
+   a=rtpmap:112 rtploopback/8000
+
+8.  SRTP Behavior
+
+   Secure RTP (SRTP) [RFC3711] MAY be used for loopback sessions.  SRTP
+   operates at a lower logical layer than RTP, and thus if both sides
+   negotiate to use SRTP, each side uses its own key and 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
+   a Master Key Identifier (MKI) or authentication tag; once the
+
+
+
+
+
+
+Kaplan, et al.               Standards Track                   [Page 17]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+   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 the 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
+   chooses to support RTCP-XR, they SHOULD support the RTCP-XR Loss Run
+   Length Encoding (RLE) Report Block, Duplicate RLE Report Block,
+   Statistics Summary Report Block, and VoIP Metrics Report 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 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.
+
+11.  Examples
+
+   This section provides examples for media descriptions using SDP for
+   different scenarios.  The examples are given for SIP-based
+   transactions; for convenience, they are abbreviated and do not show
+   the complete signaling.
+
+
+
+
+
+
+Kaplan, et al.               Standards Track                   [Page 18]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+11.1.  Offer for Specific Media Loopback Type
+
+   An agent sends an SDP offer that looks like:
+
+   v=0
+   o=alice 2890844526 2890842807 IN IP4 host.atlanta.example.com
+   s=-
+   c=IN IP4 host.atlanta.example.com
+   t=0 0
+   m=audio 49170 RTP/AVP 0
+   a=loopback:rtp-media-loopback
+   a=loopback-source
+   a=rtpmap:0 pcmu/8000
+
+   The agent is offering to source the media and expects the answering
+   agent to mirror the RTP stream per the loopback type
+   rtp-media-loopback.
+
+   An answering agent sends an SDP answer that looks like:
+
+   v=0
+   o=bob 1234567890 1122334455 IN IP4 host.biloxi.example.com
+   s=-
+   c=IN IP4 host.biloxi.example.com
+   t=0 0
+   m=audio 49270 RTP/AVP 0
+   a=loopback:rtp-media-loopback
+   a=loopback-mirror
+   a=rtpmap:0 pcmu/8000
+
+   The answerer agrees to mirror the media from the offerer at the media
+   level.
+
+11.2.  Offer for Choice of Media Loopback Type
+
+   An agent sends an SDP offer that looks like:
+
+   v=0
+   o=alice 2890844526 2890842807 IN IP4 host.atlanta.example.com
+   s=-
+   c=IN IP4 host.atlanta.example.com
+   t=0 0
+   m=audio 49170 RTP/AVP 0 112 113
+   a=loopback:rtp-media-loopback rtp-pkt-loopback
+   a=loopback-source
+   a=rtpmap:0 pcmu/8000
+   a=rtpmap:112 encaprtp/8000
+   a=rtpmap:113 rtploopback/8000
+
+
+
+Kaplan, et al.               Standards Track                   [Page 19]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+   The offerer is offering to source the media and expects the answerer
+   to mirror the RTP stream at either the media or RTP level.
+
+   An answering agent sends an SDP answer that looks like:
+
+   v=0
+   o=bob 1234567890 1122334455 IN IP4 host.biloxi.example.com
+   s=-
+   c=IN IP4 host.biloxi.example.com
+   t=0 0
+   m=audio 49270 RTP/AVP 0 112
+   a=loopback:rtp-pkt-loopback
+   a=loopback-mirror
+   a=rtpmap:0 pcmu/8000
+   a=rtpmap:112 encaprtp/8000
+
+   The answerer agrees to mirror the media from the offerer at the
+   packet level using the encapsulated RTP payload format.
+
+11.3.  Answerer Rejecting Loopback Media
+
+   An agent sends an SDP offer that looks like:
+
+   v=0
+   o=alice 2890844526 2890842807 IN IP4 host.atlanta.example.com
+   s=-
+   c=IN IP4 host.atlanta.example.com
+   t=0 0
+   m=audio 49170 RTP/AVP 0
+   a=loopback:rtp-media-loopback
+   a=loopback-source
+   a=rtpmap:0 pcmu/8000
+
+   The offerer is offering to source the media and expects the answerer
+   to mirror the RTP stream at the media level.
+
+   An answering agent sends an SDP answer that looks like:
+
+   v=0
+   o=bob 1234567890 1122334455 IN IP4 host.biloxi.example.com
+   s=-
+   c=IN IP4 host.biloxi.example.com
+   t=0 0
+   m=audio 0 RTP/AVP 0
+   a=rtpmap:0 pcmu/8000
+
+
+
+
+
+
+Kaplan, et al.               Standards Track                   [Page 20]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+   Note in this case that the answerer did not indicate loopback
+   support, although it could have and still used a port number of 0 to
+   indicate that it does not wish to accept that media session.
+
+   Alternatively, the answering agent could have simply rejected the
+   entire SDP offer through some higher-layer signaling protocol means
+   (e.g., by rejecting the SIP INVITE request if the SDP offer was in
+   the INVITE).
+
+12.  Security Considerations
+
+   The security considerations of [RFC3264] and [RFC3550] apply.
+
+   Given that media loopback may be automated without the end user's
+   knowledge, the answerer of the media loopback should be aware of
+   denial-of-service attacks.  It is RECOMMENDED that session requests
+   for media loopback be authenticated and the frequency of such
+   sessions limited by the answerer.
+
+   If the higher-layer signaling protocol were not authenticated, a
+   malicious attacker could create a session between two parties the
+   attacker wishes to target, with each party acting as the loopback
+   mirror to the other, of the rtp-pkt-loopback type.  A few RTP packets
+   sent to either party would then infinitely loop among the two, as
+   fast as they could process them, consuming their resources and
+   network bandwidth.
+
+   Furthermore, media loopback provides a means of attack indirection,
+   whereby a malicious attacker creates a loopback session as the
+   loopback source and uses the mirror to reflect the attacker's packets
+   against a target -- perhaps a target the attacker could not reach
+   directly, such as one behind a firewall, for example.  Or, the
+   attacker could initiate the session as the loopback mirror, in the
+   hopes of making the peer generate media against another target.
+
+   If end-user devices such as mobile phones answer loopback requests
+   without authentication and without notifying the end user, then an
+   attacker could cause the battery to drain, and possibly deny the end
+   user normal phone service or cause network data usage fees.  This
+   could even occur naturally if a legitimate loopback session does not
+   terminate properly and the end device does not have a timeout
+   mechanism for such.
+
+   For the reasons noted above, end-user devices SHOULD provide a means
+   of indicating to the human user that the device is in a loopback
+   session, even if it is an authenticated session.  Devices that answer
+
+
+
+
+
+Kaplan, et al.               Standards Track                   [Page 21]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+   or generate loopback sessions SHOULD either perform keepalive/refresh
+   tests of the session state through some means or time out the session
+   automatically.
+
+13.  Implementation Considerations
+
+   The media loopback approach described in this document is a complete
+   solution that would work under all scenarios.  However, it is
+   possible that the solution may not be lightweight enough for some
+   implementations.  In light of this concern, this section clarifies
+   which features of the loopback proposal MUST be 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.  These
+   requirements are intended to provide a minimal level of
+   interoperability between different implementations.
+
+14.  IANA Considerations
+
+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:            kh274@cornell.edu
+      Telephone number:         +1-617-899-3279
+      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 for 'loopback' may be
+                                one or more of "rtp-pkt-loopback" and
+                                "rtp-media-loopback".  See Section 4
+                                of RFC 6849 for syntax.
+
+
+
+
+
+
+
+
+
+
+
+Kaplan, et al.               Standards Track                   [Page 22]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+      Contact name:             Kaynam Hedayat
+      Email address:            kh274@cornell.edu
+      Telephone number:         +1-617-899-3279
+      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: N/A
+
+      Contact name:             Kaynam Hedayat
+      Email address:            kh274@cornell.edu
+      Telephone number:         +1-617-899-3279
+      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: N/A
+
+14.2.  Media Types
+
+   The IANA has registered the following media types.
+
+14.2.1.  audio/encaprtp
+
+   To: ietf-types@iana.org
+
+   Subject: Registration of media type audio/encaprtp
+
+   Type name: audio
+
+   Subtype name: encaprtp
+
+   Required parameters:
+
+      rate: RTP timestamp clock rate, which is equal to the sampling
+      rate.  This is specified by the loopback source and reflected by
+      the mirror.
+
+   Optional parameters: N/A
+
+   Encoding considerations: This media type is framed.
+
+
+
+
+Kaplan, et al.               Standards Track                   [Page 23]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+   Security considerations: See Section 12 of RFC 6849.
+
+   Interoperability considerations: N/A
+
+   Published specification: RFC 6849.
+
+   Applications that use this media type: Applications wishing to
+      monitor and ensure the quality of transport to the edge of a given
+      VoIP service.
+
+   Additional information: N/A
+
+   Contact: the authors of RFC 6849.
+
+   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 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
+
+   Subtype name: encaprtp
+
+   Required parameters:
+
+      rate: RTP timestamp clock rate, which is equal to the sampling
+      rate.  This is specified by the loopback source and reflected by
+      the mirror.
+
+   Optional parameters: N/A
+
+   Encoding considerations: This media type is framed.
+
+   Security considerations: See Section 12 of RFC 6849.
+
+   Interoperability considerations: N/A
+
+
+
+Kaplan, et al.               Standards Track                   [Page 24]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+   Published specification: RFC 6849.
+
+   Applications that 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: N/A
+
+   Contact: the authors of RFC 6849.
+
+   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 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
+
+   Subtype name: encaprtp
+
+   Required parameters:
+
+      rate: RTP timestamp clock rate, which is equal to the sampling
+      rate.  This is specified by the loopback source and reflected by
+      the mirror.
+
+   Optional parameters: N/A
+
+   Encoding considerations: This media type is framed.
+
+   Security considerations: See Section 12 of RFC 6849.
+
+   Interoperability considerations: N/A
+
+   Published specification: RFC 6849.
+
+
+
+
+
+Kaplan, et al.               Standards Track                   [Page 25]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+   Applications that 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: N/A
+
+   Contact: the authors of RFC 6849.
+
+   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 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
+
+   Subtype name: encaprtp
+
+   Required parameters:
+
+      rate: RTP timestamp clock rate, which is equal to the sampling
+      rate.  This is specified by the loopback source and reflected by
+      the mirror.
+
+   Optional parameters: N/A
+
+   Encoding considerations: This media type is framed.
+
+   Security considerations: See Section 12 of RFC 6849.
+
+   Interoperability considerations: N/A
+
+   Published specification: RFC 6849.
+
+   Applications that use this media type: Applications wishing to
+      monitor and ensure the quality of transport to the edge of a given
+      real-time application service.
+
+
+
+Kaplan, et al.               Standards Track                   [Page 26]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+   Additional information: N/A
+
+   Contact: the authors of RFC 6849.
+
+   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 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
+
+   Subtype name: rtploopback
+
+   Required parameters:
+
+      rate: RTP timestamp clock rate, which is equal to the sampling
+      rate.  This is specified by the loopback source and reflected by
+      the mirror.
+
+   Optional parameters: N/A
+
+   Encoding considerations: This media type is framed.
+
+   Security considerations: See Section 12 of RFC 6849.
+
+   Interoperability considerations: N/A
+
+   Published specification: RFC 6849.
+
+   Applications that use this media type: Applications wishing to
+      monitor and ensure the quality of transport to the edge of a given
+      VoIP service.
+
+   Additional information: N/A
+
+   Contact: the authors of RFC 6849.
+
+
+
+Kaplan, et al.               Standards Track                   [Page 27]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+   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 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
+
+   Subtype name: rtploopback
+
+   Required parameters:
+
+      rate: RTP timestamp clock rate, which is equal to the sampling
+      rate.  This is specified by the loopback source and reflected by
+      the mirror.
+
+   Optional parameters: N/A
+
+   Encoding considerations: This media type is framed.
+
+   Security considerations: See Section 12 of RFC 6849.
+
+   Interoperability considerations: N/A
+
+   Published specification: RFC 6849.
+
+   Applications that 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: N/A
+
+   Contact: the authors of RFC 6849.
+
+   Intended usage: LIMITED USE
+
+
+
+
+
+Kaplan, et al.               Standards Track                   [Page 28]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+   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 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
+
+   Subtype name: rtploopback
+
+   Required parameters:
+
+      rate: RTP timestamp clock rate, which is equal to the sampling
+      rate.  This is specified by the loopback source and reflected by
+      the mirror.
+
+   Optional parameters: N/A
+
+   Encoding considerations: This media type is framed.
+
+   Security considerations: See Section 12 of RFC 6849.
+
+   Interoperability considerations: N/A
+
+   Published specification: RFC 6849.
+
+   Applications that 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: N/A
+
+   Contact: the authors of RFC 6849.
+
+   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.
+
+
+
+Kaplan, et al.               Standards Track                   [Page 29]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+   Author: Kaynam Hedayat.
+
+   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
+
+   Subtype name: rtploopback
+
+   Required parameters:
+
+      rate: RTP timestamp clock rate, which is equal to the sampling
+      rate.  This is specified by the loopback source and reflected by
+      the mirror.
+
+   Optional parameters: N/A
+
+   Encoding considerations: This media type is framed.
+
+   Security considerations: See Section 12 of RFC 6849.
+
+   Interoperability considerations: N/A
+
+   Published specification: RFC 6849.
+
+   Applications that 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: N/A
+
+   Contact: the authors of RFC 6849.
+
+   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.
+
+
+
+
+
+
+
+Kaplan, et al.               Standards Track                   [Page 30]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+   Author: Kaynam Hedayat.
+
+   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.
+
+16.  References
+
+16.1.  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 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. and S. Casner, "RTP Profile for Audio and
+               Video Conferences with Minimal Control", STD 65,
+               RFC 3551, July 2003.
+
+   [RFC3611]   Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
+               "RTP Control Protocol Extended Reports (RTCP XR)",
+               RFC 3611, November 2003.
+
+   [RFC3711]   Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+               Norrman, "The Secure Real-time Transport Protocol
+               (SRTP)", RFC 3711, March 2004.
+
+   [RFC4566]   Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+               Description Protocol", RFC 4566, July 2006.
+
+
+
+
+
+
+Kaplan, et al.               Standards Track                   [Page 31]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+   [RFC4961]   Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
+               BCP 131, RFC 4961, July 2007.
+
+   [RFC5234]   Crocker, D., Ed., and P. Overell, "Augmented BNF for
+               Syntax Specifications: ABNF", STD 68, RFC 5234,
+               January 2008.
+
+16.2.  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.
+
+   [RFC5389]   Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
+               "Session Traversal Utilities for NAT (STUN)", RFC 5389,
+               October 2008.
+
+   [RFC5766]   Mahy, R., Matthews, P., and J. Rosenberg, "Traversal
+               Using Relays around NAT (TURN): Relay Extensions to
+               Session Traversal Utilities for NAT (STUN)", RFC 5766,
+               April 2010.
+
+   [RFC6263]   Marjou, X. and A. Sollaud, "Application Mechanism for
+               Keeping Alive the NAT Mappings Associated with RTP / RTP
+               Control Protocol (RTCP) Flows", RFC 6263, June 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kaplan, et al.               Standards Track                   [Page 32]
+
+RFC 6849                   SDP Media Loopback              February 2013
+
+
+Authors' Addresses
+
+   Hadriel Kaplan (editor)
+   Acme Packet
+   100 Crosby Drive
+   Bedford, MA  01730
+   US
+   EMail: hkaplan@acmepacket.com
+   URI:   http://www.acmepacket.com
+
+
+   Kaynam Hedayat
+   EXFO
+   285 Mill Road
+   Chelmsford, MA  01824
+   US
+   EMail: kh274@cornell.edu
+   URI:   http://www.exfo.com/
+
+
+   Nagarjuna Venna
+   Saperix
+   c/o DogPatch Labs
+   One Cambridge Center, 6th Floor
+   Cambridge, MA  02142
+   US
+   EMail: vnagarjuna@saperix.com
+   URI:   http://www.saperix.com/
+
+
+   Paul E. Jones
+   Cisco Systems, Inc.
+   7025 Kit Creek Rd.
+   Research Triangle Park, NC  27709
+   US
+   EMail: paulej@packetizer.com
+   URI:   http://www.cisco.com/
+
+
+   Nathan Stratton
+   BlinkMind, Inc.
+   2027 Briarchester Dr.
+   Katy, TX  77450
+   US
+   EMail: nathan@robotics.net
+   URI:   http://www.robotics.net/
+
+
+
+
+
+Kaplan, et al.               Standards Track                   [Page 33]
+