idnits 2.17.1 draft-westerlund-avtcore-rtp-simulcast-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 : ---------------------------------------------------------------------------- -- 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 (February 25, 2013) is 4071 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC5234' is mentioned on line 613, but not defined == Outdated reference: A later version (-03) exists of draft-westerlund-avtext-rtcp-sdes-srcname-00 == Outdated reference: A later version (-02) exists of draft-westerlund-mmusic-max-ssrc-00 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-03 == Outdated reference: A later version (-02) exists of draft-lennox-avtcore-rtp-multi-stream-01 == Outdated reference: A later version (-03) exists of draft-westerlund-avtcore-multiplex-architecture-00 == Outdated reference: A later version (-07) exists of draft-westerlund-avtcore-transport-multiplexing-00 -- 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: 1 error (**), 0 flaws (~~), 8 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 M. Lindqvist 5 Expires: August 29, 2013 F. Jansson 6 Ericsson 7 February 25, 2013 9 Using Simulcast in RTP Sessions 10 draft-westerlund-avtcore-rtp-simulcast-02 12 Abstract 14 In some applications it may be necessary to send multiple media 15 encodings derived from the same media source in independent RTP media 16 streams. This is called Simulcast. This document discusses the best 17 way of accomplishing this in RTP and how to signal it in SDP. It is 18 concluded that a solution where the different simulcast versions are 19 based on separate SDP media descriptions provides best support for 20 simulcast. A solution is defined by making two extensions to SDP. 21 The first extension consists of two new attributes in SDP that 22 express capability to send or receive simulcast streams, 23 respectively. The second extension describes how to group media 24 descriptions belonging to the same simulcast source by using the 25 grouping framework. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 29, 2013. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 65 3. Simulcast Scenarios . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. Simulcasting to RTP Mixer . . . . . . . . . . . . . . . . 5 67 3.1.1. Simulcast Combined with Scalable Encoding . . . . . . 7 68 3.2. Multicast Transported Simulcasted Media . . . . . . . . . 7 69 3.2.1. Diversity in Receiver Population . . . . . . . . . . . 7 70 3.2.2. Bit-rate Adaptation . . . . . . . . . . . . . . . . . 8 71 3.3. Same Encoding to Multiple Destinations . . . . . . . . . . 9 72 3.4. Different Encoding to Independent Destinations . . . . . . 9 73 4. Network Aspects . . . . . . . . . . . . . . . . . . . . . . . 10 74 5. Simulcast Alternatives . . . . . . . . . . . . . . . . . . . . 10 75 5.1. Using the Payload Type . . . . . . . . . . . . . . . . . . 11 76 5.2. Using Single RTP session . . . . . . . . . . . . . . . . . 11 77 5.3. Using Multiple RTP sessions . . . . . . . . . . . . . . . 12 78 5.4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 12 79 6. Simulcast Signaling Proposal . . . . . . . . . . . . . . . . . 13 80 6.1. Simulcast Capability . . . . . . . . . . . . . . . . . . . 14 81 6.2. Grouping Simulcast Media Descriptions . . . . . . . . . . 16 82 6.2.1. Declarative Use . . . . . . . . . . . . . . . . . . . 16 83 6.2.2. Offer/Answer Use . . . . . . . . . . . . . . . . . . . 16 84 6.3. Two-Phase Negotiation . . . . . . . . . . . . . . . . . . 17 85 6.4. Media Stream Requirements . . . . . . . . . . . . . . . . 17 86 6.5. Relating Alternative Encodings . . . . . . . . . . . . . . 18 87 6.6. Multiple Stream handling . . . . . . . . . . . . . . . . . 18 88 7. Simulcast Signaling Examples . . . . . . . . . . . . . . . . . 18 89 7.1. Alice: Desktop Client . . . . . . . . . . . . . . . . . . 19 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 94 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 95 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 99 1. Introduction 101 Simulcast is the act of simultaneously sending multiple different 102 versions of the same media content, e.g. the same video source 103 encoded with different video encoders or target resolutions. This 104 can be done in several ways and for different purposes. This 105 document focuses on the case where one wants to provide multiple 106 streams with different encodings over RTP [RFC3550] towards an 107 intermediary so that the intermediary can select which encoding to 108 forward to other participants in the session, and more specifically 109 how the grouping of the streams is defined. From an RTP perspective, 110 simulcast is a specific application of the aspects discussed in RTP 111 Multiplexing Architecture 112 [I-D.westerlund-avtcore-multiplex-architecture]. 114 The different encodings of a media content that are considered in 115 this document can differ in: 117 Bit-rate: The difference is the amount of bits spent to encode the 118 media thus giving different quality. 120 Codec: Different media codecs are used to ensure that different 121 receivers that do not have a common set of decoders can decode at 122 least one of the versions. This can include codec configuration 123 options that are not compatible, like video encoder profiles, or 124 the capability of receiving the transport packetization. 126 Sampling: Different sampling of media, in spatial as well as in 127 temporal domain, may be used to suit different rendering 128 capabilities or needs at the receiving endpoints, as well as a 129 method to achieve different bit-rates. For video streams, spatial 130 sampling affects image resolution and temporal sampling affects 131 video frame rate. For audio, spatial sampling relates to the 132 number of audio channels and temporal sampling affects audio 133 bandwidth. Obviously, a difference in sampling may result in 134 difference in bit-rate. 136 There are different reasons for an application to provide multiple 137 different encodings of a single media source. As soon as an 138 application has the need to send multiple encodings, there is a 139 potential need for simulcast. This need can arise even when using 140 media codecs that have scalability features built in. The purpose of 141 this document is to describe a few scenarios where it is motivated to 142 use simulcast, elaborate on possible alternatives and available 143 mechanisms, and find a suitable solution for signaling and performing 144 RTP simulcast. The discussion results in a signaling proposal to 145 support simulcast. 147 2. Definitions 149 2.1. Terminology 151 The following terms and abbreviations are used in this document: 153 Encoding: A particular encoding is the choice of the media encoder 154 (codec) that has been used to compress the media and the fidelity 155 of that encoding through the choice of sampling, bit-rate and 156 other codec configuration parameters. 158 Different encodings: An encoding is different when some parameter 159 that characterize the encoding of a particular media source is 160 changed. Such changes can be one or more of the following 161 parameters; codec, codec configuration, bit-rate, sampling. 163 Simulcast versions: Media streams used for simulcast that use 164 different encodings and thus constitute different versions of the 165 same media source. 167 2.2. Requirements Language 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in RFC 2119 [RFC2119]. 173 3. Simulcast Scenarios 175 This section discusses different usage scenarios for the term 176 simulcast and clarifies which of those this document focuses on. It 177 also reviews why simulcast and scalable codecs can be a useful 178 combination. 180 3.1. Simulcasting to RTP Mixer 182 This scenario relates to a multi-party session where one or more 183 central nodes are used to facilitate the media transport between the 184 session participants. Thus, this targets the RTP Mixer Topology 185 defined in [RFC5117] (Section 3.4: Topo-Mixer). This scenario is 186 targeted for further discussion in this document. 188 Simulcasting different media encodings of video that differ both in 189 resolution and in bit-rate is highly applicable to video conferencing 190 scenarios. For example, an RTP mixer selects the video of the most 191 active speaker and sends that participant's video stream as a high 192 resolution stream to the other participants, and in addition also 193 sends a number of low resolution video streams of the other 194 participants, enabling the receiving user to both display the current 195 speaker in high quality and monitor the other participants in lower 196 quality/resolution/size. As the participants should not receive the 197 stream showing themselves, the set of streams will be unique to all 198 participants. 200 A number of alternatives exist to provide both high and low 201 resolutions from an RTP Mixer: 203 Simulcast: The clients send one stream for the low resolution and 204 another for the high resolution to the RTP Mixer. 206 Scalable Video Coding: The clients send one stream to the RTP Mixer, 207 using a video encoder that in this stream can provide both the 208 high resolution and also enables the mixer to extract a low 209 resolution representation from that single stream. 211 Transcoding in the Mixer: The clients send a high resolution stream 212 to the RTP Mixer which performs a transcoding to a lower 213 resolution stream. 215 The Transcoding alternative requires that the RTP mixer has 216 sufficient amount of transcoding resources to produce the number of 217 low resolution streams required. In worst case, all participants' 218 streams may need to be transcoded. If the resources are not 219 available, a different solution is needed. There will also normally 220 be a quality loss and an increase in latency associated with the 221 transcoding operation. 223 Scalable video encoding requires a more complex encoder compared to 224 non-scalable encoding. Also, if the resolution difference between 225 the streams is large, a scalable codec may in fact be only marginally 226 more bandwidth efficient than the simulcast case where the different 227 resolutions are sent as separate streams from the clients to the 228 mixer. At the same time, with scalable video encoding using the 229 currently available scalable video codecs, the transmission of all 230 but the lowest resolution will consume more bandwidth from the mixer 231 to the other participants compared to a non-scalable encoding. 233 Simulcasting has the benefit that it is conceptually simple. It 234 enables the use of any media codec that the participants agree on, 235 allowing the RTP mixer to be codec-agnostic. 237 +------------+ +---+ 238 +---+ | |----->| B | 239 | |=====>| | +---+ 240 | A | | Mixer | 241 | |----->| | +---+ 242 +---+ | |=====>| C | 243 +------------+ +---+ 245 Figure 1: RTP Mixer selecting from simulcast versions 247 The sender A provides the mixer with both a high resolution version 248 "===>" and a low resolution version "--->". The mixer selects who in 249 it's receiver population should get a particular version. 251 3.1.1. Simulcast Combined with Scalable Encoding 253 As explained in the previous section, a scalable codec is not always 254 more bandwidth efficient than simulcast, especially in the path from 255 the mixer to the receiver. 257 There are however cases where a combination of simulcast and scalable 258 encoding can be beneficial. By using simulcast in cases where the 259 scalable codec is less efficient, it is possible to optimize the 260 efficiency of the complete system. A good example of this usage 261 would be where the video is encoded using SVC transported in RTP 262 [RFC6190], where each simulcast stream has a different resolution, 263 and each SVC media stream uses temporal scalability and signal to 264 noise ratio (SNR) scalability within that single media stream. If 265 only resolution and temporal variations are needed, this can be 266 implemented using the non-scalable part of H.264, as each simulcast 267 version provides the different resolution, and each media stream 268 within a simulcast encoding has temporal scalability through the use 269 of non-reference frames. 271 3.2. Multicast Transported Simulcasted Media 273 When using multicast, particularly Source-Specific Multicast (SSM) 274 [RFC3569] to distribute RTP/RTCP packets to a large receiver 275 population one faces some issues. There are at least two different 276 issues where simulcast can potentially be useful. 278 3.2.1. Diversity in Receiver Population 280 If there is any diversity in the receivers regarding e.g. capability, 281 codec support or code base, there are potentially restrictions in 282 what streams can be delivered to the receivers. If using the lowest 283 common denominator over a diverse receiver population isn't 284 acceptable, simulcast can be one possible solution. By offering 285 different stream alternatives, it is possible to let the receivers 286 choose the simulcast version that matches their capabilities. By 287 using explicit signalling for simulcast, it is not necessary for the 288 stream distributor to handle multiple receiver configurations 289 individually for a multi-media session, nor to ensure that each 290 receiver gets an encoding that matches their capabilities. 292 The simulcast version granularity the receivers can select will be on 293 multicast group level. Thus, this use case puts a strict requirement 294 on supporting separation through differnt RTP sessions. The reason 295 being that having a single RTP session straddle several multicast 296 groups makes any reporting on the received sources very difficult to 297 interpret. Using one RTP session per simulcast version instead 298 provides consistency. 300 3.2.2. Bit-rate Adaptation 302 If the network paths from the media sender to the receivers can 303 support different bit-rates, there is a need to support media streams 304 encoded to different bit-rates. If these path differences are of a 305 more static nature, for example depending primarily on the underlying 306 link layers, using simulcast has an advantage over scalable encoding. 307 The reason is that the efficiency of scalable coding will never be 308 better than encoding to a single target rate. When the receiver can 309 determine current network interface connectivity, it can choose 310 simulcast version with certainty. That choice will also be correct 311 until the event of another network interface becoming the active one. 312 This assumes that the multicast transmission uses dedicated resources 313 and will thus not be congested due to other network traffic. To 314 support this behavior, the signalling must support indication of 315 which media streams that are alternatives to each other, and it is 316 also necessary to be able to determine aggregate bit-rate for the 317 selected multicast group(s) compared to available network properties. 319 Simulcast is possible to use also in more dynamic situations where 320 each receiver continuously gathers reception statistics to detect 321 path congestion and based on that may change which version to 322 receive. The main issue with such usage is how to achieve a switch 323 from one version to another with minimal playback interruption and 324 also avoiding to put extra load on the network during the actual 325 switch. Here, scalable encoding in general have better 326 characteristics since scalability layers are typically synchronized. 328 When comparing simulcast and scalable encoding, the trade-offs are 329 different and the down-sides occur at different places. Simulcast 330 will have a higher bit-rate load at a media sender and that will also 331 be the case for any network path shared between receivers of multiple 332 simulcast versions. However, for parts of the network path where 333 there is only a single simulcast version, the achievable quality at a 334 given bit-rate will be slightly higher for simulcast. It will also 335 be more difficult to seamlessly switch between simulcast versions 336 than between different scalable encodings, as simulcast actually 337 switches from one media stream version to another instead of adding 338 or removing some enhancement layers. 340 3.3. Same Encoding to Multiple Destinations 342 One interpretation of simulcast is when one encoding is sent to 343 multiple receivers. This is well supported in RTP by simply copying 344 all outgoing RTP and RTCP traffic to several transport destinations, 345 if the intention is to create a common RTP session. As long as all 346 participants do the same, a full mesh is constructed and everyone in 347 the multi party session have a similar view of the joint RTP session. 348 This is analog to an Any Source Multicast (ASM) session but without 349 the traffic optimization as multiple copies of the same content is 350 likely to have to pass over the same link. 352 +---+ +---+ 353 | A |<---->| B | 354 +---+ +---+ 355 ^ ^ 356 \ / 357 \ / 358 v v 359 +---+ 360 | C | 361 +---+ 363 Figure 2: Full Mesh / Multi-unicast 365 As this type of simulcast is analog to ASM usage and RTP has good 366 support for ASM sessions, no further consideration is made in this 367 document for this scenario. 369 3.4. Different Encoding to Independent Destinations 371 Another alternative interpretation of simulcast includes multiple 372 destinations, where each destination gets a specifically tailored 373 version, but where the destinations are independent. A typical 374 example for this would be a streaming server distributing the same 375 live session to a number of receivers, adapting the quality and 376 resolution of the multi-media session to each receiver's capability 377 and available bit-rate. This case can be solved in RTP by having 378 independent RTP sessions between the sender and the receivers. Thus 379 this case is not considered further. 381 4. Network Aspects 383 The network aspects that are relevant for simulcast are: 385 Quality of Service: When using simulcast it might be of interest to 386 prioritize a particular simulcast version, rather than applying 387 equal treatment to all versions. For example, lower bit-rate 388 versions may be prioritized over higher bit-rate versions to 389 minimize congestion or packet losses in the low bit-rate versions. 390 Thus, there is a benefit to use a simulcast solution that supports 391 QoS as good as possible. By separating simulcast versions into 392 different RTP sessions and send those RTP sessions over different 393 transport flows, a simulcast version can be prioritized by 394 existing flow based QoS mechanisms. When using unicast, QoS 395 mechanisms based on individual packet marking are also feasible, 396 which do not require separation of simulcast versions into 397 different RTP sessions to apply different QoS. 399 NAT/FW Traversal: Using multiple RTP sessions will incur more cost 400 for NAT/FW traversal unless they can re-use the same transport 401 flow, which can be achieved by either one of multiplexing multiple 402 RTP sessions on a single lower layer transport 403 [I-D.westerlund-avtcore-transport-multiplexing] or Multiplexing 404 Negotiation Using SDP Port Numbers 405 [I-D.ietf-mmusic-sdp-bundle-negotiation]. If flow based QoS with 406 any differentiation is desirable, the cost for additional 407 transport flows is likely necessary. 409 Multicast: Multiple RTP sessions will be required to enable 410 combining simulcast with multicast. Different simulcast versions 411 have to be separated to different multicast groups to allow a 412 multicast receiver to pick the version it wants, rather than 413 receive all of them. In this case, the only reasonable 414 implementation is to use different RTP sessions for each multicast 415 group so that reporting and other RTCP functions operate as 416 intended. 418 5. Simulcast Alternatives 420 Simulcast is in this document defined as the act of sending multiple 421 alternative encodings of the same underlying media source. When 422 transmitting multiple independent streams that originate from the 423 same source, it could potentially be done in several different ways 424 using RTP. A general discussion on how considerations for use of the 425 different RTP multiplexing alternatives can be found in Guidelines 426 for using the Multiplexing Features of RTP 427 [I-D.westerlund-avtcore-multiplex-architecture]. Discussion and 428 clarification on how to handle multiple streams in an RTP session can 429 be found in [I-D.lennox-avtcore-rtp-multi-stream]. 431 The below sub-sections briefly describe potential ways of achieving 432 RTP media stream multiplexing and identification of which streams are 433 alternative simulcast encodings of the same source. In the following 434 descriptions it is also included how this interacts with multiple 435 sources (SSRCs) in the same RTP session for other reasons than 436 simulcast. Multiple SSRCs may occur for various reasons such as 437 multiple participants in multipoint topologies like multicast, 438 transport relays or full mesh transport simulcasting, multiple source 439 devices such as multiple cameras or microphones at one end-point, or 440 other RTP mechanisms such as RTP Retransmission [RFC4588]. 442 5.1. Using the Payload Type 444 An alternative could be to use only the RTP payload type to identify 445 the different simulcast streams. This could be tempting, since 446 simulcast streams may differ in codec, codec configuration, or 447 sampling, all of which are typically specified in SDP by a format 448 number on the media line that is in turn connected to an RTP Payload 449 Type. Thus all simulcast streams would be sent in the same RTP 450 session using only a single SSRC per actual media source. However, 451 as discussed in Guidelines for using the Multiplexing Features of RTP 452 [I-D.westerlund-avtcore-multiplex-architecture], using Payload Type 453 Multiplexing does not generally work and is hereby dismissed as 454 potential solution. 456 5.2. Using Single RTP session 458 This idea is based on using a unique SSRC for each alternative 459 encoding of an actual media source within a single RTP session. The 460 identification of streams and how they are specified to be related 461 alternatives needs an additional mechanism, for example using SSRC 462 grouping [RFC5576], and potentially also a new SDES item such as 463 SRCNAME proposed in [I-D.westerlund-avtext-rtcp-sdes-srcname] with a 464 semantics that indicate them as alternatives of a particular media 465 source. When there are multiple actual media sources in a session, 466 each media source will have to use a number of SSRCs to represent the 467 different simulcast alternatives it produces. For example, assume 468 the number of media sources is n and if they all produce the same 469 number of simulcast versions, m, there will be n*m SSRCs in use in 470 the RTP session. Each SSRC can use any of the configured payload 471 types for this RTP session. All session level attributes and 472 parameters that are not source specific will apply and must function 473 with all the alternative encodings in use. 475 In the currently used signaling system based on SDP [RFC4566] and 476 Offer/Answer [RFC3264], the properties of media streams are typically 477 negotiated on media block (m-line) level. Sending simulcast 478 alternatives as different SSRC belonging to the same media 479 description is likely possible to achieve, but SSRC centric signaling 480 providing the needed media stream properties is currently almost non- 481 existent and it would require a considerable effort to make the 482 necessary SDP extensions. 484 A single RTP session can be described in SDP by more than a single 485 m-line, like for BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation], and 486 it can re-use the same m-line grouping [RFC5888] as would be used for 487 multiple RTP sessions (Section 5.3), but the RTP aspects described in 488 this section will still apply. This would enable the same signalling 489 expressenes for multiple RTP sessions as for a single RTP sessions. 491 5.3. Using Multiple RTP sessions 493 Using multiple RTP sessions means that each different simulcast 494 version of an actual media source is transmitted in a separate RTP 495 session, using whatever session identifier to distinguish the 496 different versions. Since each RTP session is described by one or 497 more SDP m-lines, this solution needs explicit m-line grouping 498 [RFC5888] with a semantics that indicate them as simulcast 499 alternatives. It is also important to identify the SSRCs in the 500 different sessions that are alternative encodings of the same media 501 source, if there are more than a single media source in each RTP 502 session. This could be accomplished using the same SSRC across the 503 sessions, but that is not robust against SSRC collisions and could 504 potentially force cascading SSRC changes between sessions. A better 505 choice would be to use different SSRC, but relate streams through a 506 new SDES item proposed in [I-D.westerlund-avtext-rtcp-sdes-srcname]. 507 Each RTP session will have its own set of configured RTP payload 508 types available for use with any SSRC in that session. In addition, 509 all other attributes for sessions or sources can be used as normal to 510 indicate the configuration of that particular alternative. 512 5.4. Conclusions 514 If it is at all desirable to support simulcast based on multicast, 515 the solution must support using multiple RTP sessions. The main 516 reason is that receiver based selection of simulcast version must be 517 possible, which is accomplished in multicast through receiver 518 selection of which multicast group(s) it joins. This also has the 519 advantage of being able to use the existing SDP media description 520 (m=) expressiveness to signal or negotiate simulcast versions. 522 When using simulcast based on unicast, it is desirable to be able to 523 use the same media description signalling expressiveness regardless 524 if multiple RTP sessions are used or not. Assuming that MMUSIC 525 decides to enable single RTP media stream negotiation per SDP media 526 description and combine that with BUNDLE to identify RTP sessions, it 527 appears that using one or more RTP sessions for simulcast over 528 unicast will be able to use the same signalling solution. Thus the 529 decision to use one or more RTP sessions can be taken based on other 530 limitations, such as cost of NAT/FW traversal, need for flow-based 531 QoS etc. 533 A solution proposal for an SDP media description level signaling for 534 Simulcast version parameters is outlined below. 536 6. Simulcast Signaling Proposal 538 Signaling simulcast is about negotiating between media sender and 539 receiver what the different simulcast versions should be, how to 540 identify them in terms of RTP streams, and how to relate those RTP 541 streams. 543 The proposed solution consists of: 545 o Signaling simulcast capability as SDP media level attributes in a 546 first round of Offer/Answer 548 * Separate send and receive simulcast capabilities 550 * Media properties that are supported as base for different 551 simulcast versions are listed as parameters 553 o Adding SDP media descriptions for the simulcast streams in a 554 second round of Offer/Answer 556 * Grouping SDP media descriptions from the same media source, 557 belonging to the same simulcast, using the SDP grouping 558 framework [RFC5888] 560 * Separate send and receive simulcast groupings 562 * Negotiating parameters for simulcast version using regular, 563 individual SDP media descriptions 565 * Identifying RTP media streams (SSRC) from same media source 566 using new SDES Item SRCNAME 567 [I-D.westerlund-avtext-rtcp-sdes-srcname] 569 This is further outlined below. 571 6.1. Simulcast Capability 573 There are numerous media properties that can be varied to construct a 574 set of simulcast versions. A simulcast enabled endpoint could also 575 support simulcast based on several of those properties. As long as 576 those properties are relatively independent and if each simulcast 577 version need explicit definition (an m-line) in the SDP, this would 578 lead to an exponential number of simulcast version candidates and a 579 very long SDP that is likely also hard to interpret. There is thus a 580 need to limit the simulcast version candidates included in the SDP to 581 cover as small set of properties as possible. 583 If a legacy endpoint not supporting simulcast were to be presented 584 with an SDP including media descriptions for a set of simulcast 585 versions, it may not know how to correctly handle or interpret these 586 "surplus" media descriptions. 588 Based on the functionality that simulcast is intended to achieve, it 589 should be clear that the reasons to send simulcast versions are not 590 the same as to receive simulcast versions, seen from a single 591 endpoint. 593 For these reasons, it is proposed to define two new SDP media level 594 attributes, "a=sim-send" and "a=sim-recv", which explicitly signal 595 support for simulcast media transmission and simulcast media 596 reception, respectively, for that media description. "a=sim-send" and 597 "a=sim-recv" MAY be used independently and simulaneously. These 598 attributes are also proposed to have parameters indicating the media 599 properties used to create the simulcast versions. The meaning of the 600 attributes on SDP session level is undefined and MUST NOT be used. 601 simulcast = "a="( "sim-send:" / "sim-recv:" ) prop-list 602 prop-list = prop-entry *(WSP prop-entry) 603 prop-entry = prop *("=" q-value) 604 prop = "rtpmap" 605 / "fmtp" 606 / "imageattr" 607 / "ptime" 608 / "crypto" 609 / token ; for future extensions 610 q-value = ( "0" "." 1*2DIGIT ) 611 / ( "1" "." 1*2("0") ) 612 ; Values between 0.00 and 1.00 613 ; WSP and DIGIT defined in [RFC5234] 614 ; token defined in [RFC4566] 616 Figure 3: ABNF for Simulcast 618 The media property values are taken from existing (and could likely 619 be extended to cover future) SDP attributes that express media 620 properties that can be varied to create different simulcast versions: 622 rtpmap: Differences in codec type, sampling rate (see Section 6.4), 623 and number of channels 625 fmtp: Differences in codec-specific encoding parameters 627 imageattr: Differences in video resolution, aspect ratio, and 628 framerate [RFC6236] 630 ptime: Differences in frame aggregation per packet 632 crypto: Differences in encryption [RFC4568] 634 ...: 636 The optional q-value expresses the relative preference to base a 637 simulcast version on that media property, with 1.00 meaning maximum 638 (100%) preference and 0.00 meaning no (0%) preference. Several media 639 properties can share the same q-value, in which case they are equally 640 preferred. 642 An offerer wanting to use simulcast SHALL include either one or both 643 of those attributes, depending on in which direction(s) simulcast 644 will be used. An offerer that receives an answer without "a=sim- 645 send" or "a=sim-recv" MUST NOT define or use any simulcast 646 alternatives belonging to that media description and in that 647 direction to the answerer. 649 An answerer that does not understand the concept of simulcast will 650 also not know those attributes and will remove them in the SDP 651 answer, as defined in existing SDP Offer/Answer procedures. An 652 answerer that does understand the attributes and that wants to 653 support simulcast in the indicated direction SHALL reverse 654 directionality of the attribute, "sim-send" becomes "sim-recv" and 655 vice versa, and include it in the answer. 657 An offerer that intends to send simulcast alternatives and thus 658 includes "a=sim-send", MUST also include at least one media property 659 parameter that it intends to use to construct the simulcast 660 alternatives, but it MAY include more media property parameters. 661 Including multiple media property parameters in "a=sim-send" SHALL be 662 interpreted as an offer to send simulcast versions covering all 663 combinations thereof, but MAY be further restricted by other 664 information in the SDP such as for example the number of simulcast- 665 related media descriptions in the SDP or use of max-ssrc signaling 667 [I-D.westerlund-mmusic-max-ssrc]. 669 An offerer that is capable of receiving simulcast alternatives and 670 thus includes "a=sim-recv", MUST also include at least one media 671 property parameter that it is willing to use as discriminator between 672 received simulcast alternatives, but MAY include more media property 673 parameters. Including multiple media property parameters in "a=sim- 674 recv" SHALL be interpreted as an offer to receive simulcast versions 675 covering all combinations thereof, but MAY be further restricted by 676 other information in the SDP such as for example the number of 677 simulcast-related media descriptions in the SDP or use of max-ssrc 678 signaling [I-D.westerlund-mmusic-max-ssrc]. 680 An answerer either lacks the capability or desire to use simulcast 681 versions based on a certain media property parameter in a specific 682 direction MUST remove such media property parameter from "a=sim-send" 683 or "a=sim-recv". The answerer MUST NOT add any media property 684 parameters that were not included in the offer. 686 6.2. Grouping Simulcast Media Descriptions 688 To relate media descriptions holding simulcast versions, two new 689 simulcast grouping semantics are defined, "SimulCast Receive" (SCR) 690 and "SimulCast Send" (SCS). There is a need to separate semantics 691 for the intent to send simulcast streams from the semantics that 692 describe capability to recognize and receive simulcast streams. Both 693 sematics act as an indicator that simulcast is desired and that the 694 grouped media descriptions (m-lines) carries simulcast versions of 695 media sources. There may be multiple sets of media descriptions that 696 carries simulcast versions. 698 6.2.1. Declarative Use 700 When used as a declarative media description, SCR indicates the 701 configured end-point's required capability to recognize and receive a 702 specified set of RTP streams as simulcast streams. In the same 703 fashion, SCS requests the end-point to send a specified set of RTP 704 streams as simulcast streams. SCR and SCS MAY be used independently 705 and at the same time and they need not specify the same or even the 706 same number of media descriptions in the group. 708 6.2.2. Offer/Answer Use 710 When used in an offer, SCS indicates the SDP providing agent's intent 711 of sending simulcast and the particular set of media descriptions, 712 and SCR indicates the agent's capability of receiving simulcast 713 streams within the configured set of media descriptions. SCS and SCR 714 MAY be used independently and at the same time and they need not 715 specify the same or even the same number of media descriptions in the 716 group. The answerer MUST change SCS to SCR and SCR to SCS in the 717 answer, given that it has and wants to use the corresponding 718 (reverse) capability. An answerer not supporting the SCS or SCR 719 direction, or not supporting SCS or SCR grouping semantics at all, 720 will remove that grouping attribute altogether, according to the 721 grouping framework [RFC5888]. However, this case should not occur or 722 at least be very rare due to the proposed two-phase approach 723 (Section 6.3). An offerer that receives an answer indicating lack of 724 simulcast support in one or both directions, where SCR and/or SCS 725 grouping are removed, MUST NOT use simulcast in the non-supported 726 direction(s). 728 6.3. Two-Phase Negotiation 730 These new "a=sim-send" and "a=sim-recv" attributes are proposed to be 731 included in the SDP as a first phase in a two-phased approach, where 732 the first phase involves a first SDP Offer/Answer procedure that only 733 establishes simulcast capability at both the offerer and the 734 answerer. This has the additional advantage to avoid sending media 735 descriptions related to simulcast to an endpoint that does not 736 support simulcast. It is also not likely that it incurs any 737 significant extra signaling round-trips, given that many other recent 738 SDP techniques also makes use of two Offer/Answer procedures, as long 739 as this phased approach can be used in parallel with those. Such 740 other two-phase techniques include ICE [RFC5245] and BUNDLE 741 [I-D.ietf-mmusic-sdp-bundle-negotiation]. 743 Thus, the first Offer/Answer SHOULD NOT include any simulcast-grouped 744 media descriptions, which SHOULD then be added in a second Offer/ 745 Answer phase. This second phase SHOULD be initiated by the simulcast 746 receiver, meaning the endpoint that included "a=sim-recv" in the 747 first phase SDP SHOULD be offerer in the second phase. If both 748 endpoints are simulcast receivers, it is not possible to define a 749 preferred offerer in the second phase and either endpoint MAY then 750 send the offer, using regular Offer/Answer rules to handle race 751 conditions. 753 The first phase of establishing capability is not possible to use 754 with declarative SDP, in which case it SHALL be by-passed, using the 755 second phase media description grouping directly. 757 6.4. Media Stream Requirements 759 When doing simulcast, the media streams that are alternatives need to 760 meet certain constraints to ensure that switching between alternative 761 streams are as issue-free as possible. The following constraints are 762 needed: 764 Same Clock Base: To enable correct alignment of media packets on the 765 source time-line, all alternative streams (SSRCs) MUST use the 766 same underlying clock to relate their RTP timestamp values with 767 the network time protocol (NTP) formatted sender time in the RTCP 768 Sender Reports. 770 6.5. Relating Alternative Encodings 772 To ensure that simulcast streams can be related correctly also on RTP 773 level, the usage of SDES SRCNAME 774 [I-D.westerlund-avtext-rtcp-sdes-srcname] to label and relate 775 simulcast versions belonging to the same media source is RECOMMENDED. 777 6.6. Multiple Stream handling 779 When using multiple SSRC in a single media description, for example 780 when using simulcast for multiple independent media sources, the 781 grouping semantics SCR and SCS SHOULD be combined with the SDP 782 attributes "a=max-send-ssrc" and "a=max-recv-ssrc" 783 [I-D.westerlund-mmusic-max-ssrc] to indicate the number of 784 simultaneous streams of each encoding that may be sent or that can be 785 handled in the receive direction. 787 7. Simulcast Signaling Examples 789 For brevity and clarity, the SDP in all below examples does not 790 contain signaling for multiple streams, such as the ones related to 791 RTP level relations (Section 6.5) or multiple SSRC signaling 792 (Section 6.6). 794 This example is for a case of client to video conference service 795 using a centralized media topology with an RTP mixer. Alice and Bob 796 calls into a conference server for a conference call with audio and 797 video sent to the RTP mixer, these clients being capable to send a 798 few video simulcast versions. The conference server also dials out 799 to Fred, which is a legacy client resulting in fallback behavior. 800 When dialing out to Joe, more functionality is enabled as Joe is a 801 client similar to Alice. 803 +---+ +-----------+ +---+ 804 | A |<---->| |<---->| B | 805 +---+ | | +---+ 806 | Mixer | 807 +---+ | | +---+ 808 | F |<---->| |<---->| J | 809 +---+ +-----------+ +---+ 811 Figure 4: Four-party Mixer-based Conference 813 Example of Media plane for RTP mixer based multi-party conference 814 with 4 participants. 816 7.1. Alice: Desktop Client 818 Alice is calling in to the mixer with an audiovisual single stream 819 desktop client, only adding capability to send video resolution 820 [RFC6236] ("imageattr") and framerate based simulcast compared to a 821 legacy client. The first phase offer from Alice looks like 823 v=0 824 o=alice 2362969037 2362969040 IN IP4 192.0.2.156 825 s=Simulcast enabled Desktop Client 826 t=0 0 827 c=IN IP4 192.0.2.156 828 b=AS:665 829 m=audio 49200 RTP/AVP 96 97 9 8 830 b=AS:145 831 a=rtpmap:96 G719/48000/2 832 a=rtpmap:97 G719/48000 833 a=rtpmap:9 G722/8000 834 a=rtpmap:8 PCMA/8000 835 m=video 49300 RTP/AVP 96 836 b=AS:520 837 a=rtpmap:96 H264/90000 838 a=fmtp:96 profile-level-id=42c01e 839 a=sim-send:imageattr=1.0 fmtp=0.8 840 a=imageattr:* send [x=640,y=360] recv [x=640,y=360] [x=320,y=180] 841 a=content:main 843 Figure 5: Alice First Offer for a Simulcast Conference 845 In this first phase, the only thing in the SDP that indicates 846 simulcast capability is the line in the video media description 847 containing the "sim-send" attribute. 849 The answer from the server indicates both that it is simulcast 850 capable and that it would only like to use video resolution 851 ("imageattr") based simulcast only. Should it not have been 852 simulcast capable, the "a=sim-recv" line would not have been present 853 and communication would have started with the media negotiated in the 854 SDP. 856 v=0 857 o=server 823479283 1209384938 IN IP4 192.0.2.2 858 s=Answer to simulcast enabled Desktop Client 859 t=0 0 860 c=IN IP4 192.0.2.43 861 b=AS:665 862 m=audio 49200 RTP/AVP 96 863 b=AS:145 864 a=rtpmap:96 G719/48000/2 865 m=video 49300 RTP/AVP 96 866 b=AS:520 867 a=rtpmap:96 H264/90000 868 a=fmtp:96 profile-level-id=42c01e 869 a=sim-recv:imageattr 870 a=imageattr:* send [x=640,y=360] [x=320,y=180] recv [x=640,y=360] 871 a=content:main 873 Figure 6: Server First Answer for a Simulcast Conference 875 Since the server is the simulcast media receiver, it immediately 876 initiates another Offer/Answer including the simulcast versions. The 877 server also keeps the "sim-recv" as explicit simulcast capability 878 indication in this second Offer/Answer round. Note that the "non- 879 simulcast" media can be started already now, before the second phase 880 Offer/Answer, with the only restriction that the simulcast 881 functionality is not yet established. 883 v=0 884 o=server 823479283 1209384938 IN IP4 192.0.2.2 885 s=Server inviting simulcast enabled Desktop Client 886 t=0 0 887 c=IN IP4 192.0.2.43 888 b=AS:825 889 a=group:SCR 2 3 890 m=audio 49200 RTP/AVP 96 891 b=AS:145 892 a=rtpmap:96 G719/48000/2 893 a=mid:1 894 m=video 49300 RTP/AVP 96 895 b=AS:520 896 a=rtpmap:96 H264/90000 897 a=fmtp:96 profile-level-id=42c01e 898 a=sim-recv:imageattr 899 a=imageattr:* send [x=640,y=360] [x=320,y=180] recv [x=640,y=360] 900 a=mid:2 901 a=content:main 902 m=video 49400 RTP/AVP 96 903 b=AS:160 904 a=rtpmap:96 H264/90000 905 a=fmtp:96 profile-level-id=42c00d 906 a=imageattr:96 recv [x=320,y=180] 907 a=mid:3 908 a=recvonly 910 Figure 7: Server Second Offer for a Simulcast Conference 912 The server has added one additional receive-only media description 913 with the simulcast version based on difference only in imageattr. 914 That the two media lines are considered to be simulcast versions is 915 seen from the SCR grouping tag and the two media IDs (2 and 3). The 916 first video version with media ID 2 prefers 360p resolution (signaled 917 via imageattr) and the second video version with media ID 3 prefers 918 180p resolution. The first video media line also acts as the single 919 send video (making media line sendrecv), while the second video media 920 line is only related to simulcast transmission and is thus offered 921 recvonly. 923 The fact that fmtp for this second video is also different should be 924 seen as a secondary effect from the change of resolution and does not 925 create any kind of conflict. The capabilities of Alice's client is 926 very well aligned with this and the SDP answer is straightforward. 928 v=0 929 o=alice 2362969037 2362969040 IN IP4 192.0.2.156 930 s=Final answer from simulcast enabled Desktop Client 931 t=0 0 932 c=IN IP4 192.0.2.156 933 b=AS:825 934 a=group:SCS 2 3 935 m=audio 49200 RTP/AVP 96 936 b=AS:145 937 a=rtpmap:96 G719/48000/2 938 a=mid:1 939 m=video 49300 RTP/AVP 96 940 b=AS:520 941 a=rtpmap:96 H264/90000 942 a=fmtp:96 profile-level-id=42c01e 943 a=sim-send:imageattr 944 a=imageattr:* send [x=640,y=360] recv [x=640,y=360] [x=320,y=180] 945 a=mid:2 946 a=content:main 947 m=video 49400 RTP/AVP 96 948 b=AS:160 949 a=rtpmap:96 H264/90000 950 a=fmtp:96 profile-level-id=42c00d 951 a=imageattr:96 send [x=320,y=180] 952 a=mid:3 953 a=sendonly 955 Figure 8: Alice Second Answer for a Simulcast Conference 957 8. IANA Considerations 959 This document requests that two new attributes sim-send and sim-recv, 960 with a new registry of defined parameters taken from existing SDP 961 attributes, and two new SDP grouping semantics, SCS and SCR, are 962 registered. 964 Formal registrations to be written. 966 9. Security Considerations 968 The simulcast capability attributes and parameters are vulnerable to 969 attacks in signaling. 971 A false inclusion of simulcast attributes may result in generation of 972 a second phase SDP that potentially contains a large number of non- 973 supported media descriptions expressing simulcast alternatives. A 974 correct SDP implementation will however be able to reject any non- 975 supported media descriptions and the effect from that should be 976 limited. 978 A hostile removal of the simulcast attributes will result in skipping 979 any second phase Offer/Answer and that simulcast is not used. 981 The simulcast grouping semantics are vulnerable to attacks in the 982 signalling. 984 A false grouping of non-simulcast streams as simulcast would risk 985 that some streams are incorrectly ignored by receivers that know 986 simulcast and that are not interested in the assumed simulcast 987 streams. 989 A hostile removal of simulcast grouping will prevent streams from 990 being interpreted as simulcast, which obviously prevents use of the 991 simulcast functionality. It will also risk that intended simulcast 992 streams are instead presented as separate, independent streams to a 993 receiver. 995 Neither of the above will likely have any major consequences and can 996 be mitigated by signaling that is at least integrity and source 997 authenticated to prevent an attacker to change it. 999 10. Acknowledgements 1001 11. References 1003 11.1. Normative References 1005 [I-D.westerlund-avtext-rtcp-sdes-srcname] 1006 Westerlund, M., Burman, B., and P. Sandgren, "RTCP SDES 1007 Item SRCNAME to Label Individual Sources", 1008 draft-westerlund-avtext-rtcp-sdes-srcname-00 (work in 1009 progress), October 2011. 1011 [I-D.westerlund-mmusic-max-ssrc] 1012 Holmberg, C., Westerlund, M., Burman, B., and F. Jansson, 1013 "Multiple Synchronization Sources (SSRC) in SDP Media 1014 Descriptions", draft-westerlund-mmusic-max-ssrc-00 (work 1015 in progress), September 2012. 1017 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1018 Requirement Levels", BCP 14, RFC 2119, March 1997. 1020 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1021 Jacobson, "RTP: A Transport Protocol for Real-Time 1022 Applications", STD 64, RFC 3550, July 2003. 1024 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1025 Description Protocol", RFC 4566, July 2006. 1027 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 1028 Description Protocol (SDP) Security Descriptions for Media 1029 Streams", RFC 4568, July 2006. 1031 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 1032 Media Attributes in the Session Description Protocol 1033 (SDP)", RFC 5576, June 2009. 1035 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1036 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 1038 [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image 1039 Attributes in the Session Description Protocol (SDP)", 1040 RFC 6236, May 2011. 1042 11.2. Informative References 1044 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1045 Holmberg, C., Alvestrand, H., and C. Jennings, 1046 "Multiplexing Negotiation Using Session Description 1047 Protocol (SDP) Port Numbers", 1048 draft-ietf-mmusic-sdp-bundle-negotiation-03 (work in 1049 progress), February 2013. 1051 [I-D.lennox-avtcore-rtp-multi-stream] 1052 Lennox, J. and M. Westerlund, "Real-Time Transport 1053 Protocol (RTP) Considerations for Endpoints Sending 1054 Multiple Media Streams", 1055 draft-lennox-avtcore-rtp-multi-stream-01 (work in 1056 progress), October 2012. 1058 [I-D.westerlund-avtcore-multiplex-architecture] 1059 Westerlund, M., Burman, B., and C. Perkins, "RTP 1060 Multiplexing Architecture", 1061 draft-westerlund-avtcore-multiplex-architecture-00 (work 1062 in progress), October 2011. 1064 [I-D.westerlund-avtcore-transport-multiplexing] 1065 Westerlund, M., "Multiple RTP Session on a Single Lower- 1066 Layer Transport", 1067 draft-westerlund-avtcore-transport-multiplexing-00 (work 1068 in progress), October 2011. 1070 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1071 with Session Description Protocol (SDP)", RFC 3264, 1072 June 2002. 1074 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 1075 Multicast (SSM)", RFC 3569, July 2003. 1077 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1078 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1079 July 2006. 1081 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 1082 January 2008. 1084 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1085 (ICE): A Protocol for Network Address Translator (NAT) 1086 Traversal for Offer/Answer Protocols", RFC 5245, 1087 April 2010. 1089 [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 1090 "RTP Payload Format for Scalable Video Coding", RFC 6190, 1091 May 2011. 1093 Authors' Addresses 1095 Magnus Westerlund 1096 Ericsson 1097 Farogatan 6 1098 SE-164 80 Kista 1099 Sweden 1101 Phone: +46 10 714 82 87 1102 Email: magnus.westerlund@ericsson.com 1104 Bo Burman 1105 Ericsson 1106 Farogatan 6 1107 SE-164 80 Kista 1108 Sweden 1110 Phone: +46 10 714 13 11 1111 Email: bo.burman@ericsson.com 1112 Morgan Lindqvist 1113 Ericsson 1114 Farogatan 6 1115 Kista, SE-164 80 1116 Sweden 1118 Phone: +46 10 719 00 00 1119 Fax: 1120 Email: morgan.lindqvist@ericsson.com 1121 URI: 1123 Fredrik Jansson 1124 Ericsson 1125 Farogatan 6 1126 Kista, SE-164 80 1127 Sweden 1129 Phone: +46 10 719 00 00 1130 Fax: 1131 Email: fredrik.k.jansson@ericsson.com 1132 URI: