idnits 2.17.1 draft-westerlund-avtcore-multi-media-rtp-session-00.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 (Using the creation date from RFC3550, updated by this document, for RFC5378 checks: 1998-04-07) -- 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 (July 9, 2012) is 4309 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: 'RFCXXXX' is mentioned on line 412, but not defined == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-00 == Outdated reference: A later version (-03) exists of draft-westerlund-avtcore-multiplex-architecture-01 == Outdated reference: A later version (-07) exists of draft-westerlund-avtcore-transport-multiplexing-02 -- Obsolete informational reference (is this intentional?): RFC 2733 (Obsoleted by RFC 5109) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5117 (Obsoleted by RFC 7667) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVTCORE WG M. Westerlund 3 Internet-Draft Ericsson 4 Updates: 3550 (if approved) C. Perkins 5 Intended status: Standards Track University of Glasgow 6 Expires: January 10, 2013 J. Lennox 7 Vidyo 8 July 9, 2012 10 Multiple Media Types in an RTP Session 11 draft-westerlund-avtcore-multi-media-rtp-session-00 13 Abstract 15 This document specifies how an RTP session can contain media streams 16 with media from multiple media types such as audio, video, and text. 17 This has been restricted by the RTP Specification, and thus this 18 document updates RFC 3550 to enable this behavior for applications 19 that satisfy the applicability for using multiple media types in a 20 single RTP session. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 10, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 59 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. NAT and Firewalls . . . . . . . . . . . . . . . . . . . . 4 62 3.2. No Transport Level QoS . . . . . . . . . . . . . . . . . . 5 63 3.3. Architectural Equality . . . . . . . . . . . . . . . . . . 5 64 4. Overview of Solution . . . . . . . . . . . . . . . . . . . . . 5 65 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5.1. Usage of the RTP session . . . . . . . . . . . . . . . . . 6 67 5.2. Signalled Support . . . . . . . . . . . . . . . . . . . . 6 68 5.3. Homogeneous Multi-party . . . . . . . . . . . . . . . . . 7 69 5.4. Reduced number of Payload Types . . . . . . . . . . . . . 8 70 5.5. Stream Differentiation . . . . . . . . . . . . . . . . . . 8 71 5.6. Non-compatible Extensions . . . . . . . . . . . . . . . . 8 72 6. RTP Session Specification . . . . . . . . . . . . . . . . . . 9 73 6.1. RTP Session . . . . . . . . . . . . . . . . . . . . . . . 9 74 6.2. Sender Source Restrictions . . . . . . . . . . . . . . . . 10 75 6.3. Payload Type Applicability . . . . . . . . . . . . . . . . 10 76 6.4. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 7. Extension Considerations . . . . . . . . . . . . . . . . . . . 11 78 7.1. RTP Retransmission . . . . . . . . . . . . . . . . . . . . 12 79 7.2. Generic FEC . . . . . . . . . . . . . . . . . . . . . . . 12 80 8. Signalling . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 8.1. SDP-Based Signalling . . . . . . . . . . . . . . . . . . . 13 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 84 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14 87 12.2. Informative References . . . . . . . . . . . . . . . . . . 14 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 90 1. Introduction 92 When the Real-time Transport Protocol (RTP) [RFC3550] was designed, 93 close to 20 years ago, IP networks were very different compared to 94 the ones in 2012 when this is written. The almost ubiquitous 95 deployment of Network Address Translators (NAT) and Firewalls has 96 increased the cost and likely-hood of communication failure when 97 using many different transport flows. Thus there exists a pressure 98 to reduce the number of concurrent transport flows. 100 RTP [RFC3550] as defined recommends against having multiple media 101 types, like audio and video, in the same RTP session. The motivation 102 for this is dependent on particular usage or dependencies on lower 103 layer Quality of Service (QoS). When these aren't present, there are 104 no strong RTP reasons for not allowing multiple media types in one 105 RTP session. However, the Session Description Protocol (SDP) 106 [RFC4566], as one of the dominant signalling method for establishing 107 RTP session, has enforced this rule, by not allowing multiple media 108 types for a given receiver destination or set of ICE candidates, 109 which is the most common method to determine which RTP session the 110 packets are intended for. 112 The fact that these limitations have been in place for so long a 113 time, in addition to RFC 3550 being written without fully considering 114 multiple media types in an RTP session, does result in a number of 115 considerations being needed. This document provides such 116 considerations regarding applicability as well as functionality, 117 including normative specification of behavior. 119 First, some basic definitions are provided. This is followed by a 120 background that discusses the motivation in more detail. A overview 121 of the solution of how to provide multiple media types in one RTP 122 session is then presented. Next is the formal applicability this 123 specification have followed by the normative specification. This is 124 followed by a discussion how some RTP/RTCP Extensions should function 125 in the case of multiple media types in one RTP session. A 126 specification of the requirements on signalling from this 127 specification and a look how this is realized in SDP using Bundle 128 [I-D.ietf-mmusic-sdp-bundle-negotiation]. The document ends with the 129 security considerations. 131 2. Definitions 132 2.1. Requirements Language 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 2.2. Terminology 140 The following terms are used with supplied definitions: 142 Endpoint: A single entity sending or receiving RTP packets. It may 143 be decomposed into several functional blocks, but as long as it 144 behaves as a single RTP stack entity it is classified as a single 145 endpoint. 147 Media Stream: A sequence of RTP packets using a single SSRC that 148 together carries part or all of the content of a specific Media 149 Type from a specific sender source within a given RTP session. 151 Media Type: Audio, video, text or application whose form and meaning 152 are defined by a specific real-time application. 154 RTP Session: As defined by [RFC3550], the endpoints belonging to the 155 same RTP Session are those that share a single SSRC space. That 156 is, those endpoints can see an SSRC identifier transmitted by any 157 one of the other endpoints. An endpoint can receive an SSRC 158 either as SSRC or as CSRC in RTP and RTCP packets. Thus, the RTP 159 Session scope is decided by the endpoints' network interconnection 160 topology, in combination with RTP and RTCP forwarding strategies 161 deployed by endpoints and any interconnecting middle nodes. 163 3. Motivation 165 This section discusses in more detail the main motivations why 166 allowing multiple media types in the same RTP session is suitable. 168 3.1. NAT and Firewalls 170 The existence of NATs and Firewalls at almost all Internet access has 171 had implications on protocols like RTP that were designed to use 172 multiple transport flows. First of all, the NAT/FW traversal 173 solution one uses needs to ensure that all these transport flows are 174 established. This has three different impacts: 176 1. Increased delay to perform the transport flow establishment 178 2. The more transport flows, the more state and the more resource 179 consumption in the NAT and Firewalls. When the resource 180 consumption in NAT/FWs reaches their limits, unexpected behaviors 181 usually occur. 183 3. More transport flows means a higher risk that some transport flow 184 fails to be established, thus preventing the application to 185 communicate. 187 Using fewer transport flows reduces the risk of communication 188 failure, improved establishment behavior and less load on NAT and 189 Firewalls. 191 3.2. No Transport Level QoS 193 Many RTP-using applications don't utilize any network level Quality 194 of Service functions. Nor do they expect or desire any separation in 195 network treatment of its media packets, independent of whether they 196 are audio, video or text. When an application has no such desire, it 197 doesn't need to provide a transport flow structure that simplifies 198 flow based QoS. 200 3.3. Architectural Equality 202 For applications that don't desire any type of different treatment, 203 neither on the transport level nor in RTP or RTCP reporting, using 204 the same RTP session for both media types appears a reasonable 205 choice. The architecture should be neutral to media type, rather 206 look at what it provides based on the application users choice. 207 Therefore this bias should be removed and let the application 208 designer make the choice if they need multiple RTP sessions or not 209 based on other aspects. 211 4. Overview of Solution 213 The goal of the solution is to enable having one or more RTP 214 sessions, where each RTP session may contain two or more media types. 215 This includes having multiple RTP sessions containing a given media 216 type, for example having three sessions containing video and audio. 218 The solution is quite straightforward. The first step is to override 219 the SHOULD and SHOULD NOT language of the RTP specification 220 [RFC3550]. This is done by appropriate exception clauses given that 221 this specification is followed. 223 Within an RTP session where multiple media types have been configured 224 for use, a SSRC may only send one media type during its lifetime. 225 Different SSRCs must be used for the different media sources, the 226 same way multiple media sources of the same media type already have 227 to do. The payload type will inform a receiver which media type the 228 SSRC is being used for. Thus the payload type must be unique across 229 all of the payload configurations independent of media type that may 230 be used in the RTP session. 232 Some few extra considerations within the RTP sessions also needs to 233 be considered. RTCP bandwidth and regular reporting suppression 234 (AVPF and SAVPF) should be considered to be configured. Certain 235 payload types like FEC also need additional rules. 237 The final important part of the solution to this is to use signalling 238 and ensure that agreement on using multiple media types in an RTP 239 session exists, and how that then is configured. Thus document 240 documents some existing requirements, while an external reference 241 defines how this is accomplished in SDP. 243 5. Applicability 245 This specification has limited applicability and any one intending to 246 use must ensure that their application and usage meets the below 247 criteria for usage. 249 5.1. Usage of the RTP session 251 Before choosing to use this specification, an application implementer 252 needs to ensure that they don't have a need for different RTP 253 sessions between the media types for some reason. The main rule is 254 that if one expects to have equal treatment of all media packets, 255 then this specification might be suitable. The equal treatment 256 include anything from network level up to RTCP reporting and 257 feedback. The document Guidance on RTP Multiplexing Architecture 258 [I-D.westerlund-avtcore-multiplex-architecture] gives more detailed 259 guidance on aspects to consider when choosing how to use RTP and 260 specifically sessions. RTP-using applications that need or would 261 prefer multiple RTP sessions, but do not require the functionalities 262 or behaviors that multiple transport flows give, can consider using 263 Multiple RTP Sessions on a Single Lower-Layer Transport 264 [I-D.westerlund-avtcore-transport-multiplexing]. 266 5.2. Signalled Support 268 Usage of this specification is not compatible with anyone following 269 RFC 3550 and intending to have different RTP sessions for each media 270 type. Therefore there must be mutual agreement to use multiple media 271 types in one RTP session by all participants within an RTP session. 272 This agreement must in most cases be determined using signalling. 274 This requirement can be a problem for signalling solutions that can't 275 negotiate with all participants. For declarative signalling 276 solutions, mandating that the session is using multiple media types 277 in one RTP session can be a way of attempting to ensure that all 278 participants in the RTP session follow the requirement. However, for 279 signalling solutions that lack methods for enforcing that a receiver 280 supports a specific feature, this can still cause issues. 282 5.3. Homogeneous Multi-party 284 In multiparty communication scenarios it is important to separate two 285 different cases. One case is where the RTP session contains multiple 286 participants in a common RTP session. This occurs for example in Any 287 Source Multicast (ASM) and Transport Translator topologies as defined 288 in RTP Topologies [RFC5117]. It may also occur in some 289 implementations of RTP mixers that share the same SSRC/CSRC space 290 across all participants. The second case is when the RTP session is 291 terminated in a middlebox and the other participants sources are 292 projected or switched into each RTP session and rewritten on RTP 293 header level including SSRC mappings. 295 For the first case, with a common RTP session or at least shared 296 SSRC/CSRC values, all participants in multiparty communication are 297 required to support multiple media types in an RTP session. An 298 participant using two or more RTP sessions towards a multiparty 299 session can't be collapsed into a single session with multiple media 300 types. The reason is that in case of multiple RTP sessions, the same 301 SSRC value can be use in both RTP sessions without any issues, but 302 when collapsed to a single session there is an SSRC collision. In 303 addition some collisions can't be represented in the multiple 304 separate RTP sessions. For example, in a session with audio and 305 video, an SSRC value used for video will not show up in the Audio RTP 306 session at the participant using multiple RTP sessions, and thus not 307 trigger any collision handling. Thus any application using this type 308 of RTP session structure must have a homogeneous support for multiple 309 media types in one RTP session, or be forced to insert a translator 310 node between that participant and the rest of the RTP session. 312 For the second case of separate RTP sessions for each multiparty 313 participant and a central node it is possible to have a mix of single 314 RTP session users and multiple RTP session users as long as one is 315 willing to remap the SSRCs used by a participant with multiple RTP 316 sessions into non-used values in the single RTP session SSRC space 317 for each of the participants using a single RTP session with multiple 318 media types. It can be noted that this type of implementation is 319 required to understand any type of RTP/RTCP extension being used in 320 the RTP sessions to correctly be able to translate them between the 321 RTP sessions. 323 5.4. Reduced number of Payload Types 325 An RTP session with multiple media types in it have only a single 326 7-bit Payload Type range for all its payload types. Within the 128 327 available values, only 96 or less if "Multiplexing RTP Data and 328 Control Packets on a Single Port" [RFC5761] is used, all the 329 different RTP payload configurations for all the media types must 330 fit. For most applications this will not be a real problem, but the 331 limitation exists and could be encountered. 333 5.5. Stream Differentiation 335 If network level differentiation of the media streams of different 336 media types are desired using this specification can cause severe 337 limitations. All media streams in an RTP session, independent of the 338 media type, will be sent over the same underlying transport flow. 339 Any flow-based Quality of Service (QoS) mechanism will be unable to 340 provide differentiated treatment between different media types, e.g. 341 to prioritize audio over video. If that is desired, separate RTP 342 sessions over different underlying transport flows needs to be used. 343 Any marking-based QoS scheme like DiffServ is not affected unless a 344 network ingress marks based on flows. 346 5.6. Non-compatible Extensions 348 There exist some RTP and RTCP extensions that rely on the existence 349 of multiple RTP sessions. If the goal of using an RTP session with 350 multiple media types is to have only a single RTP session, then these 351 extensions can't be used. If one has no need to have different RTP 352 sessions for the media types but is willing to have multiple RTP 353 sessions, one for the main media transmission and one for the 354 extension, they can be used. It should be noted that this assumes 355 that it is possible to get the extension working when the related RTP 356 session contains multiple media types. 358 Identified RTP/RTCP extensions that require multiple RTP Sessions 359 are: 361 RTP Retransmission: RTP Retransmission [RFC4588] has a session 362 multiplexed mode. It also has a SSRC multiplexed mode that can be 363 used instead. So use the mode that is suitable for the RTP 364 application. 366 XOR-Based FEC: The RTP Payload Format for Generic Forward Error 367 Correction [RFC5109] and its predecessor [RFC2733] requires a 368 separate RTP session unless the FEC data is carried in RTP Payload 369 for Redundant Audio Data [RFC2198] which has another set of 370 restrictions. 372 Note that the Source-Specific Media Attributes [RFC5576] 373 specification defines an SDP syntax (the "FEC" semantic of the 374 "ssrc-group" attribute) to signal FEC relationships between 375 multiple media streams within a single RTP session. However, this 376 can't be used as the FEC repair packets are required to have the 377 same SSRC value as the source packets being protected. [RFC5576] 378 does not normatively update and resolve that restriction. 380 6. RTP Session Specification 382 This section defines what needs to be done or avoided to make an RTP 383 session with multiple media types function without issues. 385 6.1. RTP Session 387 Section 5.2 of "RTP: A Transport Protocol for Real-Time Applications" 388 [RFC3550] states: 390 For example, in a teleconference composed of audio and video media 391 encoded separately, each medium SHOULD be carried in a separate 392 RTP session with its own destination transport address. 394 Separate audio and video streams SHOULD NOT be carried in a single 395 RTP session and demultiplexed based on the payload type or SSRC 396 fields. 398 This specification changes both of these sentences. The first 399 sentence is changed to: 401 For example, in a teleconference composed of audio and video media 402 encoded separately, each medium SHOULD be carried in a separate 403 RTP session with its own destination transport address, unless 404 specification [RFCXXXX] is followed and the application meets the 405 applicability constraints. 407 The second sentence is changed to: 409 Separate audio and video streams SHOULD NOT be carried in a single 410 RTP session and demultiplexed based on the payload type or SSRC 411 fields, unless multiplexed based on both SSRC and payload type and 412 usage meets what Multiple Media Types in an RTP Session [RFCXXXX] 413 specifies. 415 RFC-Editor Note: Please replace RFCXXXX with the RFC number of this 416 specification when assigned. 418 TBD: Discussion of the motivations in Section 5.2 of the RTP 419 Specification [RFC3550]. 421 6.2. Sender Source Restrictions 423 A SSRC in the RTP session MUST only send one media type (audio, 424 video, text etc.) during the SSRC's lifetime. The main motivation is 425 that a given SSRC has its own RTP timestamp and sequence number 426 spaces. The same way that you can't send two streams of encoded 427 audio on the same SSRC, you can't send one audio and one video 428 encoding on the same SSRC. Each media encoding when made into an RTP 429 stream needs to have the sole control over the sequence number and 430 timestamp space. If not, one would not be able to detect packet loss 431 for that particular stream. Nor can one easily determine which clock 432 rate a particular SSRCs timestamp shall increase with. 434 6.3. Payload Type Applicability 436 Most Payload Types have a native media type, like an audio codec is 437 natural belonging to the audio media type. However, there exist a 438 number of RTP payload types that don't have a native media type. For 439 example, transport robustification mechanisms like RTP Retransmission 440 [RFC4588] and Generic FEC [RFC5109] inherit their media type from 441 what they protect. RTP Retransmission is explicitly bound to the 442 payload type it is protecting, and thus will inherit it. However 443 Generic FEC is a excellent example of an RTP payload type that has no 444 natural media type. The media type for what it protects is not 445 relevant as it is the recovered RTP packets that have a particular 446 media type, and thus Generic FEC is best categorized as an 447 application media type. 449 The above discussion is relevant to what limitations exist for RTP 450 payload type usage within an RTP session that has multiple media 451 types. When it comes to Generic FEC, is an configured payload type 452 allowed to be used to protect both audio SSRCs and Video SSRCs? Note 453 a particular SSRC carrying Generic FEC will clearly only protect a 454 specific SSRC and thus that instance is bound to the SSRC's media 455 type. For this specific case, it appears possible to have one be 456 applicable to both. However, in cases when the signalling is setup 457 to enable fallback to using separate RTP sessions, then using a 458 different media type, e.g. application, than the media being 459 protected can create issues. 461 TBD: What recommendations are needed here? 463 6.4. RTCP 465 All SSRCs in an RTP session fall under the same set of RTCP 466 configuration parameters, such as the RR and RS bandwidth and the 467 trr-int parameter if AVPF or SAVPF is used. This means that at least 468 the regular reporting period by, and on, a source will be equal, 469 independent of the media type for that source. This should in most 470 cases not be an issue, but it may result in more frequent reporting 471 than is considered necessary for a particular media type or set of 472 media sources. Having multiple media types in one RTP session also 473 results in more SSRCs being present in this RTP session. This 474 increasing the amount of cross reporting between the SSRCs. From an 475 RTCP perspective, two RTP sessions with half the number of SSRCs in 476 each will be slightly more efficient. If someone needs either the 477 higher efficiency due to the lesser number of SSRCs or the fact that 478 one can't tailor RTCP usage per media type, they need to use 479 independent RTP sessions. 481 When it comes to handling multiple SSRCs in an RTP session there is a 482 clarification under discussion in Real-Time Transport Protocol (RTP) 483 Considerations for Multi-Stream Endpoints 484 [I-D.lennox-avtcore-rtp-multi-stream]. When it comes to configuring 485 RTCP the need for regular periodic reporting needs to be weighted 486 against any feedback or control messages being sent. The 487 applications using AVPF or SAVPF are RECOMMENDED to consider setting 488 trr-int parameter to a value suitable for the applications needs, 489 thus potentially reducing the need for regular reporting and thus 490 releasing more bandwidth for use for feedback or control. 492 Another aspect of an RTP session with multiple media types is that 493 the used RTCP packets, RTCP Feedback Messages, or RTCP XR metrics 494 used may not be applicable to all media types. Instead all RTP/RTCP 495 endpoints need to correlate the media type of the SSRC being 496 referenced in an messages/packet and only use those that apply to 497 that particular SSRC and its media type. Signalling solutions may 498 have shortcomings when it comes to indicate that a particular set of 499 RTCP reports or feedback messages only apply to a particular media 500 type within an RTP session. 502 7. Extension Considerations 504 This section discusses the impact on some RTP/RTCP extensions due to 505 usage of multiple media types in on RTP session. Only extensions 506 where something worth noting has been included. 508 7.1. RTP Retransmission 510 SSRC-multiplexed RTP retransmission [RFC4588] is actually very 511 straightforward. Each retransmission RTP payload type is explicitly 512 connected to an associated payload type. If retransmission is only 513 to be used with a subset of all payload types, this is not a problem, 514 as it will be evident from the retransmission payload types which 515 payload types that have retransmission enabled for them. 517 Session-multiplexed RTP retransmission is also possible to use where 518 an retransmission session contains the retransmissions of the 519 associated payload types in the source RTP session. The only 520 difference to previously is that the source RTP session is one which 521 contains multiple media types. Thus it is even more likely that only 522 a subset of the source RTP session's payload types and SSRCs are 523 actually retransmitted. 525 Open Issue: When using SDP to signal retransmission for one RTP 526 session with multiple media types and one RTP session for the 527 retransmission data will cause a situation where one will have 528 multiple m= lines grouped using FID and the ones belonging to 529 respective RTP session being grouped using BUNDLE. This usage may 530 contradict both the FID semantics [RFC5888] and an assumption in the 531 RTP retransmission specification [RFC4588]. 533 7.2. Generic FEC 535 TBW: 537 8. Signalling 539 The Signalling requirements 541 Establishing an RTP session with multiple media types requires 542 signalling. This signalling needs to fulfill the following 543 requirements: 545 1. Ensure that any participant in the RTP session is aware that this 546 is an RTP session with multiple media types. 548 2. Ensure that the payload types in use in the RTP session are using 549 unique values, with no overlap between the media types. 551 3. Configure the RTP session level parameters, such as RTCP RR and 552 RS bandwidth, AVPF trr-int, underlying transport, the RTCP 553 extensions in use, and security parameters, commonly for the RTP 554 session. 556 4. RTP and RTCP functions that can be bound to a particular media 557 type should be reused when possible also for other media types, 558 instead of having to be configured for multiple code-points. 559 Note: In some cases one will not have a choice but to use 560 multiple configurations. 562 8.1. SDP-Based Signalling 564 The signalling of multiple media types in one RTP session in SDP is 565 specified in "Multiplexing Negotiation Using Session Description 566 Protocol (SDP) Port Numbers" 567 [I-D.ietf-mmusic-sdp-bundle-negotiation]. 569 9. IANA Considerations 571 This document makes no request of IANA. 573 Note to RFC Editor: this section may be removed on publication as an 574 RFC. 576 10. Security Considerations 578 Having an RTP session with multiple media types doesn't change the 579 methods for securing a particular RTP session. One possible 580 difference is that the different media have often had different 581 security requirements. When combining multiple media types in one 582 session, their security requirements must also be combined by 583 selecting the most demanding for each property. Thus having multiple 584 media types may result in increased overhead for security for some 585 media types to ensure that all requirements are meet. 587 Otherwise, the recommendations for how to configure and RTP session 588 do not add any additional requirements compared to normal RTP, except 589 for the need to be able to ensure that the participants are aware 590 that it is a multiple media type session. If not that is ensured it 591 can cause issues in the RTP session for both the unaware and the 592 aware one. Similar issues can also be produced in an normal RTP 593 session by creating configurations for different end-points that 594 doesn't match each other. 596 11. Acknowledgements 598 The authors would like to thank Christer Holmberg for the feedback on 599 the document. 601 12. References 603 12.1. Normative References 605 [I-D.ietf-mmusic-sdp-bundle-negotiation] 606 Holmberg, C. and H. Alvestrand, "Multiplexing Negotiation 607 Using Session Description Protocol (SDP) Port Numbers", 608 draft-ietf-mmusic-sdp-bundle-negotiation-00 (work in 609 progress), February 2012. 611 [I-D.lennox-avtcore-rtp-multi-stream] 612 Lennox, J. and M. Westerlund, "Real-Time Transport 613 Protocol (RTP) Considerations for Multi-Stream Endpoints", 614 July 2012. 616 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 617 Requirement Levels", BCP 14, RFC 2119, March 1997. 619 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 620 Jacobson, "RTP: A Transport Protocol for Real-Time 621 Applications", STD 64, RFC 3550, July 2003. 623 12.2. Informative References 625 [I-D.westerlund-avtcore-multiplex-architecture] 626 Westerlund, M., Burman, B., and C. Perkins, "RTP 627 Multiplexing Architecture", 628 draft-westerlund-avtcore-multiplex-architecture-01 (work 629 in progress), March 2012. 631 [I-D.westerlund-avtcore-transport-multiplexing] 632 Westerlund, M. and C. Perkins, "Multiple RTP Sessions on a 633 Single Lower-Layer Transport", 634 draft-westerlund-avtcore-transport-multiplexing-02 (work 635 in progress), March 2012. 637 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 638 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 639 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 640 September 1997. 642 [RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format 643 for Generic Forward Error Correction", RFC 2733, 644 December 1999. 646 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 647 Description Protocol", RFC 4566, July 2006. 649 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 650 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 651 July 2006. 653 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 654 Correction", RFC 5109, December 2007. 656 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 657 January 2008. 659 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 660 Media Attributes in the Session Description Protocol 661 (SDP)", RFC 5576, June 2009. 663 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 664 Control Packets on a Single Port", RFC 5761, April 2010. 666 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 667 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 669 Authors' Addresses 671 Magnus Westerlund 672 Ericsson 673 Farogatan 6 674 SE-164 80 Kista 675 Sweden 677 Phone: +46 10 714 82 87 678 Email: magnus.westerlund@ericsson.com 680 Colin Perkins 681 University of Glasgow 682 School of Computing Science 683 Glasgow G12 8QQ 684 United Kingdom 686 Email: csp@csperkins.org 687 Jonathan Lennox 688 Vidyo, Inc. 689 433 Hackensack Avenue 690 Seventh Floor 691 Hackensack, NJ 07601 692 US 694 Email: jonathan@vidyo.com