idnits 2.17.1 draft-ietf-avtcore-multi-media-rtp-session-08.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) (Using the creation date from RFC3551, updated by this document, for RFC5378 checks: 1997-03-27) -- 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 07, 2015) is 3216 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 330, but not defined == Unused Reference: 'I-D.westerlund-avtcore-transport-multiplexing' is defined on line 635, but no explicit reference was found in the text == Unused Reference: 'RFC4566' is defined on line 650, but no explicit reference was found in the text == Unused Reference: 'RFC5761' is defined on line 664, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-avtcore-rtp-multi-stream-07 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-22 == Outdated reference: A later version (-12) exists of draft-ietf-avtcore-multiplex-guidelines-03 == Outdated reference: A later version (-08) exists of draft-ietf-avtext-rtp-grouping-taxonomy-07 -- Obsolete informational reference (is this intentional?): RFC 2733 (Obsoleted by RFC 5109) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 4 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, 3551 (if approved) C. Perkins 5 Intended status: Standards Track University of Glasgow 6 Expires: January 08, 2016 J. Lennox 7 Vidyo 8 July 07, 2015 10 Sending Multiple Types of Media in a Single RTP Session 11 draft-ietf-avtcore-multi-media-rtp-session-08 13 Abstract 15 This document specifies how an RTP session can contain RTP 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 and RFC 3551 to enable this behaviour for 19 applications that satisfy the applicability for using multiple media 20 types in a 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 08, 2016. 39 Copyright Notice 41 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Background and Motivation . . . . . . . . . . . . . . . . . . 3 59 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 60 5. Using Multiple Media Types in a Single RTP Session . . . . . 7 61 5.1. Allowing Multiple Media Types in an RTP Session . . . . . 7 62 5.2. Demultiplexing Media Streams . . . . . . . . . . . . . . 8 63 5.3. Per-SSRC Media Type Restrictions . . . . . . . . . . . . 8 64 5.4. RTCP Considerations . . . . . . . . . . . . . . . . . . . 9 65 6. Extension Considerations . . . . . . . . . . . . . . . . . . 9 66 6.1. RTP Retransmission Payload Format . . . . . . . . . . . . 9 67 6.2. RTP Payload Format for Generic FEC . . . . . . . . . . . 11 68 6.3. RTP Payload Format for Redundant Audio . . . . . . . . . 11 69 7. Signalling . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 75 11.2. Informative References . . . . . . . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 The Real-time Transport Protocol [RFC3550] was designed to use 81 separate RTP sessions to transport different types of media. This 82 implies that different transport layer flows are used for different 83 media streams. For example, a video conferencing application might 84 send audio and video traffic RTP flows on separate UDP ports. With 85 increased use of network address/port translation, firewalls, and 86 other middleboxes it is, however, becoming difficult to establish 87 multiple transport layer flows between endpoints. Hence, there is 88 pressure to reduce the number of concurrent transport flows used by 89 RTP applications. 91 This memo updates [RFC3550] and [RFC3551] to allow multiple media 92 types to be sent in a single RTP session in certain cases, thereby 93 reducing the number of transport layer flows that are needed. It 94 makes no changes to RTP behaviour when using multiple RTP streams 95 containing media of the same type (e.g., multiple audio streams or 96 multiple video streams) in a single RTP session, however 98 [I-D.ietf-avtcore-rtp-multi-stream] provides important clarifications 99 to RTP behaviour in that case. 101 This memo is structured as follows. Section 2 defines terminology. 102 Section 3 further describes the background to, and motivation for, 103 this memo and Section 4 describes the scenarios where this memo is 104 applicable. (tbd: fixme) 106 2. Terminology 108 The terms Encoded Stream, Endpoint, Media Source, RTP Session, and 109 RTP Stream are used as defined in 110 [I-D.ietf-avtext-rtp-grouping-taxonomy]. We also define the 111 following terms: 113 Media Type: The general type of media data used by a real-time 114 application. The media type corresponds to the value used in the 115 field of an SDP m= line. The media types defined at the 116 time of this writing are "audio", "video", "text", "application", 117 and "message". 119 Quality of Service (QoS): Network mechanisms that are intended to 120 ensure that the packets within a flow or with a specific marking 121 are transported with certain properties. 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 3. Background and Motivation 129 RTP was designed to support multimedia sessions, containing multiple 130 types of media sent simultaneously, by using multiple transport layer 131 flows. The existence of network address translators, firewalls, and 132 other middleboxes complicates this, however, since a mechanism is 133 needed to ensure that all the transport layer flows needed by the 134 application can be established. This has three consequences: 136 1. increased delay to establish a complete session, since each of 137 the transport layer flows needs to be negotiated and established; 139 2. increased state and resource consumption in the middleboxes, that 140 can lead to unexpected behaviour when middlebox resource limits 141 are reached; and 143 3. increased risk that a subset of the transport layer flows will 144 fail to be established, thus preventing the application from 145 communicating. 147 Using fewer transport layer flows can hence be seen to reduce the 148 risk of communication failure, and can lead to improved reliability 149 and performance. 151 One of the benefits of using multiple transport layer flows is that 152 it makes it easy to use network layer quality of service (QoS) 153 mechanisms to give differentiated performance for different flows. 154 However, we note that many RTP-using application don't use network 155 QoS features, and don't expect or desire any separation in network 156 treatment of their media packets, independent of whether they are 157 audio, video or text. When an application has no such desire, it 158 doesn't need to provide a transport flow structure that simplifies 159 flow based QoS. 161 Given this, it might seem desirable for RTP-based applications to 162 send all their media streams bundled into one RTP session, that runs 163 on a single transport layer flow. Unfortunately, this is prohibited 164 by the RTP specification, since RTP makes certain assumptions that 165 can be incompatible with sending multiple media types in a single RTP 166 session. Specifically, the RTP control protocol (RTCP) timing rules 167 assume that all RTP media flows in a single RTP session have broadly 168 similar RTCP reporting and feedback requirements, which can be 169 problematic when different types of media are multiplexed together. 170 Certain RTP extensions also make assumptions that are incompatible 171 with sending different media types in a single RTP session. 173 This memo updates [RFC3550] and [RFC3551] to allow RTP sessions to 174 contain more than just one media type, and gives guidance on when it 175 is safe to perform such multiplexing. 177 4. Applicability 179 This specification has limited applicability, and anyone intending to 180 use it MUST ensure that their application and use meets the following 181 criteria: 183 Equal treatment of media: The use of a single RTP session enforces 184 similar treatment on all types of media used within the session. 185 Applications that require significantly different network QoS or 186 RTCP configuration for different media streams are better suited 187 by sending those media streams on separate RTP session, using 188 separate transport layer flows for each, since that gives greater 189 flexibility. Further guidance is given in 190 [I-D.ietf-avtcore-multiplex-guidelines] and 191 [I-D.ietf-dart-dscp-rtp]. 193 Compatible Media Requirements: The RTCP timing rules enforce a 194 single RTCP reporting interval for all participants in an RTP 195 session. Flows with very different media requirements, for 196 example a low-rate audio flow with no feedback needs and a high- 197 quality video flow with different repair mechanisms, cannot be 198 multiplexed together since this results in either excessive or 199 insufficient RTCP for some flows, depending how the RTCP session 200 bandwidth, and hence reporting interval, is configured. 202 Signalled Support: The extensions defined in this memo are not 203 compatible with unmodified [RFC3550]-compatible endpoints. Their 204 use requires signalling and mutual agreement by all participants 205 within an RTP session. This requirement can be a problem for 206 signalling solutions that can't negotiate with all participants. 207 For declarative signalling solutions, mandating that the session 208 is using multiple media types in one RTP session can be a way of 209 attempting to ensure that all participants in the RTP session 210 follow the requirement. However, for signalling solutions that 211 lack methods for enforcing that a receiver supports a specific 212 feature, this can still cause issues. 214 Consistent support for multiple media types in a single RTP session: 215 In multiparty communication scenarios it is important to separate 216 two different cases. One case is where the RTP session contains 217 multiple participants in a common RTP session. This occurs for 218 example in Any Source Multicast (ASM) and Relay (Transport 219 Translator) topologies as defined in RTP Topologies 220 [I-D.ietf-avtcore-rtp-topologies-update]. It can also occur in 221 some implementations of RTP mixers that share the same SSRC/CSRC 222 space across all participants. The second case is when the RTP 223 session is terminated in a middlebox and the other participants 224 sources are projected or switched into each RTP session and 225 rewritten on RTP header level including SSRC mappings. 227 For the first case, with a common RTP session or at least shared 228 SSRC/CSRC values, all participants in multiparty communication are 229 REQUIRED to support multiple media types in an RTP session. An 230 participant using two or more RTP sessions towards a multiparty 231 session can't be collapsed into a single session with multiple 232 media types. The reason is that in case of multiple RTP sessions, 233 the same SSRC value can be use in both RTP sessions without any 234 issues, but when collapsed to a single session there is an SSRC 235 collision. In addition some collisions can't be represented in 236 the multiple separate RTP sessions. For example, in a session 237 with audio and video, an SSRC value used for video will not show 238 up in the Audio RTP session at the participant using multiple RTP 239 sessions, and thus not trigger any collision handling. Thus any 240 application using this type of RTP session structure MUST have a 241 homogeneous support for multiple media types in one RTP session, 242 or be forced to insert a translator node between that participant 243 and the rest of the RTP session. 245 For the second case of separate RTP sessions for each multiparty 246 participant and a central node it is possible to have a mix of 247 single RTP session users and multiple RTP session users as long as 248 one is willing to remap the SSRCs used by a participant with 249 multiple RTP sessions into non-used values in the single RTP 250 session SSRC space for each of the participants using a single RTP 251 session with multiple media types. It can be noted that this type 252 of implementation has to understand all types of RTP/RTCP 253 extension being used in the RTP sessions to correctly be able to 254 translate them between the RTP sessions. It might also suffer 255 issues due to differencies in configured RTCP bandwidth and other 256 parameters between the RTP sessions. It can also negatively 257 impact the possibility for loop detection, as SSRC/CSRC can't be 258 used to detect the loops, instead some other RTP stream or media 259 source identity name space that is common across all interconnect 260 parts are needed. 262 Ability to operate with limited payload type space: An RTP session 263 has only a single 7-bit payload type space for all its payload 264 type numbers. Some applications might find this space limiting 265 when media different media types and RTP payload formats are using 266 within a single RTP session. 268 Avoids incompatible Extensions: Some RTP and RTCP extensions rely on 269 the existence of multiple RTP sessions and relate media streams 270 between sessions. Others report on particular media types, and 271 cannot be used with other media types. Applications that send 272 multiple types of media into a single RTP session need to avoid 273 such extensions. 275 5. Using Multiple Media Types in a Single RTP Session 277 This section defines what needs to be done or avoided to make an RTP 278 session with multiple media types function without issues. 280 5.1. Allowing Multiple Media Types in an RTP Session 282 Section 5.2 of "RTP: A Transport Protocol for Real-Time Applications" 283 [RFC3550] states: 285 For example, in a teleconference composed of audio and video media 286 encoded separately, each medium SHOULD be carried in a separate 287 RTP session with its own destination transport address. 289 Separate audio and video streams SHOULD NOT be carried in a single 290 RTP session and demultiplexed based on the payload type or SSRC 291 fields. 293 This specification changes both of these sentences. The first 294 sentence is changed to: 296 For example, in a teleconference composed of audio and video media 297 encoded separately, each medium SHOULD be carried in a separate 298 RTP session with its own destination transport address, unless 299 specification [RFCXXXX] is followed and the application meets the 300 applicability constraints. 302 The second sentence is changed to: 304 Separate audio and video media sources SHOULD NOT be carried in a 305 single RTP session, unless the guidelines specified in [RFCXXXX] 306 are followed. 308 Second paragraph of Section 6 in RTP Profile for Audio and Video 309 Conferences with Minimal Control [RFC3551] says: 311 The payload types currently defined in this profile are assigned 312 to exactly one of three categories or media types: audio only, 313 video only and those combining audio and video. The media types 314 are marked in Tables 4 and 5 as "A", "V" and "AV", respectively. 315 Payload types of different media types SHALL NOT be interleaved or 316 multiplexed within a single RTP session, but multiple RTP sessions 317 MAY be used in parallel to send multiple media types. An RTP 318 source MAY change payload types within the same media type during 319 a session. See the section "Multiplexing RTP Sessions" of RFC 320 3550 for additional explanation. 322 This specifications purpose is to violate that existing SHALL NOT 323 under certain conditions. Thus this sentence also has to be changed 324 to allow for multiple media type's payload types in the same session. 325 The above sentence is changed to: 327 Payload types of different media types SHALL NOT be interleaved or 328 multiplexed within a single RTP session unless as specified and 329 under the restriction in Multiple Media Types in an RTP Session 330 [RFCXXXX]. Multiple RTP sessions MAY be used in parallel to send 331 multiple media types. 333 RFC-Editor Note: Please replace RFCXXXX with the RFC number of this 334 specification when assigned. 336 5.2. Demultiplexing Media Streams 338 When receiving packets from a transport layer flow, an endpoint will 339 first separate the RTP and RTCP packets from the non-RTP packets, and 340 pass them to the RTP/RTCP protocol handler. The RTP and RTCP packets 341 are then demultiplexed based on their SSRC into the different media 342 streams. For each media stream, incoming RTCP packets are processed, 343 and the RTP payload type is used to select the appropriate media 344 decoder. 346 This process remains the same irrespective of whether multiple media 347 types are sent in a single RTP session or not. It is important to 348 note that the RTP payload type is never used to demultiplex media 349 streams. Media streams are distinguished by SSRC, and the payload 350 type is then used to route data for a particular SSRC to the right 351 media decoder. 353 5.3. Per-SSRC Media Type Restrictions 355 An SSRC in an RTP session MUST NOT change media type during its 356 lifetime. For example, an SSRC cannot start sending audio, then 357 change to sending video. The lifetime of an SSRC ends when an RTCP 358 BYE packet for that SSRC is sent, or when it ceases transmission for 359 long enough that it times out for the other participants in the 360 session. 362 The main motivation is that a given SSRC has its own RTP timestamp 363 and sequence number spaces. The same way that you can't send two 364 encoded streams of audio on the same SSRC, you can't send one encoded 365 audio and one encoded video stream on the same SSRC. Each encoded 366 stream when made into an RTP stream needs to have the sole control 367 over the sequence number and timestamp space. If not, one would not 368 be able to detect packet loss for that particular encoded stream. 369 Nor can one easily determine which clock rate a particular SSRCs 370 timestamp will increase with. For additional arguments why RTP 371 payload type based multiplexing of multiple media sources doesn't 372 work see [I-D.ietf-avtcore-multiplex-guidelines]. 374 Within an RTP session where multiple media types have been configured 375 for use, an SSRC can only send one type of media during its lifetime 376 (i.e., it can switch between different audio codecs, since those are 377 both the same type of media, but cannot switch between audio and 378 video). Different SSRCs MUST be used for the different media 379 sources, the same way multiple media sources of the same media type 380 already have to do. The payload type will inform a receiver which 381 media type the SSRC is being used for. Thus the payload type MUST be 382 unique across all of the payload configurations independent of media 383 type that is used in the RTP session. 385 5.4. RTCP Considerations 387 When sending multiple types of media that have different rates in a 388 single RTP session, endpoints MUST follow the guidelines for handling 389 RTCP described in Section 7 of [I-D.ietf-avtcore-rtp-multi-stream]. 391 6. Extension Considerations 393 This section outlines known issues and incompatibilities with RTP and 394 RTCP extensions when multiple media types are used in a single RTP 395 sessions. Future extensions to RTP and RTCP need to consider, and 396 document, any potential incompatibility. 398 6.1. RTP Retransmission Payload Format 400 SSRC-multiplexed RTP retransmission [RFC4588] is actually very 401 straightforward. Each retransmission RTP payload type is explicitly 402 connected to an associated payload type. If retransmission is only 403 to be used with a subset of all payload types, this is not a problem, 404 as it will be evident from the retransmission payload types which 405 payload types have retransmission enabled for them. 407 Session-multiplexed RTP retransmission is also possible to use where 408 an retransmission session contains the retransmissions of the 409 associated payload types in the source RTP session. The only 410 difference to the previous case is if the source RTP session is one 411 which contains multiple media types. This results in the 412 retransmission streams in the RTP session for the retransmission 413 having multiple associated media types. 415 When using SDP signalling for a multiple media type RTP session, i.e. 416 BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation], the session 417 multiplexed case do require some recommendations on how to signal 418 this. To avoid breaking the semantics of the FID grouping as defined 419 by [RFC5888] each media line can only be included in one FID group. 420 FID is used by RTP retransmission to indicate the SDP media lines 421 that is a source and retransmission pair. Thus, for SDP using 422 BUNDLE, each original media source (m= line) that is retransmitted 423 needs a corresponding media line in the retransmission RTP session. 424 In case there are multiple media lines for retransmission, these 425 media lines will form a independent BUNDLE group from the BUNDLE 426 group with the source streams. 428 Below is an SDP example (Figure 1) which shows the grouping 429 structures. This example is not legal SDP and only the most 430 important attributes has been left in place. Note that this SDP is 431 not an initial BUNDLE offer. As can be seen there are two bundle 432 groups, one for the source RTP session and one for the 433 retransmissions. Then each of the media sources are grouped with its 434 retransmission flow using FID, resulting in three more groupings. 436 a=group:BUNDLE foo bar fiz 437 a=group:BUNDLE zoo kelp glo 438 a=group:FID foo zoo 439 a=group:FID bar kelp 440 a=group:FID fiz glo 441 m=audio 10000 RTP/AVP 0 442 a=mid:foo 443 a=rtpmap:0 PCMU/8000 444 m=video 10000 RTP/AVP 31 445 a=mid:bar 446 a=rtpmap:31 H261/90000 447 m=video 10000 RTP/AVP 31 448 a=mid:fiz 449 a=rtpmap:31 H261/90000 450 m=audio 40000 RTP/AVPF 99 451 a=rtpmap:99 rtx/90000 452 a=fmtp:99 apt=0;rtx-time=3000 453 a=mid:zoo 454 m=video 40000 RTP/AVPF 100 455 a=rtpmap:100 rtx/90000 456 a=fmtp:199 apt=31;rtx-time=3000 457 a=mid:kelp 458 m=video 40000 RTP/AVPF 100 459 a=rtpmap:100 rtx/90000 460 a=fmtp:199 apt=31;rtx-time=3000 461 a=mid:glo 463 Figure 1: SDP example of Session Multiplexed RTP Retransmission 465 6.2. RTP Payload Format for Generic FEC 467 The RTP Payload Format for Generic Forward Error Correction 468 [RFC5109], and also its predecessor [RFC2733], requires some 469 considerations, and they are different depending on what type of 470 configuration of usage one has. 472 Independent RTP Sessions, i.e. where source and repair data are sent 473 in different RTP sessions. As this mode of configuration requires 474 different RTP session, there has to be at least one RTP session for 475 source data, this session can be one using multiple media types. The 476 repair session only needs one RTP Payload type indicating repair 477 data, i.e. x/ulpfec or x/parityfec depending if RFC 5109 or RFC 2733 478 is used. The media type in this session is not relevant and can in 479 theory be any of the defined ones. It is RECOMMENDED that one uses 480 "Application". 482 If one uses SDP signalling with BUNDLE 483 [I-D.ietf-mmusic-sdp-bundle-negotiation], then the RTP session 484 carrying the FEC streams will be its own BUNDLE group. The media 485 line with the source stream for the FEC and the FEC stream's media 486 line will be grouped using media line grouping using the FEC or FEC- 487 FR [RFC5956] grouping. This is very similar to the situation that 488 arise for RTP retransmission with session multiplexing discussed 489 above inSection 6.1. 491 The RTP Payload Format for Generic Forward Error Correction [RFC5109] 492 and its predecessor [RFC2733] requires a separate RTP session unless 493 the FEC data is carried in RTP Payload for Redundant Audio Data 494 [RFC2198]. 496 Note that the Source-Specific Media Attributes [RFC5576] 497 specification defines an SDP syntax (the "FEC" semantic of the "ssrc- 498 group" attribute) to signal FEC relationships between multiple RTP 499 streams within a single RTP session. However, this can't be used as 500 the FEC repair packets need to have the same SSRC value as the source 501 packets being protected. [RFC5576] does not normatively update and 502 resolve that restriction. There is ongoing work on an ULP extension 503 to allow it be use FEC RTP streams within the same RTP Session as the 504 source stream [I-D.lennox-payload-ulp-ssrc-mux]. 506 6.3. RTP Payload Format for Redundant Audio 508 In stream, using RTP Payload for Redundant Audio Data [RFC2198] 509 combining repair and source data in the same packets. This is 510 possible to use within a single RTP session. However, the usage and 511 configuration of the payload types can create an issue. First of all 512 it might be necessary to have one payload type per media type for the 513 FEC repair data payload format, i.e. one for audio/ulpfec and one 514 for text/ulpfec if audio and text are combined in an RTP session. 515 Secondly each combination of source payload and its FEC repair data 516 has to be an explicit configured payload type. This has potential 517 for making the limitation of RTP payload types available into a real 518 issue. 520 7. Signalling 522 Establishing an RTP session with multiple media types requires 523 signalling. This signalling needs to fulfil the following 524 requirements: 526 1. Ensure that any participant in the RTP session is aware that this 527 is an RTP session with multiple media types. 529 2. Ensure that the payload types in use in the RTP session are using 530 unique values, with no overlap between the media types. 532 3. Configure the RTP session level parameters, such as RTCP RR and 533 RS bandwidth, AVPF trr-int, underlying transport, the RTCP 534 extensions in use, and security parameters, commonly for the RTP 535 session. 537 4. RTP and RTCP functions that can be bound to a particular media 538 type SHOULD be reused when possible also for other media types, 539 instead of having to be configured for multiple code-points. 540 Note: In some cases one will not have a choice but to use 541 multiple configurations. 543 The signalling of multiple media types in one RTP session in SDP is 544 specified in "Multiplexing Negotiation Using Session Description 545 Protocol (SDP) Port Numbers" 546 [I-D.ietf-mmusic-sdp-bundle-negotiation]. 548 8. Security Considerations 550 Having an RTP session with multiple media types doesn't change the 551 methods for securing a particular RTP session. One possible 552 difference is that the different media have often had different 553 security requirements. When combining multiple media types in one 554 session, their security requirements also have to be combined by 555 selecting the most demanding for each property. Thus having multiple 556 media types can result in increased overhead for security for some 557 media types to ensure that all requirements are meet. 559 Otherwise, the recommendations for how to configure and RTP session 560 do not add any additional requirements compared to normal RTP, except 561 for the need to be able to ensure that the participants are aware 562 that it is a multiple media type session. If not that is ensured it 563 can cause issues in the RTP session for both the unaware and the 564 aware one. Similar issues can also be produced in an normal RTP 565 session by creating configurations for different end-points that 566 doesn't match each other. 568 9. IANA Considerations 570 This memo makes no request of IANA. 572 10. Acknowledgements 574 The authors would like to thank Christer Holmberg, Gunnar Hellstroem, 575 and Charles Eckel for the feedback on the document. 577 11. References 579 11.1. Normative References 581 [I-D.ietf-avtcore-rtp-multi-stream] 582 Lennox, J., Westerlund, M., Wu, W., and C. Perkins, 583 "Sending Multiple Media Streams in a Single RTP Session", 584 draft-ietf-avtcore-rtp-multi-stream-07 (work in progress), 585 March 2015. 587 [I-D.ietf-mmusic-sdp-bundle-negotiation] 588 Holmberg, C., Alvestrand, H., and C. Jennings, 589 "Negotiating Media Multiplexing Using the Session 590 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 591 negotiation-22 (work in progress), June 2015. 593 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 594 Requirement Levels", BCP 14, RFC 2119, March 1997. 596 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 597 Jacobson, "RTP: A Transport Protocol for Real-Time 598 Applications", STD 64, RFC 3550, July 2003. 600 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 601 Video Conferences with Minimal Control", STD 65, RFC 3551, 602 July 2003. 604 11.2. Informative References 606 [I-D.ietf-avtcore-multiplex-guidelines] 607 Westerlund, M., Perkins, C., and H. Alvestrand, 608 "Guidelines for using the Multiplexing Features of RTP to 609 Support Multiple Media Streams", draft-ietf-avtcore- 610 multiplex-guidelines-03 (work in progress), October 2014. 612 [I-D.ietf-avtcore-rtp-topologies-update] 613 Westerlund, M. and S. Wenger, "RTP Topologies", draft- 614 ietf-avtcore-rtp-topologies-update-10 (work in progress), 615 July 2015. 617 [I-D.ietf-avtext-rtp-grouping-taxonomy] 618 Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 619 B. Burman, "A Taxonomy of Semantics and Mechanisms for 620 Real-Time Transport Protocol (RTP) Sources", draft-ietf- 621 avtext-rtp-grouping-taxonomy-07 (work in progress), June 622 2015. 624 [I-D.ietf-dart-dscp-rtp] 625 Black, D. and P. Jones, "Differentiated Services 626 (DiffServ) and Real-time Communication", draft-ietf-dart- 627 dscp-rtp-10 (work in progress), November 2014. 629 [I-D.lennox-payload-ulp-ssrc-mux] 630 Lennox, J., "Supporting Source-Multiplexing of the Real- 631 Time Transport Protocol (RTP) Payload for Generic Forward 632 Error Correction", draft-lennox-payload-ulp-ssrc-mux-00 633 (work in progress), February 2013. 635 [I-D.westerlund-avtcore-transport-multiplexing] 636 Westerlund, M. and C. Perkins, "Multiplexing Multiple RTP 637 Sessions onto a Single Lower-Layer Transport", draft- 638 westerlund-avtcore-transport-multiplexing-07 (work in 639 progress), October 2013. 641 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 642 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 643 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 644 September 1997. 646 [RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format 647 for Generic Forward Error Correction", RFC 2733, December 648 1999. 650 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 651 Description Protocol", RFC 4566, July 2006. 653 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 654 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 655 July 2006. 657 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 658 Correction", RFC 5109, December 2007. 660 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 661 Media Attributes in the Session Description Protocol 662 (SDP)", RFC 5576, June 2009. 664 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 665 Control Packets on a Single Port", RFC 5761, April 2010. 667 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 668 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 670 [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in 671 the Session Description Protocol", RFC 5956, September 672 2010. 674 Authors' Addresses 676 Magnus Westerlund 677 Ericsson 678 Farogatan 6 679 SE-164 80 Kista 680 Sweden 682 Phone: +46 10 714 82 87 683 Email: magnus.westerlund@ericsson.com 685 Colin Perkins 686 University of Glasgow 687 School of Computing Science 688 Glasgow G12 8QQ 689 United Kingdom 691 Email: csp@csperkins.org 692 Jonathan Lennox 693 Vidyo, Inc. 694 433 Hackensack Avenue 695 Seventh Floor 696 Hackensack, NJ 07601 697 US 699 Email: jonathan@vidyo.com