idnits 2.17.1 draft-ejzak-avtcore-rtp-subsessions-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 23, 2012) is 4195 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-alvestrand-mmusic-msid-01 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-00 == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-rtp-usage-02 == Outdated reference: A later version (-02) exists of draft-westerlund-avtcore-max-ssrc-01 == 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 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVTCORE R. Ejzak 3 Internet-Draft Alcatel-Lucent 4 Intended status: Informational October 23, 2012 5 Expires: April 26, 2013 7 Media multiplexing with Real-time Transport Protocol (RTP) subsessions 8 draft-ejzak-avtcore-rtp-subsessions-02 10 Abstract 12 This document describes a means of multiplexing RTP streams having 13 different media types within a single transport connection and a 14 means of representing this multiplexing option in SDP so that network 15 nodes can easily identify groups of RTP streams and their associated 16 RTCP packets for differential treatment as necessary. This mechanism 17 can be used to complement the BUNDLE multiplexing scheme, which uses 18 the grouping framework to identify all media lines associated with a 19 single transport connection, but provides no means for network nodes 20 to group RTP streams and their RTCP packets for differential 21 treatment. RTP subsessions is an alternative to the SHIM 22 multiplexing proposal; it clearly partitions packets associated with 23 different media lines without changing the format of individual RTP 24 and RTCP packets, but it does not maintain a completely independent 25 SSRC space for each media line, as does SHIM. RTP subsessions avoid 26 SSRC conflicts by construction and can be used in all RTP topologies 27 in which all systems implement RTP subsessions, although SSRC mapping 28 might be needed when forwarding RTP streams from an unpartitioned RTP 29 session into an RTP subsession. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 26, 2013. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Overview of RTP subsessions . . . . . . . . . . . . . . . . . 4 66 2.1. RTP procedures . . . . . . . . . . . . . . . . . . . . . . 4 67 2.2. Summary of SSRC bit assignments . . . . . . . . . . . . . 5 68 2.3. SDP procedures . . . . . . . . . . . . . . . . . . . . . . 5 69 2.4. Additional procedures for relays . . . . . . . . . . . . . 7 70 2.5. When a system doesn't support RTP subsessions . . . . . . 8 71 2.6. Alternative SDP procedures considered . . . . . . . . . . 8 72 2.6.1. Signaling only MSID . . . . . . . . . . . . . . . . . 8 73 2.6.2. MSID with implicit SSRC range reservation . . . . . . 8 74 3. Applicability of RTP subsessions . . . . . . . . . . . . . . . 9 75 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 5. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 5.1. Comparison to BUNDLE . . . . . . . . . . . . . . . . . . . 12 78 5.2. Comparison to SHIM . . . . . . . . . . . . . . . . . . . . 13 79 5.3. Comparison to other SSRC proposals . . . . . . . . . . . . 13 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 8. Informative References . . . . . . . . . . . . . . . . . . . . 14 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 1. Introduction 87 The subject of RTP multiplexing has received significant attention 88 within RTCWEB and AVTCORE in the last year. It would be highly 89 desirable to multiplex RTP streams associated with a communications 90 session onto as few transport connections as possible to reduce the 91 messaging required to complete ICE connectivity checks [RFC5245] and 92 DTLS key exchange [RFC6347] prior to being able to send media. RTP 93 is specified in [RFC3550]. This document focuses specifically on how 94 to enable network nodes to provide differential treatment to 95 multiplexed media types within the same transport connection, since 96 means already exist to apply differential treatment to an entire 97 transport connection and RTP is capable of multiplexing RTP streams 98 of the same media type onto a single transport connection using the 99 SSRC field. While an application may be able to request different 100 DSCP markings for these flows, the treatment associated with a 101 particular marking is network-specific and many networks routinely 102 remap packet markings according to local policy unless they can 103 independently verify the requested treatment. 105 The following drafts provide key background and context, which will 106 not be duplicated here: [I-D.ietf-rtcweb-rtp-usage], 107 [I-D.westerlund-avtcore-multiplex-architecture], 108 [I-D.westerlund-avtcore-max-ssrc] and [I-D.alvestrand-mmusic-msid]. 109 Note in particular that the use of MSID, mandated in RTCWEB, uses 110 SSRC reservation to assist in stream identification. 112 The BUNDLE solution [I-D.ietf-mmusic-sdp-bundle-negotiation] uses SDP 113 [RFC4566] to assign different sets of payload type values for each 114 media line sharing an RTP session. The SHIM solution 115 [I-D.westerlund-avtcore-transport-multiplexing] extends the RTP frame 116 with an RTP session identifier to allow multiple RTP sessions to 117 share a single transport connection. Schemes no longer under 118 consideration, based on SSRC, are described in 119 [I-D.rosenberg-rtcweb-rtpmux] and 120 [I-D.peterson-rosenberg-avt-rtp-ssrc-demux]. 122 This document describes an optional enhancement to BUNDLE that allows 123 network nodes to identify RTP streams associated with an SDP media 124 line and their associated RTCP packets for differential treatment in 125 the network. Also included is a description of a means of 126 negotiating use of RTP subsessions in SDP, along with some 127 alternatives. This document assumes the use of unicast RTP sessions 128 only and there is no discussion of multicast sessions. 130 2. Overview of RTP subsessions 132 2.1. RTP procedures 134 An RTP subsession is a set of RTP streams and corresponding RTCP 135 packets that use a subset of the entire range of SSRC values. Each 136 RTP subsession has most of the characteristics of a complete RTP 137 session with some exceptions described below. RTP subsessions that 138 are assigned non-overlapping SSRC value ranges can share a single 139 transport connection. 141 As described in [RFC3550], RTP topologies can include end systems, 142 translators(relays) and mixers. RTP subsessions are particularly 143 suited to supporting end systems and mixers, since these systems 144 typically remap SSRC values when forwarding RTP streams and so can 145 independently assign SSRC values on each transport connection. The 146 remainder of this section describes use of RTP subsessions by end 147 systems and mixers; a later section describes use of RTP subsessions 148 by relays. 150 Each RTP subsession sharing a single transport connection is assigned 151 a unique 24-bit SSRC prefix for each direction of transmission, i.e., 152 the first (highest order) bit is reserved to indicate each direction 153 of transmission and the next 23 bits of the 32-bit SSRC field have a 154 fixed value for RTP streams associated with the RTP subsession. Each 155 assigned SSRC prefix is also unique in the first 8 bits to allow for 156 potential connection to relays that forward RTP streams from other 157 sources. The network can use the first 8 bits of the SSRC prefix to 158 filter IP packets on the transport connection to identify those 159 associated with the RTP subsession. 161 In non-relay topologies, the SDP offerer selects the first 24 bits of 162 the SSRC for RTP streams associated with a media line that it 163 transmits to the SDP answerer, and the SDP answerer selects the other 164 value of the 1st bit and the same values of the remaining 23 bits of 165 the SSRC prefix selected by the SDP offerer for RTP streams 166 associated with the same media line that it transmits in the other 167 direction to the SDP offerer. The final 8 bits of the SSRC are 168 available to specify separate RTP streams within the RTP subsession. 169 The SDP offerer selects the 24 bits of the SSRC prefix randomly for 170 each RTP subsession in such a way that the first 8 bits are also 171 unique across known RTP subsessions in the transport connection, and 172 each endpoint selects the last 8 bits of the SSRC randomly for each 173 RTP stream within an RTP subsession. The SDP offerer is allowed to 174 specify either value for the 1st bit of the SSRC to allow the offerer 175 and answerer to change roles during subsequent session modifications 176 while allowing continued use of already assigned SSRC values. 178 When concatenating multiple RTP or RTCP packets within a single IP 179 packet, as allowed by existing specifications, RTP systems will only 180 combine packets from the same RTP subsession. RTP subsessions are 181 thus segregated into separate IP packets to allow differential 182 treatment in the network. 184 2.2. Summary of SSRC bit assignments 186 RTP subsessions supports topologies including end systems, mixers and 187 translators (relays), where relays are classified either as "master" 188 or "slave". These end systems share responsibility for SSRC bit 189 assignments as described in the following table, using the procedure 190 described in the following section. There is a strict precedence 191 order between these systems, where a master relay can override SSRC 192 prefix assignments made by a slave relay, which can override SSRC 193 prefix assignments made by a mixer or end system, but not the other 194 way around. 196 +---------------------+---------------------------------------------+ 197 | SSRC bit range | Purpose | 198 +---------------------+---------------------------------------------+ 199 | 1 | identifies direction of flow | 200 | 2-8 | subsession id (for QoS) | 201 | 9-16 | allocated by primary relay to slave relays | 202 | | (except one value reserved for self) | 203 | 17-24 | allocated by slave relays to non-relay | 204 | | systems | 205 | 25-32 | allocated by non-relay systems to | 206 | | individual RTP streams (e.g., via MSID) | 207 +---------------------+---------------------------------------------+ 209 SSRC bit assignments 211 2.3. SDP procedures 213 The use of RTP subsessions is negotiated during the SDP offer/answer 214 exchange as follows. When signaled in combination with BUNDLE, 215 BUNDLE defines each group of media lines to share a transport 216 connection, and the SDP attribute for RTP subsessions defines the 217 SSRC prefix for each media line. Use of RTP subsessions without 218 BUNDLE is possible but not defined within this document. This draft 219 assumes that only one port is assigned for transport of RTP streams 220 on each m line, since use of multiple ports, though allowed in 221 [RFC4566], is rarely used. SDP subsessions can be readily enhanced 222 to support multiple media ports per m line if necessary. 224 BUNDLE specifies how the connection and port information is to be set 225 for each media line in a BUNDLE group. When RTP subsessions is used 226 with BUNDLE, there is no requirement for the payload type numbers for 227 each media line in the group to be non-overlapping, as required for 228 BUNDLE without RTP subsessions. The payload type field is not needed 229 to identify the media line associated with an RTP stream if the SSRC 230 prefix is known. 232 A system supporting RTP subsessions will include an "ssrc-prefix" 233 attribute for each media line in a sharing group, where each ssrc- 234 prefix attribute includes a parameter that indicates whether the 235 system is a relay (supporting RTP stream forwarding) and a parameter 236 that is a hex representation of the 24-bit SSRC prefix proposed for 237 use by the RTP subsession associated with the m line. If the 238 endpoint expects to transmit or receive more than 256 RTP streams of 239 the same media type, it should allocate more than one m line for that 240 media type. The system will also include the rtcp-mux attribute 241 [RFC5761] for each media line sharing the same transport connection. 242 A system supporting RTP subsessions that receives SDP with ssrc- 243 prefix attributes will assume the presence of the rtcp-mux attribute 244 for each associated media line, even in its absence. While rtcp-mux 245 could be made optional, there is no clear use case for supporting RTP 246 subsessions without rtcp-mux. 248 In addition to including the requisite BUNDLE attributes, the SDP 249 offer includes the ssrc-prefix attribute and the rtcp-mux attribute 250 for each media line in the sharing group. If the SDP answerer is not 251 a relay and agrees to use RTP subsessions (regardless of the role of 252 the SDP offerer), or if the SDP offerer is not a relay and the SDP 253 answerer is a relay that agrees to use RTP subsessions with the 254 value(s) of the SSRC prefix in the SDP offer, then the SDP answerer 255 also includes in the SDP answer the BUNDLE attributes, the ssrc- 256 prefix attribute and the rtcp-mux attribute for each media line in 257 the sharing group, with the same ssrc-prefix parameter values as the 258 corresponding ones from the SDP offer, but with the 1st bit changed, 259 i.e., '0' becomes '1' or '1' becomes '0'. The SDP answerer can 260 disable the use of RTP subsessions by not including the ssrc-prefix 261 attributes in the answer. 263 If the SDP offerer is not a relay and the SDP answerer is a relay 264 that selects not to use the SSRC prefix in the SDP offer for one or 265 more of the media lines, then it includes in the SDP answer the 266 BUNDLE attributes, the ssrc-prefix attribute and the rtcp-mux 267 attribute for each media line in the sharing group, with its own 268 ssrc-prefix parameter values for those selected media lines and as 269 described in the previous paragraph for the remaining media lines. 270 The SDP offerer must then use the ssrc-prefix values from the 271 selected media lines in the SDP answer with the 1st bit changed as 272 above. Note that for these selected media lines, any SSRC values 273 selected by other SDP attributes (such as ssrc for msid) in the SDP 274 offer are assumed by the SDP answerer to be remapped to include the 275 ssrc-prefix from the SDP answer with the 1st bit changed and the 276 original final 8 bits from the attribute in the SDP offer. The SDP 277 offerer will also assume the use of the remapped values and include 278 the remapped values in any subsequent SDP messages. 280 2.4. Additional procedures for relays 282 RTP subsessions will work without SSRC collisions for RTP system 283 configurations consisting of a single master relay directly connected 284 to up to 256 slave relays, where each relay may be directly connected 285 to up to 256 end systems or mixers. Note that a master relay 286 incorporates the function of at least one slave relay so that it can 287 connect to non-relay systems. The only requirements are that the 288 master relay initiate all connections to separate slave relays using 289 SDP offer/answer procedures and that all participating systems in the 290 RTP session comprising the RTP subsessions support SDP offer/answer 291 procedures to negotiate RTP subsessions. The master relay picks the 292 first 8 bits of the SSRC for every RTP subsession (used for filtering 293 in the network), thus allowing up to 128 RTP subsessions within an 294 RTP session. Each RTP subsession multiplexes traffic that is to 295 receive the same QoS treatment throughout the RTP session. The 296 master relay picks the first 16 bits of the SSRC that a slave relay 297 can use with a particular RTP subsession and the slave relay picks 298 the first 24 bits of the SSRC that an end system or mixer can use 299 with a particular RTP subsession. The non-relay systems are free to 300 allocate the last 8 bits of the SSRC to multiplex RTP streams on an 301 RTP subsession. 303 The previous sections already describe how SDP offer/answer occurs 304 between relay and non-relay systems to ensure that the relay 305 determines the 24-bit SSRC prefix that the non-relay system uses for 306 an RTP subsession, regardless of which system initiates the SDP 307 offer/answer procedure. 309 Once a relay system chooses the role of a master relay by selecting 310 an SSRC prefix for an RTP subsession, it refuses to accept an SDP 311 offer from any other relay. When sending an SDP offer to another 312 system, without knowing if it is another relay, it selects a 24-bit 313 SSRC prefix for each media line as already discussed, ensuring that 314 the first 16 bits of the SSRC have not been assigned to any other 315 transport connection. If the SDP answerer is not a relay, then the 316 24-bit SSRC prefix is reserved for the non-relay system to use for 317 the RTP subsession. If the SDP answerer is another relay (a slave 318 relay), it can accept the RTP subsession in the same manner as a non- 319 relay system by responding with the same ssrc-prefix with the first 320 bit changed. A slave relay is not allowed to respond to a master 321 relay with a different SSRC prefix except for the changed first bit. 323 Since the SDP offerer and answerer both signal that they are relays, 324 they both understand that the master relay will reserve the first 16 325 bits of the SSRC to the slave relay, thus allowing the master relay 326 to delegate SSRC prefix assignment to up to 256 slave relays and 327 allowing each slave relay to select the 24-bit SSRC prefix for the 328 RTP subsessions for up to 256 non-relay systems. 330 2.5. When a system doesn't support RTP subsessions 332 When a non-relay system fails to negotiate the use of RTP subsessions 333 with a peer, it will be difficult for the network to identify flows 334 for differential treatment in the presence of BUNDLE type 335 multiplexing. Once a relay has committed to RTP subsessions with one 336 or more other systems, it has only two choices if a new system being 337 added to the RTP session does not support RTP subsessions: it can re- 338 negotiate with all existing systems to disable RTP subsessions; or it 339 can perform SSRC mapping with the non-conformant system. 341 2.6. Alternative SDP procedures considered 343 Since [I-D.alvestrand-mmusic-msid] already describes an SSRC 344 reservation procedure for SDP, it is appropriate to consider the 345 relationship to RTP subsessions and whether MSID can be used to 346 simplify the signaling of RTP subsessions in SDP. 348 2.6.1. Signaling only MSID 350 If we consider using MSID without change to signal the use of RTP 351 subsessions, there are two limitations to consider. MSID provides 352 for explicit identification of the SSSRC used for each stream, so a 353 traffic filter could be constructed to search for RTP packets with 354 particular SSRC values, but this is quite cumbersome once there is 355 any significant amount of multiplexing per media line. Furthermore, 356 MSID includes no SSRC collision resolution procedure, thus making the 357 use of SDP offer/answer re-negotiation necessary for collision 358 resolution. While SSRC collisions are fairly rare if SSRC assignment 359 is completely random, collisions will occur and this form of 360 resolution is expensive and preferably avoided. 362 2.6.2. MSID with implicit SSRC range reservation 364 RTP subsession negotiation could be easily added to MSID as a 365 mandatory feature, as follows. If selection of an SSRC value for 366 MSID implicitly reserves SSRC ranges according to the conventions 367 described earlier in the document, then there would be no need to 368 explicitly signal the SSRC prefix. The only aspect missing is to 369 create a convention to negotiate precedence (master relay, slave 370 relay, or other) to provide for a simple method of resolving any SSRC 371 or SSRC range collisions. Details are left for further study if this 372 proposal for enhancing MSID is agreed. 374 3. Applicability of RTP subsessions 376 Each RTP subsession is able to provide most of the capabilities of a 377 full RTP session with some limitations associated with constraints on 378 SSRC assignment. No changes are required to RTP or SRTP packet 379 formats to realize RTP subsessions. The RTP streams associated with 380 an individual media line can be easily identified for separate 381 handling (e.g., to provide separate QoS treatment) by filtering on 382 the first 8 bits of the SSRC field, in addition to the five-tuple for 383 the transport connection. RTP systems can enable successful 384 filtering on the port and SSRC fields, which are above the IP layer, 385 by adhering to MTU limits to avoid IP fragmentation. 387 [RFC3550] describes three kinds of systems that can use RTP: end 388 systems, translators (relays) and mixers. RTP subsessions can be 389 freely used by end systems and mixers since these systems can freely 390 assign any SSRC value to each RTP stream and thus are free to detect 391 and resolve SSRC conflicts. For interworking with systems not 392 supporting RTP subsessions in particular, a relay can act as a mixer 393 to reassign the SSRC value associated with an RTP stream before 394 forwarding. When performing SSRC mapping rather than SRC forwarding, 395 RTCP is handled differently and SRTP forwarding is more complex, 396 requiring the decrypting and re-encrypting of each packet, as 397 discussed in [I-D.westerlund-avtcore-multiplex-architecture]. While 398 there is some additional processing needed to change SSRC when 399 forwarding SRTP, there seems to be no consensus in RTCWEB to require 400 support for forwarding with SSRC preservation. Systems that provide 401 additional media processing functions before forwarding RTP streams 402 need to decrypt SRTP packets anyway. 404 The relay procedures for RTP subsessions allow support of most relay 405 topologies as long as all systems in an RTP session support RTP 406 subsessions. This is a limitation in the short term when 407 interworking with existing systems, but if RTP subsession support is 408 made available early in the deployment of RTCWEB systems, then new 409 applications where relay systems, multiplexing of different media 410 types, and differential treatment of media flows are desirable can 411 require support for RTP subsessions. 413 Some applications require the ability to allocate the same SSRC value 414 across multiple ports or media lines. RTP streams in different RTP 415 subsessions are considered to use identical SSRC values if they match 416 on the last 24 bits of the SSRC, so RTP subsessions can also be used 417 for these applications. 419 Most RTP capabilities and extensions depend primarily on the use of a 420 different SSRC for each RTP stream. Since RTP subsessions retain 421 this characteristic, they introduce no new compatibility issues. 422 Examples of such extensions include FEC, interleaving and RTP 423 retransmissions. 425 Another short term limitation of RTP subsessions is that most 426 networks capable of assigning differential treatment do so with the 427 granularity of a five-tuple. The availability of a simple filter to 428 identify flows for differential treatment allows deployment of DPI or 429 custom gateways to enforce or verify DSCP markings in the short term. 430 In the longer term, network policy control systems can be enhanced to 431 perform SSRC prefix filtering. 433 4. Examples 435 In the first example, a non-relay SDP offerer desiring to use a 436 single transport connection for an audio m line and a video m line 437 might construct the following SDP offer. BUNDLE attributes are 438 present but not shown. 440 c=... 441 m=audio 49170 RTP/AVP 96 97 442 a=rtcp-mux 443 a=ssrc-prefix: non-relay 0x111111 444 ... 445 m=video 49170 RTP/AVP 98 99 446 a=rtcp-mux 447 a=ssrc-prefix: non-relay 0x222222 448 ... 450 The non-relay SDP answerer agrees to use SDP subsessions as described 451 in the SDP offer and accepts the SSRC prefixes for the two m lines as 452 shown below. BUNDLE attributes are present but not shown. 454 c=... 455 m=audio 36008 RTP/AVP 96 97 456 a=rtcp-mux 457 a=ssrc-prefix: non-relay 0x911111 458 ... 459 m=video 36008 RTP/AVP 98 99 460 a=rtcp-mux 461 a=ssrc-prefix: non-relay 0xa22222 462 ... 464 The endpoints will establish one audio RTP subsession and one video 465 RTP subsession associated with the SDP offer/answer exchange. These 466 SDP subsessions and their corresponding RTCP will each share a single 467 transport connection using ports 49170 and 36008, respectively. 468 Media flows associated with each SDP subsession can be identified by 469 filtering on the first 8 bits of the SSRC field as necessary for 470 differential handling, e.g., to assign separate QoS treatment. The 471 SDP offerer will send RTP streams on the two RTP subsessions for the 472 audio and video media m lines using 24-bit SSRC prefixes 0x111111 and 473 0x222222, respectively. The SDP answerer will send RTP streams using 474 24-bit SSRC prefixes 0x911111 and 0xa22222, respectively. The 475 network can filter on 8-bit SSRC prefixes 0x11 and 0x22 for packets 476 in the five-tuple from the SDP offerer and the network can filter on 477 8-bit SSRC prefixes 0x91 and 0xa2 for packets in the five-tuple sent 478 to the SDP offerer. 480 In another example to highlight how a relay may override an SSRC 481 prefix selected by a non-relay system, a non-relay SDP offerer 482 desiring to use a single transport connection for an audio m line and 483 a video m line might construct the following SDP offer. BUNDLE 484 attributes are present but not shown. 486 c=... 487 m=audio 49170 RTP/AVP 96 97 488 a=rtcp-mux 489 a=ssrc-prefix: non-relay 0x111111 490 ... 491 m=video 49170 RTP/AVP 98 99 492 a=rtcp-mux 493 a=ssrc-prefix: non-relay 0x222222 494 ... 496 The SDP answerer performing as an RTP relay agrees to use SDP 497 subsessions as described in the SDP offer. It accepts the SSRC 498 prefix for the audio m line but selects an alternate SSRC prefix for 499 the video m line as shown below. BUNDLE attributes are present but 500 not shown. 502 c=... 503 m=audio 36008 RTP/AVP 96 97 504 a=rtcp-mux 505 a=ssrc-prefix: relay 0x911111 506 ... 507 m=video 36008 RTP/AVP 98 99 508 a=rtcp-mux 509 a=ssrc-prefix: relay 0x333333 510 ... 512 The endpoints will establish one audio RTP subsession and one video 513 RTP subsession associated with the SDP offer/answer exchange. These 514 SDP subsessions and their corresponding RTCP will each share a single 515 transport connection using ports 49170 and 36008, respectively. 516 Media flows associated with each SDP subsession can be identified by 517 filtering on the first 8 bits of the SSRC field as necessary for 518 differential handling, e.g., to assign separate QoS treatment. The 519 non-relay SDP offerer will send RTP streams on the two RTP 520 subsessions for the audio and video media m lines using 24-bit SSRC 521 prefixes 0x111111 and 0xb33333, respectively. The SDP answerer 522 performing as an RTP relay will send RTP streams (forwarded from 523 other systems) using 8-bit SSRC prefixes 0x91 and 0x33, respectively. 524 The network can filter on 8-bit SSRC prefixes 0x11 and 0xb3 for 525 packets in the five-tuple from the SDP offerer and the network can 526 filter on 8-bit SSRC prefixes 0x91 and 0x33 for packets in the five- 527 tuple sent to the SDP offerer. Note that the 32-bit prefix for any 528 ssrc values selected for RTP streams associated with the video m line 529 are assumed to be changed from 0x222222 to 0xb33333 while ssrc values 530 selected for the audio line can remain unchanged. 532 5. Evaluation 534 5.1. Comparison to BUNDLE 536 BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] effectively merges 537 RTP sessions together in relay topologies, thus slightly increasing 538 the probability of SSRC collisions, although the impact is minor. In 539 the context of RTCWEB, an SSRC collision, though rare, will require 540 the use of an additional SDP offer/answer transaction to change msid/ 541 ssrc mappings, so is clearly undesirable. This can be avoided with 542 RTP subsessions, since SDP offer/answer is used to pre-allocate SSRC 543 ranges for each m line, thus completely avoiding SSRC collisions. It 544 must also be assured that different RTP streams do not share the same 545 SSRC, even though they use non-overlapping payload type values, so 546 that each RTCP packet can be uniquely associated with a particular 547 RTP stream. It is difficult to define a filter to allow the network 548 to identify the RTP streams associated with different media lines 549 with BUNDLE since this requires filtering on sets of payload type 550 values. RTP subsessions can enhance BUNDLE for this purpose, since 551 it is only necessary to screen for a single value in the first 8 bits 552 of the SSRC. It is also not possible with BUNDLE to associate RTP 553 streams from different m lines using a single SSRC value (as it is 554 possible to do using the last 24 bits of the SSRC with RTP 555 subsessions), due to the need to separate the RTCP messages for each 556 RTP stream. 558 The author proposes that RTP subsessions be adopted to augment BUNDLE 559 to eliminate the restrictions described above. 561 5.2. Comparison to SHIM 563 SHIM [I-D.westerlund-avtcore-transport-multiplexing] is the most 564 successful scheme in preserving the SSRC space of each RTP session 565 when multiplexing those RTP sessions onto a single transport 566 connection. SHIM changes RTP so it can potentially impact many 567 different middleboxes. It also slightly increases the size of each 568 media packet, which can be of concern in some bandwidth-limited 569 deployments. 571 The author recommends RTP subsessions over SHIM to better address two 572 key requirements: to support flow identification for differential 573 treatment; and to minimize impact on the RTP packet format. Given 574 the increasing use of pre-selected SSRC values to identify individual 575 RTP streams, which is inconsistent with the idea of random SSRC 576 assignment and the use of SSRC collision detection and resolution 577 schemes, the author also recommends the use of an effective SSRC 578 collision avoidance scheme based on SSRC range reservation, such as 579 the one defined for RTP subsessions. 581 5.3. Comparison to other SSRC proposals 583 Two expired drafts, [I-D.rosenberg-rtcweb-rtpmux] and 584 [I-D.peterson-rosenberg-avt-rtp-ssrc-demux], propose other means of 585 multiplexing based on the SSRC field. [I-D.rosenberg-rtcweb-rtpmux] 586 uses a portion of the SSRC to identify the media type for the RTP 587 stream. This scheme redefines the SSRC field and has significant 588 limitations when multiple m lines share the same media type, since 589 some other mechanism is still needed to separate them. 590 [I-D.peterson-rosenberg-avt-rtp-ssrc-demux] assumes a single SSRC 591 value per m line, so is not consistent with current RTP multiplexing 592 requirements. 594 Neither earlier SSRC-based scheme fully addresses the requirements 595 for multiplexing agreed in the working groups. 597 6. IANA Considerations 599 To be completed. 601 7. Security Considerations 603 To be completed. 605 8. Informative References 607 [I-D.alvestrand-mmusic-msid] 608 Alvestrand, H., "Cross Session Stream Identification in 609 the Session Description Protocol", 610 draft-alvestrand-mmusic-msid-01 (work in progress), 611 October 2012. 613 [I-D.ietf-mmusic-sdp-bundle-negotiation] 614 Holmberg, C. and H. Alvestrand, "Multiplexing Negotiation 615 Using Session Description Protocol (SDP) Port Numbers", 616 draft-ietf-mmusic-sdp-bundle-negotiation-00 (work in 617 progress), February 2012. 619 [I-D.ietf-rtcweb-rtp-usage] 620 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 621 Communication (WebRTC): Media Transport and Use of RTP", 622 draft-ietf-rtcweb-rtp-usage-02 (work in progress), 623 March 2012. 625 [I-D.peterson-rosenberg-avt-rtp-ssrc-demux] 626 Peterson, J. and J. Rosenberg, "A Multiplexing Mechanism 627 for the Real-Time Protocol (RTP)", 628 draft-peterson-rosenberg-avt-rtp-ssrc-demux-00 (work in 629 progress), July 2004. 631 [I-D.rosenberg-rtcweb-rtpmux] 632 Rosenberg, J., Jennings, C., Peterson, J., Kaufman, M., 633 Rescorla, E., and T. Terriberry, "Multiplexing of Real- 634 Time Transport Protocol (RTP) Traffic for Browser based 635 Real-Time Communications (RTC)", 636 draft-rosenberg-rtcweb-rtpmux-00 (work in progress), 637 July 2011. 639 [I-D.westerlund-avtcore-max-ssrc] 640 Westerlund, M., Burman, B., and F. Jansson, "Multiple 641 Synchronization sources (SSRC) in RTP Session Signaling", 642 draft-westerlund-avtcore-max-ssrc-01 (work in progress), 643 April 2012. 645 [I-D.westerlund-avtcore-multiplex-architecture] 646 Westerlund, M., Burman, B., and C. Perkins, "RTP 647 Multiplexing Architecture", 648 draft-westerlund-avtcore-multiplex-architecture-01 (work 649 in progress), March 2012. 651 [I-D.westerlund-avtcore-transport-multiplexing] 652 Westerlund, M. and C. Perkins, "Multiple RTP Sessions on a 653 Single Lower-Layer Transport", 654 draft-westerlund-avtcore-transport-multiplexing-02 (work 655 in progress), March 2012. 657 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 658 Jacobson, "RTP: A Transport Protocol for Real-Time 659 Applications", STD 64, RFC 3550, July 2003. 661 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 662 Description Protocol", RFC 4566, July 2006. 664 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 665 (ICE): A Protocol for Network Address Translator (NAT) 666 Traversal for Offer/Answer Protocols", RFC 5245, 667 April 2010. 669 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 670 Control Packets on a Single Port", RFC 5761, April 2010. 672 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 673 Security Version 1.2", RFC 6347, January 2012. 675 Author's Address 677 Richard Ejzak 678 Alcatel-Lucent 679 1960 Lucent Lane 680 Naperville, Illinois 60563-1594 681 US 683 Phone: +1 630 979 7036 684 Email: richard.ejzak@alcatel-lucent.com