idnits 2.17.1 draft-ietf-mmusic-sdp-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 (October 6, 2015) is 3122 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) == Outdated reference: A later version (-02) exists of draft-pthatcher-mmusic-rid-00 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-12) exists of draft-ietf-avtcore-multiplex-guidelines-03 == Outdated reference: A later version (-11) exists of draft-ietf-avtcore-rtp-multi-stream-09 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-23 -- Obsolete informational reference (is this intentional?): RFC 5117 (Obsoleted by RFC 7667) -- Obsolete informational reference (is this intentional?): RFC 5285 (Obsoleted by RFC 8285) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Burman 3 Internet-Draft M. Westerlund 4 Intended status: Standards Track Ericsson 5 Expires: April 8, 2016 S. Nandakumar 6 M. Zanaty 7 Cisco 8 October 6, 2015 10 Using Simulcast in SDP and RTP Sessions 11 draft-ietf-mmusic-sdp-simulcast-02 13 Abstract 15 In some application scenarios it may be desirable to send multiple 16 differently encoded versions of the same media source in different 17 RTP streams. This is called simulcast. This document discusses the 18 best way of accomplishing simulcast in RTP and how to signal it in 19 SDP. A solution is defined by making an extension to SDP, and using 20 RTP/RTCP identification methods to relate RTP streams belonging to 21 the same media source. The SDP extension consists of a new media 22 level SDP attribute that expresses capability to send and/or receive 23 simulcast RTP streams. RTP/RTCP identification using either payload 24 types or a separately defined method for RTP stream configuration are 25 defined. 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 April 8, 2016. 44 Copyright Notice 46 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 65 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. Reaching a Diverse Set of Receivers . . . . . . . . . . . 5 67 3.2. Application Specific Media Source Handling . . . . . . . 6 68 3.3. Receiver Adaptation in Multicast/Broadcast . . . . . . . 7 69 3.4. Receiver Media Source Preferences . . . . . . . . . . . . 8 70 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 6. Detailed Description . . . . . . . . . . . . . . . . . . . . 10 73 6.1. Simulcast Capability . . . . . . . . . . . . . . . . . . 10 74 6.1.1. Declarative Use . . . . . . . . . . . . . . . . . . . 12 75 6.1.2. Offer/Answer Use . . . . . . . . . . . . . . . . . . 12 76 6.2. Relating Simulcast Streams . . . . . . . . . . . . . . . 14 77 6.3. Signaling Examples . . . . . . . . . . . . . . . . . . . 14 78 6.3.1. Unified Plan Client . . . . . . . . . . . . . . . . . 15 79 6.3.2. Multi-Source Client . . . . . . . . . . . . . . . . . 16 80 7. Network Aspects . . . . . . . . . . . . . . . . . . . . . . . 18 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 83 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 84 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 87 12.2. Informative References . . . . . . . . . . . . . . . . . 21 88 Appendix A. Changes From Earlier Versions . . . . . . . . . . . 23 89 A.1. Modifications Between WG Version -01 and -02 . . . . . . 23 90 A.2. Modifications Between WG Version -00 and -01 . . . . . . 23 91 A.3. Modifications Between Individual Version -00 and WG 92 Version -00 . . . . . . . . . . . . . . . . . . . . . . . 23 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 95 1. Introduction 97 Most of today's multiparty video conference solutions make use of 98 centralized servers to reduce the bandwidth and CPU consumption in 99 the endpoints. Those servers receive RTP streams from each 100 participant and send some suitable set of possibly modified RTP 101 streams to the rest of the participants, which usually have 102 heterogeneous capabilities (screen size, CPU, bandwidth, codec, etc). 103 One of the biggest issues is how to perform RTP stream adaptation to 104 different participants' constraints with the minimum possible impact 105 on both video quality and server performance. 107 Simulcast is defined in this memo as the act of simultaneously 108 sending multiple different encoded streams of the same media source, 109 e.g. the same video source encoded with different video encoder types 110 or image resolutions. This can be done in several ways and for 111 different purposes. This document focuses on the case where it is 112 desirable to provide a media source as multiple encoded streams over 113 RTP [RFC3550] towards an intermediary so that the intermediary can 114 provide the wanted functionality by selecting which RTP stream to 115 forward to other participants in the session, and more specifically 116 how the identification and grouping of the involved RTP streams are 117 done. From an RTP perspective, simulcast is a specific application 118 of the aspects discussed in RTP Multiplexing Guidelines 119 [I-D.ietf-avtcore-multiplex-guidelines]. 121 This document describes a few scenarios where it is motivated to use 122 simulcast, and also defines the needed SDP signaling for it. 124 2. Definitions 126 2.1. Terminology 128 This document makes use of the terminology defined in RTP Taxonomy 129 [I-D.ietf-avtext-rtp-grouping-taxonomy], RTP Topology [RFC5117] and 130 RTP Topologies Update [I-D.ietf-avtcore-rtp-topologies-update]. In 131 addition, the following terms are used: 133 RTP Mixer: An RTP middle node, defined in [RFC5117] (Section 3.4: 134 Topo-Mixer), further elaborated and extended with other topologies 135 in [I-D.ietf-avtcore-rtp-topologies-update] (Section 3.6 to 3.9). 137 RTP Switch: A common short term for the terms "switching RTP mixer", 138 "source projecting middlebox", and "video switching MCU" as 139 discussed in [I-D.ietf-avtcore-rtp-topologies-update]. 141 Simulcast Stream: One Encoded Stream or Dependent Stream from a set 142 of concurrently transmitted Encoded Streams and optional Dependent 143 Streams, all sharing a common Media Source, as defined in 144 [I-D.ietf-avtext-rtp-grouping-taxonomy]. Decoding a Dependent 145 Stream also requires the related (Dependent and) Encoded 146 Stream(s), but in the context of simulcast that is considered a 147 property of the Dependent Stream constituting the simulcast 148 stream. For example, HD and thumbnail video simulcast versions of 149 a single Media Source sent concurrently as separate RTP Streams. 151 Simulcast Format: Different formats of a simulcast stream serve the 152 same purpose as alternative RTP payload types in non-simulcast 153 SDP, to allow multiple alternative media formats for a given RTP 154 Stream. As for multiple RTP payload types on the m-line, any one 155 of the alternative formats can be used at a given point in time, 156 but not more than one (based on RTP timestamp), and what format is 157 used can change dynamically from one RTP packet to another. For 158 example, if all participants in a group video call can decode 159 H.264 and H.265 video, but only some can encode H.265, both H.264 160 and H.265 can be kept as alternative formats, and the format may 161 dynamically switch between H.264 and H.265 as different 162 participants become active speaker. 164 2.2. Requirements Language 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in RFC 2119 [RFC2119]. 170 3. Use Cases 172 Many use cases of simulcast as described in this document relate to a 173 multi-party communication session where one or more central nodes are 174 used to adapt the view of the communication session towards 175 individual participants, and facilitate the media transport between 176 participants. Thus, these cases targets the RTP Mixer type of 177 topology. 179 There are two principle approaches for an RTP Mixer to provide this 180 adapted view of the communication session to each receiving 181 participant: 183 o Transcoding (decoding and re-encoding) received RTP streams with 184 characteristics adapted to each receiving participant. This often 185 include mixing or composition of media sources from multiple 186 participants into a mixed media source originated by the RTP 187 Mixer. The main advantage of this approach is that it achieves 188 close to optimal adaptation to individual receiving participants. 189 The main disadvantages are that it can be very computationally 190 expensive to the RTP Mixer and typically also degrades media 191 Quality of Experience (QoE) such as end-to-end delay for the 192 receiving participants. 194 o Switching a subset of all received RTP streams or sub-streams to 195 each receiving participant, where the used subset is typically 196 specific to each receiving participant. The main advantages of 197 this approach are that it is computationally cheap to the RTP 198 Mixer and it has very limited impact on media QoE. The main 199 disadvantage is that it can be difficult to combine a subset of 200 received RTP streams into a perfect fit to the resource situation 201 of a receiving participant. 203 The use of simulcast relates to the latter approach, where it is more 204 important to reduce the load on the RTP Mixer and/or minimize QoE 205 impact than to achieve an optimal adaptation of resource usage. 207 A multicast/broadcast case where the receivers themselves selects the 208 most appropriate simulcast stream and tune in to the right media 209 transport to receive that stream is also considered (Section 3.3) . 210 This enables large, heterogeneous receiver populations, when it comes 211 to capabilities and the use of network path bandwidth resources. 213 3.1. Reaching a Diverse Set of Receivers 215 The media sources provided by a sending participant potentially need 216 to reach several receiving participants that differ in terms of 217 available resources. The receiver resources that typically differ 218 include, but are not limited to: 220 Codec: This includes codec type (such as SDP MIME type) and can 221 include codec configuration options (e.g. SDP fmtp parameters). 222 A couple of codec resources that differ only in codec 223 configuration will be "different" if they are somehow not 224 "compatible", like if they differ in video codec profile, or the 225 transport packetization configuration. 227 Sampling: This relates to how the media source is sampled, in 228 spatial as well as in temporal domain. For video streams, spatial 229 sampling affects image resolution and temporal sampling affects 230 video frame rate. For audio, spatial sampling relates to the 231 number of audio channels and temporal sampling affects audio 232 bandwidth. This may be used to suit different rendering 233 capabilities or needs at the receiving endpoints, as well as a 234 method to achieve different transport capabilities, bitrates and 235 eventually QoE by controlling the amount of source data. 237 Bitrate: This relates to the amount of bits spent per second to 238 transmit the media source as an RTP stream, which typically also 239 affects the Quality of Experience (QoE) for the receiving user. 241 Letting the sending participant create a simulcast of a few 242 differently configured RTP streams per media source can be a good 243 tradeoff when using an RTP switch as middlebox, instead of sending a 244 single RTP stream and using an RTP mixer to create individual 245 transcodings to each receiving participant. 247 This requires that the receiving participants can be categorized in 248 terms of available resources and that the sending participant can 249 choose a matching configuration for a single RTP stream per category 250 and media source. 252 For example, assume for simplicity a set of receiving participants 253 that differ only in that some have support to receive Codec A, and 254 the others have support to receive Codec B. Further assume that the 255 sending participant can send both Codec A and B. It can then reach 256 all receivers by creating two simulcasted RTP streams from each media 257 source; one for Codec A and one for Codec B. 259 In another simple example, a set of receiving participants differ 260 only in screen resolution; some are able to display video with at 261 most 360p resolution and some support 720p resolution. A sending 262 participant can then reach all receivers by creating a simulcast of 263 RTP streams with 360p and 720p resolution for each sent video media 264 source. 266 In more elaborate cases, the receiving participants differ both in 267 available sampling and bitrate, and maybe also codec, and it is up to 268 the RTP switch to find a good trade-off in which simulcasted stream 269 to choose for each intended receiver. It is also the responsibility 270 of the RTP switch to negotiate a good fit of simulcast streams with 271 the sending participant. 273 The maximum number of simulcasted RTP streams that can be sent is 274 mainly limited by the amount of processing and uplink network 275 resources available to the sending participant. 277 3.2. Application Specific Media Source Handling 279 The application logic that controls the communication session may 280 include special handling of some media sources. It is for example 281 commonly the case that the media from a sending participant is not 282 sent back to itself. 284 It is also common that a currently active speaker participant is 285 shown in larger size or higher quality than other participants (the 286 sampling or bitrate aspects of Section 3.1). Not sending the active 287 speaker media back to itself means there is some other participant's 288 media that instead has to receive special handling towards the active 289 speaker; typically the previous active speaker. This way, the 290 previously active speaker is needed both in larger size (to current 291 active speaker) and in small size (to the rest of the participants), 292 which can be solved with a simulcast from the previously active 293 speaker to the RTP switch. 295 3.3. Receiver Adaptation in Multicast/Broadcast 297 When using broadcast or multicast technology to distribute real-time 298 media streams to large populations of receivers, there can still be 299 significant heterogeneity among the receiver population. This can 300 depend on several factors: 302 Network Bandwidth: The network paths to individual receivers will 303 have variations in the bandwidth, thus putting different limits on 304 the supported bit-rates that can be received. 306 Endpoint Capabilities: The end point's hardware and software can 307 have varying capabilities in relation to screen resolution, 308 decoding capabilities, and supported media codecs. 310 To handle these variations, a transmitter of real-time media may want 311 to apply simulcast to a media source and provide it as a set of 312 different encoded streams, enabling the receivers to select the best 313 fit from this set themselves. The end point capabilities will 314 usually result in a single initial choice. However, the network 315 bandwidth can vary over time, which requires a client to continuously 316 monitor its reception to determine if the received RTP streams still 317 fit within the available bandwidth. If not, another set of encoded 318 streams from the ones offered in the simulcast will have to be 319 chosen. 321 When using IP multicast, the level of granularity that the receiver 322 can select from is decided by its ability to choose different 323 multicast addresses. Thus, different simulcast streams need to be 324 put on different media transports using different multicast 325 addresses. If these simulcast streams are described using SDP, they 326 need to be part of different SDP media descriptions, as SDP binds to 327 transport on media description level. 329 3.4. Receiver Media Source Preferences 331 The application logic that controls the communication session may 332 allow receiving participants to apply preferences to the 333 characteristics of the RTP stream they receive, for example in terms 334 of the aspects listed in Section 3.1. Sending a simulcast of RTP 335 streams is one way of accommodating receivers with conflicting or 336 otherwise incompatible preferences. 338 4. Requirements 340 The following requirements need to be met to support the use cases in 341 previous sections: 343 REQ-1: Identification. It must be possible to identify a set of 344 simulcasted RTP streams as originating from the same media source: 346 REQ-1.1: In SDP signaling. 348 REQ-1.2: On RTP/RTCP level. 350 REQ-2: Transport usage. The solution must work when using: 352 REQ-2.1: Legacy SDP with separate media transports per SDP media 353 description. 355 REQ-2.2: Bundled [I-D.ietf-mmusic-sdp-bundle-negotiation] SDP 356 media descriptions. 358 REQ-3: Capability negotiation. It must be possible that: 360 REQ-3.1: Sender can express capability of sending simulcast. 362 REQ-3.2: Receiver can express capability of receiving simulcast. 364 REQ-3.3: Sender can express maximum number of simulcast streams 365 that can be provided. 367 REQ-3.4: Receiver can express maximum number of simulcast streams 368 that can be received. 370 REQ-3.5: Sender can detail the characteristics of the simulcast 371 streams that can be provided. 373 REQ-3.6: Receiver can detail the characteristics of the simulcast 374 streams that it prefers to receive. 376 REQ-4: Distinguishing features. It must be possible to have 377 different simulcast streams use different codec parameters, as can 378 be expressed by SDP format values and RTP payload types. 380 REQ-5: Compatibility. It must be possible to use simulcast in 381 combination with other RTP mechanisms that generate additional RTP 382 streams: 384 REQ-5.1: RTP Retransmission [RFC4588]. 386 REQ-5.2: RTP Forward Error Correction [RFC5109]. 388 REQ-5.3: Related payload types such as audio Comfort Noise and/or 389 DTMF. 391 REQ-6: Interoperability. The solution must be possible to use in: 393 REQ-6.1: Interworking with non-simulcast legacy clients using a 394 single media source per media type. 396 REQ-6.2: WebRTC "Unified Plan" environment with a single media 397 source per SDP media description. 399 5. Overview 401 As an overview, the above requirements are met by signaling simulcast 402 capability and configurations in SDP [RFC4566]: 404 o An offer or answer can contain a number of simulcast streams, 405 separate for send and receive directions. 407 o An offer or answer can contain multiple, alternative simulcast 408 streams in the same fashion as multiple, alternative codecs can be 409 offered in a media description. 411 o A single media source per SDP media description is assumed, which 412 makes the solution work in an Unified Plan 413 [I-D.roach-mmusic-unified-plan] context (although different from 414 what is currently defined there), both with and without BUNDLE 415 [I-D.ietf-mmusic-sdp-bundle-negotiation] grouping. This is also 416 aligned with the concepts defined in 417 [I-D.ietf-avtext-rtp-grouping-taxonomy]. 419 o The codec configuration for each simulcast stream is expressed in 420 terms of existing SDP formats (and typically RTP payload types). 421 Some codecs may rely on codec configuration based on general 422 attributes that apply for all formats within a media description, 423 and which could thus not be used to separate different simulcast 424 streams. When many different media formats and/or simulcast 425 streams are used in the SDP, the available RTP payload type number 426 space may not be sufficient. This can be particularly prominent 427 when BUNDLE is used. To mitigate those limitations, this memo 428 also allows optional use of a separately specified RTP-level 429 identification mechanism [I-D.pthatcher-mmusic-rid], which 430 complements and effectively extends the available simulcast stream 431 identification number space. This also specifies a number of 432 codec agnostic constraint attributes that may be used to define 433 simulcast streams. 435 o It is possible, but not required to use source-specific signaling 436 [RFC5576] with the proposed solution. 438 6. Detailed Description 440 This section further details the overview above (Section 5). 442 6.1. Simulcast Capability 444 Simulcast capability is expressed as a new media level SDP attribute, 445 "a=simulcast". For each desired direction (send/recv/sendrecv), the 446 simulcast attribute defines a list of simulcast streams (separated by 447 semicolons), each of which is a list of simulcast formats (separated 448 by commas). The meaning of the attribute on SDP session level is 449 undefined and MUST NOT be used. There MUST NOT be more than one 450 "a=simulcast" attribute per media description. The ABNF [RFC5234] 451 for this attribute is: 453 sc-attr = "a=simulcast:" 1*3( WSP sc-dir-list ) 454 sc-dir-list = sc-dir WSP sc-id-type "=" sc-alt-list *( ";" sc-alt-list ) 455 sc-dir = "send" / "recv" / "sendrecv" 456 sc-id-type = "pt" / "rid" / token 457 sc-alt-list = sc-id *( "," sc-id ) 458 sc-id = fmt / rid-value / token 459 ; WSP defined in [RFC5234] 460 ; fmt, token defined in [RFC4566] 461 ; rid-value defined in [I-D.pthatcher-mmusic-rid] 463 Figure 1: ABNF for Simulcast 465 There are separate and independent sets of parameters for simulcast 466 in send and receive directions. When listing multiple directions, 467 each direction MUST NOT occur more than once on the same line. 469 Two simulcast stream identification methods are defined; "pt" using 470 RTP payload type (SDP format), and "rid" using an additional RTP- 471 level identification mechanism [I-D.pthatcher-mmusic-rid]. 473 Attribute parameters are grouped by direction and consist of a 474 listing of simulcast stream identifications to be used. The number 475 of (non-alternative, see below) identifications in the list sets a 476 limit to the number of supported simulcast streams in that direction. 477 Simulcast stream identifications present in "sendrecv" direction MUST 478 NOT be present also in "send" or "recv" directions, since the meaning 479 of that would be ambiguous. The order of the listed simulcast 480 streams in the "send" direction is not significant. The order of the 481 listed simulcast streams in the "recv" direction expresses a 482 preference which simulcast streams that are preferred, with the 483 leftmost being most preferred. This can be of importance if the 484 number of actually sent simulcast streams have to be reduced for some 485 reason. 487 Editor's note: Consider to remove the sendrecv definitions, as 488 they don't match PTs and RIDs unidirectionality. 490 Formats that have explicit dependencies [RFC5583] 491 [I-D.pthatcher-mmusic-rid] to other formats (even in the same media 492 description) MAY be listed as different simulcast streams. 494 Alternative simulcast formats MAY be specified as part of the 495 attribute parameters by expressing each simulcast stream as a comma- 496 separated list of alternative format identifiers. In this case, 497 there MUST NOT be any capability restriction in what alternatives can 498 be used across different simulcast streams, like requiring all 499 simulcast streams to use the same codec alternative. The order of 500 the alternatives within a simulcast stream is significant; the 501 alternatives are listed from (left) most preferred to (right) least 502 preferred. For the use of simulcast, this overrides the normal codec 503 preference as expressed by format type ordering on the m-line, using 504 regular SDP rules. This is to enable a separation of general codec 505 preferences and simulcast stream codec preferences. 507 A simulcast stream can use a codec defined such that the same RTP 508 SSRC can change RTP payload type multiple times during a session, 509 possibly even on a per-packet basis. A typical example can be a 510 speech codec that makes use of Comfort Noise [RFC3389] and/or DTMF 511 [RFC4733] formats. In those cases, such "related" formats MUST NOT 512 be listed explicitly in the attribute parameters, since they are not 513 strictly simulcast streams of the media source, but rather a specific 514 way of generating the RTP stream of a single simulcast stream with 515 varying RTP payload type. Instead, only a single simulcast stream 516 identification MUST be used per simulcast stream or alternative 517 simulcast format (if there are such) in the SDP. The used simulcast 518 stream identification SHOULD be the codec format most relevant to the 519 media description, if possible to identify, for example the audio 520 codec rather than the DTMF. What codec format to choose in the case 521 of switching between multiple equally "important" formats is left 522 open, but it is assumed that in the presence of such strong relation 523 it does not matter which is chosen. 525 Use of the redundant audio data [RFC2198] format could be seen as a 526 form of simulcast for loss protection purposes, but is not considered 527 conflicting with the mechanisms described in this memo and MAY 528 therefore be used as any other format. In this case the "red" 529 format, rather than the carried formats, SHOULD be the one to list as 530 a simulcast stream on the "a=simulcast" line. 532 Editor's note: Consider adding the possibility to put an RTP 533 stream in "paused" state [I-D.ietf-avtext-rtp-stream-pause] from 534 the beginning of the session, possibly starting it at a later 535 point in time by applying RTP/RTCP level procedures from that 536 specification. 538 6.1.1. Declarative Use 540 When used as a declarative media description, a=simulcast "recv" 541 direction formats indicates the configured end point's required 542 capability to recognize and receive a specified set of RTP streams as 543 simulcast streams. In the same fashion, a=simulcast "send" direction 544 requests the end point to send a specified set of RTP streams as 545 simulcast streams. The "sendrecv" direction combines "send" and 546 "recv" requirements, using the same format values for both. 548 If multiple simulcast formats are listed, it means that the 549 configured end point MUST be prepared to receive any of the "recv" 550 formats, and MAY send any of the "send" formats for that simulcast 551 stream. 553 Editor's note: The external RTP identification mechanism currently 554 lacks a declarative use definition. As declarative use may also 555 not follow unified plan with a single media source per m= line, it 556 is uncertain if declarative can be defined for the mechanism in 557 its current shape. 559 6.1.2. Offer/Answer Use 561 An offerer wanting to use simulcast SHALL include the "a=simulcast" 562 attribute in the offer. An offerer that receives an answer without 563 "a=simulcast" MUST NOT use simulcast towards the answerer. An 564 offerer that receives an answer with "a=simulcast" not listing a 565 direction or without any simulcast stream identifications in a 566 specified direction MUST NOT use simulcast in that direction. 568 An answerer that does not understand the concept of simulcast will 569 also not know the attribute and will remove it in the SDP answer, as 570 defined in existing SDP Offer/Answer [RFC3264] procedures. An 571 answerer that does understand the attribute and that wants to support 572 simulcast in an indicated direction SHALL reverse directionality of 573 the unidirectional direction parameters; "send" becomes "recv" and 574 vice versa, and include it in the answer. If the offered direction 575 is "sendrecv", the answerer MAY keep it, but MAY also change it to 576 "send" or "recv" to indicate that it is only interested in simulcast 577 for a single direction. Note that, like all other use of SDP format 578 tags ("pt:") for the send direction in Offer/Answer, format tags 579 related to the simulcast stream identification send direction in an 580 offer ("send" or "sendrecv") are placeholders that refer to 581 information in the offer SDP, and the actual formats that will be 582 used on the wire (including RTP Payload Format numbers) depends on 583 information included in the SDP answer. 585 An offerer listing a set of receive simulcast streams and/or 586 alternative formats in the offer MUST be prepared to receive RTP 587 streams for any of those simulcast streams and/or alternative formats 588 from the answerer. 590 An answerer that receives an offer with simulcast containing an 591 "a=simulcast" attribute listing alternative formats for simulcast 592 streams MAY keep all the alternatives in the answer, but it MAY also 593 choose to remove any non-desirable alternatives per simulcast stream 594 in the answer. The answerer MUST NOT add any alternatives that were 595 not present in the offer. 597 An answerer that receives an offer with simulcast that lists a number 598 of simulcast streams, MAY reduce the number of simulcast streams in 599 the answer, but MUST NOT add simulcast streams. 601 An offerer that receives an answer where some simulcast formats are 602 kept MUST be prepared to receive any of the kept send direction 603 alternatives, and MAY send any of the kept receive direction 604 alternatives from the answer. Similarly, the answerer MUST be 605 prepared to receive any of the kept receive direction alternatives, 606 and MAY send any of the kept send direction alternatives in the 607 answer. 609 The offerer and answerer MUST NOT send more than a single alternative 610 format at a time (based on RTP timestamps) per simulcast stream, but 611 MAY change format on a per-RTP packet basis. This corresponds to the 612 existing (non-simulcast) SDP offer/answer case when multiple formats 613 are included on the m-line in the SDP answer. 615 An offerer that receives an answer where some of the simulcast 616 streams are removed MAY release the corresponding resources (codec, 617 transport, etc) in its receive direction and MUST NOT send any RTP 618 streams corresponding to the removed simulcast streams. 620 Simulcast streams or formats using undefined simulcast stream 621 identifications MUST NOT be used as valid simulcast streams by an RTP 622 stream receiver. 624 The media formats and corresponding characteristics of encoded 625 streams used in a simulcast SHOULD be chosen such that they are 626 different. If this difference is not required, RTP duplication 627 [RFC7104] procedures SHOULD be considered instead of simulcast. 629 Note: The inclusion of "a=simulcast" or the use of simulcast does 630 not change any of the interpretation or Offer/Answer procedures 631 for other SDP attributes, like "a=fmtp" or "a=rid". 633 6.2. Relating Simulcast Streams 635 As long as there is only a single media source per SDP media 636 description, simulcast RTP streams can be related on RTP level 637 through the RTP payload type and (optionally) RID 638 [I-D.pthatcher-mmusic-rid], as specified in the SDP "a=simulcast" 639 attribute (Section 6.1) parameters. When using BUNDLE 640 [I-D.ietf-mmusic-sdp-bundle-negotiation] with multiple SDP media 641 descriptions to specify a single RTP session, there is an 642 identification mechanism that allows relating RTP streams back to 643 individual media descriptions, after which the above RTP payload type 644 and RID relations can be used. 646 BUNDLE's MID is an RTCP source description (SDES) item. To ensure 647 rapid initial reception, required to correctly process the RTP 648 streams, it is also defined as an RTP header extension [RFC5285]. 650 Editor's note: Consider making RID an SDES item too, for the same 651 reasons as MID. 653 6.3. Signaling Examples 655 These examples describe a client to video conference service, using a 656 centralized media topology with an RTP mixer. 658 +---+ +-----------+ +---+ 659 | A |<---->| |<---->| B | 660 +---+ | | +---+ 661 | Mixer | 662 +---+ | | +---+ 663 | F |<---->| |<---->| J | 664 +---+ +-----------+ +---+ 666 Figure 2: Four-party Mixer-based Conference 668 6.3.1. Unified Plan Client 670 Alice is calling in to the mixer with a simulcast-enabled Unified 671 Plan client capable of a single media source per media type. The 672 client can send a simulcast of 2 video resolutions and frame rates: 673 HD 1280x720p 30fps and thumbnail 320x180p 15fps. This is defined 674 below using the "imageattr" [RFC6236]. Media formats (RTP payload 675 types) are used as simulcast stream identification. Alice's Offer: 677 v=0 678 o=alice 2362969037 2362969040 IN IP4 192.0.2.156 679 s=Simulcast Enabled Unified Plan Client 680 t=0 0 681 c=IN IP4 192.0.2.156 682 m=audio 49200 RTP/AVP 0 683 a=rtpmap:0 PCMU/8000 684 m=video 49300 RTP/AVP 97 98 685 a=rtpmap:97 H264/90000 686 a=rtpmap:98 H264/90000 687 a=fmtp:97 profile-level-id=42c01f; max-fs=3600; max-mbps=108000 688 a=fmtp:98 profile-level-id=42c00b; max-fs=240; max-mbps=3600 689 a=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720] 690 a=imageattr:98 send [x=320,y=180] recv [x=320,y=180] 691 a=simulcast: send pt=97;98 recv pt=97 693 Figure 3: Unified Plan Simulcast Offer 695 The only thing in the SDP that indicates simulcast capability is the 696 line in the video media description containing the "simulcast" 697 attribute. The included format parameters indicates that sent 698 simulcast streams can differ in video resolution. 700 The Answer from the server indicates that it too is simulcast 701 capable. Should it not have been simulcast capable, the 702 "a=simulcast" line would not have been present and communication 703 would have started with the media negotiated in the SDP. 705 v=0 706 o=server 823479283 1209384938 IN IP4 192.0.2.2 707 s=Answer to Simulcast Enabled Unified Plan Client 708 t=0 0 709 c=IN IP4 192.0.2.43 710 m=audio 49672 RTP/AVP 0 711 a=rtpmap:0 PCMU/8000 712 m=video 49674 RTP/AVP 97 98 713 a=rtpmap:97 H264/90000 714 a=rtpmap:98 H264/90000 715 a=fmtp:97 profile-level-id=42c01f; max-fs=3600; max-mbps=108000 716 a=fmtp:98 profile-level-id=42c00b; max-fs=240; max-mbps=3600 717 a=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720] 718 a=imageattr:98 send [x=320,y=180] recv [x=320,y=180] 719 a=simulcast: recv pt=97;98 send pt=97 721 Figure 4: Unified Plan Simulcast Answer 723 Since the server is the simulcast media receiver, it reverses the 724 direction of the "simulcast" attribute parameters. 726 6.3.2. Multi-Source Client 728 Fred is calling in to the same conference as in the example above 729 with a two-camera, two-display system, thus capable of handling two 730 separate media sources in each direction, where each media source is 731 simulcast-enabled in the send direction. Fred's client is a Unified 732 Plan client, restricted to a single media source per media 733 description. 735 The first two simulcast streams for the first media source use 736 different codecs, H264-SVC [RFC6190] and H264 [RFC6184]. These two 737 simulcast streams also have a temporal dependency. Two different 738 video codecs, VP8 [I-D.ietf-payload-vp8] and H264, are offered as 739 alternatives for the third simulcast stream for the first media 740 source. RID is used as simulcast stream identification, reducing the 741 number of media formats needed. 743 The second media source is offered with three different simulcast 744 streams. All video streams of this second media source are loss 745 protected by RTP retransmission [RFC4588]. RID is used as simulcast 746 stream identification. 748 Fred's client is also using BUNDLE to send all RTP streams from all 749 media descriptions in the same RTP session on a single media 750 transport. Although using many different simulcast streams in this 751 example, use of RID as simulcast stream identification enables use of 752 a low number of RTP payload types. Note that the use of both BUNDLE 753 and RID recommends using the RTP header extension [RFC5285] for 754 carrying these fields. 756 v=0 757 o=fred 238947129 823479223 IN IP4 192.0.2.125 758 s=Offer from Simulcast Enabled Multi-Source Client 759 t=0 0 760 c=IN IP4 192.0.2.125 761 a=group:BUNDLE foo bar zen 763 m=audio 49200 RTP/AVP 99 764 a=mid:foo 765 a=rtpmap:99 G722/8000 767 m=video 49600 RTP/AVP 100 101 103 768 a=mid:bar 769 a=rtpmap:100 H264-SVC/90000 770 a=rtpmap:101 H264/90000 771 a=rtpmap:103 VP8/90000 772 a=fmtp:100 profile-level-id=42400d; max-fs=3600; max-mbps=108000; \ 773 mst-mode=NI-TC 774 a=fmtp:101 profile-level-id=42c00d; max-fs=3600; max-mbps=54000 775 a=fmtp:103 max-fs=900; max-fr=30 776 a=rid:1 send pt=100 max-width=1280;max-height=720;max-fr=60;depend=2 777 a=rid:2 send pt=101 max-width=1280;max-height=720;max-fr=30 778 a=rid:3 send pt=101 max-width=640;max-height=360 779 a=rid:4 send pt=103 max-width=640;max-height=360 780 a=depend:100 lay bar:101 781 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 782 a=extmap:2 urn:ietf:params:rtp-hdrext:rid 783 a=simulcast: send rid=1;2;4,3 785 m=video 49602 RTP/AVP 96 104 786 a=mid:zen 787 a=rtpmap:96 VP8/90000 788 a=fmtp:96 max-fs=3600; max-fr=30 789 a=rtpmap:104 rtx/90000 790 a=fmtp:104 apt=96;rtx-time=200 791 a=rid:5 send pt=96 max-fs=921600;max-fr=30 792 a=rid:6 send pt=96 max-fs=614400;max-fr=15 793 a=rid:7 send pt=96 max-fs=230400;max-fr=30 794 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 795 a=extmap:2 urn:ietf:params:rtp-hdrext:rid 796 a=simulcast: send rid=6;5;7 798 Figure 5: Fred's Multi-Source Simulcast Offer 800 Note: Empty lines in the SDP above are added only for readability 801 and would not be present in an actual SDP. 803 7. Network Aspects 805 Simulcast is in this memo defined as the act of sending multiple 806 alternative encoded streams of the same underlying media source. 807 When transmitting multiple independent streams that originate from 808 the same source, it could potentially be done in several different 809 ways using RTP. A general discussion on considerations for use of 810 the different RTP multiplexing alternatives can be found in 811 Guidelines for Multiplexing in RTP 812 [I-D.ietf-avtcore-multiplex-guidelines]. Discussion and 813 clarification on how to handle multiple streams in an RTP session can 814 be found in [I-D.ietf-avtcore-rtp-multi-stream]. 816 The network aspects that are relevant for simulcast are: 818 Quality of Service: When using simulcast it might be of interest to 819 prioritize a particular simulcast stream, rather than applying 820 equal treatment to all streams. For example, lower bit-rate 821 streams may be prioritized over higher bit-rate streams to 822 minimize congestion or packet losses in the low bit-rate streams. 823 Thus, there is a benefit to use a simulcast solution that supports 824 QoS as good as possible. By separating simulcast streams into 825 different RTP sessions and send those RTP sessions over different 826 media transports, a simulcast stream can be prioritized by 827 existing flow based QoS mechanisms. When using unicast, QoS 828 mechanisms based on individual packet marking are also feasible, 829 which do not require separation of simulcast streams into 830 different RTP sessions to apply different QoS. The proposed 831 solution can be extended to support this functionality with an 832 optional mid: prefix before the RTP payload types of a simulcast 833 stream, to describe simulcast across multiple media descriptions. 835 Editor's note: With the chosen approach, it is not possible to 836 use different simulcast streams on different transports, so 837 either that description should be removed, or the solution has 838 to be amended to cater also for that case. 840 NAT/FW Traversal: Using multiple RTP sessions will incur more cost 841 for NAT/FW traversal unless they can re-use the same transport 842 flow, which can be achieved by either one of multiplexing multiple 843 RTP sessions on a single lower layer transport 844 [I-D.westerlund-avtcore-transport-multiplexing] or Multiplexing 845 Negotiation Using SDP Port Numbers 846 [I-D.ietf-mmusic-sdp-bundle-negotiation]. If flow based QoS with 847 any differentiation is desirable, the cost for additional 848 transport flows is likely necessary. 850 Multicast: Multiple RTP sessions will be required to enable 851 combining simulcast with multicast. Different simulcast streams 852 have to be separated to different multicast groups to allow a 853 multicast receiver to pick the stream it wants, rather than 854 receive all of them. In this case, the only reasonable 855 implementation is to use different RTP sessions for each multicast 856 group so that reporting and other RTCP functions operate as 857 intended. The proposed solution can be extended to support this 858 functionality with an optional mid: prefix before the RTP payload 859 types of a simulcast stream, to describe simulcast across multiple 860 media descriptions. 862 Editor's note: As with QoS above, different simulcast streams on 863 different multicast groups are not possible with the chosen 864 approach, and text must be changed accordingly. 866 8. IANA Considerations 868 This document requests to register a new SDP attribute, simulcast. 870 Formal registrations to be written. 872 9. Security Considerations 874 The simulcast capability, configuration attributes and parameters are 875 vulnerable to attacks in signaling. 877 A false inclusion of the "a=simulcast" attribute may result in 878 simultaneous transmission of multiple RTP streams that would 879 otherwise not be generated. The impact is limited by the media 880 description joint bandwidth, shared by all simulcast streams 881 irrespective of their number. There may however be a large number of 882 unwanted RTP streams that will impact the share of bandwidth 883 allocated for the originally wanted RTP stream. 885 A hostile removal of the "a=simulcast" attribute will result in 886 simulcast not being used. 888 Neither of the above will likely have any major consequences and can 889 be mitigated by signaling that is at least integrity and source 890 authenticated to prevent an attacker to change it. 892 10. Contributors 894 Morgan Lindqvist and Fredrik Jansson, both from Ericsson, have 895 contributed with important material to the first versions of this 896 document. Robert Hansen and Cullen Jennings, from Cisco, and Peter 897 Thatcher, from Google, contributed significantly to subsequent 898 versions. 900 11. Acknowledgements 902 12. References 904 12.1. Normative References 906 [I-D.pthatcher-mmusic-rid] 907 Thatcher, P., Zanaty, M., Nandakumar, S., Roach, A., 908 Burman, B., and B. Campen, "RTP Payload Format 909 Constraints", draft-pthatcher-mmusic-rid-00 (work in 910 progress), October 2015. 912 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 913 Requirement Levels", BCP 14, RFC 2119, 914 DOI 10.17487/RFC2119, March 1997, 915 . 917 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 918 Jacobson, "RTP: A Transport Protocol for Real-Time 919 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 920 July 2003, . 922 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 923 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 924 July 2006, . 926 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 927 Correction", RFC 5109, DOI 10.17487/RFC5109, December 928 2007, . 930 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 931 Specifications: ABNF", STD 68, RFC 5234, 932 DOI 10.17487/RFC5234, January 2008, 933 . 935 [RFC7104] Begen, A., Cai, Y., and H. Ou, "Duplication Grouping 936 Semantics in the Session Description Protocol", RFC 7104, 937 DOI 10.17487/RFC7104, January 2014, 938 . 940 12.2. Informative References 942 [I-D.ietf-avtcore-multiplex-guidelines] 943 Westerlund, M., Perkins, C., and H. Alvestrand, 944 "Guidelines for using the Multiplexing Features of RTP to 945 Support Multiple Media Streams", draft-ietf-avtcore- 946 multiplex-guidelines-03 (work in progress), October 2014. 948 [I-D.ietf-avtcore-rtp-multi-stream] 949 Lennox, J., Westerlund, M., Wu, W., and C. Perkins, 950 "Sending Multiple Media Streams in a Single RTP Session", 951 draft-ietf-avtcore-rtp-multi-stream-09 (work in progress), 952 September 2015. 954 [I-D.ietf-avtcore-rtp-topologies-update] 955 Westerlund, M. and S. Wenger, "RTP Topologies", draft- 956 ietf-avtcore-rtp-topologies-update-10 (work in progress), 957 July 2015. 959 [I-D.ietf-avtext-rtp-grouping-taxonomy] 960 Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 961 B. Burman, "A Taxonomy of Semantics and Mechanisms for 962 Real-Time Transport Protocol (RTP) Sources", draft-ietf- 963 avtext-rtp-grouping-taxonomy-08 (work in progress), July 964 2015. 966 [I-D.ietf-avtext-rtp-stream-pause] 967 Burman, B., Akram, A., Even, R., and M. Westerlund, "RTP 968 Stream Pause and Resume", draft-ietf-avtext-rtp-stream- 969 pause-10 (work in progress), September 2015. 971 [I-D.ietf-mmusic-sdp-bundle-negotiation] 972 Holmberg, C., Alvestrand, H., and C. Jennings, 973 "Negotiating Media Multiplexing Using the Session 974 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 975 negotiation-23 (work in progress), July 2015. 977 [I-D.ietf-payload-vp8] 978 Westin, P., Lundin, H., Glover, M., Uberti, J., and F. 979 Galligan, "RTP Payload Format for VP8 Video", draft-ietf- 980 payload-vp8-17 (work in progress), September 2015. 982 [I-D.roach-mmusic-unified-plan] 983 Roach, A., Uberti, J., and M. Thomson, "A Unified Plan for 984 Using SDP with Large Numbers of Media Flows", draft-roach- 985 mmusic-unified-plan-00 (work in progress), July 2013. 987 [I-D.westerlund-avtcore-transport-multiplexing] 988 Westerlund, M. and C. Perkins, "Multiplexing Multiple RTP 989 Sessions onto a Single Lower-Layer Transport", draft- 990 westerlund-avtcore-transport-multiplexing-07 (work in 991 progress), October 2013. 993 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 994 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 995 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 996 DOI 10.17487/RFC2198, September 1997, 997 . 999 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1000 with Session Description Protocol (SDP)", RFC 3264, 1001 DOI 10.17487/RFC3264, June 2002, 1002 . 1004 [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for 1005 Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389, 1006 September 2002, . 1008 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1009 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1010 DOI 10.17487/RFC4588, July 2006, 1011 . 1013 [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF 1014 Digits, Telephony Tones, and Telephony Signals", RFC 4733, 1015 DOI 10.17487/RFC4733, December 2006, 1016 . 1018 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 1019 DOI 10.17487/RFC5117, January 2008, 1020 . 1022 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 1023 Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 1024 2008, . 1026 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 1027 Media Attributes in the Session Description Protocol 1028 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 1029 . 1031 [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding 1032 Dependency in the Session Description Protocol (SDP)", 1033 RFC 5583, DOI 10.17487/RFC5583, July 2009, 1034 . 1036 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 1037 Payload Format for H.264 Video", RFC 6184, 1038 DOI 10.17487/RFC6184, May 2011, 1039 . 1041 [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 1042 "RTP Payload Format for Scalable Video Coding", RFC 6190, 1043 DOI 10.17487/RFC6190, May 2011, 1044 . 1046 [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image 1047 Attributes in the Session Description Protocol (SDP)", 1048 RFC 6236, DOI 10.17487/RFC6236, May 2011, 1049 . 1051 Appendix A. Changes From Earlier Versions 1053 NOTE TO RFC EDITOR: Please remove this section prior to publication. 1055 A.1. Modifications Between WG Version -01 and -02 1057 o Relying on the new RID solution for codec constraints and 1058 configuration identification. This has resulted in changes in 1059 syntax to identify if pt or RID is used to describe the simulcast 1060 stream. 1062 o Renamed simulcast version and simulcast version alternative to 1063 simulcast stream and simulcast format respectively, and improved 1064 definitions for them. 1066 o Clarification that it is possible to switch between simulcast 1067 version alternatives, but that only a single one be used at any 1068 point in time. 1070 o Changed the definition so that ordering of simulcast formats for a 1071 specific simulcast stream do have a preference order. 1073 A.2. Modifications Between WG Version -00 and -01 1075 o No changes. Only preventing expiry. 1077 A.3. Modifications Between Individual Version -00 and WG Version -00 1079 o Added this appendix. 1081 Authors' Addresses 1083 Bo Burman 1084 Ericsson 1085 Kistavagen 25 1086 SE-164 80 Stockholm 1087 Sweden 1089 Email: bo.burman@ericsson.com 1091 Magnus Westerlund 1092 Ericsson 1093 Farogatan 2 1094 SE-164 80 Stockholm 1095 Sweden 1097 Phone: +46 10 714 82 87 1098 Email: magnus.westerlund@ericsson.com 1100 Suhas Nandakumar 1101 Cisco 1102 170 West Tasman Drive 1103 San Jose, CA 95134 1104 USA 1106 Email: snandaku@cisco.com 1108 Mo Zanaty 1109 Cisco 1110 170 West Tasman Drive 1111 San Jose, CA 95134 1112 USA 1114 Email: mzanaty@cisco.com