idnits 2.17.1 draft-ietf-mmusic-mux-exclusive-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5761, updated by this document, for RFC5378 checks: 2006-10-02) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 8, 2016) is 2815 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) -- Looks like a reference, but probably isn't: '10' on line 304 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-13 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-31 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Updates: 5761 (if approved) August 8, 2016 5 Intended status: Standards Track 6 Expires: February 9, 2017 8 Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP 9 draft-ietf-mmusic-mux-exclusive-10.txt 11 Abstract 13 This document defines a new SDP media-level attribute, 'rtcp-mux- 14 only', that can be used by an endpoint to indicate exclusive support 15 of RTP/RTCP multiplexing. The document also updates RFC 5761, by 16 clarifying that an offerer can use a mechanism to indicate that it is 17 not able to send and receive RTCP on separate ports. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on February 9, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. SDP rtcp-mux-only Attribute . . . . . . . . . . . . . . . . . 3 56 4. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 4 57 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4.2. Generating the Initial SDP Offer . . . . . . . . . . . . 5 59 4.3. Generating the Answer . . . . . . . . . . . . . . . . . . 5 60 4.4. Offerer Processing of the SDP Answer . . . . . . . . . . 6 61 4.5. Modifying the Session . . . . . . . . . . . . . . . . . . 6 62 5. Update to RFC 5761 . . . . . . . . . . . . . . . . . . . . . 7 63 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 5.2. Update to 4th paragraph of section 5.1.1 . . . . . . . . 7 65 5.3. Update to 2nd paragraph of section 5.1.3 . . . . . . . . 8 66 6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 70 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 73 11.2. Informative References . . . . . . . . . . . . . . . . . 12 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 [RFC5761] defines how to multiplex RTP and RTCP on a single IP 79 address and port, referred to as RTP/RTCP multiplexing. [RFC5761] 80 also defines an Session Description Protocol (SDP) [RFC4566] 81 attribute, 'rtcp-mux' that can be used by entities to indicate 82 support, and negotiate usage of, RTP/RTCP multiplexing. 84 As defined in [RFC5761], if the peer endpoint does not support RTP/ 85 RTCP multiplexing, both endpoints should use separate ports for 86 sending and receiving of RTCP (referred to as fallback to usage of 87 separate ports for RTP and RTCP). 89 Some newer applications that do not require backward compatibility 90 with peers that cannot multiplex RTCP might choose to not implement 91 separation of RTP and RTCP. Examples of such applications are W3C 92 WEBRTC [W3C.WD-webrtc-20120209] applications, that are not required 93 to interoperate with non-WEBRTC clients. For such applications, this 94 document defines an SDP attribute to signal intent to require 95 multiplexing. The use of this attribute in SDP offers [RFC3264] by 96 entities that ever need to interoperate with peers that do not 97 support RTC/RTCP multiplexing may harm interoperability. Also, while 98 the SDP answerer [RFC3264] might support, and prefer usage of, 99 fallback to non-multiplex, the attribute indicates that fallback to 100 non-multiplex cannot be enabled. One example of where non-multiplex 101 is preferred is where an endpoint is connected to a radio interface, 102 and wants to use different bearers (possibly with different quality 103 characteristics) for RTP and RTCP. Another example is where the one 104 endpoint is acting as a gateway to a network where RTP/RTCP 105 multiplexing cannot be used. In such case there endpoint may prefer 106 non-multiplexing also towards the other network. Otherwise the 107 endpoint would have to perform de-multiplexing of RTP and RTCP. 109 This document defines a new SDP media-level attribute, 'rtcp-mux- 110 only', that can be used by an endpoint to indicate exclusive support 111 of RTP/RTCP multiplexing. The document also updates RFC 5761, by 112 clarifying that an offerer can use a mechanism to indicate that it is 113 not able to send and receive RTCP on separate ports. 115 The document also describes the Interactive Connectivity 116 Establishment (ICE) [RFC5245] considerations when indicating 117 exclusive support of RTP/RTCP multiplexing. 119 2. Conventions 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 3. SDP rtcp-mux-only Attribute 127 This section defines a new SDP media-level attribute, 'rtcp-mux- 128 only'. 130 Name: rtcp-mux-only 132 Value: N/A 134 Usage Level: media 136 Charset Dependent: no 138 Syntax: 140 rtcp-mux-only 142 Example: 144 a=rtcp-mux-only 146 In an SDP offer, the offerer uses the SDP 'rtcp-mux-only' attribute 147 to indicate exclusive support of RTP/RTCP multiplexing for the RTP- 148 based media associated with the SDP media description ("m=" line). 150 In an SDP answer, the 'rtcp-mux-only' attribute indicates that the 151 answerer supports, and accepts usage of, RTP/RTCP multiplexing for 152 the RTP-based media associated with the SDP media description ("m=" 153 line). 155 The usage of the SDP 'rtcp-mux-only' attribute is only defined for 156 RTP-based media. 158 The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'rtcp- 159 mux-only' attribute is 'IDENTICAL', which means that the attribute, 160 if used within a BUNDLE group 161 [I-D.ietf-mmusic-sdp-bundle-negotiation], must be associated with all 162 multiplexed RTP-based media descriptions within the BUNDLE group. 164 The 'rtcp-mux-only' attribute applies to the whole associated media 165 description. The attribute MUST NOT be defined per source (using the 166 SDP 'ssrc' attribute [RFC5576]). 168 The SDP offer/answer [RFC3264] procedures associated with the 169 attribute are defined in Section 4 171 4. SDP Offer/Answer Procedures 172 4.1. General 174 This section defines the SDP offer/answer [RFC3264] procedures for 175 indicating exclusive support of, and negotiating usage of, RTP/RTCP 176 multiplexing. 178 The procedures in this section apply to individual RTP-based SDP 179 media descriptions ("m=" lines). 181 4.2. Generating the Initial SDP Offer 183 When an offerer sends the initial offer, if the offerer wants to 184 indicate exclusive RTP/RTCP multiplexing for RTP-based media, the 185 offerer MUST associate an SDP 'rtcp-mux-only' attribute with the 186 associated SDP media description ("m=" line). 188 In addition, if the offerer associates an SDP 'rtcp-mux-only' 189 attribute with an SDP media description ("m=" line), the offerer MAY 190 also associate an SDP 'rtcp-mux' attribute with the same SDP media 191 description ("m=" line), following the procedures in [RFC5761]. 193 If the offerer associates an SDP 'rtcp' attribute [RFC3605] with an 194 SDP media description ("m=" line), and if the offerer also associates 195 an SDP 'rtcp-mux-only' attribute with the same SDP media description 196 ("m=" line), the address and port values of the SDP 'rtcp' attribute 197 MUST match the corresponding values for RTP. 199 NOTE: This specification does not mandate the usage of the SDP 'rtcp' 200 attribute for RTP/RTCP multiplexing. 202 4.3. Generating the Answer 204 When an answerer receives an offer that contains an SDP 'rtcp-mux- 205 only' attribute, associated with an RTP-based SDP media description 206 ("m=" line), if the answerer accepts the usage of RTP/RTCP 207 multiplexing, the answerer MUST associate an SDP 'rtcp-mux-only' 208 attribute with the corresponding SDP media description ("m=") in the 209 associated answer. If the answerer does not accept the usage of RTP/ 210 RTCP multiplexing, the answerer MUST either reject the SDP media 211 description ("m=") by setting the port value to zero in the 212 associated answer, or reject the whole offer, following the 213 procedures in [RFC3264]. 215 In addition, if the answerer associates an SDP 'rtcp-mux-only' 216 attribute with an SDP media description ("m=" line) in the answer, 217 and if the corresponding "m=" line in the associated offer contained 218 an SDP 'rtcp-mux' attribute, the answerer MUST in addition associate 219 an SDP 'rtcp-mux' attribute with the same "m=" line, following the 220 procedures in [RFC5761]. 222 4.4. Offerer Processing of the SDP Answer 224 If an offerer associated an SDP 'rtcp-mux-only' attribute with an 225 RTP-based SDP media description ("m=" line) in an offer, and if the 226 corresponding SDP media description ("m=" line) in the associated 227 answer contains an SDP 'rtcp-mux-only' attribute, and/or an SDP 228 'rtcp-mux' attribute, the offerer MUST apply the RTP/RTCP 229 multiplexing procedures [RFC5761] to the associated RTP-based media. 230 If the corresponding SDP media description ("m=" line) in the 231 associated answer does not contain an SDP 'rtcp-mux-only' attribute, 232 nor an SDP 'rtcp-mux' attribute, the offerer MUST either take 233 appropriate actions in order to disable the associated RTP-based 234 media, or send a new offer without associating an SDP 'rtcp-mux-only' 235 attribute with the SDP media description ("m=" line). 237 NOTE: This document does not mandate specific actions on how to 238 terminate the RTP media. The offerer might e.g. send a new offer 239 where the port value of the SDP media description is set to zero in 240 order to terminate the RTP media. 242 4.5. Modifying the Session 244 When an offerer sends a subsequent offer, if the offerer and answerer 245 have previously negotiated usage of exclusive RTP/RTCP multiplexing 246 for the media associated with an RTP-based SDP media description 247 ("m=" line), the offerer SHOULD associate an SDP 'rtcp-mux-only' with 248 the corresponding SDP media description ("m=" line). 250 In addition, if the offerer associates an SDP 'rtcp-mux-only' 251 attribute with an SDP media description ("m=" line), the offerer MAY 252 also associate an SDP 'rtcp-mux' attribute with the same SDP media 253 description ("m=" line), following the procedures in [RFC5761]. 255 If the offerer does not associate the attributes with the 256 corresponding SDP media description ("m=" line) it is an indication 257 that the offerer no longer wants to use RTP/RTCP multiplexing, and 258 instead MUST fallback to usage of separate ports for RTP and RTCP 259 once the offer has been accepted by the answerer. 261 When an offerer sends a subsequent offer, if the offerer and answerer 262 have not previously negotiated usage of RTP/RTCP multiplexing for the 263 media associated with an RTP-based SDP media description ("m=" line), 264 the offerer MAY indicate exclusive support of RTP/RTCP multiplexing, 265 following the procedures in Section 4.2. The offerer MUST process 266 the associated answer following the procedures in Section 4.4. 268 It is RECOMMENDED to not switch between usage of RTP/RTCP 269 multiplexing and usage of separate ports for RTP and RTCP in a 270 subsequent offer, unless there is a use-case that mandates it. 272 5. Update to RFC 5761 274 5.1. General 276 This section updates sections 5.1.1 and 5.1.3 of RFC 5761, by 277 clarifying that an offerer can use a mechanism to indicate that it is 278 not able to send and receive RTCP on separate ports, and that the 279 offerer shall terminate the affected streams if the answerer does not 280 indicate support of RTP/RTCP multiplexing. It also clarifies that, 281 when the offerer is not able to send and receive RTCP on separate 282 ports, the offerer will not provide an SDP 'candidate' attribute for 283 RTCP, nor will the offerer provide a fallback port for RTCP (using 284 the SDP 'rtcp' attribute). 286 5.2. Update to 4th paragraph of section 5.1.1 288 OLD TEXT: 290 If the answer does not contain an "a=rtcp-mux" attribute, the offerer 291 MUST NOT multiplex RTP and RTCP packets on a single port. Instead, 292 it should send and receive RTCP on a port allocated according to the 293 usual port-selection rules (either the port pair, or a signalled port 294 if the "a=rtcp:" attribute [10] is also included). This will occur 295 when talking to a peer that does not understand the "a=rtcp-mux" 296 attribute. 298 NEW TEXT: 300 If the answer does not contain an "a=rtcp-mux" attribute, the offerer 301 MUST NOT multiplex RTP and RTCP packets on a single port. Instead, 302 it should send and receive RTCP on a port allocated according to the 303 usual port-selection rules (either the port pair, or a signaled port 304 if the "a=rtcp:" attribute [10] is also included). This will occur 305 when talking to a peer that does not understand the "a=rtcp-mux" 306 attribute. However, if the offerer indicated in the offer that it is 307 not able to send and receive RTCP on a separate port, the offerer 308 MUST disable the media streams associated with the attribute. The 309 mechanism for indicating that the offerer is not able to send and 310 receive RTCP on a separate port is outside the scope of this 311 specification. 313 5.3. Update to 2nd paragraph of section 5.1.3 315 OLD TEXT: 317 If it is desired to use both ICE and multiplexed RTP and RTCP, the 318 initial offer MUST contain an "a=rtcp-mux" attribute to indicate that 319 RTP and RTCP multiplexing is desired and MUST contain "a=candidate:" 320 lines for both RTP and RTCP along with an "a=rtcp:" line indicating a 321 fallback port for RTCP in the case that the answerer does not support 322 RTP and RTCP multiplexing. This MUST be done for each media where 323 RTP and RTCP multiplexing is desired. 325 NEW TEXT: 327 If it is desired to use both ICE and multiplexed RTP and RTCP, the 328 initial offer MUST contain an "a=rtcp-mux" attribute to indicate that 329 RTP and RTCP multiplexing is desired and MUST contain "a=candidate:" 330 lines for both RTP and RTCP along with an "a=rtcp:" line indicating a 331 fallback port for RTCP in the case that the answerer does not support 332 RTP and RTCP multiplexing. This MUST be done for each media where 333 RTP and RTCP multiplexing is desired. However, if the offerer 334 indicates in the offer that it is not able to send and receive RTCP 335 on a separate port, the offerer MUST NOT include "a=candidate:" 336 lines for RTCP, and the offerer MUST NOT provide a fallback port for 337 RTCP using the "a=rtcp:" line. 339 6. ICE Considerations 341 As defined in [RFC5245], if an entity is aware that the remote peer 342 supports, and is willing to use, RTP/RTCP multiplexing, the entity 343 will only provide RTP candidates (component ID 1). However, only 344 providing RTP candidates does not as such imply exclusive support of 345 RTP/RTCP multiplexing. RTCP candidates would not be provided also in 346 cases where RTCP is not supported at all. Therefore, additional 347 information is needed in order to indicate support of exclusive RTP/ 348 RTCP multiplexing. This document defines such mechanism using the 349 SDP 'rtcp-mux-only' attributes. 351 7. Security Considerations 353 This document does not introduce new security considerations in 354 additions to those specified in [RFC3605] and [RFC5761]. 356 8. IANA Considerations 358 This document updates the "Session Description Protocol Parameters" 359 registry as specified in Section 8.2.2 of [RFC4566]. Specifically, 360 it adds the SDP 'rtcp-mux-only' attribute to the table for SDP media 361 level attributes. 363 Attribute name: rtcp-mux-only 364 Type of attribute: media-level 365 Subject to charset: no 366 Purpose: Indicate exclusive support of RTP/RTCP multiplexing 367 Appropriate Values: N/A 368 Contact name: Christer Holmberg (christer.holmberg@ericsson.com) 369 Mux Category: IDENTICAL 371 9. Acknowledgments 373 Thanks to Roman Shpount, Paul Kyzivat, Ari Keranen, Bo Burman, Tomas 374 Frankkila and Martin Thomson for their comments and input on the 375 document. Thanks to Francis Dupont for the genart review. 377 10. Change Log 379 [RFC EDITOR NOTE: Please remove this section when publishing] 381 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-09 383 o Changes based on IESG review comments from Alexey Melnikov and 384 Mirja Kuhlewind: 386 o - References to draft-mux-attributes and draft-sdp-bundle made 387 normative. 389 o - Text added regarding cases where entities might want to use non- 390 multiplexed RTP and RTCP. 392 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-08 394 o Editorial changes based on genart comments from Francis Dupont. 396 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-07 398 o Comments from Ben Campbell. 400 o - Additional text regarding applications for which the mechanism 401 is suitable. 403 o - Removal of pre-RFC5378 disclaimer. 405 o - Editorial fixes. 407 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-06 409 o - Editorial fix. 411 o - Addition of pre-RFC5378 disclaimer. 413 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-05 415 o Editorial fix. 417 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-04 419 o Changes based on comments from Flemming Andreasen. 421 o - Attribute mux category changed to IDENTICAL. 423 o - Reference to draft-5245bis changed to RFC 5245. 425 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-03 427 o Editorial changes based on comments from Martin Thomson. 429 o Change of attribute name. 431 o RFC 5761 updates added. 433 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-02 435 o Minor editorial fix. 437 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-01 439 o Mux category and source-specific applicability added. 441 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-00 443 o Defined new SDP attribute for indicating rtcp-mux-exclusive. 445 o Updates to RFC 5761 removed. 447 o IANA considerations added. 449 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-03 451 o Submitted as draft-ietf-mmusic-rtcp-mux-exclusive-00. 453 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-02 455 o Intended status changed to "Standards track". 457 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-01 459 o Clarified that the SDP rtcp attribute may contain the optional IP 460 address part. 462 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-00 464 o Additional updates to Section 5.1.1 of RFC 5761. 466 o ICE considerations added. 468 11. References 470 11.1. Normative References 472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, 474 DOI 10.17487/RFC2119, March 1997, 475 . 477 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 478 with Session Description Protocol (SDP)", RFC 3264, 479 DOI 10.17487/RFC3264, June 2002, 480 . 482 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 483 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 484 July 2006, . 486 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 487 (ICE): A Protocol for Network Address Translator (NAT) 488 Traversal for Offer/Answer Protocols", RFC 5245, 489 DOI 10.17487/RFC5245, April 2010, 490 . 492 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 493 Control Packets on a Single Port", RFC 5761, 494 DOI 10.17487/RFC5761, April 2010, 495 . 497 [I-D.ietf-mmusic-sdp-mux-attributes] 498 Nandakumar, S., "A Framework for SDP Attributes when 499 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-13 500 (work in progress), June 2016. 502 [I-D.ietf-mmusic-sdp-bundle-negotiation] 503 Holmberg, C., Alvestrand, H., and C. Jennings, 504 "Negotiating Media Multiplexing Using the Session 505 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 506 negotiation-31 (work in progress), June 2016. 508 11.2. Informative References 510 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 511 in Session Description Protocol (SDP)", RFC 3605, 512 DOI 10.17487/RFC3605, October 2003, 513 . 515 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 516 Media Attributes in the Session Description Protocol 517 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 518 . 520 [W3C.WD-webrtc-20120209] 521 Bergkvist, A., Burnett, D., Jennings, C., and A. 522 Narayanan, "WebRTC 1.0: Real-time Communication Between 523 Browsers", World Wide Web Consortium WD WD-webrtc- 524 20120209, February 2012, 525 . 527 Author's Address 529 Christer Holmberg 530 Ericsson 531 Hirsalantie 11 532 Jorvas 02420 533 Finland 535 Email: christer.holmberg@ericsson.com