idnits 2.17.1 draft-westerlund-avtcore-rtp-simulcast-03.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2013) is 3839 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4568' is defined on line 1413, but no explicit reference was found in the text == Unused Reference: 'RFC5888' is defined on line 1430, but no explicit reference was found in the text == Unused Reference: 'RFC3264' is defined on line 1474, but no explicit reference was found in the text == Unused Reference: 'RFC3569' is defined on line 1478, but no explicit reference was found in the text == Unused Reference: 'RFC5245' is defined on line 1488, but no explicit reference was found in the text == Unused Reference: 'RFC6190' is defined on line 1493, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-westerlund-avtext-rtp-stream-pause-03 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285) == Outdated reference: A later version (-12) exists of draft-ietf-avtcore-multiplex-guidelines-01 == Outdated reference: A later version (-11) exists of draft-ietf-avtcore-rtp-multi-stream-01 == Outdated reference: A later version (-10) exists of draft-ietf-avtcore-rtp-topologies-update-00 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-05 == Outdated reference: A later version (-07) exists of draft-westerlund-avtcore-transport-multiplexing-06 -- Obsolete informational reference (is this intentional?): RFC 5117 (Obsoleted by RFC 7667) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 2 errors (**), 0 flaws (~~), 13 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Westerlund 3 Internet-Draft B. Burman 4 Intended status: Standards Track Ericsson 5 Expires: April 25, 2014 S. Nandakumar 6 Cisco 7 October 22, 2013 9 Using Simulcast in RTP Sessions 10 draft-westerlund-avtcore-rtp-simulcast-03 12 Abstract 14 In some application scenarios it may be desirable to send multiple 15 differently encoded versions of the same Media Source in independent 16 Source Packet Streams. This is called Simulcast. This document 17 discusses the best way of accomplishing Simulcast in RTP and how to 18 signal it in SDP. A solution is defined by making three extensions 19 to SDP, and using RTP/RTCP identification methods to relate RTP 20 Source Packet Streams. The first SDP extension consists of two new 21 session level SDP attributes that express capability to send or 22 receive Simulcast Source Packet Streams, respectively. The second 23 SDP extension introduces an SDP media level attribute that groups and 24 identifies a selected set of media level parameters for a specific 25 direction, called a media configuration. The third SDP extension 26 describes how to group such media configurations on SDP session or 27 media level for Simulcast purposes. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 25, 2014. 46 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 66 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Reaching a Diverse Set of Receivers . . . . . . . . . . . 5 68 3.2. Application Specific Media Source Handling . . . . . . . 6 69 3.3. Receiver Adaptation in Multicast/Broadcast . . . . . . . 7 70 3.4. Receiver Media Source Preferences . . . . . . . . . . . . 7 71 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8 72 5. Proposed Solution Overview . . . . . . . . . . . . . . . . . 9 73 6. Proposed Signaling . . . . . . . . . . . . . . . . . . . . . 10 74 6.1. Simulcast Capability . . . . . . . . . . . . . . . . . . 11 75 6.1.1. Declarative Use . . . . . . . . . . . . . . . . . . . 12 76 6.1.2. Offer/Answer Use . . . . . . . . . . . . . . . . . . 12 77 6.2. Media Configuration . . . . . . . . . . . . . . . . . . . 13 78 6.2.1. Simulcast Limitations . . . . . . . . . . . . . . . . 16 79 6.2.2. Declarative Use . . . . . . . . . . . . . . . . . . . 17 80 6.2.3. Offer/Answer Use . . . . . . . . . . . . . . . . . . 17 81 6.3. Grouping Simulcast Configurations . . . . . . . . . . . . 18 82 6.3.1. Declarative Use . . . . . . . . . . . . . . . . . . . 19 83 6.3.2. Offer/Answer Use . . . . . . . . . . . . . . . . . . 19 84 6.4. Relating Simulcast Versions . . . . . . . . . . . . . . . 20 85 6.5. Two-Phase Negotiation . . . . . . . . . . . . . . . . . . 20 86 6.6. Signaling Examples . . . . . . . . . . . . . . . . . . . 21 87 6.6.1. Unified Plan Client . . . . . . . . . . . . . . . . . 21 88 6.6.2. Multi-Transport Client . . . . . . . . . . . . . . . 24 89 6.6.3. Multi-Source Client . . . . . . . . . . . . . . . . . 26 90 7. Network Aspects . . . . . . . . . . . . . . . . . . . . . . . 28 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 93 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 94 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 95 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 96 12.1. Normative References . . . . . . . . . . . . . . . . . . 30 97 12.2. Informative References . . . . . . . . . . . . . . . . . 31 98 Appendix A. Discussion on Receiver Diversity . . . . . . . . . . 32 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 101 1. Introduction 103 Most of today's multiparty video conference solutions make use of 104 centralized servers to reduce the bandwidth and CPU consumption in 105 the endpoints. Those servers receive Source Packet Streams from each 106 participant and send some suitable set of possibly modified streams 107 to the rest of the participants, which usually have heterogeneous 108 capabilities (screen size, CPU, bandwidth, codec, etc). One of the 109 biggest issues is how to perform stream adaptation to different 110 participants' constraints with the minimum possible impact on video 111 quality and server performance. 113 Simulcast is the act of simultaneously sending multiple different 114 versions of the same media content, e.g. the same video source 115 encoded with different video encoder types or image resolutions. 116 This can be done in several ways and for different purposes. This 117 document focuses on the case where it is desirable to provide a Media 118 Source as multiple Source Packet Streams over RTP [RFC3550] towards 119 an intermediary so that the intermediary can provide the wanted 120 functionality by selecting which Source Packet Stream to forward to 121 other participants in the session, and more specifically how the 122 identification and grouping of the involved Source Packet Streams are 123 done. From an RTP perspective, Simulcast is a specific application 124 of the aspects discussed in RTP Multiplexing Guidelines 125 [I-D.ietf-avtcore-multiplex-guidelines]. 127 The purpose of this document is to describe a few scenarios where it 128 is motivated to use Simulcast, and propose a suitable solution for 129 signaling and performing RTP Simulcast. 131 2. Definitions 133 2.1. Terminology 135 This document makes use of the terminology defined in RTP Taxonomy 136 [I-D.lennox-raiarea-rtp-grouping-taxonomy]. In addition, the 137 following terms are used: 139 Media Configuration: A specific set of parameter values applied on 140 the encoding and packetization process that creates a specific 141 Source Packet Stream. In SDP, the applicable parameter values are 142 described by the joint set of "rtpmap" parameters, "fmtp" 143 parameters, and the "config-id" (Section 6.2) parameters, 144 including extensions. 146 2.2. Requirements Language 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in RFC 2119 [RFC2119]. 152 3. Use Cases 154 Many use cases of Simulcast as described in this document relate to a 155 multi-party Communication Session where one or more central nodes are 156 used to adapt the view of the Communication Session towards 157 individual Participants, and facilitate the Media Transport between 158 Participants. Thus, these cases targets the RTP Mixer topology 159 defined in [RFC5117] (Section 3.4: Topo-Mixer), further elaborated 160 and extended with other topologies in 161 [I-D.ietf-avtcore-rtp-topologies-update] (Section 3.6 to 3.9). 163 There are two principle approaches for an RTP Mixer to provide this 164 adapted view of the Communication Session to each receiving 165 Participant: 167 o Transcoding (decoding and re-encoding) received Source Packet 168 Streams with characteristics adapted to each receiving 169 Participant. This often include mixing or composition of Media 170 Sources from multiple Participants into a mixed Media Source 171 originated by the RTP Mixer. The main advantage of this approach 172 is that it achieves close to optimal adaptation to individual 173 receiving Participants. The main disadvantages are that it can be 174 very computationally expensive to the RTP Mixer and typically also 175 degrades media Quality of Experience (QoE) such as end-to-end 176 delay for the receiving Participants. 178 o Switching a subset of all received Source Packet Streams or sub- 179 streams to each receiving Participant, where the used subset is 180 typically specific to each receiving Participant. The main 181 advantages of this approach are that it is computationally cheap 182 to the RTP Mixer and it has very limited impact on media QoE. The 183 main disadvantage is that it can be difficult to combine a subset 184 of received Source Packet Streams into a perfect fit to the 185 resource situation of a receiving Participant. 187 The use of Simulcast is relates to the latter approach, where it is 188 more important to reduce the load on the RTP Mixer and/or minimize 189 QoE impact than to achieve an optimal adaptation of resource usage. 191 A multicast/broadcast case where the receivers themselves selects the 192 most appropriate simulcast version and tune in to the right transport 193 to receive that version is also considered (Section 3.3) . This 194 enables large receiver populations with heterogeneity where it comes 195 to capabilities and the use network paths bandwidth. 197 In this section, an "RTP switch" is used as a common short term for 198 the terms "switching RTP mixer", "source projecting middlebox", and 199 "video switching MCU" as discussed in 200 [I-D.ietf-avtcore-rtp-topologies-update]. 202 3.1. Reaching a Diverse Set of Receivers 204 The Media Sources provided by a sending Participant potentially need 205 to reach several receiving Participants that differ in terms of 206 available resources. A discussion on that topic is included in 207 Appendix A. The receiver resources that typically differ include, but 208 are not limited to: 210 Codec: This includes codec type (such as SDP MIME type) and can 211 include codec configuration options (e.g. SDP fmtp parameters). A 212 couple of codec resources that differ only in codec configuration 213 will be "different" if they are somehow not "compatible", like if 214 they differ in video codec profile, or the transport packetization 215 configuration. 217 Sampling: This relates to how the Media Source is sampled, in 218 spatial as well as in temporal domain. For video streams, spatial 219 sampling affects image resolution and temporal sampling affects 220 video frame rate. For audio, spatial sampling relates to the 221 number of audio channels and temporal sampling affects audio 222 bandwidth. This may be used to suit different rendering 223 capabilities or needs at the receiving endpoints, as well as a 224 method to achieve different transport capabilities, bitrates and 225 eventually QoE by controlling the amount of source data. 227 Bitrate: This relates to the amount of bits spent per second to 228 transmit the Media Source as an Source Packet Stream, which 229 typically also affects the Quality of Experience (QoE) for the 230 receiving user. 232 Letting the sending Participant create a Simulcast of a few 233 differently configured Source Packet Streams per Media Source can be 234 a good trade-off when using an RTP switch as middlebox, instead of 235 sending a single Source Packet Stream and using an RTP Mixer to 236 create individual transcodings to each receiving Participant. 238 This requires that the receiving Participants can be categorized in 239 terms of available resources and that the sending Participant can 240 choose a matching configuration for a single Source Packet Stream per 241 category and Media Source. 243 For example, assume for simplicity a set of receiving Participants 244 that differ only in that some have support to receive Codec A, and 245 the others have support to receive Codec B. Further assume that the 246 sending participant can send both Codec A and B. It can then reach 247 all receivers by creating two Simulcasted Source Packet Streams from 248 each Media Source; one for Codec A and one for Codec B. 250 In another simple example, a set of receiving Participants differ 251 only in screen resolution; some are able to display video with at 252 most 360p resolution and some support 720p resolution. A sending 253 Participant can then reach all receivers by creating a Simulcast of 254 Source Packet Streams with 360p and 720p resolution for each sent 255 video Media Source. 257 In more elaborate cases, the receiving Participants differ both in 258 available Sampling and Bitrate, and maybe also Codec, and it is up to 259 the RTP switch to find a good trade-off in which Simulcasted stream 260 to choose for each intended receiver. It is also the responsibility 261 of the RTP switch to negotiate a good fit of Simulcast streams with 262 the sending Participant. 264 The maximum number of Simulcasted Source Packet Streams that can be 265 sent is mainly limited by the amount of processing and uplink network 266 resources available to the sending Participant. 268 3.2. Application Specific Media Source Handling 270 The application logic that controls the Communication Session may 271 include special handling of some Media Sources. It is for example 272 commonly the case that the media from a sending Participant is not 273 sent back to itself. 275 It is also common that a currently active speaker Participant is 276 shown in larger size or higher quality than other Participants (the 277 Sampling or Bitrate aspects of Section 3.1). Not sending the active 278 speaker media back to itself means there is some other Participant's 279 media instead that receive special handling towards the active 280 speaker; typically the previous active speaker. This way, the 281 previously active speaker is needed both in larger size (to current 282 active speaker) and in small size (to the rest of the Participants), 283 which can be solved with a Simulcast from the previously active 284 speaker to the RTP switch. 286 3.3. Receiver Adaptation in Multicast/Broadcast 288 When using Broadcast or Multicast technology to distribute real-time 289 media streams to large populations of receivers there can still be 290 significant heterogeneity among the receiver population. This can 291 depend on several factors: 293 Network Bandwidth: The network paths to individual receivers will 294 have variations in the bandwidth. Thus putting different limits 295 on the supported bit-rates that can be received. 297 Endpoint Capabilities: The endpoint's hardware and software can have 298 varying capabilities in relation to screen resolution, decoding 299 capabilities, and supported media codecs. 301 To handle these variations, a transmitter of real-time media may want 302 to apply Simulcast to its Source Packet Streams and provide a set of 303 media configurations, enabling the receivers to select the best fit 304 from these sets themselves. The endpoint capabilities will usually 305 result in a single initial choice. However, the network bandwidth 306 can vary over time, which requires a client to continuously monitor 307 its reception to determine if the received media streams still fit 308 within the available bandwidth. If not, another Simulcast media 309 configuration containing a thinner set of Source Packet Streams will 310 have to be chosen. 312 When one uses IP multicast, the level of Simulcast granularity that 313 the receiver can select from is by choosing different multicast 314 addresses. Thus, different Simulcast versions need to be put on 315 different Media Transports using different multicast addresses. If 316 these Simulcast versions are described using SDP, they need to be 317 part of different SDP media descriptions, as SDP binds to transport 318 on media description level. To enable more than the initial choice 319 to function well, there is a need to enable correct mapping of Source 320 Packet Streams in one Simulcast media configuration to a 321 corresponding Source Packet Stream in another Simulcast media 322 configuration on another multicast group. 324 3.4. Receiver Media Source Preferences 326 The application logic that controls the Communication Session may 327 allow receiving Participants to apply preferences to the 328 characteristics of the Source Packet Stream they receive, for example 329 in terms of the aspects listed in Section 3.1. Sending a Simulcast 330 of Source Packet Streams is one way of accommodating receivers with 331 conflicting or otherwise incompatible preferences. 333 4. Requirements 335 The following requirements need to be met to support the use cases in 336 previous sections: 338 REQ-1: Identification. It must be possible to identify a set of 339 simulcasted Source Packet Streams as originating from the same 340 Media Source: 342 REQ-1.1: In SDP signaling. 344 REQ-1.2: On RTP/RTCP level. 346 REQ-2: Transport usage. The solution must work when distributing 347 different Simulcast versions on: 349 REQ-2.1: Same Media Transport and RTP session. 351 REQ-2.2: Different Media Transports and RTP sessions. 353 REQ-3: Capability negotiation. It must be possible that: 355 REQ-3.1: Sender can express capability of sending simulcast. 357 REQ-3.2: Receiver can express capability of receiving simulcast. 359 REQ-3.3: Sender can express maximum number of Simulcast versions 360 that can be provided. 362 REQ-3.4: Receiver can express maximum number of Simulcast 363 versions that can be received. 365 REQ-3.5: Sender can detail the characteristics of the Simulcast 366 versions that can be provided. 368 REQ-3.6: Receiver can detail the characteristics of the Simulcast 369 versions that it prefers to receive. 371 REQ-4: Distinguishing features. It must be possible to have 372 different Simulcast versions use different values for any 373 combination of: 375 REQ-4.1: Codec. This includes both codec type and configuration 376 options for both codec and RTP packetization. It also 377 includes different layers from a scalable codec, but only as 378 long as those layers are possible to identify on RTP level. 380 REQ-4.2: Bitrate of Source Packet Stream. 382 REQ-4.3: Sampling in spatial as well as in temporal domain. 384 REQ-5: Compatibility. It must be possible to use Simulcast in 385 combination with other RTP mechanisms that generate additional 386 Source Packet Streams: 388 REQ-5.1: RTP Retransmission [RFC4588]. 390 REQ-5.2: RTP Forward Error Correction [RFC5109]. 392 REQ-6: Interoperability. The solution must also be able to use in: 394 REQ-6.1: Interworking with non-simulcast legacy clients using a 395 single Media Source per media type. 397 REQ-6.2: WebRTC "Unified Plan" environment. 399 5. Proposed Solution Overview 401 Signaling Simulcast is about negotiating between media sender and 402 receiver what the different Simulcast versions should be, how to 403 identify them in terms of Source Packet Streams, and how to inter- 404 relate those Source Packet Streams. 406 The proposed solution consists of: 408 o Signaling Simulcast capability in an optional, pre-stage Offer/ 409 Answer: 411 * Separate send and receive Simulcast capabilities as SDP session 412 level attributes. 414 * Media properties that are supported as base for different 415 Simulcast versions are listed as parameters that are also 416 possible to rank. 418 * Early indication of maximum number of available encoding/ 419 decoding resources on SDP media level. 421 o Including detailed information for the Simulcast in a main Offer/ 422 Answer: 424 * Including Simulcast capability indications, as described above, 425 being kept from the pre-stage Offer/Answer, if any. 427 * Defining and labeling of the media configuration for each 428 Simulcast version to be sent or received. 430 * The media configuration for a Simulcast version can include 431 acceptable parameter ranges for parameters that are most likely 432 used to distinguish Simulcast versions. 434 * Indicating the use of Simulcast, separately per direction, by 435 grouping the defined media configurations, not individual 436 streams, that will constitute the Simulcast. 438 * Allowing that any one of the media configurations in a specific 439 Simulcast is signaled inactive from the start of the session. 440 This is defined as equivalent to the affected Source Packet 441 Stream being in PAUSED state 442 [I-D.westerlund-avtext-rtp-stream-pause]. 444 * Adding and/or modifying SDP media descriptions as needed to 445 accommodate the negotiated Simulcast streams. 447 * Parameter limits to the aggregate of media configurations are 448 signaled by existing SDP attributes on session and media 449 description level. 451 * Including media level indication of maximum number of available 452 encoding/decoding resources on SDP media level. They MAY be 453 modified compared to the pre-stage Offer/Answer, if any. 455 * Identifying which Source Packet Stream corresponds to which 456 media configuration by including the configuration label as 457 part of the SDES item SRCNAME 458 [I-D.westerlund-avtext-rtcp-sdes-srcname] information include 459 in the RTP and RTCP packets. The optional mechanism for source 460 specific signalling defined in SRCNAME could be used to let 461 Simulcast sender pre-announce such a relationship before 462 sending the Source Packet Stream. 464 o Adding Simulcast information to the Source Packet Stream: 466 * Identifying Source Packet Streams from same Media Source using 467 the new RTCP SDES Item SRCNAME 468 [I-D.westerlund-avtext-rtcp-sdes-srcname], and as described 469 there including the possibility to send the same information as 470 an RTP Header Extension [RFC5285]. 472 * Using PAUSE/RESUME [I-D.westerlund-avtext-rtp-stream-pause] 473 functionality to temporarily turn individual Simulcast versions 474 on or off. 476 6. Proposed Signaling 477 This section further details the signaling solution outlined above 478 (Section 5). 480 6.1. Simulcast Capability 482 There are numerous media properties that can be varied to construct a 483 set of Simulcast versions. A Simulcast enabled endpoint could also 484 support Simulcast based on several of those properties. As long as 485 those properties are relatively independent and if each Simulcast 486 version need explicit definition in the SDP, this would lead to an 487 exponential number of Simulcast version candidates and a very long 488 SDP that is likely also hard to interpret. There is thus a need to 489 limit the Simulcast version candidates included in the SDP to cover 490 as small set of properties as possible. 492 If a legacy endpoint not supporting Simulcast were to be presented 493 with an SDP including media descriptions for a set of Simulcast 494 versions, it may not know how to correctly handle or interpret these 495 "surplus" media descriptions. 497 Based on the functionality that Simulcast is intended to achieve, it 498 should be clear that the reasons to send Simulcast versions are not 499 the same as to receive Simulcast versions, seen from a single 500 endpoint. 502 For these reasons, it is proposed to define two new SDP session level 503 attributes, "a=sim-send-cap" and "a=sim-recv-cap", which explicitly 504 signal support for Simulcast media transmission and Simulcast media 505 reception, respectively, for that media description. "a=sim-send- 506 cap" and "a=sim-recv-cap" MAY be used independently and 507 simultaneously. These attributes are also proposed to have 508 parameters indicating the media properties used to create the 509 Simulcast versions, and their preferred ranking. The meaning of the 510 attributes on SDP media level is undefined and MUST NOT be used. 512 simulcast-cap = "a="( "sim-send-cap:" / "sim-recv-cap:" ) 513 cap-prop-list 514 cap-prop-list = cap-prop-entry *(WSP cap-prop-entry) 515 cap-prop-entry = cap-prop ["=" q-value] 516 cap-prop = "rtpmap" 517 / "fmtp" 518 / "imageattr" 519 / "framerate" 520 / token ; for future extensions 521 q-value = ( "0" "." 1*2DIGIT ) 522 / ( "1" "." 1*2("0") ) 523 ; Values between 0.00 and 1.00 524 ; WSP and DIGIT defined in [RFC5234] 525 ; token defined in [RFC4566] 527 Figure 1: ABNF for Simulcast Capability 529 The media property values are taken from existing (and could be 530 extended to cover other or future) SDP attributes that express media 531 properties that can be varied to create different Simulcast versions: 533 rtpmap: Differences in codec type, sampling rate (see Section 4), 534 and number of channels. 536 fmtp: Differences in codec-specific encoding parameters. 538 imageattr: Differences in video resolution and aspect ratio 539 [RFC6236]. 541 framerate: Differences in framerate. 543 The optional q-value expresses the relative preference to base a 544 Simulcast version on that media property, with 1.00 meaning maximum 545 (100%) preference and 0.00 meaning no (0%) preference. Several media 546 properties can share the same q-value, in which case they are equally 547 preferred. Not including any q-value for a media property value 548 SHALL default to a q-value of 1.00. 550 The list of media properties is made extensible, to allow introducing 551 additional dimensions for Simulcast versions. 553 6.1.1. Declarative Use 555 When used as a declarative media description, sim-recv-cap indicates 556 the configured end-point's required capability to recognize and 557 receive a specified set of Source Packet Streams as Simulcast 558 streams. In the same fashion, sim-send-cap requests the end-point to 559 send a specified set of Source Packet Streams as Simulcast streams. 560 sim-recv-cap and sim-send-cap MAY be used independently and at the 561 same time and they need not specify the same capability properties. 563 6.1.2. Offer/Answer Use 565 An offerer wanting to use Simulcast SHALL include either one or both 566 of those attributes, depending on in which direction(s) Simulcast is 567 both supported and desirable. An offerer that receives an answer 568 without "a=sim-send-cap" or "a=sim-recv-cap" MUST NOT define or use 569 any Simulcast alternatives in that direction to the answerer. 571 An answerer that does not understand the concept of Simulcast will 572 also not know those attributes and will remove them in the SDP 573 answer, as defined in existing SDP Offer/Answer procedures. An 574 answerer that does understand the attributes and that wants to 575 support Simulcast in the indicated direction SHALL reverse 576 directionality of the attribute; "sim-send-cap" becomes "sim-recv- 577 cap" and vice versa, and include it in the answer. 579 An offerer that intends to send Simulcast alternatives and thus 580 includes "a=sim-send-cap", MUST also include at least one media 581 property parameter that it intends to use to construct the Simulcast 582 alternatives, but it MAY include more media property parameters. 583 Including multiple media property parameters in "a=sim-send-cap" 584 SHALL be interpreted as an offer to send Simulcast versions covering 585 all combinations thereof, but MAY be further restricted by other 586 information in the SDP such as for example the number of simulcast- 587 related media descriptions in the SDP or use of max-ssrc signaling 588 [I-D.westerlund-mmusic-max-ssrc]. 590 An offerer that is capable of receiving Simulcast alternatives and 591 thus includes "a=sim-recv-cap", MUST also include at least one media 592 property parameter that it is willing to use as discriminator between 593 received Simulcast alternatives, but MAY include more media property 594 parameters. Including multiple media property parameters in "a=sim- 595 recv-cap" SHALL be interpreted as an offer to receive Simulcast 596 versions covering all combinations thereof, but MAY be further 597 restricted by other information in the SDP such as for example the 598 number of simulcast-related media descriptions in the SDP or use of 599 max-ssrc signaling [I-D.westerlund-mmusic-max-ssrc]. 601 An answerer that either lacks the capability or does not desire to 602 use Simulcast versions based on a certain media property parameter in 603 a specific direction MUST remove such media property parameter from 604 "a=sim-send-cap" or "a=sim-recv-cap". The answerer MUST NOT add any 605 media property parameters that were not included in the offer. 607 An answerer SHOULD take the offerer's q-values into account when 608 choosing which media configurations (Section 6.2) to include in the 609 answer and how to group them (Section 6.3) into the resulting 610 Simulcast(s). 612 6.2. Media Configuration 614 Media that constitutes a Simulcast version has certain desirable 615 characteristics that is meant to suit one category of diverse 616 receivers (Section 3.1). A receiver that is willing to receive 617 Simulcast streams must be given sufficient means to express what it 618 is capable of and desires to receive. A sender that is willing to 619 send Simulcast streams must similarly be given sufficient means to 620 express what it is capable of and desires to send. 622 An obvious candidate to express those characteristics is the media 623 format in an SDP media description, defined by the rtpmap and fmtp 624 attributes, which is typically mapped to an RTP Payload Type. Some 625 of the most interesting characteristics for Simulcast purposes are 626 however not included in rtpmap or fmtp, but are instead defined as 627 separate attributes. Some of those individual attributes are 628 possible to directly relate to a defined media format and could form 629 a configuration together with the media format, but some attributes 630 cannot be related to a specific media format and using the existing 631 media format as a common identifier for a media configuration is not 632 fully sufficient. 634 The act of Simulcast is trying to handle senders and receivers 635 belonging to the vast multi-dimensional parameter space of "media 636 configuration" by sub-dividing that parameter space into manageable 637 and meaningful sub-sets. Communication between a sender and a 638 receiver can be established successfully only when the actually sent 639 media configuration (sub-set) fits within the receiver's available 640 media configuration sub-set. At the same time, practical and 641 implementation aspects often limits the size of those sub-sets. When 642 that receiver or sender sub-set is either too small or is not known, 643 the probability of successful communication decreases significantly. 644 To increase the probability of finding a match between sender and 645 receiver media configurations, it is essential that a media 646 configuration can be a set instead of a single point in the parameter 647 space, i.e. include parameter listings and/or ranges instead of 648 single values. 650 Therefore, it is proposed to define a new media level SDP attribute, 651 "a=config-id", which has relate the needed parameter types and the 652 corresponding value ranges that together constitute a Simulcast media 653 configuration. Each SDP media description MAY contain zero or more 654 config-id attributes. The meaning of the attribute on SDP session 655 level is undefined and MUST NOT be used. 657 configuration = "a=config-id:" config-id WSP config-dir 658 WSP config-list 659 config-id = token 660 config-dir = "send" 661 / "recv" 662 config-list = config-entry *(WSP config-entry) 663 config-entry = "pt" "=" pt-value *("," pt-value) 664 / image-attr 665 / "framerate" "=" fr-param 666 / "b" "=" bw-mod ":" bw-value *1("-" bw-value) 667 / ext-config-id [ "=" ext-config-value ] 668 ; for future ext 669 image-attr = "imageattr" "=" resolution-list 670 resolution-list = resolution-set *("," resolution-set) 671 ext-config-id = token 672 ext-config-value = non-ws-string 673 pt-value = 1*3DIGIT ; could be made more strict 674 resolution-set = "[" "x=" xyrange "," "y=" xyrange *key-values "]" 675 key-values = ( "," key-value ) 676 key-value = ( "sar=" srange ) 677 / ( "par=" prange ) 678 / ( "q=" qvalue ) 679 onetonine = "1" / "2" / "3" / "4" / "5" 680 / "6" / "7" / "8" / "9" 681 xyvalue = onetonine *5DIGIT 682 step = xyvalue 683 xyrange = ( "[" xyvalue ":" [ step ":" ] xyvalue "]" ) 684 / ( "[" xyvalue 1*( "," xyvalue ) "]" ) 685 / ( xyvalue ) 686 spvalue = ( "0" "." onetonine *3DIGIT ) 687 / ( onetonine "." 1*4DIGIT ) 688 srange = ( "[" spvalue 1*( "," spvalue ) "]" ) 689 / ( "[" spvalue "-" spvalue "]" ) 690 / ( spvalue ) 691 prange = ( "[" spvalue "-" spvalue "]" ) 692 qvalue = ( "0" "." 1*2DIGIT ) 693 / ( "1" "." 1*2("0") ) 694 fr-param = fr-value *("," fr-value) 695 / fr-value "-" fr-value 696 fr-value = 1*3DIGIT [ "." 1*2DIGIT ] 697 bw-mod = "AS" 698 / "TIAS" 699 / token ; for future extensions 700 bw-value = 1*DIGIT 701 ; WSP, DQUOTE and DIGIT defined in [RFC5234] 702 ; token and non-ws-string defined in [RFC4566] 704 Figure 2: ABNF for Media Configuration 706 A media configuration is thus identified by: 708 config-id: A token that identifies the media configuration, which 709 MUST be unique across all media configurations and media 710 descriptions in the SDP. 712 config-dir: The direction for the stream(s) receiving the media 713 configuration, as seen from the part issuing the SDP. 715 The media configuration MUST contain at least one and MAY contain 716 more of the below media configuration entries. Each entry type MUST 717 NOT appear more than once in every media configuration. 719 pt: A comma-separated list of media formats, RTP payload types, 720 which MUST be defined within the same media description as config- 721 id. This describes the allowed set of codecs or codec 722 configurations for this media configuration. MUST be present in 723 every media configuration. 725 imageattr: An OPTIONAL listing of preferred image resolutions for 726 this media configuration. MUST NOT be used with other than video 727 and image media types. An imageattr media configuration entry 728 MUST NOT conflict with any "a=imageattr" attribute present in the 729 same media description. 731 framerate: An OPTIONAL range or enumeration of preferred framerates 732 for this media configuration. MUST NOT be used with other than 733 video media types. The high end of the range MUST be equal to or 734 larger than the low end. An enumerating framerate media 735 configuration entry MUST include the value of the "a=framerate" 736 attribute, if any. A framerate range media configuration entry 737 MUST include the "a=framerate" value in the range. 739 b: An acceptable bandwidth range for this media configuration. 740 Either one of the defined bandwidth modifiers MAY be used, which 741 MUST share semantics with corresponding bandwidth modifiers from 742 the SDP bandwidth attribute. The bandwidth value MUST be 743 interpreted as defined by the bandwidth modifier. The high end of 744 the range MUST be equal to or larger than the low end. The high 745 end of the range MUST NOT exceed the bandwidth parameter in the 746 same media description, if any. The sum of bandwidth range low 747 ends for all media configurations within a media description MUST 748 NOT exceed the value of that media description's bandwidth 749 parameter. MUST be present in every media configuration. 751 Media configuration entry types "pt" and "b" MUST be supported by all 752 implementations of this specification. Otherwise, an implementation 753 MAY ignore any media configuration entry types that are not 754 understood. A media configuration MAY be re-used to describe more 755 than a single Source Packet Stream. 757 6.2.1. Simulcast Limitations 759 The Session and Media level attributes and parameters outside of 760 individual media configurations (a=config-id) provides limitations on 761 the set of media configurations in simultanuous use. For example a 762 media description bandwidth limitation using b=AS would apply on all 763 the Packet Streams sent within the scope of that media description, 764 thus forcing the sum of the media configuration bandwidth in use to 765 share that available bandwidth. Don't forget other Packet Streams 766 such as RTP retransmission or FEC flows that also needs to be 767 included. 769 There exist a number of different limitations, and this section does 770 not intend to be complete. The payload formats and their 771 configurations can offer limitations, for example video profile and 772 levels imposes a joint limit on bit-rate, frame-rate and resolution. 773 The bandwidth parameters on session and media description level apply 774 according to their semantics and their level. Packetization 775 limitations, e.g. maxptime, as well as recommendations apply to all 776 the configurations within the scope where this parameter is defined. 778 It is important to note that limits, such as bandwidth expressed 779 within a media configuration are not limited by the media description 780 values. First of all, the sum of bit-rates across all media 781 configurations in a media description can be greater than the media 782 description limit as not all configurations may be in simultanuous 783 use. For example, only a single configuration can be enabled, which 784 is then allowed to consume the full outer limit. Secondly, the media 785 configuration directionality needs to be taken into account, for 786 example that SDP receiver limitations are not applied to the sender 787 configuration. 789 6.2.2. Declarative Use 791 When used as a declarative media description, config-id with recv 792 parameter indicates the configured end-point's required media 793 configuration to receive a specified set of Source Packet Streams as 794 Simulcast streams. In the same fashion, config-id with send 795 parameter requests the end-point to use the specified media 796 configuration when sending a specified set of Source Packet Streams 797 as Simulcast streams. 799 6.2.3. Offer/Answer Use 801 An offerer wanting to use Simulcast in a specific direction SHALL use 802 config-id to describe the media configurations to use in that 803 direction in the Offer. 805 An answerer receiving a config-id media configuration for a specific 806 direction, accepting to use that media configuration SHALL include a 807 corresponding media configuration with the reverse direction in the 808 Answer. The config-id identification value MUST be kept between the 809 Offer and the Answer. An answerer not accepting to use a specific 810 media configuration SHALL remove it from the Answer. 812 The Answer MUST keep exactly the same media configuration types in a 813 media configuration as were present in the corresponding media 814 configuration in the Offer. 816 The answerer MAY remove values from enumerations and MAY reduce 817 ranges of media configuration entries in the Answer. If the reduced 818 media configuration entry relates to the answerer's send direction, 819 negotiation is complete and no further action is needed. If the 820 reduced media configuration relates to the answerer's receive 821 direction, the offerer SHOULD send another Offer where that related, 822 send direction media configuration is reduced at least to the level 823 in the previous Answer, but MAY be reduced even more, and MAY be 824 removed entirely. 826 6.3. Grouping Simulcast Configurations 828 A set of media configurations (Section 6.2) is needed to describe a 829 Simulcast. Each Source Packet Stream in the Simulcast share the same 830 Media Source, but have different media configurations. Thus, the 831 actual grouping of media configurations is what defines a specific 832 Simulcast. It is proposed to define two new media level and session 833 level SDP attributes, "a=sim-send" and "a=sim-recv", which uses 834 config-id values to group media configurations for the purpose of 835 Simulcast transmission and reception, respectively. "a=sim-send" and 836 "a=sim-recv" MAY be used independently and simultaneously. They MAY 837 be used on session level to group media configurations when different 838 Simulcast encodings of a Media Source are to be sent in different 839 Media Transports and RTP sessions. They MAY also be used on media 840 level to group media configurations when different Simulcast 841 encodings of a Media Source are to be sent based on the same media 842 description and thus use the same Media Transport and RTP session. 843 When used on media level, the Simulcast direction MAY conflict with 844 the general media description direction, but a conflict MUST be 845 interpreted as the Simulcast being effectively inhibited. For 846 example, sim-send in a recvonly media description means that no 847 Simulcast Source Packet Streams are sent. 849 simulcast = "a="( "sim-send:" / "sim-recv:" ) config-id-list 850 config-id-list = config-item *(WSP config-item) 851 config-item = config-id [":" config-param-list] 852 config-id = token 853 config-param-list = config-param *("," config-param) 854 config-param = "inactive" 855 / token ["=" param-value] ; for future extension 856 param-value = 1*(value-char) 857 / DQUOTE non_ws_string DQUOTE 858 value-char = token-char / %x28 / %x29 / %x2F / %x3A-3C 859 / %x3E-40 / %x5B-5D ; VCHAR except "=" and "," 861 ; WSP and VCHAR defined in [RFC5234] 862 ; token, token-char and non_ws_string defined in [RFC4566] 864 Figure 3: ABNF for Simulcast Configuration Grouping 866 The config-id identification of a media configuration MUST be defined 867 by a "config-id" attribute in any of the media descriptions that are 868 part of the SDP. 870 6.3.1. Declarative Use 872 When used as a declarative media description, sim-recv indicates the 873 configured end-point's required ability to receive Source Packet 874 Streams with the specified set of media configurations as Simulcast 875 streams. In the same fashion, sim-send requests the end-point to 876 send Source Packet Streams with the specified set of media 877 configurations as Simulcast streams. 879 The configuration parameter "inactive" SHALL be interpreted as the 880 related Source Packet Stream is in PAUSED state 881 [I-D.westerlund-avtext-rtp-stream-pause] at the start of the session, 882 and applicable RTP level procedures from that specification SHALL be 883 applied. 885 6.3.2. Offer/Answer Use 887 An offerer wanting to send a set of Source Packet Streams as 888 Simulcast streams includes sim-send in the Offer to describe which 889 media configurations to use for that Simulcast. Similarly, an 890 offerer wanting to receive a set of Source Packet Streams as 891 Simulcast streams includes sim-recv in the Offer to describe which 892 media configurations to use for that Simulcast. 894 An answerer receiving sim-send, accepting to receive those media 895 configurations as Simulcasted Source Packet Streams SHALL include 896 sim-recv with the accepted media configurations in the Answer. 897 Similarly, an answerer receiving sim-recv, accepting to send those 898 media configurations as Simulcasted Source Packet Streams SHALL 899 include sim-send with the accepted media configurations in the 900 Answer. An answerer MAY remove media configurations from sim-send or 901 sim-recv included in the Answer compared to the ones included in the 902 sim-send or sim-recv in the Offer. The answerer MUST NOT add any 903 media configurations to sim-send or sim-recv in the Answer that were 904 not in the corresponding ones in the Offer. 906 An "inactive" parameter present in the Offer MUST be kept in the 907 Answer. The Answer MAY add an "inactive" parameter to any of the 908 media configurations. An "inactive" parameter on a media 909 configuration in "sim-recv" is equivalent to a PAUSE (or in some 910 cases, an equivalent TMMBR 0) message 911 [I-D.westerlund-avtext-rtp-stream-pause] being sent for the received 912 Source Packet Stream at the start of the session, and applicable RTP 913 level procedures from that specification SHALL be applied. An 914 "inactive" parameter on a media configuration in "sim-send" is 915 equivalent to the related Source Packet Stream being in PAUSED state 916 at the start of the session, and applicable RTP level procedures 917 SHALL be applied. 919 The number of different Source Packet Streams used for a Simulcast 920 related to a single media description MUST NOT exceed the number of 921 listed media configurations in the corresponding sim-recv in that 922 media description sent by the media receiver. 924 6.4. Relating Simulcast Versions 926 To ensure that Simulcast Packet Streams can be related correctly on 927 RTP level, SDES SRCNAME [I-D.westerlund-avtext-rtcp-sdes-srcname] 928 MUST be used to label Simulcast versions belonging to the same Media 929 Source. The RTP Header Extension option of that specification MAY be 930 used with Simulcast. 932 The SRCNAME identifier for Simulcast MUST contain a first part that 933 uniquely identifies the Media Source within a given CNAME, followed 934 by a single "." (period) and the config-id as defined above 935 (Section 6.2). 937 The SRCNAME parameter to source-specific signaling [RFC5576] 938 ("a=ssrc") MAY be used for Source Packet Streams in the send 939 direction to relate SRCNAME to SSRC already in the SDP. 941 6.5. Two-Phase Negotiation 943 The new "a=sim-send-cap" and "a=sim-recv-cap" attributes MAY be 944 included in the SDP as an optional pre-stage in a two-phased 945 approach, where the pre-stage involves a first SDP Offer/Answer 946 procedure that only establishes Simulcast capability at both the 947 offerer and the answerer. This has the additional advantage to avoid 948 sending media descriptions related to Simulcast to an endpoint that 949 does not support simulcast. In case two Offer/Answer procedures are 950 already used for other reasons, it will not incur any significant 951 extra signaling round-trips. Such other two-phase techniques include 952 use of SIP OPTIONS, SIP UPDATE [RFC3311] with reliable provisional 953 responses, and BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation]. 955 Thus, when using the pre-stage Offer/Answer, it SHOULD NOT include 956 any simulcast-grouped media descriptions, which SHOULD then instead 957 be added in a main Offer/Answer phase. When using the pre-stage 958 Offer/Answer, half a signaling round-trip time can sometimes be saved 959 if main phase is initiated by the Simulcast receiver, meaning that 960 the endpoint that included "a=sim-recv" in the pre-stage SDP is the 961 offerer in the main phase. If both endpoints are Simulcast 962 receivers, it does not matter which endpoint sends the main Offer, 963 using regular Offer/Answer rules to handle any race conditions. 965 It is not possible to use any pre-stage to establish capability with 966 declarative SDP, in which case it SHALL be by-passed, using only the 967 main phase directly. 969 6.6. Signaling Examples 971 These examples are for a case of client to video conference service 972 using a centralized media topology with an RTP mixer. 974 +---+ +-----------+ +---+ 975 | A |<---->| |<---->| B | 976 +---+ | | +---+ 977 | Mixer | 978 +---+ | | +---+ 979 | F |<---->| |<---->| J | 980 +---+ +-----------+ +---+ 982 Figure 4: Four-party Mixer-based Conference 984 6.6.1. Unified Plan Client 986 Alice is calling in to the mixer with a Simulcast-enabled Unified 987 Plan client capable of a single Media Source per media type. The 988 only difference to a non-Simulcast client is capability to send video 989 resolution [RFC6236] ("imageattr") and framerate based Simulcast. 990 Alice uses a pre-stage Offer, which looks like: 992 v=0 993 o=alice 2362969037 2362969040 IN IP4 192.0.2.156 994 s=Simulcast Enabled Unified Plan Client 995 t=0 0 996 c=IN IP4 192.0.2.156 997 b=AS:665 998 a=sim-send-cap:imageattr framerate 999 m=audio 49200 RTP/AVP 96 8 1000 b=AS:145 1001 a=rtpmap:96 G719/48000/2 1002 a=rtpmap:8 PCMA/8000 1003 m=video 49300 RTP/AVP 97 1004 b=AS:520 1005 a=rtpmap:97 H264/90000 1006 a=fmtp:97 profile-level-id=42c01e 1007 a=imageattr:97 send [x=640,y=360] [x=320,y=180] \ 1008 recv [x=640,y=360] [x=320,y=180] 1010 Figure 5: Unified Plan Simulcast Pre-Stage Offer 1012 In this pre-stage, the only thing in the SDP that indicates Simulcast 1013 capability is the line in the video media description containing the 1014 "sim-send-cap" attribute, which also indicates that sent Simulcast 1015 versions can differ in video resolution and/or framerate. 1017 The Answer from the server indicates both that it too is Simulcast 1018 capable and that it would prefer to use video resolution 1019 ("imageattr") based Simulcast, but that it supports both video 1020 resolution and framerate. Should it not have been Simulcast capable, 1021 the "a=sim-recv-cap" line would not have been present and 1022 communication would have started with the media negotiated in the 1023 SDP. 1025 v=0 1026 o=server 823479283 1209384938 IN IP4 192.0.2.2 1027 s=Answer to Simulcast Enabled Unified Plan Client 1028 t=0 0 1029 c=IN IP4 192.0.2.43 1030 b=AS:665 1031 a=sim-recv-cap:imageattr=1.0 framerate=0.8 1032 m=audio 49200 RTP/AVP 96 1033 b=AS:145 1034 a=rtpmap:96 G719/48000/2 1035 m=video 49300 RTP/AVP 97 1036 b=AS:520 1037 a=rtpmap:97 H264/90000 1038 a=fmtp:97 profile-level-id=42c01e 1039 a=imageattr:97 send [x=640,y=360] [x=320,y=180] \ 1040 recv [x=640,y=360] [x=320,y=180] 1042 Figure 6: Unified Plan Simulcast Pre-Stage Answer 1044 Since the server is the Simulcast media receiver, it immediately 1045 initiates another Offer/Answer including details on the Simulcast 1046 versions. The server also keeps the "sim-recv-cap" as explicit 1047 Simulcast capability indication in this main Offer/Answer. Note that 1048 the "non-simulcast" media can be started already now, before the main 1049 Offer/Answer, with the only restriction that the Simulcast 1050 functionality is not yet established. 1052 v=0 1053 o=server 823479283 1209384938 IN IP4 192.0.2.2 1054 s=Server Inviting Simulcast Enabled Unified Plan Client 1055 t=0 0 1056 c=IN IP4 192.0.2.43 1057 b=AS:825 1058 a=sim-recv-cap:imageattr=1.0 framerate=0.8 1059 m=audio 49200 RTP/AVP 96 1060 b=AS:145 1061 a=rtpmap:96 G719/48000/2 1062 m=video 49300 RTP/AVP 97 1063 b=AS:2200 1064 a=rtpmap:97 H264/90000 1065 a=fmtp:97 profile-level-id=42c01e 1066 a=config-id:a recv pt=97 imageattr=[x=640,y=360],[x=1280,y=720] \ 1067 framerate=25-60 b=AS:500-2500 1068 a=config-id:b recv pt=97 imageattr=[x=320,y=180],[x=640,y=360] \ 1069 framerate=25-60 b=AS:150-500 1070 a=config-id:c recv pt=97 imageattr=[x=256,y=144],[x=320,y=180] \ 1071 framerate=10-30 b=AS:100-250 1072 a=sim-recv:a b c 1074 Figure 7: Unified Plan Simulcast Main Offer 1076 The server chooses to structure the Answer according to Unified Plan 1077 and has added three config-id lines in the video media description, 1078 one for each Simulcast media configuration that it is prepared to 1079 receive. Each media configuration refers to a defined media format, 1080 and lists a set of preferred video resolutions as well as a range of 1081 acceptable framerates, concluded by a bandwidth range. It also 1082 includes the sim-recv attribute for those three media configurations, 1083 indicating that the Simulcast it is prepared to receive in this media 1084 description can include one or more of those media configurations. 1086 Alice's Answer is: 1088 v=0 1089 o=alice 2362969037 2362969040 IN IP4 192.0.2.156 1090 s=Final answer from Simulcast Enabled Unified Plan Client 1091 t=0 0 1092 c=IN IP4 192.0.2.156 1093 b=AS:825 1094 a=sim-send-cap:imageattr framerate 1095 m=audio 49200 RTP/AVP 96 1096 b=AS:145 1097 a=rtpmap:96 G719/48000/2 1098 m=video 49300 RTP/AVP 97 1099 b=AS:520 1100 a=rtpmap:97 H264/90000 1101 a=fmtp:97 profile-level-id=42c01e 1102 a=config-id:b send pt=97 imageattr=[x=640,y=360] \ 1103 framerate=25-30 b=AS:150-400 1104 a=config-id:c send pt=97 imageattr=[x=320,y=180] \ 1105 framerate=10-12.5 b=AS:100-150 1106 a=sim-send:b c:inactive 1107 a=ssrc:31053821 cname=SDIe93850aQFid9P srcname=1.b 1108 a=ssrc:43298172 cname=SDIe93850aQFid9P srcname=1.c 1109 a=imageattr:97 send [x=640,y=360] [x=320,y=180] \ 1110 recv [x=640,y=360] [x=320,y=180] 1112 Figure 8: Unified Plan Simulcast Main Answer 1114 The Simulcast capability, sim-send-cap, is kept from Alice's previous 1115 Offer. One of the media configurations from the server Offer, 1116 config-id:a, is not acceptable to Alice's client for some reason and 1117 is removed from the Answer. The resulting Simulcast, described by 1118 sim-send, thus contains two media configurations, b and c, where c is 1119 initially set to "inactive" that effectively means it is paused from 1120 the start of the session. The media configuration parameter value 1121 ranges are in some cases reduced, which makes a more precise 1122 definition of what will actually be sent. This Answer SDP also 1123 includes a specification of the SSRC values that will be sent and 1124 what media configurations those SSRC will carry, by including the 1125 srcname parameter. The first part of srcname, before the ".", is the 1126 Media Source identification. Both SSRC share the same Media Source 1127 identification, since they are part of the same Simulcast. The 1128 second part, after the ".", is the config-id of the media 1129 configuration sent with that SSRC. 1131 6.6.2. Multi-Transport Client 1133 Bob is calling in to the mixer with a Simulcast-enabled client, like 1134 Alice's capable of a single Media Source per media type, but also 1135 capable of sending Source Packet Streams as Simulcast versions on 1136 separate Media Transports. In this example, Bob's client knows that 1137 the server is capable of Simulcast and does not use any pre-stage 1138 Offer, but goes straight to the main Offer. 1140 v=0 1141 o=bob 94572932847 3429478298 IN IP4 192.0.2.93 1142 s=Offer from Simulcast Enabled Multi-Transport Client 1143 t=0 0 1144 c=IN IP4 192.0.2.93 1145 b=AS:825 1146 a=sim-send-cap:imageattr=1.0 framerate=0.9 1147 a=sim-send:x y 1148 m=audio 50138 RTP/AVP 101 1149 b=AS:145 1150 a=rtpmap:101 G719/48000/2 1151 m=video 50226 RTP/AVP 118 1152 b=AS:500 1153 a=rtpmap:118 H264/90000 1154 a=fmtp:118 profile-level-id=42c01e 1155 a=config-id:x send pt=118 imageattr=[x=320,y=180],[x=640,y=360] \ 1156 framerate=25-50 b=AS:200-500 1157 a=ssrc:3929384298 cname=Nsdko39Oen828FKn srcname=M.x 1158 a=imageattr:118 send [x=640,y=360] [x=320,y=180] \ 1159 recv [x=640,y=360] [x=320,y=180] 1160 m=video 50228 RTP/AVP 119 1161 b=AS:150 1162 a=config-id:y send pt=119 imageattr=[x=256,y=144],[x=320,y=180] \ 1163 framerate=12.5-25 b=AS:100-200 1164 a=ssrc:1923419284 cname=Nsdko39Oen828FKn srcname=M.y 1165 a=imageattr:119 send [x=320,y=180] [x=256,y=144] 1166 a=sendonly 1168 Figure 9: Multi-Transport Simulcast Main Offer 1170 As can be seen from above, this Offer uses sim-send on session level 1171 and has split the Simulcast media configurations on two media 1172 descriptions, in order to be able to use separate Media Transports 1173 and enable differentiated treatment of the two Simulcast streams. 1175 The server accepts this structure to the Answer: 1177 v=0 1178 o=server 283479882 9384298374 IN IP4 192.0.2.2 1179 s=Server Answering Simulcast Enabled Multi-Transport Client 1180 t=0 0 1181 c=IN IP4 192.0.2.45 1182 b=AS:825 1183 a=sim-recv-cap:imageattr framerate 1184 a=sim-recv:x y 1185 m=audio 49200 RTP/AVP 96 1186 b=AS:145 1187 a=rtpmap:96 G719/48000/2 1188 m=video 49300 RTP/AVP 118 1189 b=AS:500 1190 a=rtpmap:118 H264/90000 1191 a=fmtp:118 profile-level-id=42c01e 1192 a=config-id:x recv pt=118 imageattr=[x=640,y=360] \ 1193 framerate=25-50 b=AS:350-500 1194 a=imageattr:118 send [x=640,y=360] [x=320,y=180] \ 1195 recv [x=640,y=360] [x=320,y=180] 1196 m=video 49300 RTP/AVP 119 1197 b=AS:150 1198 a=rtpmap:119 H264/90000 1199 a=fmtp:119 profile-level-id=42c01e 1200 a=config-id:y recv pt=119 imageattr=[x=256,y=144] \ 1201 framerate=12.5-25 b=AS:120-150 1202 a=imageattr:119 recv [x=320,y=180] [x=256,y=144] 1203 a=recvonly 1205 Figure 10: Multi-Transport Simulcast Main Answer 1207 6.6.3. Multi-Source Client 1209 Fred is calling in to the same conference as in the examples above 1210 with a three-camera, three-display system, thus capable of handling 1211 three separate Media Sources in each direction, where each Media 1212 Source is also Simulcast-enabled in the send direction. Fred's 1213 client is a Unified Plan client, restricted to a single Media Source 1214 per media description. 1216 v=0 1217 o=fred 238947129 823479223 IN IP4 192.0.2.125 1218 s=Offer from Simulcast Enabled Multi-Source Client 1219 t=0 0 1220 c=IN IP4 192.0.2.125 1221 b=AS:825 1222 a=sim-send-cap:imageattr=1.0 framerate=0.5 1224 m=audio 49200 RTP/AVP 98 1225 b=AS:145 1226 a=rtpmap:98 G719/48000/2 1228 m=video 49600 RTP/AVP 100 1229 b=AS:3500 1230 a=rtpmap:100 H264/90000 1231 a=fmtp:100 profile-level-id=42c02a 1232 a=config-id:1h send pt=100 imageattr=[x=1920,y=1080] \ 1233 framerate=30-60 b=AS:2000-3500 1234 a=config-id:1m send pt=100 imageattr=[x=1280,y=720] \ 1235 framerate=15-60 b=AS:1000-2000 1236 a=config-id:1l send pt=100 imageattr=[x=640,y=360] \ 1237 framerate=10-60 b=AS:200-1000 1238 a=sim-send:1h 1m 1l 1239 a=ssrc:2397234521 cname=EkeS32892FeO29DK srcname=1.1h 1240 a=ssrc:1023894789 cname=EkeS32892FeO29DK srcname=1.1m 1241 a=ssrc:4029284928 cname=EkeS32892FeO29DK srcname=1.1l 1242 a=imageattr:100 send [x=1920,y=1080] [x=1280,y=720] [x=640,y=360] \ 1243 recv [x=1920,y=1080] [x=1280,y=720] [x=640,y=360] 1245 m=video 49600 RTP/AVP 100 1246 b=AS:3500 1247 a=rtpmap:100 H264/90000 1248 a=fmtp:100 profile-level-id=42c02a 1249 a=config-id:2h send pt=100 imageattr=[x=1920,y=1080] \ 1250 framerate=30-60 b=AS:2000-3500 1251 a=config-id:2m send pt=100 imageattr=[x=1280,y=720] \ 1252 framerate=15-60 b=AS:1000-2000 1253 a=config-id:2l send pt=100 imageattr=[x=640,y=360] \ 1254 framerate=10-60 b=AS:200-1000 1255 a=sim-send:2h 2m 2l 1256 a=ssrc:2301017618 cname=EkeS32892FeO29DK srcname=2.2h 1257 a=ssrc:639711316 cname=EkeS32892FeO29DK srcname=2.2m 1258 a=ssrc:3293473905 cname=EkeS32892FeO29DK srcname=2.2l 1259 a=imageattr:100 send [x=1920,y=1080] [x=1280,y=720] [x=640,y=360] \ 1260 recv [x=1920,y=1080] [x=1280,y=720] [x=640,y=360] 1262 m=video 49600 RTP/AVP 100 1263 b=AS:3500 1264 a=rtpmap:100 H264/90000 1265 a=fmtp:100 profile-level-id=42c02a 1266 a=config-id:3h send pt=100 imageattr=[x=1920,y=1080] \ 1267 framerate=30-60 b=AS:2000-3500 1268 a=config-id:3m send pt=100 imageattr=[x=1280,y=720] \ 1269 framerate=15-60 b=AS:1000-2000 1270 a=config-id:3l send pt=100 imageattr=[x=640,y=360] \ 1271 framerate=10-60 b=AS:200-1000 1272 a=sim-send:3h 3m 3l 1273 a=ssrc:4115355057 cname=EkeS32892FeO29DK srcname=3.3h 1274 a=ssrc:3196538337 cname=EkeS32892FeO29DK srcname=3.3m 1275 a=ssrc:3757973912 cname=EkeS32892FeO29DK srcname=3.3l 1276 a=imageattr:100 send [x=1920,y=1080] [x=1280,y=720] [x=640,y=360] \ 1277 recv [x=1920,y=1080] [x=1280,y=720] [x=640,y=360] 1279 Figure 11: Fred's Multi-Source Simulcast Main Offer 1281 The three media descriptions for video are essentially the same, 1282 except values that needs to be unique are provided unique values. 1283 The above also assumes that BUNDLE will be used across these three 1284 video media description to create a common RTP session. 1286 7. Network Aspects 1288 Simulcast is in defined as the act of sending multiple alternative 1289 encodings of the same underlying media source. When transmitting 1290 multiple independent streams that originate from the same source, it 1291 could potentially be done in several different ways using RTP. A 1292 general discussion on considerations for use of the different RTP 1293 multiplexing alternatives can be found in Guidelines for Multiplexing 1294 in RTP [I-D.ietf-avtcore-multiplex-guidelines]. Discussion and 1295 clarification on how to handle multiple streams in an RTP session can 1296 be found in [I-D.ietf-avtcore-rtp-multi-stream]. 1298 The network aspects that are relevant for Simulcast are: 1300 Quality of Service: When using Simulcast it might be of interest to 1301 prioritize a particular Simulcast version, rather than applying 1302 equal treatment to all versions. For example, lower bit-rate 1303 versions may be prioritized over higher bit-rate versions to 1304 minimize congestion or packet losses in the low bit-rate versions. 1305 Thus, there is a benefit to use a Simulcast solution that supports 1306 QoS as good as possible. By separating Simulcast versions into 1307 different RTP sessions and send those RTP sessions over different 1308 Media Transports, a Simulcast version can be prioritized by 1309 existing flow based QoS mechanisms. When using unicast, QoS 1310 mechanisms based on individual packet marking are also feasible, 1311 which do not require separation of Simulcast versions into 1312 different RTP sessions to apply different QoS. 1314 NAT/FW Traversal: Using multiple RTP sessions will incur more cost 1315 for NAT/FW traversal unless they can re-use the same transport 1316 flow, which can be achieved by either one of multiplexing multiple 1317 RTP sessions on a single lower layer transport 1318 [I-D.westerlund-avtcore-transport-multiplexing] or Multiplexing 1319 Negotiation Using SDP Port Numbers 1320 [I-D.ietf-mmusic-sdp-bundle-negotiation]. If flow based QoS with 1321 any differentiation is desirable, the cost for additional 1322 transport flows is likely necessary. 1324 Multicast: Multiple RTP sessions will be required to enable 1325 combining Simulcast with multicast. Different Simulcast versions 1326 have to be separated to different multicast groups to allow a 1327 multicast receiver to pick the version it wants, rather than 1328 receive all of them. In this case, the only reasonable 1329 implementation is to use different RTP sessions for each multicast 1330 group so that reporting and other RTCP functions operate as 1331 intended. 1333 8. IANA Considerations 1335 This document requests that five new attributes, sim-send-cap, sim- 1336 recv-cap, sim-send, sim-recv, and config-id. It is also requested to 1337 make a new registry of defined parameters taken from existing SDP 1338 attributes for sim-send-cap, sim-recv-cap, and config-id. 1340 Formal registrations to be written. 1342 9. Security Considerations 1344 The Simulcast capability and configuration attributes and parameters 1345 are vulnerable to attacks in signaling. 1347 A false inclusion of Simulcast attributes may result in generation of 1348 a second phase SDP that potentially contains a large number of non- 1349 supported media descriptions expressing Simulcast alternatives. A 1350 correct SDP implementation will however be able to reject any non- 1351 supported media descriptions and the effect from that should be 1352 limited. 1354 A hostile removal of the Simulcast attributes will result in skipping 1355 any second phase Offer/Answer and that Simulcast is not used. 1357 The Simulcast grouping semantics are vulnerable to attacks in the 1358 signalling. Changing the set of media configurations that are used 1359 in a Simulcast will impact the number of Source Packet Streams. 1361 A hostile removal of Simulcast grouping will prevent streams from 1362 being interpreted as Simulcast, which obviously prevents use of the 1363 Simulcast functionality. It will also risk that intended Simulcast 1364 streams are instead presented as separate, independent streams to a 1365 receiver. 1367 Neither of the above will likely have any major consequences and can 1368 be mitigated by signaling that is at least integrity and source 1369 authenticated to prevent an attacker to change it. 1371 10. Contributors 1373 Morgan Lindqvist and Fredrik Jansson, both from Ericsson, have 1374 contributed with important material to the first versions of this 1375 document. 1377 11. Acknowledgements 1379 12. References 1381 12.1. Normative References 1383 [I-D.westerlund-avtext-rtcp-sdes-srcname] 1384 Westerlund, M., "RTCP Source Description Item SRCNAME to 1385 Label Individual Media Sources", draft-westerlund-avtext- 1386 rtcp-sdes-srcname-03 (work in progress), October 2013. 1388 [I-D.westerlund-avtext-rtp-stream-pause] 1389 Akram, A., Burman, B., Grondal, D., and M. Westerlund, 1390 "RTP Media Stream Pause and Resume", draft-westerlund- 1391 avtext-rtp-stream-pause-03 (work in progress), October 1392 2012. 1394 [I-D.westerlund-mmusic-max-ssrc] 1395 Holmberg, C., Westerlund, M., and F. Jansson, "Multiple 1396 Synchronization Sources (SSRC) in SDP Media Descriptions", 1397 draft-westerlund-mmusic-max-ssrc-02 (work in progress), 1398 September 2013. 1400 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1401 Requirement Levels", BCP 14, RFC 2119, March 1997. 1403 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1404 UPDATE Method", RFC 3311, October 2002. 1406 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1407 Jacobson, "RTP: A Transport Protocol for Real-Time 1408 Applications", STD 64, RFC 3550, July 2003. 1410 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1411 Description Protocol", RFC 4566, July 2006. 1413 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 1414 Description Protocol (SDP) Security Descriptions for Media 1415 Streams", RFC 4568, July 2006. 1417 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 1418 Correction", RFC 5109, December 2007. 1420 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1421 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1423 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 1424 Header Extensions", RFC 5285, July 2008. 1426 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 1427 Media Attributes in the Session Description Protocol 1428 (SDP)", RFC 5576, June 2009. 1430 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1431 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 1433 [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image 1434 Attributes in the Session Description Protocol (SDP)", RFC 1435 6236, May 2011. 1437 12.2. Informative References 1439 [I-D.ietf-avtcore-multiplex-guidelines] 1440 Westerlund, M., Perkins, C., and H. Alvestrand, 1441 "Guidelines for using the Multiplexing Features of RTP to 1442 Support Multiple Media Streams", draft-ietf-avtcore- 1443 multiplex-guidelines-01 (work in progress), July 2013. 1445 [I-D.ietf-avtcore-rtp-multi-stream] 1446 Lennox, J., Westerlund, M., Wu, W., and C. Perkins, 1447 "Sending Multiple Media Streams in a Single RTP Session", 1448 draft-ietf-avtcore-rtp-multi-stream-01 (work in progress), 1449 July 2013. 1451 [I-D.ietf-avtcore-rtp-topologies-update] 1452 Westerlund, M. and S. Wenger, "RTP Topologies", draft- 1453 ietf-avtcore-rtp-topologies-update-00 (work in progress), 1454 April 2013. 1456 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1457 Holmberg, C., Alvestrand, H., and C. Jennings, 1458 "Multiplexing Negotiation Using Session Description 1459 Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp- 1460 bundle-negotiation-05 (work in progress), October 2013. 1462 [I-D.lennox-raiarea-rtp-grouping-taxonomy] 1463 Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, 1464 "A Taxonomy of Grouping Semantics and Mechanisms for Real- 1465 Time Transport Protocol (RTP) Sources", draft-lennox- 1466 raiarea-rtp-grouping-taxonomy-03 (work in progress), 1467 October 2013. 1469 [I-D.westerlund-avtcore-transport-multiplexing] 1470 Westerlund, M. and C. Perkins, "Multiple RTP Sessions on a 1471 Single Lower-Layer Transport", draft-westerlund-avtcore- 1472 transport-multiplexing-06 (work in progress), August 2013. 1474 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1475 with Session Description Protocol (SDP)", RFC 3264, June 1476 2002. 1478 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 1479 Multicast (SSM)", RFC 3569, July 2003. 1481 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1482 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1483 July 2006. 1485 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 1486 January 2008. 1488 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1489 (ICE): A Protocol for Network Address Translator (NAT) 1490 Traversal for Offer/Answer Protocols", RFC 5245, April 1491 2010. 1493 [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 1494 "RTP Payload Format for Scalable Video Coding", RFC 6190, 1495 May 2011. 1497 Appendix A. Discussion on Receiver Diversity 1499 Receiver diversity can be handled in a number of different ways, each 1500 with its own advantages and disadvantages. In that, there are 1501 relations between RTP Mixer processing requirement, bandwidth usage 1502 on uplink from sending Participant to RTP Mixer, bandwidth usage on 1503 downlink from RTP Mixer to receiving Participant, and media Quality 1504 of Experience at the receiving Participant. 1506 The following is a listing of possible approaches: 1508 1. Lowest Common Denominator: Create a single Source Packet Stream 1509 per Media Source and, assuming that everyone can receive a 1510 "simple" stream, adapt the characteristics of that Source Packet 1511 Stream already at the sending Participant to the lowest common 1512 denominator among all receiving Participants. Let the RTP Mixer 1513 forward this single Source Packet Stream to all receiving 1514 Participants. The advantages are low bandwidth usage on both 1515 uplink and downlink and low RTP Mixer processing requirements. 1516 The disadvantage is that the least capable receiver and/or 1517 network path dictates the (low) QoE for everyone else. 1519 2. Individual Transcoding: Create a single Source Packet Stream per 1520 Media Source with characteristics governed by resources available 1521 to the sending Participant and the network path to the RTP Mixer. 1523 Let the RTP Mixer transcode (decode and re-encode) that into 1524 individual Source Packet Streams for each receiving Participant, 1525 governed by the RTP Mixer resources, receiving Participant 1526 resources, and the network path to that Participant. The 1527 advantages are adapted although overall slightly lowered QoE (due 1528 to transcoding) to each Participant and optimised bandwidth usage 1529 on both uplink and downlink. The disadvantage is (very) high RTP 1530 Mixer processing requirements. 1532 3. Individual Simulcast: Create individual Source Packet Streams of 1533 each Media Source to each receiving Participant, constituting a 1534 complete individual Simulcast. Let the RTP Mixer forward each 1535 individual Source Packet Stream to the targeted receiving 1536 Participant. The advantages are low RTP Mixer processing and 1537 optimised downlink bandwidth. The disadvantage is (very) high 1538 uplink bandwidth. 1540 4. Grouped Simulcast: For each Media Source, create a "suitable" 1541 logical grouping of receiving Participants in sub-groups with 1542 respect to available receiver resources, for example the 1543 resources listed above (Section 3.1). Create a set of Source 1544 Packet Streams for this Media Source with well-chosen 1545 characteristics, where each Source Packet Stream in the set is a 1546 good-enough fit to the receiving sub-group of Participants. This 1547 set of Source Packet Streams constitutes a Simulcast of the Media 1548 Source. The size of the set and the characteristics of each 1549 Source Packet Stream can be adjusted to cater for various 1550 restrictions in the sending Participant, receiving Participants 1551 in the sub-group, and network path(s) to the Participants in the 1552 sub-group. Let the RTP Mixer forward the same Source Packet 1553 Stream to all Participants in a sub-group, for all Source Packet 1554 Streams and sub-groups. The advantages are low RTP Mixer 1555 processing, near optimum QoE, and near optimum downlink 1556 bandwidth. The disadvantages are high uplink bandwidth and 1557 arguably that downlink bandwidth and QoE are optimum only for a 1558 sub-group and not per individual receiving Participant. 1560 A summary of the advantages and disadvantages of the above four 1561 principle alternatives is given below (Table 1): 1563 +--------+-----------+-----------+--------------+--------------+ 1564 | Method | Mixer CPU | Uplink | Downlink | QoE | 1565 +--------+-----------+-----------+--------------+--------------+ 1566 | 1 | Low | Low | Low | Low | 1567 | 2 | Very high | Optimum | Optimum | Near optimum | 1568 | 3 | Low | Very high | Optimum | Optimum | 1569 | 4 | Low | High | Near optimum | Near optimum | 1570 +--------+-----------+-----------+--------------+--------------+ 1571 Table 1: Receiver Diversity Handling Comparison 1573 The authors of this document believes that alternative 4, the Grouped 1574 Simulcast, can be a good tradeoff whenever supported by sufficient 1575 uplink resources. 1577 Authors' Addresses 1579 Magnus Westerlund 1580 Ericsson 1581 Farogatan 6 1582 SE-164 80 Kista 1583 Sweden 1585 Phone: +46 10 714 82 87 1586 Email: magnus.westerlund@ericsson.com 1588 Bo Burman 1589 Ericsson 1590 Farogatan 6 1591 SE-164 80 Kista 1592 Sweden 1594 Phone: +46 10 714 13 11 1595 Email: bo.burman@ericsson.com 1597 Suhas Nandakumar 1598 Cisco 1599 170 West Tasman Drive 1600 San Jose, CA 95134 1601 USA 1603 Email: snandaku@cisco.com