idnits 2.17.1 draft-ietf-mmusic-media-loopback-27.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 14, 2013) is 4091 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC5766' is mentioned on line 544, but not defined ** Obsolete undefined reference: RFC 5766 (Obsoleted by RFC 8656) == Missing Reference: 'RFC5389' is mentioned on line 545, but not defined ** Obsolete undefined reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MMUSIC Working Group H. Kaplan (ed.) 2 Internet-Draft Acme Packet 3 Intended status: Proposed Standard K. Hedayat 4 Expires: July 14, 2013 EXFO 5 N. Venna 6 Saperix 7 P. Jones 8 Cisco Systems, Inc. 9 N. Stratton 10 BlinkMind, Inc. 11 January 14, 2013 13 An Extension to the Session Description Protocol (SDP) 14 and Real-time Transport Protocol (RTP) for Media Loopback 15 draft-ietf-mmusic-media-loopback-27 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with 20 the provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other 29 documents at any time. It is inappropriate to use Internet-Drafts 30 as reference material or to cite them other than as "work in 31 progress". 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on July 14, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with 51 respect to this document. Code Components extracted from this 52 document must include Simplified BSD License text as described in 53 Section 4.e of the Trust Legal Provisions and are provided without 54 warranty as described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) 62 controlling the copyright in such materials, this document may not 63 be modified outside the IETF Standards Process, and derivative 64 works of it may not be created outside the IETF Standards Process, 65 except to format it for publication as an RFC or to translate it 66 into languages other than English. 68 Abstract 70 The wide deployment of Voice over IP (VoIP), Text and Video over IP 71 services has introduced new challenges in managing and maintaining 72 real-time voice/text/video quality, reliability, and overall 73 performance. In particular, media delivery is an area that needs 74 attention. One method of meeting these challenges is monitoring 75 the media delivery performance by looping media back to the 76 transmitter. This is typically referred to as "active monitoring" 77 of services. Media loopback is especially popular in ensuring the 78 quality of transport to the edge of a given VoIP, Real-time Text or 79 Video over IP service. Today in networks that deliver real-time 80 media, short of running 'ping' and 'traceroute' to the edge, 81 administrators are left without the necessary tools to actively 82 monitor, manage, and diagnose quality issues with their service. 83 The extension defined herein adds new SDP media types and 84 attributes, which enable establishment of media sessions where the 85 media is looped back to the transmitter. Such media sessions will 86 serve as monitoring and troubleshooting tools by providing the 87 means for measurement of more advanced VoIP, Real-time Text and 88 Video over IP performance metrics. 90 Table of Contents 92 1. Introduction..................................................3 93 1.1 Use Cases Supported.......................................4 94 2. Terminology...................................................6 95 3. Overview of Operation.........................................6 96 3.1 SDP Offerer Behavior......................................6 97 3.2 SDP Answerer Behavior.....................................7 98 4. New SDP Attributes............................................7 99 4.1 Loopback Type Attribute...................................7 100 4.2 Loopback Role Attributes: loopback-source and loopback- 101 mirror........................................................8 102 5. Rules for Generating the SDP offer/answer.....................9 103 5.1 Generating the SDP Offer for Loopback Session.............9 104 5.2 Generating the SDP Answer for Loopback Session...........10 105 5.3 Offerer Processing of the SDP Answer.....................12 106 5.4 Modifying the Session....................................12 107 5.5 Establishing Sessions Between Entities Behind NAT........12 108 6. RTP Requirements.............................................13 109 7. Payload formats for Packet loopback..........................13 110 7.1 Encapsulated Payload format..............................14 111 7.2 Direct loopback RTP payload format.......................16 112 8. SRTP Behavior................................................17 113 9. RTCP Requirements............................................18 114 10. Congestion Control..........................................18 115 11. Examples....................................................18 116 11.1 Offer for specific media loopback type..................19 117 11.2 Offer for choice of media loopback type.................19 118 11.3 Answerer rejecting loopback media.......................20 119 12. Security Considerations.....................................21 120 13. Implementation Considerations...............................22 121 14. IANA Considerations.........................................22 122 14.1 SDP Attributes..........................................22 123 14.2 Media Types.............................................23 124 15. Acknowledgements............................................31 125 16. Normative References........................................31 126 17. Informative References......................................32 128 1. Introduction 130 The overall quality, reliability, and performance of VoIP, 131 Real-time Text and Video over IP services rely on the performance 132 and quality of the media path. In order to assure the quality of 133 the delivered media there is a need to monitor the performance of 134 the media transport. One method of monitoring and managing the 135 overall quality of real-time VoIP, Text and Video over IP Services 136 is through monitoring the quality of the media in an active 137 session. This type of "active monitoring" of services is a method 138 of proactively managing the performance and quality of VoIP based 139 services. 141 The goal of active monitoring is to measure the media quality of a 142 VoIP, Text or Video over IP session. A way to achieve this goal is 143 to request an endpoint to loop media back to the other endpoint and 144 to provide media statistics (e.g., RTCP and RTCP-XR information). 145 Another method involves deployment of special endpoints that always 146 loop incoming media back for all sessions. Although the latter 147 method has been used and is functional, it does not scale to 148 support large networks and introduces new network management 149 challenges. Further, it does not offer the granularity of testing 150 a specific endpoint that may be exhibiting problems. 152 The extension defined in this document introduces new SDP media 153 types and attributes that enable establishment of media sessions 154 where the media is looped back to the transmitter. The SDP 155 offer/answer model [RFC3264] is used to establish a loopback 156 connection. Furthermore, this extension provides guidelines on 157 handling RTP [RFC3550], as well as usage of RTP Control Protocol 158 (RTCP) [RFC3550] and RTCP Extended Reports (RTCP-XR) [RFC3611] for 159 reporting media related measurements. 161 1.1 Use Cases Supported 163 As a matter of terminology in this document, packets flow from one 164 peer acting as a "loopback source", to the other peer acting as a 165 "loopback mirror", which in turn returns packets to the loopback 166 source. In advance of the session, the peers negotiate to determine 167 which one acts in which role, using the SDP offer/answer exchange. 168 The negotiation also includes details such as the type of loopback 169 to be used. 171 This specification supports three use cases: "encapsulated packet 172 loopback", "direct loopback", and "media loopback". These are 173 distinguished by the treatment of incoming RTP packets at the 174 loopback mirror. 176 1.1.1 Encapsulated Packet Loopback 178 In the encapsulated packet loopback case, the entire incoming RTP 179 packet is encapsulated as payload within an outer RTP packet that 180 is specific to this use case and specified in Section 7.1. The 181 encapsulated packet is returned to the loopback source. The 182 loopback source can generate statistics for one-way path 183 performance up to the RTP level for each direction of travel by 184 examining sequence numbers and timestamps in the encapsulating 185 outer RTP header and the encapsulated RTP packet payload. The 186 loopback source can also play back the returned media content for 187 evaluation. 189 Because the encapsulating RTP packet header extends the packet 190 size, it could encounter difficulties in an environment where the 191 original RTP packet size is close to the path Maximum Transmission 192 Unit (MTU) size. The encapsulating payload format therefore offers 193 the possibility of RTP-level fragmentation of the returned packets. 194 The use of this facility could affect statistics derived for the 195 return path. In addition, the increased bit rate required in the 196 return direction may affect these statistics more directly in a 197 restricted-bandwidth situation. 199 1.1.2 Direct Loopback 201 In the direct loopback case, the loopback mirror copies the payload 202 of the incoming RTP packet into a new RTP packet, using a payload 203 format specific to this use case and specified in Section 7.2. The 204 loopback mirror returns the new packet to the packet source. There 205 is no provision in this case for RTP-level fragmentation. 207 This use case has the advantage of keeping the packet size the same 208 in both directions. The packet source can compute only two-way 209 path statistics from the direct loopback packet header, but can 210 play back the returned media content. 212 It has been suggested that the loopback source, knowing that the 213 incoming packet will never be passed to a decoder, can store a 214 timestamp and sequence number inside the payload of the packet it 215 sends to the mirror, then extract that information from the 216 returned direct loopback packet and compute one-way path statistics 217 as in the previous case. Obviously, playout of returned content is 218 no longer possible if this is done. 220 1.1.3 Media Loopback 222 In the media loopback case, the loopback mirror submits the 223 incoming packet to a decoder appropriate to the incoming payload 224 type. The packet is taken as close as possible to the analog level, 225 then re-encoded according to an outgoing format determined by SDP 226 negotiation. The reencoded content is returned to the loopback 227 source as an RTP packet with payload type corresponding to the 228 reencoding format. 230 This usage allows trouble-shooting at the codec level. The 231 capability for path statistics is limited to what is available from 232 RTCP reports. 234 2. Terminology 236 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 237 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 238 this document are to be interpreted as described in RFC 2119 239 [RFC2119]. 241 SDP: Session Description Protocol, as defined in [RFC4566]. This 242 document assumes the SDP offer/answer model is followed, per 243 [RFC3264], but does not assume any specific signaling protocol for 244 carrying the SDP. 246 The following terms are borrowed from [RFC3264] definitions: offer, 247 offerer, answer, answerer, and agent. 249 3. Overview of Operation 251 This document defines two loopback 'types', two 'roles', and two 252 encoding formats for loopback. For any given SDP offerer or 253 answerer pair, one side is the source of RTP packets, while the 254 other is the mirror looping packets/media back. Those define the 255 two loopback roles. As the mirror, two 'types' of loopback can be 256 performed: packet-level or media-level. When media-level is used, 257 there is no further choice of encoding format - there is only one 258 format: whatever is indicated for normal media, since the "looping" 259 is performed at the codec level. When packet-level looping is 260 performed, however, the mirror can either send back RTP in an 261 encapsulated format or direct-loopback format. The rest of this 262 document describes these loopback types, roles, and encoding 263 formats, and the SDP offer/answer rules for indicating them. 265 3.1 SDP Offerer Behavior 267 An SDP offerer compliant to this specification and attempting to 268 establish a media session with media loopback will include 269 "loopback" media attributes for each individual media description 270 in the offer message that it wishes to have looped back. Note that 271 the offerer may choose to only request loop back for some media 272 descriptions/streams but not others. For example it might wish to 273 request loopback for a video stream but not audio, or vice-versa. 275 The offerer will look for the "loopback" media attributes in the 276 media description(s) of the response from the SDP answer for 277 confirmation that the request is accepted. 279 3.2 SDP Answerer Behavior 281 In order to accept a loopback offer (that is, an offer containing 282 "loopback" in the media description), an SDP answerer includes the 283 "loopback" media attribute in each media description for which it 284 desires loopback. 286 An answerer can reject an offered stream (either with loopback- 287 source or loopback-mirror) if the loopback-type is not specified, 288 the specified loopback-type is not supported, or the endpoint 289 cannot honor the offer for any other reason. The loopback request 290 is rejected by setting the stream's media port number to zero in 291 the answer as defined in RFC 3264 [RFC3264], or by rejecting the 292 entire offer (i.e., by rejecting the session request entirely). 294 Note that an answerer that is not compliant to this specification 295 and which receives an offer with the "loopback" media attributes 296 would ignore the attributes and treat the incoming offer as a 297 normal request. If the offerer does not wish to establish a 298 "normal" RTP session, it would need to terminate the session upon 299 receiving such an answer. 301 4. New SDP Attributes 303 Three new SDP media-level attributes are defined: one indicates the 304 type of loopback, and the other two define the role of the agent. 306 4.1 Loopback Type Attribute 308 This specification defines a new "loopback" attribute, which 309 indicates that the agent wishes to perform loopback, and the type 310 of loopack that the agent is able to do. The loopback-type is a 311 value media attribute [RFC4566] with the following syntax: 313 a=loopback: 315 Following is the Augmented BNF [RFC5234] for loopback-type: 317 attribute /= loopback-attr 318 ; attribute defined in RFC 4566 320 loopback-attr = "loopback:" SP loopback-type 321 loopback-type = loopback-choice [1*SP loopback-choice] 322 loopback-choice = loopback-type-pkt / loopback-type-media 323 loopback-type-pkt = "rtp-pkt-loopback" 324 loopback-type-media = "rtp-media-loopback" 326 The loopback-type is used to indicate the type of loopback. The 327 loopback-type values are rtp-pkt-loopback, and rtp-media-loopback. 329 rtp-pkt-loopback: In this mode, the RTP packets are looped back to 330 the sender at a point before the encoder/decoder function in the 331 receive direction to a point after the encoder/decoder function in 332 the send direction. This effectively re-encapsulates the RTP 333 payload with the RTP/UDP/IP headers appropriate for sending it in 334 the reverse direction. Any type of encoding related functions, 335 such as packet loss concealment, MUST NOT be part of this type of 336 loopback path. In this mode the RTP packets are looped back with a 337 new payload type and format. Section 7 describes the payload 338 formats that are to be used for this type of loopback. This type 339 of loopback applies to the encapsulated and direct loopback use- 340 cases described in Section 1.1. 342 rtp-media-loopback: This loopback is activated as close as possible 343 to the analog interface and after the decoder so that the RTP 344 packets are subsequently re-encoded prior to transmission back to 345 the sender. This type of loopback applies to the media loopback 346 use-case described in Section 1.1.3. 348 4.2 Loopback Role Attributes: loopback-source and loopback-mirror 350 The loopback role defines two property media attributes [RFC4566] 351 that are used to indicate the role of the agent generating the SDP 352 offer or answer. The syntax of the two loopback role media 353 attributes are as follows: 355 a=loopback-source 357 and 359 a=loopback-mirror 361 Following is the Augmented BNF [RFC5234] for loopback-type: 363 attribute /= loopback-source / loopback-mirror 364 ; attribute defined in RFC 4566 365 loopback-source = "loopback-source" 366 loopback-mirror = "loopback-mirror" 368 loopback-source: This attribute specifies that the entity that 369 generated the SDP is the media source and expects the receiver of 370 the SDP message to act as a loopback-mirror. 372 loopback-mirror: This attribute specifies that the entity that 373 generated the SDP will mirror (echo) all received media back to the 374 sender of the RTP stream. No media is generated locally by the 375 looping back entity for transmission in the mirrored stream. 377 The "m=" line in the SDP includes all the payload types that will 378 be used during the loopback session. The complete payload space for 379 the session is specified in the "m=" line and the rtpmap attribute 380 is used to map from the payload type number to an encoding name 381 denoting the payload format to be used. 383 5. Rules for Generating the SDP offer/answer 385 5.1 Generating the SDP Offer for Loopback Session 387 If an offerer wishes to make a loopback request, it includes both 388 the loopback-type and loopback-role attributes in a valid SDP 389 offer: 391 Example: m=audio 41352 RTP/AVP 0 8 100 392 a=loopback:rtp-media-loopback 393 a=loopback-source 394 a=rtpmap:0 pcmu/8000 395 a=rtpmap:8 pcma/8000 396 a=rtpmap:100 G7221/16000/1 398 Since media loopback requires bidirectional RTP, its normal 399 direction mode is "sendrecv"; the "sendrecv" direction attribute 400 MAY be encoded in SDP or not, as per Section 5.1 of [RFC3264], 401 since it is implied by default. If either the loopback source or 402 mirror wish to disable loopback use during a session, the direction 403 mode attribute "inactive" MUST be used as per [RFC3264]. The 404 direction mode attributes "recvonly" and "sendonly" are 405 incompatible with the loopback mechanism and MUST NOT be indicated 406 when generating an SDP Offer or Answer. When receiving an SDP 407 Offer or Answer, if "recvonly" or "sendonly" is indicated for 408 loopback, the SDP-receiving agent SHOULD treat it as a protocol 409 failure of the loopback negotiation and terminate the session 410 through its normal means (e.g., by sending a SIP BYE if SIP is 411 used), or reject the offending media stream. 413 The offerer may offer more than one loopback-type in the SDP offer. 414 The port number and the address in the offer (m/c= lines) indicate 415 where the offerer would like to receive the media stream(s). The 416 payload type numbers indicate the value of the payload the offerer 417 expects to receive. However, the answer might indicate a subset of 418 payload type numbers from those given in the offer. In that case, 419 the offerer MUST only send the payload types received in the 420 answer, per normal SDP offer/answer rules. 422 If the offer indicates rtp-pkt-loopback support, the offer MUST 423 also contain either an encapsulated or direct loopback encoding 424 format encoding name, or both, as defined in Sections 7.1 and 7.2 425 of this document. If the offer only indicates rtp-media-loopback 426 support, then neither encapsulated nor direct loopback encoding 427 formats apply and they MUST NOT be in the offer. 429 If loopback-type is rtp-pkt-loopback, the loopback-mirror MUST send 430 and the loopback-source MUST receive the looped back packets 431 encoded in one of the two payload formats (encapsulated RTP or 432 direct loopback) as defined in Section 7. 434 Example: m=audio 41352 RTP/AVP 0 8 112 435 a=loopback:rtp-pkt-loopback 436 a=loopback-source 437 a=rtpmap:112 encaprtp/8000 439 Example: m=audio 41352 RTP/AVP 0 8 112 440 a=loopback:rtp-pkt-loopback 441 a=loopback-source 442 a=rtpmap:112 rtploopback/8000 444 5.2 Generating the SDP Answer for Loopback Session 446 As with the offer, an SDP answer for loopback follows SDP 447 offer/answer rules for the direction attribute, but directions of 448 "sendonly" or "recvonly" do not apply for loopback operation. 450 The port number and the address in the answer (m/c= lines) indicate 451 where the answerer would like to receive the media stream. The 452 payload type numbers indicate the value of the payload types the 453 answerer expects to send and receive. 455 An answerer includes both the loopback role and loopback type 456 attributes in the answer to indicate that it will accept the 457 loopback request. When a stream is offered with the loopback-source 458 attribute, the corresponding stream in the response will be 459 loopback-mirror and vice versa, provided the answerer is capable of 460 supporting the requested loopback-type. 462 For example, if the offer contains the loopback-source attribute: 464 m=audio 41352 RTP/AVP 0 8 465 a=loopback:rtp-media-loopback 466 a=loopback-source 468 The answer that is capable of supporting the offer must contain the 469 loopback-mirror attribute: 471 m=audio 12345 RTP/AVP 0 8 472 a=loopback:rtp-media-loopback 473 a=loopback-mirror 475 If a stream is offered with multiple loopback type attributes, the 476 answer MUST include only one of the loopback types that are 477 accepted by the answerer. The answerer SHOULD give preference to 478 the first loopback-type in the SDP offer. 480 For example, if the offer contains: 482 m=audio 41352 RTP/AVP 0 8 112 483 a=loopback:rtp-media-loopback rtp-pkt-loopback 484 a=loopback-source 485 a=rtpmap:112 encaprtp/8000 487 The answer that is capable of supporting the offer and chooses to 488 loopback the media using the rtp-media-loopback type must contain: 490 m=audio 12345 RTP/AVP 0 8 491 a=loopback:rtp-media-loopback 492 a=loopback-mirror 494 As specified in Section 7, if the loopback-type is 495 rtp-pkt-loopback, either the encapsulated RTP payload format or 496 direct loopback RTP payload format MUST be used for looped back 497 packets. 499 For example, if the offer contains: 501 m=audio 41352 RTP/AVP 0 8 112 113 502 a=loopback:rtp-pkt-loopback 503 a=loopback-source 504 a=rtpmap:112 encaprtp/8000 505 a=rtpmap:113 rtploopback/8000 507 The answer that is capable of supporting the offer must contain one 508 of the following: 510 m=audio 12345 RTP/AVP 0 8 112 511 a=loopback:rtp-pkt-loopback 512 a=loopback-mirror 513 a=rtpmap:112 encaprtp/8000 515 m=audio 12345 RTP/AVP 0 8 113 516 a=loopback:rtp-pkt-loopback 517 a=loopback-mirror 518 a=rtpmap:113 rtploopback/8000 520 The previous examples used the 'encaprtp' and 'rtploopback' 521 encoding names, which will be defined in Sections 7.1.3 and 7.2.3. 523 5.3 Offerer Processing of the SDP Answer 525 If the received SDP answer does not contain an a=loopback-mirror or 526 a=loopback-source attribute, it is assumed that the loopback 527 extensions are not supported by the remote agent. This is not a 528 protocol failure, and instead merely completes the SDP offer/answer 529 exchange with whatever normal rules apply; the offerer MAY decide 530 to end the established RTP session (if any) through normal means of 531 the upper-layer signaling protocol (e.g., by sending a SIP BYE). 533 5.4 Modifying the Session 535 At any point during the loopback session, either participant MAY 536 issue a new offer to modify the characteristics of the previous 537 session, as defined in Section 8 of RFC 3264 [RFC3264]. This also 538 includes transitioning from a normal media processing mode to 539 loopback mode, and vice versa. 541 5.5 Establishing Sessions Between Entities Behind NAT 543 Interactive Connectivity Establishment (ICE) [RFC5245], Traversal 544 Using Relays around NAT (TURN) [RFC5766], and Session Traversal 545 Utilities for NAT (STUN) [RFC5389] provide a general solution to 546 establishing media sessions between entities that are behind 547 Network Address Translators (NATs). Loopback sessions that involve 548 one or more endpoints behind NATs can also use these general 549 solutions wherever possible. 551 If ICE is not supported, then in the case of loopback, the 552 mirroring entity will not send RTP packets, and therefore will not 553 automatically create the NAT pinhole in the way that other SIP 554 sessions do. Therefore, if the mirroring entity is behind a NAT, 555 it MUST send some packets to the identified address/port(s) of the 556 peer, in order to open the NAT pinhole. Using ICE, this would be 557 accomplished with the STUN connectivity check process, or through a 558 TURN server connection. If ICE is not supported, either [RFC6263] 559 or Section 10 of ICE [RFC5245] can be followed to open the pinhole 560 and keep the NAT binding alive/refreshed. 562 Note that for any form of NAT traversal to function, symmetric 563 RTP/RTCP [RFC4961] MUST be used, unless the mirror can control the 564 NAT(s) in its path to create explicit pinholes. In other words 565 both agents MUST send packets from the source address and port they 566 receive packets on, unless some mechanism is used to avoid that 567 need (e.g., by using Port Control Protocol). 569 6. RTP Requirements 571 A loopback source MUST NOT send multiple source streams on the same 572 5-tuple, since there is no means for the mirror to indicate which 573 is which in its mirrored RTP packets. 575 A loopback mirror that is compliant to this specification and 576 accepts media with rtp-pkt-loopback loopback type loops back the 577 incoming RTP packets using either the encapsulated RTP payload 578 format or the direct loopback RTP payload format as defined in 579 Section 7 of this specification. 581 A device that is compliant to this specification and performing the 582 mirroring using the loopback type rtp-media-loopback MUST transmit 583 all received media back to the sender, unless congestion feedback 584 or other lower-layer constraints prevent it from doing so. The 585 incoming media is treated as if it were to be played; for example, 586 the media stream may receive treatment from Packet Loss Concealment 587 (PLC) algorithms. The mirroring entity re-generates all the RTP 588 header fields as it would when transmitting media. The mirroring 589 entity MAY choose to encode the loopback media according to any of 590 the media descriptions supported by the offering entity. 591 Furthermore, in cases where the same media type is looped back, the 592 mirroring entity can choose to preserve number of frames/packet and 593 bitrate of the encoded media according to the received media. 595 7. Payload formats for Packet loopback 596 The payload formats described in this section MUST be used by a 597 loopback-mirror when 'rtp-pkt-loopback' is the specified 598 loopback-type. Two different formats are specified here - an 599 encapsulated RTP payload format and a direct loopback RTP payload 600 format. The encapsulated RTP payload format should be used when 601 the incoming RTP header information needs to be preserved during 602 the loopback operation. This is useful in cases where loopback 603 source needs to measure performance metrics in both directions. 604 However, this comes at the expense of increased packet size as 605 described in Section 7.1. The direct loopback RTP payload format 606 should be used when bandwidth requirements prevent the use of 607 encapsulated RTP payload format. 609 7.1 Encapsulated Payload format 611 A received RTP packet is encapsulated in the payload section of the 612 RTP packet generated by a loopback-mirror. Each received packet is 613 encapsulated in a separate encapsulating RTP packet; the 614 encapsulated packet would be fragmented only if required (for 615 example: due to MTU limitations). 617 7.1.1 Usage of RTP Header fields 619 Payload Type (PT): The assignment of an RTP payload type for this 620 packet format is outside the scope of this document; it is either 621 specified by the RTP profile under which this payload format is 622 used or more likely signaled dynamically out-of-band (e.g., using 623 SDP; Section 7.1.3 defines the name binding). 625 Marker (M) bit: If the received RTP packet is looped back in 626 multiple encapsulating RTP packets, the M bit is set to 1 in every 627 fragment except the last packet, otherwise it is set to 0. 629 Extension (X) bit: Defined by the RTP Profile used. 631 Sequence Number: The RTP sequence number SHOULD be generated by the 632 loopback-mirror in the usual manner with a constant random offset 633 as described in RFC 3550 [RFC3550]. 635 Timestamp: The RTP timestamp denotes the sampling instant for when 636 the loopback-mirror is transmitting this packet to the loopback- 637 source. The RTP timestamp MUST use the same clock rate as that of 638 the encapsulated packet. The initial value of the timestamp SHOULD 639 be random for security reasons (see Section 5.1 of RFC 3550 640 [RFC3550]). 642 SSRC: set as described in RFC 3550 [RFC3550]. 644 CC and CSRC fields are used as described in RFC 3550 [RFC3550]. 646 7.1.2 RTP Payload Structure 648 The outer RTP header of the encapsulating packet is followed by the 649 payload header defined in this section, after any header 650 extension(s). If the received RTP packet has to be looped back in 651 multiple encapsulating packets due to fragmentation, the 652 encapsulating RTP header in each packet is followed by the payload 653 header defined in this section. The header is devised so that the 654 loopback-source can decode looped back packets in the presence of 655 moderate packet loss [RFC3550]. The RTP payload of the 656 encapsulating RTP packet starts with the payload header defined in 657 this section. 659 0 1 2 3 660 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 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | receive timestamp | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | F | R | CC |M| PT | sequence number | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | transmit timestamp | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | synchronization source (SSRC) identifier | 669 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 670 | contributing source (CSRC) identifiers | 671 | .... | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 Figure 1: Encapsulating RTP Packet Payload Header 675 The 12 octets after the receive timestamp are identical to the 676 encapsulated RTP header of the received packet except for the first 677 2 bits of the first octet. In effect, the received RTP packet is 678 encapsulated by creating a new outer RTP header followed by 4 new 679 bytes of a receive timestamp, followed by the original received RTP 680 header and payload, except that the first two bits of the received 681 RTP header are overwritten as defined here. 683 Receive Timestamp: 32 bits 685 The Receive timestamp denotes the sampling instant for when the 686 last octet of the received media packet that is being encapsulated 687 by the loopback-mirror is received from the loopback-source. The 688 same clock rate MUST be used by the loopback-source. The initial 689 value of the timestamp SHOULD be random for security reasons (see 690 Section 5.1 of RFC 3550 [RFC3550]). 692 Fragmentation (F): 2 bits 694 First Fragment (00) /Last Fragment (01) /No Fragmentation(10)/ 695 Intermediate Fragment (11). This field identifies how much of the 696 received packet is encapsulated in this packet by the loopback- 697 mirror. If the received packet is not fragmented, this field is 698 set to 10; otherwise the packet that contains the first fragments 699 sets this field to 00, the packet that contains the last fragment 700 sets this field to 01, all other packets set this field to 11. 702 7.1.3 Usage of SDP 704 The payload type number for the encapsulated stream can be 705 negotiated using SDP. There is no static payload type assignment 706 for the encapsulating stream, so dynamic payload type numbers MUST 707 be used. The binding to the name is indicated by an rtpmap 708 attribute. The name used in this binding is "encaprtp". 710 The following is an example SDP fragment for encapsulated RTP. 712 m=audio 41352 RTP/AVP 112 713 a=rtpmap:112 encaprtp/8000 715 7.2 Direct loopback RTP payload format 717 The direct loopback RTP payload format can be used in scenarios 718 where the 16 byte overhead of the encapsulated payload format is of 719 concern, or simply due to local policy. When using this payload 720 format, the receiver loops back each received RTP packet payload 721 (not header) in a separate RTP packet. 723 Because a direct loopback format does not retain the original RTP 724 headers, there will be no indication of the original payload-type 725 sent to the mirror, in looped-back packets. Therefore, the 726 loopback source SHOULD only send one payload type per loopback RTP 727 session, if direct mode is used. 729 7.2.1 Usage of RTP Header fields 731 Payload Type (PT): The assignment of an RTP payload type for the 732 encapsulating packet format is outside the scope of this document; 733 it is either specified by the RTP profile under which this payload 734 format is used or more likely signaled dynamically out-of-band 735 (e.g., using SDP; Section 7.2.3 defines the name binding). 737 Marker (M) bit: Set to the value in the received packet. 739 Extension (X) bit: Defined by the RTP Profile used. 741 Sequence Number: The RTP sequence number SHOULD be generated by the 742 loopback-mirror in the usual manner with a constant random offset, 743 as per [RFC3550]. 745 Timestamp: The RTP timestamp denotes the sampling instant for when 746 the loopback-mirror is transmitting this packet to the 747 loopback-source. The same clock rate MUST be used as that of the 748 received RTP packet. The initial value of the timestamp SHOULD be 749 random for security reasons (see Section 5.1 of RFC 3550 750 [RFC3550]). 752 SSRC: set as described in RFC 3550 [RFC3550]. 754 CC and CSRC fields are used as described in RFC 3550 [RFC3550]. 756 7.2.2 RTP Payload Structure 758 This payload format does not define any payload specific headers. 759 The loopback-mirror simply copies the RTP payload data from the 760 payload portion of the RTP packet received from the loopback- 761 source. 763 7.2.3 Usage of SDP 765 The payload type number for the payload loopback stream can be 766 negotiated using a mechanism like SDP. There is no static payload 767 type assignment for the stream, so dynamic payload type numbers 768 MUST be used. The binding to the name is indicated by an rtpmap 769 attribute. The name used in this binding is "rtploopback". 771 The following is an example SDP fragment for direct loopback RTP 772 format. 774 m=audio 41352 RTP/AVP 112 775 a=rtpmap:112 rtploopback/8000 777 8. SRTP Behavior 779 Secure RTP [RFC3711] MAY be used for loopback sessions. SRTP 780 operates at a lower logical layer than RTP, and thus if both sides 781 negotiate to use SRTP, each side uses its own key, performs 782 encryption/decryption, authentication, etc. Therefore the loopback 783 function on the mirror occurs after the SRTP packet has been 784 decrypted and authenticated, as a normal cleartext RTP packet 785 without an MKI or authentication tag; once the cleartext RTP packet 786 or payload is mirrored - either at the media-layer, direct packet- 787 layer, or encapsulated packet-layer - it is encrypted by the mirror 788 using its own key. 790 In order to provide the same level of protection to both forward 791 and reverse media flows (media to and from the mirror), if SRTP is 792 used it MUST be used in both directions with the same properties. 794 9. RTCP Requirements 796 The use of the loopback attribute is intended for monitoring of 797 media quality of the session. Consequently the media performance 798 information should be exchanged between the offering and the 799 answering entities. An offering or answering agent that is 800 compliant to this specification SHOULD support RTCP per [RFC3550] 801 and RTCP-XR per RFC 3611 [RFC3611]. Furthermore, if the offerer or 802 answerer choose to support RTCP-XR, they SHOULD support RTCP-XR 803 Loss Run Length Encoding (RLE) report block, Duplicate RLE report 804 block, Statistics Summary report block, and VoIP Metric Reports 805 Block per Sections 4.1, 4.2, 4.6, and 4.7 of RFC 3611 [RFC3611]. 806 The offerer and the answerer MAY support other RTCP-XR reporting 807 blocks as defined by RFC 3611 [RFC3611]. 809 10. Congestion Control 811 All the participants in a media-level loopback session SHOULD 812 implement congestion control mechanisms as defined by the RTP 813 profile under which the loopback mechanism is implemented. For 814 audio video profiles, implementations SHOULD conform to the 815 mechanism defined in Section 2 of RFC 3551 [RFC3551]. 817 For packet-level loopback types, the loopback source SHOULD 818 implement congestion control. The mirror will simply reflect back 819 the RTP packets it receives (either in encapsulated or direct 820 modes), therefore the source needs to control the congestion of 821 both forward and reverse paths by reducing its sending rate to the 822 mirror. This keeps the loopback mirror implementation simpler, and 823 provides more flexibility for the source performing a loopback 824 test. 826 11. Examples 828 This section provides examples for media descriptions using SDP for 829 different scenarios. The examples are given for SIP-based 830 transactions and are abbreviated and do not show the complete 831 signaling for convenience. 833 11.1 Offer for specific media loopback type 835 An agent sends an SDP offer which looks like: 837 v=0 838 o=alice 2890844526 2890842807 IN IP4 host.atlanta.example.com 839 s=- 840 c=IN IP4 host.atlanta.example.com 841 t=0 0 842 m=audio 49170 RTP/AVP 0 843 a=loopback:rtp-media-loopback 844 a=loopback-source 845 a=rtpmap:0 pcmu/8000 847 The agent is offering to source the media and expects the answering 848 agent to mirror the RTP stream per rtp-media-loopback loopback 849 type. 851 An answering agent sends an SDP answer which looks like: 853 v=0 854 o=bob 1234567890 1122334455 IN IP4 host.biloxi.example.com 855 s=- 856 c=IN IP4 host.biloxi.example.com 857 t=0 0 858 m=audio 49270 RTP/AVP 0 859 a=loopback:rtp-media-loopback 860 a=loopback-mirror 861 a=rtpmap:0 pcmu/8000 863 The answerer is accepting to mirror the media from the offerer at 864 the media level. 866 11.2 Offer for choice of media loopback type 868 An agent sends an SDP offer which looks like: 870 v=0 871 o=alice 2890844526 2890842807 IN IP4 host.atlanta.example.com 872 s=- 873 c=IN IP4 host.atlanta.example.com 874 t=0 0 875 m=audio 49170 RTP/AVP 0 112 113 876 a=loopback:rtp-media-loopback rtp-pkt-loopback 877 a=loopback-source 878 a=rtpmap:0 pcmu/8000 879 a=rtpmap:112 encaprtp/8000 880 a=rtpmap:113 rtploopback/8000 882 The offerer is offering to source the media and expects the 883 answerer to mirror the RTP stream at either the media or rtp level. 885 An answering agent sends an SDP answer which looks like: 887 v=0 888 o=box 1234567890 1122334455 IN IP4 host.biloxi.example.com 889 s=- 890 c=IN IP4 host.biloxi.example.com 891 t=0 0 892 m=audio 49270 RTP/AVP 0 112 893 a=loopback:rtp-pkt-loopback 894 a=loopback-mirror 895 a=rtpmap:0 pcmu/8000 896 a=rtpmap:112 encaprtp/8000 898 The answerer is accepting to mirror the media from the offerer at 899 the packet level using the encapsulated RTP payload format. 901 11.3 Answerer rejecting loopback media 903 An agent sends an SDP offer which looks like: 905 v=0 906 o=alice 2890844526 2890842807 IN IP4 host.atlanta.example.com 907 s=- 908 c=IN IP4 host.atlanta.example.com 909 t=0 0 910 m=audio 49170 RTP/AVP 0 911 a=loopback:rtp-media-loopback 912 a=loopback-source 913 a=rtpmap:0 pcmu/8000 915 The offerer is offering to source the media and expects the 916 answerer to mirror the RTP stream at the media level. 918 An answering agent sends an SDP answer which looks like: 920 v=0 921 o=bob 1234567890 1122334455 IN IP4 host.biloxi.example.com 922 s=- 923 c=IN IP4 host.biloxi.example.com 924 t=0 0 925 m=audio 0 RTP/AVP 0 926 a=rtpmap:0 pcmu/8000 928 Note in this case the answerer did not indicate loopback support, 929 although it could have and still used a port number of 0 to 930 indicate it does not wish to accept that media session. 932 Alternatively, the answering agent could have simply rejected the 933 entire SDP offer through some higher-layer signaling protocol means 934 (e.g., by rejecting the SIP INVITE request if the SDP offer was in 935 the INVITE). 937 12. Security Considerations 939 The security considerations of [RFC3264] and [RFC3550] apply. 941 Given that media loopback may be automated without the end user's 942 knowledge, the answerer of the media loopback should be aware of 943 denial of service attacks. It is RECOMMENDED that session requests 944 for media loopback be authenticated and the frequency of such 945 sessions limited by the answerer. 947 If the higher-layer signaling protocol were not authenticated, a 948 malicious attacker could create a session between two parties the 949 attacker wishes to target, with each party acting as the loopback- 950 mirror to the other, of rtp-pkt-loopback type. A few RTP packets 951 sent to either party would then infinitely loop among the two, as 952 fast as they could process them, consuming their resources and 953 network bandwidth. 955 Furthermore, media-loopback provides a means of attack indirection, 956 whereby a malicious attacker creates a loopback session as the 957 loopback-source, and uses the mirror to reflect the attacker's 958 packets against a target - perhaps a target the attacker could not 959 reach directly, such as one behind a firewall for example. Or the 960 attacker could initiate the session as the loopback-mirror, in the 961 hopes of making the peer generate media against another target. 963 If end-user devices such as mobile phones answer loopback requests 964 without authentication and without notifying the end-user, then an 965 attacker could cause the battery to drain, and possibly deny the 966 end-user normal phone service or cause network data usage fees. 967 This could even occur naturally if a legitimate loopback session 968 does not terminate properly and the end device does not have a 969 timeout mechanism for such. 971 For the reasons noted above, end user devices SHOULD provide a 972 means of indicating to the human user that the device is in a 973 loopback session, even if it is an authenticated session. Devices 974 that answer or generate loopback sessions SHOULD either perform 975 keepalive/refresh tests of the session state through some means, or 976 time out the session automatically. 978 13. Implementation Considerations 980 The media loopback approach described in this document is a 981 complete solution that would work under all scenarios. However, it 982 is possible that the solution may not be light-weight enough for 983 some implementations. In light of this concern, this section 984 clarifies which features of the loopback proposal MUST be 985 implemented for all implementations and which features MAY be 986 deferred if the complete solution is not desired. 988 All implementations MUST at least support the rtp-pkt-loopback mode 989 for loopback-type, with direct media loopback payload encoding. In 990 addition, for the loopback role, all implementations of an SDP 991 offerer MUST at least be able to act as a loopback-source. These 992 requirements are intended to provide a minimal level of 993 interoperability between different implementations. 995 14. IANA Considerations 997 [Note to RFC Editor: Please replace "XXXX" with the appropriate RFC 998 number on publication] 1000 14.1 SDP Attributes 1002 This document defines three new media-level SDP attributes. IANA 1003 has registered the following attributes: 1005 Contact name: Kaynam Hedayat 1006 Email address: kaynam.hedayat@exfo.com 1007 Telephone number: +1-978-367-5611 1008 Attribute name: loopback 1009 Type of attribute: Media level. 1010 Subject to charset: No. 1011 Purpose of attribute: The 'loopback' attribute is used to 1012 indicate the type of media loopback. 1013 Allowed attribute values: The parameters to 'loopback' may be 1014 one or more of "rtp-pkt-loopback" and 1015 "rtp-media-loopback". See Section 5 1016 of RFC XXXX for syntax. 1018 Contact name: Kaynam Hedayat 1019 Email address: kaynam.hedayat@exfo.com 1020 Telephone number: +1-978-367-5611 1021 Attribute name: loopback-source 1022 Type of attribute: Media level. 1023 Subject to charset: No. 1024 Purpose of attribute: The 'loopback-source' attribute 1025 specifies that the sender is the media 1026 source and expects the receiver to act 1027 as a loopback-mirror. 1028 Allowed attribute values: None. 1030 Contact name: Kaynam Hedayat 1031 Email address: kaynam.hedayat@exfo.com 1032 Telephone number: +1-978-367-5611 1033 Attribute name: loopback-mirror 1034 Type of attribute: Media level. 1035 Subject to charset: No. 1036 Purpose of attribute: The 'loopback-mirror' attribute 1037 specifies that the receiver will 1038 mirror (echo) all received media back 1039 to the sender of the RTP stream. 1040 Allowed attribute values: None. 1042 14.2 Media Types 1044 The IANA has registered the following media types: 1046 14.2.1 audio/encaprtp 1048 To: ietf-types@iana.org 1050 Subject: Registration of media type audio/encaprtp 1052 Type name: audio 1054 Subtype name: encaprtp 1056 Required parameters: 1058 rate: RTP timestamp clock rate, which is equal to the 1059 sampling rate. The typical rate is 8000; other rates 1060 may be specified. This is specified by the loop back 1061 source, and reflected by the mirror. 1063 Optional parameters: none 1065 Encoding considerations: This media type is framed. 1067 Security considerations: See Section 12 of RFC XXXX. 1069 Interoperability considerations: none 1071 Published specification: RFC XXXX. 1073 Applications which use this media type: Applications wishing 1074 to monitor and ensure the quality of transport to the 1075 edge of a given VoIP Service. 1077 Additional information: none 1079 Contact: the authors of RFC XXXX. 1081 Intended usage: LIMITED USE 1083 Restrictions on usage: This media type depends on RTP 1084 framing, and hence is only defined for transfer via 1085 RTP. Transfer within other framing protocols is not 1086 defined at this time. 1088 Author: 1089 Kaynam Hedayat. 1091 Change controller: IETF PAYLOAD working 1092 group delegated from the IESG. 1094 14.2.2 video/encaprtp 1096 To: ietf-types@iana.org 1098 Subject: Registration of media type video/encaprtp 1100 Type name: video 1102 Subtype name: encaprtp 1104 Required parameters: 1106 rate: RTP timestamp clock rate, which is equal to the 1107 sampling rate. This is specified by the loop back 1108 source, and reflected by the mirror. 1110 Optional parameters: none 1112 Encoding considerations: This media type is framed. 1114 Security considerations: See Section 12 of RFC XXXX. 1116 Interoperability considerations: none 1118 Published specification: RFC XXXX. 1120 Applications which use this media type: Applications wishing 1121 to monitor and ensure the quality of transport to the 1122 edge of a given Video Over IP Service. 1124 Additional information: none 1126 Contact: the authors of RFC XXXX. 1128 Intended usage: LIMITED USE 1130 Restrictions on usage: This media type depends on RTP 1131 framing, and hence is only defined for transfer via 1132 RTP. Transfer within other framing protocols is not 1133 defined at this time. 1135 Author: 1136 Kaynam Hedayat. 1138 Change controller: IETF PAYLOAD working 1139 group delegated from the IESG. 1141 14.2.3 text/encaprtp 1143 To: ietf-types@iana.org 1145 Subject: Registration of media type text/encaprtp 1147 Type name: text 1149 Subtype name: encaprtp 1151 Required parameters: 1153 rate: RTP timestamp clock rate, which is equal to the 1154 sampling rate. This is specified by the loop back 1155 source, and reflected by the mirror. 1157 Optional parameters: none 1159 Encoding considerations: This media type is framed. 1161 Security considerations: See Section 12 of RFC XXXX. 1163 Interoperability considerations: none 1165 Published specification: RFC XXXX. 1167 Applications which use this media type: Applications wishing 1168 to monitor and ensure the quality of transport to the 1169 edge of a given Real-Time Text Service. 1171 Additional information: none 1173 Contact: the authors of RFC XXXX. 1175 Intended usage: LIMITED USE 1177 Restrictions on usage: This media type depends on RTP 1178 framing, and hence is only defined for transfer via 1179 RTP. Transfer within other framing protocols is not 1180 defined at this time. 1182 Author: 1183 Kaynam Hedayat. 1185 Change controller: IETF PAYLOAD working 1186 group delegated from the IESG. 1188 14.2.4 application/encaprtp 1190 To: ietf-types@iana.org 1192 Subject: Registration of media type 1193 application/encaprtp 1195 Type name: application 1197 Subtype name: encaprtp 1199 Required parameters: 1201 rate: RTP timestamp clock rate, which is equal to the 1202 sampling rate. This is specified by the loop back 1203 source, and reflected by the mirror. 1205 Optional parameters: none 1207 Encoding considerations: This media type is framed. 1209 Security considerations: See Section 12 of RFC XXXX. 1211 Interoperability considerations: none 1213 Published specification: RFC XXXX. 1215 Applications which use this media type: Applications wishing 1216 to monitor and ensure the quality of transport to the 1217 edge of a given Real-Time Application Service. 1219 Additional information: none 1221 Contact: the authors of RFC XXXX. 1223 Intended usage: LIMITED USE 1225 Restrictions on usage: This media type depends on RTP 1226 framing, and hence is only defined for transfer via 1227 RTP. Transfer within other framing protocols is not 1228 defined at this time. 1230 Author: 1231 Kaynam Hedayat. 1233 Change controller: IETF PAYLOAD working 1234 group delegated from the IESG. 1236 14.2.5 audio/rtploopback 1238 To: ietf-types@iana.org 1240 Subject: Registration of media type audio/rtploopback 1242 Type name: audio 1244 Subtype name: rtploopback 1246 Required parameters: 1248 rate:RTP timestamp clock rate, which is equal to the 1249 sampling rate. The typical rate is 8000; other rates 1250 may be specified. This is specified by the loop back 1251 source, and reflected by the mirror. 1253 Optional parameters: none 1255 Encoding considerations: This media type is framed. 1257 Security considerations: See Section 12 of RFC XXXX. 1259 Interoperability considerations: none 1261 Published specification: RFC XXXX. 1263 Applications which use this media type: Applications wishing 1264 to monitor and ensure the quality of transport to the 1265 edge of a given VoIP Service. 1267 Additional information: none 1269 Contact: the authors of RFC XXXX. 1271 Intended usage: LIMITED USE 1273 Restrictions on usage: This media type depends on RTP 1274 framing, and hence is only defined for transfer via 1275 RTP. Transfer within other framing protocols is not 1276 defined at this time. 1278 Author: 1279 Kaynam Hedayat. 1281 Change controller: IETF PAYLOAD working 1282 group delegated from the IESG. 1284 14.2.6 video/rtploopback 1286 To: ietf-types@iana.org 1288 Subject: Registration of media type video/rtploopback 1290 Type name: video 1292 Subtype name: rtploopback 1294 Required parameters: 1296 rate:RTP timestamp clock rate, which is equal to the 1297 sampling rate. This is specified by the loop back 1298 source, and reflected by the mirror. 1300 Optional parameters: none 1302 Encoding considerations: This media type is framed. 1304 Security considerations: See Section 12 of RFC XXXX. 1306 Interoperability considerations: none 1307 Published specification: RFC XXXX. 1309 Applications which use this media type: Applications wishing 1310 to monitor and ensure the quality of transport to the 1311 edge of a given Video Over IP Service. 1313 Additional information: none 1315 Contact: the authors of RFC XXXX. 1317 Intended usage: LIMITED USE 1319 Restrictions on usage: This media type depends on RTP 1320 framing, and hence is only defined for transfer via 1321 RTP. Transfer within other framing protocols is not 1322 defined at this time. 1324 Author: 1325 Kaynam Hedayat. 1327 Change controller: IETF PAYLOAD working 1328 group delegated from the IESG. 1330 14.2.7 text/rtploopback 1332 To: ietf-types@iana.org 1334 Subject: Registration of media type text/rtploopback 1336 Type name: text 1338 Subtype name: rtploopback 1340 Required parameters: 1342 rate:RTP timestamp clock rate, which is equal to the 1343 sampling rate. This is specified by the loop back 1344 source, and reflected by the mirror. 1346 Optional parameters: none 1348 Encoding considerations: This media type is framed. 1350 Security considerations: See Section 12 of RFC XXXX. 1352 Interoperability considerations: none 1354 Published specification: RFC XXXX. 1356 Applications which use this media type: Applications wishing 1357 to monitor and ensure the quality of transport to the 1358 edge of a given Real-Time Text Service. 1360 Additional information: none 1362 Contact: the authors of RFC XXXX. 1364 Intended usage: LIMITED USE 1366 Restrictions on usage: This media type depends on RTP 1367 framing, and hence is only defined for transfer via 1368 RTP. Transfer within other framing protocols is not 1369 defined at this time. 1371 Author: 1372 Kaynam Hedayat. 1374 Change controller: IETF PAYLOAD working 1375 group delegated from the IESG. 1377 14.2.8 application/rtploopback 1379 To: ietf-types@iana.org 1381 Subject: Registration of media type 1382 application/rtploopback 1384 Type name: application 1386 Subtype name: rtploopback 1388 Required parameters: 1390 rate:RTP timestamp clock rate, which is equal to the 1391 sampling rate. This is specified by the loop back 1392 source, and reflected by the mirror. 1394 Optional parameters: none 1396 Encoding considerations: This media type is framed. 1398 Security considerations: See Section 12 of RFC XXXX. 1400 Interoperability considerations: none 1402 Published specification: RFC XXXX. 1404 Applications which use this media type: Applications wishing 1405 to monitor and ensure the quality of transport to the 1406 edge of a given Real-Time Application Service. 1408 Additional information: none 1410 Contact: the authors of RFC XXXX. 1412 Intended usage: LIMITED USE 1414 Restrictions on usage: This media type depends on RTP 1415 framing, and hence is only defined for transfer via 1416 RTP. Transfer within other framing protocols is not 1417 defined at this time. 1419 Author: 1420 Kaynam Hedayat. 1422 Change controller: IETF PAYLOAD working 1423 group delegated from the IESG. 1425 15. Acknowledgements 1427 This document's editor would like to thank the original authors of 1428 the document: Kaynam Hedayat, Nagarjuna Venna, Paul E. Jones, Arjun 1429 Roychowdhury, Chelliah SivaChelvan, and Nathan Stratton. The 1430 editor has made fairly insignificant changes in the end. Also, 1431 we'd like to thank Magnus Westerlund, Miguel Garcia, Muthu Arul 1432 Mozhi Perumal, Jeff Bernstein, Paul Kyzivat, Dave Oran, Flemming 1433 Andreasen, Gunnar Hellstrom, Emil Ivov and Dan Wing for their 1434 feedback, comments and suggestions. 1436 16. Normative References 1438 [RFC2119] Bradner, S.,"Key words for use in RFCs to Indicate 1439 Requirement Levels", BCP 14, RFC 2119, March 1997. 1441 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer 1442 Model with the Session Description Protocol (SDP)", 1443 RFC 3264, June 2002. 1445 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. 1446 Jacobson, "RTP: A Transport Protocol for Real-Time 1447 Applications", STD 64, RFC 3550, July 2003. 1449 [RFC3551] Schulzrinne, H., Casner, S., "RTP Profile for Audio 1450 and Video Conferences with Minimial Control", STD 65, 1451 RFC 3551, July 2003. 1453 [RFC3611] Almeroth, K., Caceres, R., Clark, A., Cole, R., 1454 Duffield, N., Friedman, T., Hedayat, K., Sarac, K. 1455 and M. Westerlund, "RTP Control Protocol Extended 1456 Reports (RTCP XR)", RFC 3611, November 2003. 1458 [RFC3711] Baugher, M., et al, "The Secure Real-time Transport 1459 Protocol (SRTP)", RFC 3711, March 2004. 1461 [RFC4566] Handley, M., Jacobson, V., Perkins, C., "SDP: Session 1462 Description Protocol", RFC 4566, July 2006. 1464 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol 1465 (RTCP)", RFC 4961, July 2007. 1467 [RFC5234] Crocker, P. Overell, "Augmented ABNF for Syntax 1468 Specification: ABNF", RFC 5234, October 2005. 1470 17. Informative References 1472 [RFC5245] Rosenberg, J., "Interactive Connectivity 1473 Establishment (ICE): A Protocol for Network Address 1474 Translator (NAT) Traversal for Offer/Answer 1475 Protocols", RFC 5245, April 2010. 1477 [RFC6263] Marjou, X., Sollaud, A., "Application Mechanism for 1478 Keeping Alive the NAT Mappings Associated with RTP / 1479 RTP Control Protocol (RTCP) Flows", RFC 6263, June 1480 2011. 1482 Authors' Addresses 1484 Hadriel Kaplan 1485 Acme Packet 1486 100 Crosby Drive 1487 Bedford, MA 01730 1488 USA 1490 EMail: hkaplan@acmepacket.com 1491 URI: http://www.acmepacket.com 1492 Kaynam Hedayat 1493 EXFO 1494 285 Mill Road 1495 Chelmsford, MA 01824 1496 US 1498 EMail: kaynam.hedayat@exfo.com 1499 URI: http://www.exfo.com/ 1501 Nagarjuna Venna 1502 Saperix 1503 738 Main Street, #398 1504 Waltham, MA 02451 1505 US 1507 EMail: vnagarjuna@saperix.com 1508 URI: http://www.saperix.com/ 1510 Paul E. Jones 1511 Cisco Systems, Inc. 1512 7025 Kit Creek Rd. 1513 Research Triangle Park, NC 27709 1514 US 1516 EMail: paulej@packetizer.com 1517 URI: http://www.cisco.com/ 1519 Nathan Stratton 1520 BlinkMind, Inc. 1521 2027 Briarchester Dr. 1522 Katy, TX 77450 1524 EMail: nathan@robotics.net 1525 URI: http://www.robotics.net/