idnits 2.17.1 draft-ietf-mmusic-media-loopback-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 1) being 59 lines 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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 11, 2011) is 4767 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) == Unused Reference: 'RFC2119' is defined on line 1829, but no explicit reference was found in the text == Unused Reference: 'RFC2736' is defined on line 1832, but no explicit reference was found in the text == Unused Reference: 'RFC3551' is defined on line 1836, but no explicit reference was found in the text == Unused Reference: 'RFC4855' is defined on line 1843, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft K. Hedayat 3 Expires: September 11, 2011 EXFO 4 N. Venna 5 Saperix 6 P. Jones 7 Cisco Systems, Inc. 8 A. Roychowdhury 9 Hughes Systique Corp. 10 C. SivaChelvan 11 Cisco Systems, Inc. 12 N. Stratton 13 BlinkMind, Inc. 14 March 11, 2011 16 An Extension to the Session Description Protocol (SDP) for Media 17 Loopback 18 draft-ietf-mmusic-media-loopback-15 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with 23 the provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other 32 documents at any time. It is inappropriate to use Internet-Drafts 33 as reference material or to cite them other than as "work in 34 progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on Septembre 11, 2011. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with 54 respect to this document. Code Components extracted from this 55 document must include Simplified BSD License text as described in 56 Section 4.e of the Trust Legal Provisions and are provided without 57 warranty as described in the BSD License. 59 Abstract 61 The wide deployment of Voice over IP (VoIP), Real-time Text and 62 Video over IP services has introduced new challenges in managing 63 and maintaining voice/real-time Text/video quality, reliability, 64 and overall performance. In particular, media delivery is an area 65 that needs attention. One method of meeting these challenges is 66 monitoring the media delivery performance by looping media back to 67 the transmitter. This is typically referred to as "active 68 monitoring" of services. Media loopback is especially popular in 69 ensuring the quality of transport to the edge of a given VoIP, 70 Real-time Text or Video over IP service. Today in networks that 71 deliver real-time media, short of running 'ping' and 'traceroute' 72 to the edge, service providers are left without the necessary tools 73 to actively monitor, manage, and diagnose quality issues with their 74 service. The extension defined herein adds new SDP media 75 attributes which enables establishment of media sessions where the 76 media is looped back to the transmitter. Such media sessions will 77 serve as monitoring and troubleshooting tools by providing the 78 means for measurement of more advanced VoIP, Real-time Text and 79 Video over IP performance metrics. 81 Table of Contents 83 1. Introduction 84 .................................................. 3 85 1.1 Use Cases Supported 86 ....................................... 4 87 2. Terminology 88 ................................................... 6 89 3. Offering Entity Behavior 90 ...................................... 6 91 4. Answering Entity Behavior 92 ..................................... 6 93 5. SDP Constructs Syntax 94 ......................................... 7 95 5.1 Loopback Type Attribute 96 ................................... 7 98 5.2 Loopback Mode Attribute 99 ................................... 7 100 5.3 Generating the Offer for Loopback Session 101 ................. 8 102 5.4 Generating the Answer for Loopback Session 103 ................ 9 104 5.5 Offerer Processing of the Answer 105 ......................... 11 106 5.6 Modifying the Session 107 .................................... 12 108 5.7 Priming the loopback pump 109 ................................ 12 110 6. RTP Requirements 111 ............................................. 13 112 7. Payload formats for Packet loopback 113 .......................... 13 114 7.1 Encapsulated Payload format 115 .............................. 14 116 7.2 Direct loopback RTP payload format 117 ....................... 16 118 8. Payload format for Priming the Loopback Pump 119 ................. 18 120 8.1 Usage of RTP Header fields 121 ............................... 18 122 8.2 Usage of SDP 123 ............................................. 18 124 9. RTCP Requirements 125 ............................................ 18 126 10. Congestion Control 127 .......................................... 19 128 11. Examples 129 .................................................... 19 130 11.1 Offer for specific media loopback type 131 .................. 19 132 11.2 Offer for choice of media loopback type 133 ................. 20 134 11.3 Offer for choice of media loopback type with loopback 135 primer 136 ....................................................... 21 137 11.4 Response to INVITE request rejecting loopback media 138 ..... 22 139 11.5 Response to INVITE request rejecting loopback media with 140 loopback primer payload type 141 ................................. 23 142 12. Security Considerations 143 ..................................... 23 144 13. Implementation Considerations 145 ............................... 24 146 14. IANA Considerations 147 ......................................... 24 148 14.1 SDP Attributes 149 .......................................... 24 150 14.2 MIME Types 151 .............................................. 25 152 15. Additional Authors and Acknowledgements 153 ..................... 39 155 ........................................ 39 157 1. 158 Introduction 160 The overall quality, reliability, and performance of VoIP, 161 Real-time Text and Video over IP services rely on the performance 162 and quality of the media path. In order to assure the quality of 163 the delivered media there is a need to monitor the performance of 164 the media transport. One method of monitoring and managing the 165 overall quality of VoIP, Real-time Text and Video over IP Services 166 is through monitoring the quality of the media in an active 167 session. This type of "active monitoring" of services is a method 168 of proactively managing the performance and quality of VoIP based 169 services. 171 The goal of active monitoring is to measure the media quality of a 172 VoIP, Real-time Text or Video over IP session. A way to achieve 173 this goal is to request an endpoint to loop media back to the other 174 endpoint and to provide media statistics (e.g., RTCP and RTCP XR 175 information). Another method involves deployment of special 176 endpoints that always loop incoming media back for sessions. 177 Although the latter method has been used and is functional, it does 178 not scale to support large networks and introduces new network 179 management challenges. Further, it does not offer the granularity 180 of testing a specific endpoint that may be exhibiting problems. 182 The extension defined in this memo introduces new SDP media 183 attributes that enable establishment of media sessions where the 184 media is looped back to the transmitter. The offer/answer model 185 [RFC3264] is used to establish a loopback connection. Furthermore, 186 this extension provides guidelines on handling RTP [RFC3550], as 187 well as usage of RTCP [RFC3550] and RTCP XR [RFC3611] for reporting 188 media related measurements. 190 1.1 191 Use Cases Supported 193 As a matter of terminology in this document, packets flow from one 194 peer acting as a "loopback source", to the other peer acting as a 195 "loopback mirror", which in turn returns packets to the loopback 196 source. In advance of the session, the peers negotiate to determine 197 which one acts in which role. The negotiation also includes details 198 such as the type of loopback to be used. 200 This specification supports three use cases: "encapsulated packet 201 loopback", "direct loopback", and "media loopback". These are 202 distinguished by the treatment of incoming RTP packets at the 203 loopback mirror. 205 As a supplement to these use cases, this specification also allows 206 the loopback source to request the loopback mirror to begin sending 207 a media stream to the loopback source, ending when the mirror 208 begins to receive packets from the source. This facility is needed 209 in some circumstances to establish the media path through 210 middleboxes lying between the peers. 212 1.1.1 Encapsulated Packet Loopback 214 In the encapsulated packet loopback case, the entire incoming RTP 215 packet is encapsulated as payload within an outer payload type that 216 is specific to this use case and specified below (Section 7.1). 217 The encapsulated packet is returned to the loopback source. The 218 loopback source can generate statistics for one-way path 219 performance up to the RTP level for each direction of travel by 220 examining sequence numbers and timestamps in the outer header and 221 the encapsulated RTP packet payload. The loopback source can also 222 play back the returned media content for evaluation. 224 Because the encapsulating payload extends the packet size, it could 225 encounter difficulties in an environment where the original RTP 226 packet size is close to the path MTU size. The encapsulating 227 payload type therefore offers the possibility of RTP-level 228 fragmentation of the returned packets. The use of this facility 229 could affect statistics derived for the return path. In addition, 230 the increased bit rate required in the return direction may affect 231 these statistics more directly in a restricted-bandwidth situation. 233 1.1.2 Direct Loopback 235 In the direct loopback case, the loopback mirror copies the payload 236 of the incoming RTP packet into a new packet, the payload type of 237 which is again specific to this use case and specified below 238 (Section 7.2). The loopback mirror returns the new packet to the 239 packet source. There is no provision in this case for RTP-level 240 fragmentation. 242 This use case has the advantage of keeping the packet size the same 243 in both directions. The packet source can compute only two-way 244 path statistics from the direct loopback packet header, but can 245 play back the returned media content. 247 It has been suggested that the loopback source, knowing that the 248 incoming packet will never be passed to a decoder, can store a 249 timestamp and sequence number inside the payload of the packet it 250 sends to the mirror, then extract that information from the 251 returned direct loopback packet and compute one-way path statistics 252 as in the previous case. Obviously, playout of returned content is 253 no longer possible if this is done. 255 1.1.3 Media Loopback 257 In the media loopback case, the loopback mirror submits the 258 incoming packet to a decoder appropriate to the incoming payload 259 type. The packet is taken as close as possible to the analog level, 260 then reencoded according to an outgoing format determined by 261 negotiation. The reencoded content is returned to the loopback 262 source as an RTP packet with payload type corresponding to the 263 reencoding format. 265 This usage allows trouble-shooting at the codec level. The 266 capability for path statistics is limited to what is available from 267 RTCP reports. 269 2. 270 Terminology 272 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 273 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 274 this document are to be interpreted as described in RFC 2119. 276 3. 277 Offering Entity Behavior 279 An offering entity compliant to this memo and attempting to 280 establish a media session with media loopback MUST include 281 "loopback" media attributes for each individual media description 282 in the offer message. The offering entity MUST look for the 283 "loopback" media attributes in the media description(s) of the 284 response from the answering entity for confirmation that the 285 request is accepted. 287 4. 288 Answering Entity Behavior 290 An answering entity compliant to this specification and receiving 291 an offer containing media descriptions with the "loopback" media 292 attributes MUST acknowledge the request by including the received 293 "loopback" media attributes for each media description in its 294 response if it agrees to do the loopback. If the answerer does not 295 want to do loopback or wants to reject the "loopback" request for 296 specific media types, it MAY do so as defined in section 5.4.1 of 297 this specification. 299 An answering entity that is not compliant to this specification and 300 which receives an offer with the "loopback" media attributes MAY 301 ignore the attribute and treat the incoming offer as a normal 302 request. 304 5. 305 SDP Constructs Syntax 307 Two new media attributes are defined: one indicates the type of 308 loopback and the other indicates the mode of the loopback. 310 5.1 311 Loopback Type Attribute 313 The loopback type is a property media attribute with the following 314 syntax: 316 a=loopback: 318 Following is the Augmented BNF [RFC5234] for loopback-type: 320 loopback-type = loopback-choice [1*SP loopback-choice] 321 loopback-choice = loopback-type-pkt / loopback-type-media 322 loopback-type-pkt = "rtp-pkt-loopback" 323 loopback-type-media = "rtp-media-loopback" 325 The loopback type is used to indicate the type of loopback. The 326 loopback-type values are rtp-pkt-loopback, and rtp-media-loopback. 328 rtp-pkt-loopback: In this mode, the RTP packets are looped back to 329 the sender at a point before the encoder/decoder function in the 330 receive direction to a point after the encoder/decoder function in 331 the send direction. This effectively re-encapsulates the RTP 332 payload with the RTP/UDP/IP headers appropriate for sending it in 333 the reverse direction. Any type of encoding related functions, 334 such as packet loss concealment, MUST NOT be part of this type of 335 loopback path. In this mode the RTP packets are looped back with a 336 new payload type and format. Section 7 describes the payload 337 formats that MUST be used for this type of loopback. 339 rtp-media-loopback: This loopback is activated as close as possible 340 to the analog interface and after the decoder so that the RTP 341 packets are subsequently re-encoded prior to transmission back to 342 the sender. 344 5.2 345 Loopback Mode Attribute 347 The loopback mode is a value media attribute that is used to 348 indicate the mode of the loopback. These attributes are additional 349 mode attributes like sendonly, recvonly, etc. The syntax of the 350 loopback mode media attribute is: 352 a=:... 354 The loopback-mode values are loopback-source and loopback-mirror. 356 loopback-source: This attribute specifies that the entity that 357 generated the SDP is the media source and expects the receiver of 358 the SDP message to act as a loopback-mirror. 360 loopback-mirror: This attribute specifies that the entity that 361 generated the SDP will mirror (echo) all received media back to the 362 sender of the RTP stream. No media is generated locally by the 363 looping back entity for transmission in the mirrored stream unless 364 the loopback primer payload type (described in Section 8 of this 365 document) is requested by the loopback-source or included in the 366 response by loopback-mirror. 368 is a media format description. The format description has the 369 semantics as defined in section 5.14 of RFC 4566[RFC4566]. When 370 loopback-mode is specified as loopback-source, the media format 371 corresponds to the RTP payload types the entity that generated the 372 SDP is willing to send. When loopback-mode is specified as 373 loopback-mirror, the media format corresponds to the RTP payload 374 types the mirror is willing to receive. The "m=" line in the SDP 375 MUST include all the payload types that will be used during the 376 loopback session including those specified in the loopback-mode 377 attribute line. The complete payload space for the call is 378 specified in the "m=" line and the rtpmap attribute is used to map 379 from the payload type number to an encoding name denoting the 380 payload format to be used. 382 5.3 383 Generating the Offer for Loopback Session 385 If an offerer wishes to make a loopback request, it MUST include 386 both the loopback-type and loopback-mode parameters in a valid SDP 387 offer: 389 Example: m=audio 41352 RTP/AVP 0 8 100 390 a=loopback:rtp-media-loopback 391 a=loopback-source:0 8 100 392 a=rtpmap:0 pcmu/8000 393 a=rtpmap:8 pcma/8000 394 a=rtpmap:100 G7221/16000/1 396 Note: A loopback offer in a given media description MUST NOT 397 contain the standard mode attributes sendonly, recvonly, sendrecv, 398 or inactive. The loopback-mode attributes (loopback-source and 399 loopback-mirror) replace the standard attributes. 401 The offerer may offer more than one loopback-type in the SDP offer. 402 The port number and the address in the offer (m= line) indicate 403 where the offerer would like to send and receive the media stream. 404 The payload type numbers indicate the value of the payload the 405 offerer expects to send and receive. If the offerer is the 406 loopback-source, the subset of payload types indicated in the 407 a=loopback-source line are the payload types for the codecs the 408 offerer is willing to send. However, the answer might indicate a 409 different payload type number for the same codec in the loopback- 410 mirror line. In that case, the offerer MUST send the payload type 411 received in the answer. If the offerer is the loopback-mirror, the 412 subset of payload types indicated in the a=loopback-mirror line are 413 the payload types for the codecs the offerer is willing to receive. 415 If loopback-type is rtp-pkt-loopback, the loopback-mirror MUST send 416 and the loopback-source MUST receive the looped back packets 417 encoded in one of the two payload formats (encapsulated RTP or 418 payload loopback) as defined in section 7. 420 Example: m=audio 41352 RTP/AVP 0 8 112 421 a=loopback:rtp-pkt-loopback 422 a=loopback-source:0 8 423 a=rtpmap:112 encaprtp/8000 425 Example: m=audio 41352 RTP/AVP 0 8 112 426 a=loopback:rtp-pkt-loopback 427 a=loopback-source:0 8 428 a=rtpmap:112 rtploopback/8000 430 5.4 431 Generating the Answer for Loopback Session 433 As with the offer, a loopback answer in a given media description 434 MUST NOT contain the standard mode attributes sendonly, recvonly, 435 sendrecv, or inactive. The loopback-mode attributes (loopbackThe 436 port number and the address in the answer (m= line) indicate where 437 the answerer would like to receive the media stream. The payload 438 type numbers indicate the value of the payload types the answerer 439 expects to send and receive. If the offerer is the loopback- 440 source, the answerer MUST be a loopback-mirror and the subset of 441 payload types indicated in the a=loopback-mirror line are the 442 payload types for the codecs the answerer is willing to receive. 443 Similarly, if the offerere is the loopback-mirror, the answerer 444 MUST be aloopback-source and the subset of payload types indicated 445 in the a=loopback-source line are the payload types for the codecs 446 the answerer is willing to send. 448 If an answerer wishes to accept the loopback request it MUST 449 include both the loopback mode and loopback type attribute in the 450 answer. When a stream is offered with the loopback-source 451 attribute, the corresponding stream in the response MUST be 452 loopback-mirror and vice versa, provided that answerer is capable 453 of supporting the requested loopback-type. 455 For example, if the offer contains the loopback-source attribute: 457 m=audio 41352 RTP/AVP 0 8 458 a=loopback:rtp-media-loopback 459 a=loopback-source:0 8 461 The answer that is capable of supporting the offer MUST contain the 462 loopback-mirror attribute: 464 m=audio 41352 RTP/AVP 0 8 465 a=loopback:rtp-media-loopback 466 a=loopback-mirror:0 8 468 If a stream is offered with multiple loopback type attributes, the 469 answer MUST include only one of the loopback types that are 470 accepted by the answerer. The answerer SHOULD give preference to 471 the first loopback-type in the SDP offer. 473 For example, if the offer contains: 475 m=audio 41352 RTP/AVP 0 8 112 476 a=loopback:rtp-media-loopback rtp-pkt-loopback 477 a=loopback-source:0 8 478 a=rtpmap:112 encaprtp/8000 480 The answer that is capable of supporting the offer and chooses to 481 loopback the media using the rtp-media-loopback type MUST contain: 483 m=audio 41352 RTP/AVP 0 8 484 a=loopback:rtp-media-loopback 485 a=loopback-mirror:0 8 487 As specified in section 7, if the loopback-type is 488 rtp-pkt-loopback, either the encapsulated RTP payload format or 489 direct loopback RTP payload format MUST be used for looped back 490 packets. 492 For example, if the offer contains: 494 m=audio 41352 RTP/AVP 0 8 112 113 495 a=loopback:rtp-pkt-loopback 496 a=loopback-source:0 8 497 a=rtpmap:112 encaprtp/8000 498 a=rtpmap:113 rtploopback/8000 500 The answer that is capable of supporting the offer must contain one 501 of the following: 503 m=audio 41352 RTP/AVP 0 8 112 504 a=loopback:rtp-pkt-loopback 505 a=loopback-mirror:0 8 506 a=rtpmap:112 encaprtp/8000 508 m=audio 41352 RTP/AVP 0 8 113 509 a=loopback:rtp-pkt-loopback 510 a=loopback-mirror:0 8 511 a=rtpmap:113 rtploopback/8000 513 5.4.1 Rejecting the Loopback Offer 515 An offered stream (either with loopback-source or loopback-mirror) 516 MAY be rejected if the loopback-type is not specified, the 517 specified loopback-type is not supported, or the endpoint cannot 518 honor the offer for any other reason. The Loopback request may be 519 rejected by setting the media port number to zero in the answer as 520 per RFC 3264 [RFC3264]. 522 5.5 523 Offerer Processing of the Answer 525 The answer to a loopback-source MUST be loopback-mirror. The 526 answer to a loopback-mirror MUST be loopback-source. The 527 loopback-mode line MUST contain at least one codec the answerer is 528 willing to send or receive depending on whether it is the loopback- 529 source or the loopback-mirror. In addition, the "m=" line MUST 530 contain at least one codec that the answerer is willing to send or 531 receive depending on whether it is the loopback-mirror or the 532 loopback-source. 534 If the answer does not contain a=loopback-mirror or 535 a=loopback-source, it is assumed that the loopback extensions are 536 not supported by the target UA. 538 5.6 539 Modifying the Session 541 At any point during the loopback session, either participant may 542 issue a new offer to modify the characteristics of the previous 543 session. In case of SIP this is defined in section 8 of RFC 3264 544 [RFC3264]. This also includes transitioning from a normal media 545 processing mode to loopback mode, and vice a versa. 547 5.7 548 Priming the loopback pump 550 ICE/STUN/TURN provide a general solution to establishing media 551 sessions between entities that are behind NATs. Loopback sessions 552 that involve one or more end points behind NATs SHOULD use these 553 general solutions wherever possible. In scenarios where 554 ICE/STUN/TURN is not available and where the loopback-mirror is 555 behind a NAT and the loopback-source has a public IP address, the 556 following solution MAY be adapted. Note that this solution 557 addresses only a small subset of all possible use cases but 558 addresses the expected dominant use case for the loopback 559 application. 561 If only the loopback-mirror is behind a NAT, it is possible that 562 the media transmitted by the loopback-source is blocked by a 563 network element until the loopback-mirror starts transmitting 564 packets. One example of this scenario is the presence of an RTP 565 relay in the path of the media. RTP relays exist in VoIP networks 566 for purpose of NAT and Firewall traversal. If an RTP relay is 567 present, the loopback-source's packets are dropped by the RTP relay 568 until the loopback-mirror has started transmitting media and the 569 media state within the RTP relay is established. This results in a 570 chicken and egg scenario as the looback-mirror cannot transmit any 571 media until it receives the media packets from the loopback-source 572 but for the loopback-mirror to receive any packets it needs to send 573 one first. In order to resolve this dilemma, Section 8 introduces a 574 new media format whose sole purpose is to establish the media state 575 in the intermediate devices. In the presence of this media format, 576 the loopback-mirror will transmit media according to the payload 577 description until it receives media from the loopback-source. The 578 loopback-mirror MAY include this media format in the answer if it 579 is not present in the offer. This may be necessary if the 580 loopback-mirror is aware of NATs, firewalls, or RTP relays on the 581 path of the call. In this case the loopback-source MUST accept 582 media corresponding to this media format. After the first media 583 packet is received from the loopback-source, the loopback-mirror 584 MUST terminate the transmission of media for this payload type and 585 MUST start looping back media as defined by the other loopback 586 attributes present in the offer. 588 6. 589 RTP Requirements 591 A loopback-mirror that is compliant to this specification and 592 accepting a media with rtp-pkt-loopback loopback-type MUST loopback 593 the incoming RTP packets using either the encapsulated RTP payload 594 format or the direct loopback RTP payload format as defined in 595 section 7 of this specification. 597 An answering entity that is compliant to this specification and 598 accepting a media with the loopback type rtp-media-loopback MUST 599 transmit all received media back to the sender. The incoming media 600 MUST be treated as if it were to be played (e.g. the media stream 601 MAY receive treatment from PLC algorithms). The answering entity 602 MUST re-generate all the RTP header fields as it would when 603 transmitting media. The answering entity MAY choose to encode the 604 loopback media according to any of the media descriptions supported 605 by the offering entity. Furthermore, in cases where the same media 606 type is looped back, the answering entity MAY choose to preserve 607 number of frames/packet and bitrate of the encoded media according 608 to the received media. 610 7. 611 Payload formats for Packet loopback 613 The payload formats described in this section MUST be used by a 614 loopback-mirror when rtp-pkt-loopback is the specified 615 loopback-type. Two different formats are specified here - an 616 encapsulated RTP payload format and a direct loopback RTP payload 617 format. The encapsulated RTP payload format should be used when 618 the incoming RTP header information needs to be preserved during 619 the loopback operation. This is useful in cases where loopback 620 source needs to measure performance metrics in both directions. 621 However, this comes at the expense of increased packet size as 622 described in section 7.1. The direct loopback RTP payload format 623 should be used when bandwidth requirement prevents the use of 624 encapsulated RTP payload format. 626 To keep the implementation of loopback-mirrors simple it is 627 mandated that no payload format other than encapsulated or direct 628 loopback formats can be used in the packets generated by a 629 loopback-mirror. As described in RFC 3550 [RFC3550], sequence 630 numbers and timestamps in the RTP header are generated with initial 631 random values for security reasons. If this were not mandated and 632 the source payload is sequence number aware, the loopback-mirror 633 will be required to understand that payload format to generate 634 looped back packets that do not violate RFC 3550 [RFC3550]. 635 Requiring looped back packets to be in one of the two formats means 636 loopback-mirror does not have to look into the actual payload 637 received before generating the loopback packets. 639 7.1 640 Encapsulated Payload format 642 A received RTP packet is encapsulated in the payload section of the 643 RTP packet generated by a loopback-mirror. Each received packet 644 MUST be encapsulated in a different packet, the encapsulated packet 645 MUST be fragmented only if required (for example: due to MTU 646 limitations). 648 7.1.1 Usage of RTP Header fields 650 Payload Type (PT): The assignment of an RTP payload type for this 651 packet format is outside the scope of this document; it is either 652 specified by the RTP profile under which this payload format is 653 used or more likely signaled dynamically out-of-band (e.g., using 654 SDP; section 7.1.3 defines the name binding). 656 Marker (M) bit: If the received RTP packet is looped back in 657 multiple RTP packets, the M bit is set to 1 in the last packet, 658 otherwise it is set to 0. 660 Extension (X) bit: Defined by the RTP Profile used. 662 Sequence Number: The RTP sequence number SHOULD be generated by the 663 loopback-mirror in the usual manner with a constant random offset 664 as described in RFC 3550 [RFC3550]. 666 Timestamp: The RTP timestamp denotes the sampling instant for when 667 the loopback-mirror is transmitting this packet to the loopback- 668 source. The RTP timestamp MUST use the same clock rate used by the 669 loopback-source. The initial value of the timestamp SHOULD be 670 random for security reasons (see Section 5.1 of RFC 3550 671 [RFC3550]). 673 SSRC: set as described in RFC 3550 [RFC3550]. 675 CC and CSRC fields are used as described in RFC 3550 [RFC3550]. 677 7.1.2 RTP Payload Structure 679 The RTP header in the encapsulated packet MUST be followed by the 680 payload header defined in this section. If the received RTP packet 681 has to be looped back in multiple packets due to fragmentation, the 682 RTP header in each packet MUST be followed by the payload header 683 defined in this section. The header is devised so that the 684 loopback-source can decode looped back packets in the presence of 685 moderate packet loss [RFC3550]. 687 0 1 2 3 688 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 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | receive timestamp | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | F | R | CC |M| PT | sequence number | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | transmit timestamp | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | synchronization source (SSRC) identifier | 697 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 698 | contributing source (CSRC) identifiers | 699 | .... | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 The 12 octets after the receive timestamp are identical to the RTP 703 header in the received packet except for the first 4 bits of the 704 first octet. 706 Receive Timestamp: 32 bits 708 The Receive timestamp denotes the sampling instant for when the 709 last octet of the received media packet that is being encapsulated 710 by the loopback-mirror is received from the loopback-source. The 711 Receive timestamp MUST be based on the same clock used by the 712 loopback-source. The initial value of the timestamp SHOULD be 713 random for security reasons (see Section 5.1 of RFC 3550 714 [RFC3550]). 716 Fragmentation (F): 2 bits 717 First Fragment (00) /Last Fragment (01) /No Fragmentation(10)/ 718 Intermediate Fragment (11). This field identifies how much of the 719 received packet is encapsulated in this packet by the loopback- 720 mirror. If the received packet is not fragmented, this field is 721 set to 10; otherwise the packet that contains the first fragments 722 sets this field to 00, the packet that contains the last fragment 723 sets this field to 01, all other packets set this field to 11. 725 Reserved: 2 bits 727 This field is reserved for future definition. In the absence of 728 such a definition, the bits in this field MUST be set to zero and 729 MUST be ignored by the receiver. 731 Any padding octets in the original packet MUST NOT be included in 732 the loopback packet generated by a loopback-mirror. The 733 loopback-mirror MAY add padding octets if required. 735 7.1.3 Usage of SDP 737 The payload type number for the encapsulated stream can be 738 negotiated using a mechanism like SDP. There is no static payload 739 type assignment for the encapsulated stream, so dynamic payload 740 type numbers MUST be used. The binding to the name is indicated by 741 an rtpmap attribute. The name used in this binding is "encaprtp". 743 The following is an example SDP fragment for encapsulated RTP. 745 m=audio 41352 RTP/AVP 112 746 a=rtpmap:112 encaprtp/8000 748 7.2 749 Direct loopback RTP payload format 751 The direct loopback RTP payload format can be used in scenarios 752 where the 16 byte overhead of the encapsulated payload format is 753 significant. This payload format MUST NOT be used in cases where 754 the MTU on the loopback path will cause fragmentation of looped 755 back RTP packets. When using this payload format, the receiver 756 MUST loop back each received packet in a separate RTP packet. 758 7.2.1 Usage of RTP Header fields 759 Payload Type (PT): The assignment of an RTP payload type for this 760 packet format is outside the scope of this document; it is either 761 specified by the RTP profile under which this payload format is 762 used or more likely signaled dynamically out-of-band (e.g., using 763 SDP; section 7.2.3 defines the name binding). 765 Marker (M) bit: Set to the value in the received packet. 767 Extension (X) bit: Defined by the RTP Profile used. 769 Sequence Number: The RTP sequence number SHOULD be generated by the 770 loopback-mirror in the usual manner with a constant random offset. 772 Timestamp: The RTP timestamp denotes the sampling instant for when 773 the loopback-mirror is transmitting this packet to the 774 loopback-source. The RTP timestamp MUST be based on the same clock 775 used by the loopback-source. The initial value of the timestamp 776 SHOULD be random for security reasons (see Section 5.1 of RFC 3550 777 [RFC3550]). 779 SSRC: set as described in RFC 3550 [RFC3550]. 781 CC and CSRC fields are used as described in RFC 3550 [RFC3550]. 783 7.2.2 RTP Payload Structure 785 This payload format does not define any payload specific headers. 786 The loopback-mirror simply copies the payload data from the payload 787 portion of the packet received from the loopback-source. 789 7.2.3 Usage of SDP 791 The payload type number for the payload loopback stream can be 792 negotiated using a mechanism like SDP. There is no static payload 793 type assignment for the stream, so dynamic payload type numbers 794 MUST be used. The binding to the name is indicated by an rtpmap 795 attribute. The name used in this binding is "rtploopback". 797 The following is an example SDP fragment for direct loopback RTP 798 format. 800 m=audio 41352 RTP/AVP 112 801 a=rtpmap:112 rtploopback/8000 803 8. 804 Payload format for Priming the Loopback Pump 806 The sole purpose of the payload format described in this section is 807 to prime the loopback pump in cases where the loopback process 808 cannot start because of intermediate devices in the network as 809 described in Section 5.7. The loopback-mirror MAY send payload data 810 of any length and any content as it desires and the loopback-source 811 MUST NOT interpret the payload data. This payload format MUST NOT 812 be used for any purpose other than priming the loopback pump. 814 8.1 815 Usage of RTP Header fields 817 Payload Type (PT): The assignment of an RTP payload type for this 818 packet format is outside the scope of this document; it is either 819 specified by the RTP profile under which this payload format is 820 used or more likely signaled dynamically out-of-band (e.g., using 821 SDP; section 8.2 defines the name binding). 823 All other fields are set as described in RFC 3550 [RFC3550]. 825 8.2 826 Usage of SDP 828 The payload type number for the loopback primer stream can be 829 negotiated using a mechanism like SDP. There is no static payload 830 type assignment for the loopback primer stream, so dynamic payload 831 type numbers MUST be used. The binding to the name is indicated by 832 an rtpmap attribute. The name used in this binding is 833 "loopbkprimer". 835 The following is an example SDP fragment for loopback primer RTP 836 stream. 838 m=audio 41352 RTP/AVP 112 839 a=rtpmap:112 loopbkprimer/8000 841 9. 842 RTCP Requirements 844 The use of the loopback attribute is intended for monitoring of 845 media quality of the session. Consequently the media performance 846 information should be exchanged between the offering and the 847 answering entities. An offering or answering entity that is 848 compliant to this specification SHOULD support RTCP per [RFC3550] 849 and RTCP-XR per RFC 3611 [RFC3611]. Furthermore, if the client or 850 the server choose to support RTCP-XR, they SHOULD support RTCP-XR 851 Loss RLE report block, Duplicate RLE report block, Statistics 852 Summary report block, and VoIP Metric Reports Block per sections 853 4.1, 4.2, 4.6, and 4.7 of RFC 3611 [RFC3611]. The client and the 854 server MAY support other RTCP-XR reporting blocks as defined by RFC 855 3611 [RFC3611]. 857 10. 858 Congestion Control 860 All the participants in a loopback session SHOULD implement 861 congestion control mechanisms as defined by the RTP profile under 862 which the loopback mechanism is implemented. For audio video 863 profiles, implementations SHOULD conform to the mechanism defined 864 in Section 2 of RFC 3551. 866 11. 867 Examples 869 This section provides examples for media descriptions using SDP for 870 different scenarios. The examples are given for SIP-based 871 transactions and are abbreviated and do not show the complete 872 signaling for convenience. 874 11.1 875 Offer for specific media loopback type 877 A client sends an INVITE request with offer SDP which looks like: 879 v=0 880 o=alice 2890844526 2890842807 IN IP4 host.atlanta.example.com 881 s=Example 882 i=An example session 883 e=alice@example.com 884 c=IN IP4 host.atlanta.example.com 885 t=0 0 886 m=audio 49170 RTP/AVP 0 887 a=loopback:rtp-media-loopback 888 a=loopback-source:0 889 a=rtpmap:0 pcmu/8000 891 The client is offering to source the media and expects the server 892 to mirror the RTP stream per rtp-media-loopback loopback type. 894 A server sends a response with answer SDP which looks like: 896 v=0 897 o=bob 2890844526 2890842807 IN IP4 host.biloxi.example.com 898 s=Example 899 i=An example session 900 e=bob@example.com 901 c=IN IP4 host.biloxi.example.com 902 t=0 0 903 m=audio 49270 RTP/AVP 0 904 a=loopback:rtp-media-loopback 905 a=loopback-mirror:0 906 a=rtpmap:0 pcmu/8000 908 The server is accepting to mirror the media from the client at the 909 media level. 911 11.2 912 Offer for choice of media loopback type 914 A client sends an INVITE request with offer SDP which looks like: 916 v=0 917 o=alice 2890844526 2890842807 IN IP4 host.atlanta.example.com 918 s=Example 919 i=An example session 920 e=alice@example.com 921 c=IN IP4 host.atlanta.example.com 922 t=0 0 923 m=audio 49170 RTP/AVP 0 112 113 924 a=loopback:rtp-media-loopback rtp-pkt-loopback 925 a=loopback-source:0 926 a=rtpmap:0 pcmu/8000 927 a=rtpmap:112 encaprtp/8000 928 a=rtpmap:113 rtploopback/8000 930 The client is offering to source the media and expects the server 931 to mirror the RTP stream at either the media or rtp level. 933 A server sends a response with answer SDP which looks like: 935 v=0 936 o=box 2890844526 2890842807 IN IP4 host.biloxi.example.com 937 s=Example 938 i=An example session 939 e=bob@example.com 940 c=IN IP4 host.biloxi.example.com 941 t=0 0 942 m=audio 49270 RTP/AVP 0 112 943 a=loopback:rtp-pkt-loopback 944 a=loopback-mirror:0 945 a=rtpmap:0 pcmu/8000 946 a=rtpmap:112 encaprtp/8000 948 The server is accepting to mirror the media from the client at the 949 packet level using the encapsulated RTP payload format. 951 11.3 952 Offer for choice of media loopback type with loopback primer 954 A client sends an INVITE request with offer SDP which looks like: 956 v=0 957 o=alice 2890844526 2890842807 IN IP4 host.atlanta.example.com 958 s=Example 959 i=An example session 960 e=alice@example.com 961 c=IN IP4 host.atlanta.example.com 962 t=0 0 963 m=audio 49170 RTP/AVP 0 112 113 114 964 a=loopback:rtp-media-loopback rtp-pkt-loopback 965 a=loopback-source:0 966 a=rtpmap:0 pcmu/8000 967 a=rtpmap:112 encaprtp/8000 968 a=rtpmap:113 rtploopback/8000 969 a=rtpmap:114 loopbkprimer/8000 971 The client is offering to source the media and expects the server 972 to mirror the RTP stream at either the media or rtp level. The 973 client also expects the server to source media until it receives 974 packets from the server per media described with the loopbkprimer 975 payload type. 977 A server sends a response with SDP which looks like: 979 v=0 980 o=bob 2890844526 2890842807 IN IP4 host.biloxi.example.com 981 s=Example 982 i=An example session 983 e=user@example.com 984 c=IN IP4 host.biloxi.example.com 985 t=0 0 986 m=audio 49270 RTP/AVP 0 113 114 987 a=loopback:rtp-pkt-loopback 988 a=loopback-mirror:0 114 989 a=rtpmap:0 pcmu/8000 990 a=rtpmap:113 rtploopback/8000 991 a=rtmap:114 loopbkprimer/8000 993 The server is accepting to mirror the media from the client at the 994 packet level using the direct loopback RTP payload format. The 995 server is also accepting to source media until it receives media 996 packets from the client. 998 11.4 999 Response to INVITE request rejecting loopback media 1001 A client sends an INVITE request with offer SDP which looks like: 1003 v=0 1004 o=alice 2890844526 2890842807 IN IP4 host.atlanta.example.com 1005 s=Example 1006 i=An example session 1007 e=user@example.com 1008 c=IN IP4 host.atlanta.example.com 1009 t=0 0 1010 m=audio 49170 RTP/AVP 0 1011 a=loopback:rtp-media-loopback 1012 a=loopback-source:0 1013 a=rtpmap:0 pcmu/8000 1015 The client is offering to source the media and expects the server 1016 to mirror the RTP stream at the media level. 1018 A server sends a response with answer SDP which looks like: 1020 v=0 1021 o=bob 2890844526 2890842807 IN IP4 host.biloxi.example.com 1022 s=Example 1023 i=An example session 1024 e=user@example.com 1025 c=IN IP4 host.biloxi.example.com 1026 t=0 0 1027 m=audio 0 RTP/AVP 0 1028 a=loopback:rtp-media-loopback 1029 a=loopback-mirror:0 1030 a=rtpmap:0 pcmu/8000 1032 NOTE: Loopback request may be rejected by either not including the 1033 loopback mode attribute (for backward compatibility) or setting the 1034 media port number to zero, or both, in the response. 1036 11.5 1037 Response to INVITE request rejecting loopback media with 1038 loopback primer payload type 1040 A client sends an INVITE request with offer SDP which looks like: 1042 v=0 1043 o=alice 2890844526 2890842807 IN IP4 host.atlanta.example.com 1044 s=Example 1045 i=An example session 1046 e=alice@example.com 1047 c=IN IP4 host.atlanta.example.com 1048 t=0 0 1049 m=audio 49170 RTP/AVP 0 100 1050 a=loopback:rtp-media-loopback 1051 a=loopback-source:0 1052 a=rtpmap:0 pcmu/8000 1053 a=rtpmap:100 loopbkprimer/8000 1055 The client is offering to source the media and expects the server 1056 to mirror the RTP stream at the media level. The client (offerer) 1057 also expects the server (answerer) to source media until it 1058 receives packets from the server using the loopbkprimer payload 1059 type. 1061 A server sends a response with answer SDP which looks like: 1063 v=0 1064 o=bob 2890844526 2890842807 IN IP4 host.biloxi.example.com 1065 s=Example 1066 i=An example session 1067 e=bob@example.com 1068 c=IN IP4 host.biloxi.example.com 1069 t=0 0 1070 m=audio 0 RTP/AVP 0 1071 a=loopback:rtp-media-loopback 1072 a=loopback-mirror:0 1074 NOTE: Loopback request may be rejected by either not including the 1075 loopback mode attribute (for backward compatibility) or setting the 1076 media port number to zero, or both, in the response. 1078 12. 1079 Security Considerations 1081 The security considerations of [RFC3261] and [RFC3264] apply. 1082 Furthermore, given that media loopback may be automated without the 1083 end user's knowledge, the server of the media loopback should be 1084 aware of denial of service attacks. It is recommended that sessions 1085 with media loopback are authenticated and the frequency of such 1086 sessions is limited by the server. 1088 13. 1089 Implementation Considerations 1091 The media loopback approach described in this document is a 1092 complete solution that would work under all scenarios. However, it 1093 is believed that the solution may not be light-weight enough for 1094 the common case. In light of this concern, this section clarifies 1095 which features of the loopback proposal MUST be implemented for all 1096 implementations and which features MAY be deferred if the complete 1097 solution is not desired. 1099 All implementations MUST support the rtp-pkt-loopback option for 1100 loopback-type attribute. In addition, for the loopback-mode 1101 attribute, all implementations of an offerer MUST at a minimum be 1102 able to act as a loopback-source. All implementation MUST also at a 1103 minimum support the direct media loopback payload type. The rtp- 1104 media-loopback attribute MAY be implemented in complete 1105 implementations of this draft. 1107 14. 1108 IANA Considerations 1110 14.1 1111 SDP Attributes 1113 This document defines three new media-level SDP attributes. IANA 1114 has registered the following attributes: 1116 Contact name: Kaynam Hedayat 1117 . 1118 Attribute name: "loopback". 1119 Type of attribute: Media level. 1120 Subject to charset: No. 1121 Purpose of attribute: The 'loopback' attribute is used to 1122 indicate the type of media loopback. 1123 Allowed attribute values: The parameters to 'loopback' may be 1124 one or more of "rtp-pkt-loopback" and 1125 "rtp-media-loopback". See section 5 1126 of this document for syntax. 1128 Contact name: Kaynam Hedayat 1129 . 1130 Attribute name: "loopback-source". 1132 Type of attribute: Media level. 1133 Subject to charset: No. 1134 Purpose of attribute: The 'loopback-source' attribute 1135 specifies that the sender is the media 1136 source and expects the receiver to act 1137 as a loopback-mirror. 1138 Allowed attribute values: The parameter to 'loopback-source' is 1139 a media format ("") description 1140 as defined in RFC 4566 Section 5.14. 1142 Contact name: Kaynam Hedayat 1143 . 1144 Attribute name: "loopback-mirror". 1145 Type of attribute: Media level. 1146 Subject to charset: No. 1147 Purpose of attribute: The 'loopback-mirror' attribute 1148 specifies that the receiver will 1149 mirror (echo) all received media back 1150 to the sender of the RTP stream. 1151 Allowed attribute values: The parameter to 'loopback-mirror' is 1152 a media format ("") description 1153 as defined in RFC 4566 Section 5.14. 1155 14.2 1156 MIME Types 1158 The IANA has registered the following MIME types: 1160 14.2.1 audio/encaprtp 1162 To: ietf-types@iana.org 1164 Subject: Registration of media type audio/encaprtp 1166 Type name: audio 1168 Subtype name: encaprtp 1170 Required parameters: 1172 rate:RTP timestamp clock rate, which is equal to the 1173 sampling rate. The typical rate is 8000; other rates 1174 may be specified. 1176 Optional parameters: none 1178 Encoding considerations: This media type is framed 1179 binary data. 1181 Security considerations: See Section 12 of this document. 1183 Interoperability considerations: none 1185 Published specification: This MIME type is described fully 1186 within this document. 1188 Applications which use this media type: Applications wishing 1189 to monitor and ensure the quality of transport to the 1190 edge of a given VoIP, Real-Time Text or Video Over IP 1191 Service. 1193 Additional information: none 1195 Person & email address to contact for further information: 1197 Kaynam Hedayat 1198 EMail: kaynam.hedayat@exfo.com 1200 Intended usage: COMMON 1202 Restrictions on usage: This media type depends on RTP 1203 framing, and hence is only defined for transfer via 1204 RTP. Transfer within other framing protocols is not 1205 defined at this time. 1207 Author: 1208 Kaynam Hedayat. 1210 Change controller: IETF Audio/Video Transport working 1211 group delegated from the IESG. 1213 14.2.2 video/encaprtp 1215 To: ietf-types@iana.org 1217 Subject: Registration of media type video/encaprtp 1219 Type name: video 1221 Subtype name: encaprtp 1223 Required parameters: 1225 rate:RTP timestamp clock rate, which is equal to the 1226 sampling rate. The typical rate is 8000; other rates 1227 may be specified. 1229 Optional parameters: none 1231 Encoding considerations: This media type is framed 1232 binary data. 1234 Security considerations: See Section 12 of this document. 1236 Interoperability considerations: none 1238 Published specification: This MIME type is described fully 1239 within this document. 1241 Applications which use this media type: Applications wishing 1242 to monitor and ensure the quality of transport to the 1243 edge of a given VoIP, Real-Time Text or Video Over IP 1244 Service. 1246 Additional information: none 1248 Person & email address to contact for further information: 1250 Kaynam Hedayat 1251 EMail: kaynam.hedayat@exfo.com 1253 Intended usage: COMMON 1255 Restrictions on usage: This media type depends on RTP 1256 framing, and hence is only defined for transfer via 1257 RTP. Transfer within other framing protocols is not 1258 defined at this time. 1260 Author: 1261 Kaynam Hedayat. 1263 Change controller: IETF Audio/Video Transport working 1264 group delegated from the IESG. 1266 14.2.3 text/encaprtp 1268 To: ietf-types@iana.org 1270 Subject: Registration of media type text/encaprtp 1272 Type name: text 1273 Subtype name: encaprtp 1275 Required parameters: 1277 rate:RTP timestamp clock rate, which is equal to the 1278 sampling rate. The typical rate is 8000; other rates 1279 may be specified. 1281 Optional parameters: none 1283 Encoding considerations: This media type is framed 1284 binary data. 1286 Security considerations: See Section 12 of this document. 1288 Interoperability considerations: none 1290 Published specification: This MIME type is described fully 1291 within this document. 1293 Applications which use this media type: Applications wishing 1294 to monitor and ensure the quality of transport to the 1295 edge of a given VoIP, Real-Time Text or Video Over IP 1296 Service. 1298 Additional information: none 1300 Person & email address to contact for further information: 1302 Kaynam Hedayat 1303 EMail: kaynam.hedayat@exfo.com 1305 Intended usage: COMMON 1307 Restrictions on usage: This media type depends on RTP 1308 framing, and hence is only defined for transfer via 1309 RTP. Transfer within other framing protocols is not 1310 defined at this time. 1312 Author: 1313 Kaynam Hedayat. 1315 Change controller: IETF Audio/Video Transport working 1316 group delegated from the IESG. 1318 14.2.4 application/encaprtp 1319 To: ietf-types@iana.org 1321 Subject: Registration of media type 1322 application/encaprtp 1324 Type name: application 1326 Subtype name: encaprtp 1328 Required parameters: 1330 rate:RTP timestamp clock rate, which is equal to the 1331 sampling rate. The typical rate is 8000; other rates 1332 may be specified. 1334 Optional parameters: none 1336 Encoding considerations: This media type is framed 1337 binary data. 1339 Security considerations: See Section 12 of this document. 1341 Interoperability considerations: none 1343 Published specification: This MIME type is described fully 1344 within this document. 1346 Applications which use this media type: Applications wishing 1347 to monitor and ensure the quality of transport to the 1348 edge of a given VoIP, Real-Time Text or Video Over IP 1349 Service. 1351 Additional information: none 1353 Person & email address to contact for further information: 1355 Kaynam Hedayat 1356 EMail: kaynam.hedayat@exfo.com 1358 Intended usage: COMMON 1360 Restrictions on usage: This media type depends on RTP 1361 framing, and hence is only defined for transfer via 1362 RTP. Transfer within other framing protocols is not 1363 defined at this time. 1365 Author: 1366 Kaynam Hedayat. 1368 Change controller: IETF Audio/Video Transport working 1369 group delegated from the IESG. 1371 14.2.5 audio/rtploopback 1373 To: ietf-types@iana.org 1375 Subject: Registration of media type audio/rtploopback 1377 Type name: audio 1379 Subtype name: rtploopback 1381 Required parameters: 1383 rate:RTP timestamp clock rate, which is equal to the 1384 sampling rate. The typical rate is 8000; other rates 1385 may be specified. 1387 Optional parameters: none 1389 Encoding considerations: This media type is framed 1390 binary data. 1392 Security considerations: See Section 12 of this document. 1394 Interoperability considerations: none 1396 Published specification: This MIME type is described fully 1397 within this document. 1399 Applications which use this media type: Applications wishing 1400 to monitor and ensure the quality of transport to the 1401 edge of a given VoIP, Real-Time Text or Video Over IP 1402 Service. 1404 Additional information: none 1406 Person & email address to contact for further information: 1408 Kaynam Hedayat 1409 EMail: kaynam.hedayat@exfo.com 1411 Intended usage: COMMON 1413 Restrictions on usage: This media type depends on RTP 1414 framing, and hence is only defined for transfer via 1415 RTP. Transfer within other framing protocols is not 1416 defined at this time. 1418 Author: 1419 Kaynam Hedayat. 1421 Change controller: IETF Audio/Video Transport working 1422 group delegated from the IESG. 1424 14.2.6 video/rtploopback 1426 To: ietf-types@iana.org 1428 Subject: Registration of media type video/rtploopback 1430 Type name: video 1432 Subtype name: rtploopback 1434 Required parameters: 1436 rate:RTP timestamp clock rate, which is equal to the 1437 sampling rate. The typical rate is 8000; other rates 1438 may be specified. 1440 Optional parameters: none 1442 Encoding considerations: This media type is framed 1443 binary data. 1445 Security considerations: See Section 12 of this document. 1447 Interoperability considerations: none 1449 Published specification: This MIME type is described fully 1450 within this document. 1452 Applications which use this media type: Applications wishing 1453 to monitor and ensure the quality of transport to the 1454 edge of a given VoIP, Real-Time Text or Video Over IP 1455 Service. 1457 Additional information: none 1459 Person & email address to contact for further information: 1461 Kaynam Hedayat 1462 EMail: kaynam.hedayat@exfo.com 1464 Intended usage: COMMON 1465 Restrictions on usage: This media type depends on RTP 1466 framing, and hence is only defined for transfer via 1467 RTP. Transfer within other framing protocols is not 1468 defined at this time. 1470 Author: 1471 Kaynam Hedayat. 1473 Change controller: IETF Audio/Video Transport working 1474 group delegated from the IESG. 1476 14.2.7 text/rtploopback 1478 To: ietf-types@iana.org 1480 Subject: Registration of media type text/rtploopback 1482 Type name: text 1484 Subtype name: rtploopback 1486 Required parameters: 1488 rate:RTP timestamp clock rate, which is equal to the 1489 sampling rate. The typical rate is 8000; other rates 1490 may be specified. 1492 Optional parameters: none 1494 Encoding considerations: This media type is framed 1495 binary data. 1497 Security considerations: See Section 12 of this document. 1499 Interoperability considerations: none 1501 Published specification: This MIME type is described fully 1502 within this document. 1504 Applications which use this media type: Applications wishing 1505 to monitor and ensure the quality of transport to the 1506 edge of a given VoIP, Real-Time Text or Video Over IP 1507 Service. 1509 Additional information: none 1511 Person & email address to contact for further information: 1513 Kaynam Hedayat 1514 EMail: kaynam.hedayat@exfo.com 1516 Intended usage: COMMON 1518 Restrictions on usage: This media type depends on RTP 1519 framing, and hence is only defined for transfer via 1520 RTP. Transfer within other framing protocols is not 1521 defined at this time. 1523 Author: 1524 Kaynam Hedayat. 1526 Change controller: IETF Audio/Video Transport working 1527 group delegated from the IESG. 1529 14.2.8 application/rtploopback 1531 To: ietf-types@iana.org 1533 Subject: Registration of media type 1534 application/rtploopback 1536 Type name: application 1538 Subtype name: rtploopback 1540 Required parameters: 1542 rate:RTP timestamp clock rate, which is equal to the 1543 sampling rate. The typical rate is 8000; other rates 1544 may be specified. 1546 Optional parameters: none 1548 Encoding considerations: This media type is framed 1549 binary data. 1551 Security considerations: See Section 12 of this document. 1553 Interoperability considerations: none 1555 Published specification: This MIME type is described fully 1556 within this document. 1558 Applications which use this media type: Applications wishing 1559 to monitor and ensure the quality of transport to the 1560 edge of a given VoIP, Real-Time Text or Video Over IP 1561 Service. 1563 Additional information: none 1565 Person & email address to contact for further information: 1567 Kaynam Hedayat 1568 EMail: kaynam.hedayat@exfo.com 1570 Intended usage: COMMON 1572 Restrictions on usage: This media type depends on RTP 1573 framing, and hence is only defined for transfer via 1574 RTP. Transfer within other framing protocols is not 1575 defined at this time. 1577 Author: 1578 Kaynam Hedayat. 1580 Change controller: IETF Audio/Video Transport working 1581 group delegated from the IESG. 1583 14.2.9 audio/loopbkprimer 1585 To: ietf-types@iana.org 1587 Subject: Registration of media type audio/loopbkprimer 1589 Type name: audio 1591 Subtype name: loopbkprimer 1593 Required parameters: 1595 rate:RTP timestamp clock rate, which is equal to the 1596 sampling rate. The typical rate is 8000; other rates 1597 may be specified. 1599 Optional parameters: none 1601 Encoding considerations: This media type is framed 1602 binary data. 1604 Security considerations: See Section 12 of this document. 1606 Interoperability considerations: none 1607 Published specification: This MIME type is described fully 1608 within this document. 1610 Applications which use this media type: Applications wishing 1611 to monitor and ensure the quality of transport to the 1612 edge of a given VoIP, Real-Time Text or Video Over IP 1613 Service. 1615 Additional information: none 1617 Person & email address to contact for further information: 1619 Kaynam Hedayat 1620 EMail: kaynam.hedayat@exfo.com 1622 Intended usage: COMMON 1624 Restrictions on usage: This media type depends on RTP 1625 framing, and hence is only defined for transfer via 1626 RTP. Transfer within other framing protocols is not 1627 defined at this time. 1629 Author: 1630 Kaynam Hedayat. 1632 Change controller: IETF Audio/Video Transport working 1633 group delegated from the IESG. 1635 14.2.10 video/loopbkprimer 1637 To: ietf-types@iana.org 1639 Subject: Registration of media type video/loopbkprimer 1641 Type name: video 1643 Subtype name: loopbkprimer 1645 Required parameters: 1647 rate:RTP timestamp clock rate, which is equal to the 1648 sampling rate. The typical rate is 8000; other rates 1649 may be specified. 1651 Optional parameters: none 1653 Encoding considerations: This media type is framed 1654 binary data. 1656 Security considerations: See Section 12 of this document. 1658 Interoperability considerations: none 1660 Published specification: This MIME type is described fully 1661 within this document. 1663 Applications which use this media type: Applications wishing 1664 to monitor and ensure the quality of transport to the 1665 edge of a given VoIP, Real-Time Text or Video Over IP 1666 Service. 1668 Additional information: none 1670 Person & email address to contact for further information: 1672 Kaynam Hedayat 1673 EMail: kaynam.hedayat@exfo.com 1675 Intended usage: COMMON 1677 Restrictions on usage: This media type depends on RTP 1678 framing, and hence is only defined for transfer via 1679 RTP. Transfer within other framing protocols is not 1680 defined at this time. 1682 Author: 1683 Kaynam Hedayat. 1685 Change controller: IETF Audio/Video Transport working 1686 group delegated from the IESG. 1688 14.2.11 text/loopbkprimer 1690 To: ietf-types@iana.org 1692 Subject: Registration of media type text/loopbkprimer 1694 Type name: text 1696 Subtype name: encaprtp 1698 Required parameters: 1700 rate:RTP timestamp clock rate, which is equal to the 1701 sampling rate. The typical rate is 8000; other rates 1702 may be specified. 1704 Optional parameters: none 1706 Encoding considerations: This media type is framed 1707 binary data. 1709 Security considerations: See Section 12 of this document. 1711 Interoperability considerations: none 1713 Published specification: This MIME type is described fully 1714 within this document. 1716 Applications which use this media type: Applications wishing 1717 to monitor and ensure the quality of transport to the 1718 edge of a given VoIP, Real-Time Text or Video Over IP 1719 Service. 1721 Additional information: none 1723 Person & email address to contact for further information: 1725 Kaynam Hedayat 1726 EMail: kaynam.hedayat@exfo.com 1728 Intended usage: COMMON 1730 Restrictions on usage: This media type depends on RTP 1731 framing, and hence is only defined for transfer via 1732 RTP. Transfer within other framing protocols is not 1733 defined at this time. 1735 Author: 1736 Kaynam Hedayat. 1738 Change controller: IETF Audio/Video Transport working 1739 group delegated from the IESG. 1741 14.2.12 application/loopbkprimer 1743 To: ietf-types@iana.org 1745 Subject: Registration of media type 1746 application/loopbkprimer 1748 Type name: application 1750 Subtype name: loopbkprimer 1752 Required parameters: 1754 rate:RTP timestamp clock rate, which is equal to the 1755 sampling rate. The typical rate is 8000; other rates 1756 may be specified. 1758 Optional parameters: none 1760 Encoding considerations: This media type is framed 1761 binary data. 1763 Security considerations: See Section 12 of this document. 1765 Interoperability considerations: none 1767 Published specification: This MIME type is described fully 1768 within this document. 1770 Applications which use this media type: Applications wishing 1771 to monitor and ensure the quality of transport to the 1772 edge of a given VoIP, Real-Time Text or Video Over IP 1773 Service. 1775 Additional information: none 1777 Person & email address to contact for further information: 1779 Kaynam Hedayat 1780 EMail: kaynam.hedayat@exfo.com 1782 Intended usage: COMMON 1784 Restrictions on usage: This media type depends on RTP 1785 framing, and hence is only defined for transfer via 1786 RTP. Transfer within other framing protocols is not 1787 defined at this time. 1789 Author: 1790 Kaynam Hedayat. 1792 Change controller: IETF Audio/Video Transport working 1793 group delegated from the IESG. 1795 15. 1796 Additional Authors and Acknowledgements 1798 The following people have contributed to the task of authoring this 1799 document: Chelliah Sivachelvan (Cisco). 1801 The authors acknowledge the contributions and comments of , Muthu 1802 ArulMozhi Perumal, Flemming Andreasen, Jeff Bernstein, Paul 1803 Kyzivat, and Dave Oran. 1805 16. 1806 Normative References 1808 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., 1809 Johnston, A., Peterson, J., Sparks, R., Handley, M. 1810 and E. Schooler, "SIP: Session Initiation Protocol", 1811 RFC 3261, June 2002. 1813 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer 1814 Model with the Session Description Protocol (SDP)", 1815 RFC 3264, June 2002. 1817 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. 1818 Jacobson, "RTP: A Transport Protocol for Real-Time 1819 Applications", STD 64, RFC 3550, July 2003. 1821 [RFC3611] Almeroth, K., Caceres, R., Clark, A., Cole, R., 1822 Duffield, N., Friedman, T., Hedayat, K., Sarac, K. 1823 and M. Westerlund, "RTP Control Protocol Extended 1824 Reports (RTCP XR)", RFC 3611, November 2003. 1826 [RFC5234] Crocker, P. Overell, "Augmented ABNF for Syntax 1827 Specification: ABNF", RFC 5234, October 2005. 1829 [RFC2119] Bradner, S.,"Key words for use in RFCs to Indicate 1830 Requirement Levels", BCP 14, RFC 2119, March 1997. 1832 [RFC2736] Handley, M., Perkins, C., "Guidelines for Writers of 1833 RTP Payload Format Specifications", RFC 2736, BCP 1834 0036, December 1999. 1836 [RFC3551] Schulzrinne, H., Casner, S., "RTP Profile for Audio 1837 and Video Conferences with Minimial Control", STD 65, 1838 RFC 3551, July 2003. 1840 [RFC4566] Handley, M., Jacobson, V., Perkins, C., "SDP: Session 1841 Description Protocol", RFC 4566, July 2006. 1843 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 1844 Formats", RFC 4855, February 2007. 1846 Authors' Addresses 1848 Kaynam Hedayat 1849 EXFO 1850 285 Mill Road 1851 Chelmsford, MA 01824 1852 US 1854 Phone: +1 978 367 5611 1855 EMail: kaynam.hedayat@exfo.com 1856 URI: http://www.exfo.com/ 1858 Nagarjuna Venna 1859 Saperix 1860 738 Main Street, #398 1861 Waltham, MA 02451 1862 US 1864 Phone: +1 978 367 5703 1865 EMail: vnagarjuna@saperix.com 1866 URI: http://www.saperix.com/ 1868 Paul E. Jones 1869 Cisco Systems, Inc. 1870 7025 Kit Creek Rd. 1871 Research Triangle Park, NC 27709 1872 US 1874 Phone: +1 919 392 6948 1875 EMail: paulej@packetizer.com 1876 URI: http://www.cisco.com/ 1877 Arjun Roychowdhury 1878 Hughes Systique Corp. 1879 15245 Shady Grove Rd, Ste 330 1880 Rockville MD 20850 1881 US 1883 Phone: +1 301 527 1629 1884 EMail: arjun@hsc.com 1885 URI: http://www. hsc.com/ 1887 Chelliah SivaChelvan 1888 Cisco Systems, Inc. 1889 2200 East President George Bush Turnpike 1890 Richardson, TX 75082 1891 US 1893 Phone: +1 972 813 5224 1894 EMail: chelliah@cisco.com 1895 URI: http://www.cisco.com/ 1897 Nathan Stratton 1898 BlinkMind, Inc. 1899 2027 Briarchester Dr. 1900 Katy, TX 77450 1902 Phone: +1 832 330 3810 1903 EMail: nathan@robotics.net 1904 URI: http://www.robotics.net/