idnits 2.17.1 draft-marjou-rtcweb-audio-codecs-for-interop-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 25, 2013) is 4077 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.ietf-rtcweb-se-ucases-and-requirements' is mentioned on line 140, but not defined == Missing Reference: 'I-D.ietf-rtcweb-audio-codecs' is mentioned on line 414, but not defined == Missing Reference: 'RFC6716' is mentioned on line 425, but not defined == Missing Reference: 'RFC3551' is mentioned on line 427, but not defined == Missing Reference: 'RFC4733' is mentioned on line 428, but not defined == Unused Reference: 'RFC2616' is defined on line 475, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtcweb-audio' is defined on line 483, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtcweb-use-cases-and-requirements' is defined on line 493, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-11) exists of draft-ietf-rtcweb-audio-01 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-06 == Outdated reference: A later version (-16) exists of draft-ietf-rtcweb-use-cases-and-requirements-10 Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Marjou 3 Internet-Draft S. Proust 4 Intended status: Informational France Telecom Orange 5 Expires: August 29, 2013 K. Bogineni 6 Verizon Wireless 7 R. Jesske 8 B. Feiten 9 Deutsche Telekom AG 10 L. Miao 11 Huawei 12 E. Enrico 13 Telecom Italia 14 E. Berger 15 Cisco 16 February 25, 2013 18 WebRTC audio codecs for interoperability with legacy networks. 19 draft-marjou-rtcweb-audio-codecs-for-interop-01 21 Abstract 23 This document presents use-cases underlining why WebRTC needs AMR-WB, 24 AMR and G.722 as additional relevant voice codecs to satisfactorily 25 ensure interoperability with existing systems. It also presents a 26 way forward that takes into consideration the concerns expressed 27 against the addition of codecs besides Opus and G.711. 29 It is especially recognized that unjustified additional costs on 30 browsers must be avoided. Therefore, the proposed solution intends 31 to fully rely on the codecs already supported on the devices 32 implementing the browsers and for which license and implementation 33 costs have been already paid. 35 It is expected that this way forward will significantly limit the 36 costs and technical impacts on browsers while greatly improving 37 interoperability with legacy systems and overall quality. It intents 38 to be considered as a good compromise beneficial to all parties and 39 to the whole industry: the user quality experience will be optimized 40 as a whole at limited additional costs without incurring high costs 41 for both networks to support transcoding and browsers to support 42 additional codecs. 44 Status of this Memo 46 This Internet-Draft is submitted to IETF in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at http://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on August 29, 2013. 61 Copyright Notice 63 Copyright (c) 2013 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 82 4.1. AMR-WB . . . . . . . . . . . . . . . . . . . . . . . . . . 5 83 4.1.1. Use case . . . . . . . . . . . . . . . . . . . . . . . 5 84 4.1.2. Problem . . . . . . . . . . . . . . . . . . . . . . . 5 85 4.1.3. Concerns from the browser manufacturers . . . . . . . 7 86 4.2. AMR . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 87 4.2.1. Use case . . . . . . . . . . . . . . . . . . . . . . . 7 88 4.2.2. Problem . . . . . . . . . . . . . . . . . . . . . . . 7 89 4.2.3. Concerns from the browser manufacturers . . . . . . . 8 90 4.3. G.722 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 91 4.3.1. Use case . . . . . . . . . . . . . . . . . . . . . . . 8 92 4.3.2. Problem . . . . . . . . . . . . . . . . . . . . . . . 8 93 4.3.3. Concerns from the browser manufacturers . . . . . . . 9 94 5. The proposed way-forward . . . . . . . . . . . . . . . . . . . 9 95 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 96 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 97 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 98 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 99 9.1. Normative references . . . . . . . . . . . . . . . . . . . 11 100 9.2. Informative references . . . . . . . . . . . . . . . . . . 12 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 103 1. Introduction 105 As indicated in [I-D.ietf-rtcweb-overview], it has been anticipated 106 that WebRTC will not remain an isolated island and that some WebRTC 107 endpoints will need to communicate with devices used in other 108 existing networks with the help of a gateway. 110 In order to reach the agreement to select OPUS and G.711 as mandatory 111 to implement codecs it was also agreed to consider possible 112 additional codecs in order to take into account the concerns 113 expressed on interoperability issues. The discussion is consequently 114 currently taking place regarding the additional voice/audio codecs 115 that need to be supported. It is mainly questioned whether Opus and 116 G.711 are sufficient to properly address the interoperability issues 117 with legacy systems or if additional codecs need to be supported. 119 This document presents some use cases highlighting that Opus and 120 G.711 are not sufficient to properly cover all interoperability 121 requirements. In Section 4, important interoperability use-cases are 122 presented describing the interoperability issues that would be 123 encountered if only Opus and G.711 were supported. It therefore 124 advocates for the addition of other codecs while addressing concerns 125 raised against such support. 127 In section 5, a way forward is proposed that intends to be a real 128 compromise taking into consideration the concerns expressed against 129 additional codecs. It is especially recognized that unjustified 130 additional costs on browsers must be avoided. Therefore the proposed 131 solution intends to strongly limit the cost and technical impact on 132 browsers for the support of additional codecs (including license 133 costs) while improving interoperability with legacy systems. 135 Regarding audio codecs, it is a common misconception that other 136 existing voice networks only support G.711. Actually existing 137 networks use circuit switched networks as well as voice-over-IP 138 networks like H.323 and SIP-based networks, which means that audio 139 codecs are not limited to G.711. For instance, from use cases 140 described in [I-D.ietf-rtcweb-se-ucases-and-requirements], it can be 141 foreseen that interoperability with mobile telephony systems will 142 often happen. In such mobile systems, the UE must support the 143 Adaptive Multi-Rate (AMR) speech codec, and if wideband speech 144 communication is offered, the UE must support AMR wideband (AMR-WB) 145 codec. An increasing number of customers are now experiencing high 146 quality voice with HD Voice services over mobile, fixed networks or 147 over the internet. For those customers, any fall back to the G.711 148 narrow band quality for interoperability purpose could be perceived 149 as a strong and unacceptable quality degradation. Support of G.711 150 as the only codec for legacy interoperability purposes is currently 151 not sufficient. 153 2. Terminology 155 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 156 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 157 and "OPTIONAL" are to be interpreted as described in RFC 2119 158 [RFC2119]. 160 3. Definitions 162 Legacy networks: In this draft, legacy networks encompass the 163 conversational networks that are already deployed like the PSTN, the 164 PLMN, the IMS, H.323 networks. 166 4. Use cases 168 4.1. AMR-WB 170 4.1.1. Use case 172 The market of voice personal communication is driven by mobile 173 terminals and WebRTC technology is expected to be increasingly used 174 on smartphones. Furthermore "HD voice" is gaining momentum and more 175 and more personal communication devices will support wideband 176 communications. Customers are now getting used to the high quality 177 offered by HD Voice mobile devices, CAT-iq fixed HD devices and 178 eventually, HD Voice via WebRTC and OPUS over the internet. 180 Hence, many communications are expected to be held between a user of 181 a WebRTC endpoint on a device integrating an AMR-WB module who wants 182 to communicate with another user that can only be reached on a mobile 183 device that only supports AMR-WB (and AMR); both endpoints support HD 184 voice quality. 186 4.1.2. Problem 188 For this use case, the best situation will be to have the AMR-WB 189 supported by both sides of the connection. Indeed, as mentioned in 190 the introduction, AMR-WB is specified by 3GPP as the mandatory codec 191 to be supported by wideband mobile terminals for a wide range of 192 communication services as described in [AMR-WB]. This includes the 193 massively deployed circuit switched mobile telephony services and new 194 multimedia telephony services over IP/IMS and 4G/VoLTE as specified 195 by GSMA as voice IMS profile for VoLTE in IR92. Hence, AMR-WB is 196 strongly increasing with deployment in more than 60 networks from 45 197 countries and more than 130 types of terminals (c.f. 198 [Information-Papers]). 200 In that use case, if OPUS and G.711 remain the only codecs supported 201 by the WebRTC endpoints, a gateway must then transcode these codecs 202 into AMR-WB, and vice-versa, in order to implement the use-case. As 203 a consequence, a high number of calls are likely to be affected by 204 transcoding operations producing a degradation of the user quality 205 experience for many customers. This will have a very significant 206 business impact for all service providers on both sides, not only 207 with respect to the transcoding costs but mainly with respect to user 208 experience degradation. 210 The drawbacks of transcoding are recalled below: 212 o Cost issues: transcoding places important additional costs on 213 network gateways for example codec implementation and license 214 costs, deployments costs, testing/validation costs etc... However 215 these costs can be seen as just transferred from the terminal side 216 to the network side. The real issue is rather the degradation of 217 the quality of service affecting the end user perceived quality 218 which will be harmful to all concerned service providers. 220 o Intrinsic quality degradation: Subjective test results show that 221 intrinsic voice quality is significantly degraded by transcoding. 222 The degradation is around 0.2 to 0.3 MOS for most of transcoding 223 use cases with AMR-WB at 12.65 kbit/s. It should be stressed that 224 if transcoding is performed between AMR-WB and G.711, wideband 225 voice quality will be lost. Such bandwidth reduction effect 226 clearly degrades the user perceived quality of service leading to 227 shorter and less frequent calls (see ref_gsma). Such a switch to 228 G.711 will not be accepted anymore by customers. If transcoding 229 is performed between AMR-WB and OPUS, wideband communication could 230 be maintained. However, as the WB codecs complexity is higher 231 than NB codecs complexity, such WB transcoding is also more costly 232 and degrades the quality: MOS scores of transcoding between AMR-WB 233 12.65kbit/s and OPUS at 16 kbit/s in both directions are 234 significantly lower than those of AMR-WB at 12.65kbit/s or OPUS at 235 16 kbit/s. Furthermore, in degraded conditions, the addition of 236 defects, like audio artifacts due to packet losses, and the audio 237 effects resulting from the cascading of different packet loss 238 recovery algorithms may result in a quality below the acceptable 239 limit for the customers. 241 o Degraded interactivity due to increased latency: Transcoding means 242 full de-packetization for decoding of the media stream (including 243 mechanisms of de-jitter buffering and packet loss recovery) then 244 re-encoding, re-packetization and re-sending. The delays produced 245 by all these operations are additive and may increase the end to 246 end delay beyond acceptable limits like with more than 1s end to 247 end latency. 249 In addition to these drawbacks related to transcoding, the following 250 issue must be considered: 252 o Efficiency over mobile radio access: AMR-WB has been designed and 253 extensively tested for optimized and robust usage over mobile 254 radio access which results in enhanced capacity and efficiency. 255 The mobile radio bearer is optimized for such a codec with channel 256 coding protecting its most sensitive bits. Furthermore, AMR-WB is 257 more efficient than OPUS at regular bit rates used for mobile 258 communication of 12.65 kbit/s with fall back modes down to 6.6 259 kbit/s. Finally, hardware optimized implementation may allow for 260 less battery consumption 262 As a consequence, re-using AMR-WB would be beneficial for the 263 specific usage of WebRTC technology over mobile networks. With the 264 strong increase of the smartphone market the capability to use such a 265 mobile codec could strongly enforce and extend the market penetration 266 of the Web RTC technology. 268 4.1.3. Concerns from the browser manufacturers 270 The browser manufacturers are concerned by the additional costs that 271 the implementation of AMR-WB would put on browsers which include 272 integration and test costs and codec license costs. The proposed way 273 forward in Section 5 takes carefully into account this concern. 275 4.2. AMR 277 4.2.1. Use case 279 A user of a WebRTC endpoint on a device integrating an AMR module 280 wants to communicate with another user that can only be reached on a 281 mobile device that only supports AMR. Although more and more 282 terminal devices are now "HD voice" and support AMR-WB a high number 283 of legacy terminals supporting only AMR (terminals with no wideband / 284 HD Voice capabilities) are still used. 286 4.2.2. Problem 288 For this use case, the best solution will be to have the AMR 289 supported by both sides of the connection. Indeed, AMR is specified 290 by 3GPP as the mandatory codec to be supported by any mobile terminal 291 for a wide range of communication services. This includes the 292 massively deployed circuit switched mobile telephony services and new 293 multimedia telephony services over IP/IMS and 4G/VoLTE as specified 294 by GSMA as voice IMS profile for VoLTE in IR92. Hundreds of millions 295 of terminals are consequently currently supporting AMR and are not 296 supporting OPUS nor G.711. 298 In that use case, if OPUS and G.711 remain the only codecs supported 299 by the WebRTC endpoints the same problem as described in 4.1.1 will 300 be experienced because of transcoding impacts (costs, quality 301 degradation and increased latency) and lower efficiency over mobile 302 radio access. 304 As a consequence, re-using AMR would be beneficial for the specific 305 usage of WebRTC technology over mobile networks. With the strong 306 increase of the smartphone market the capability to use such a mobile 307 codec could strongly enforce and extend the market penetration of the 308 Web RTC technology. 310 4.2.3. Concerns from the browser manufacturers 312 Same as in Section 4.1.3. 314 4.3. G.722 316 4.3.1. Use case 318 As mentioned in Section 4.1.1, HD Voice is gaining momentum and more 319 and more personal communication devices support wideband 320 communications. Customers get used to high quality voice and WebRTC 321 aims at providing high voice quality over internet. In this use 322 case, a user of a WebRTC endpoint on a device integrating G.722 323 module wants to communicate with another user that can only be 324 reached on a device that only supports G.722 as a wideband codec, 325 G.722 being specified by ETSI as the mandatory wideband codec for New 326 Generation DECT (e.g. CAT-iq compliant). 328 4.3.2. Problem 330 For this use case, the best solution will be to have the G.722 331 supported by both sides of the connection. 333 Indeed, G.722 has been chosen by ETSI DECT to greatly increase the 334 voice quality by extending the bandwidth from narrow band to 335 wideband. Besides providing high wideband quality, it has low 336 complexity and very low delay. It is widely used in HD fixed 337 services in both hard and soft endpoints. 339 In this use case, if OPUS and G.711 remain the only codecs supported 340 by the WebRTC endpoints, a gateway must then transcode them from and 341 into G.722 in order to implement the use-case. As in Section 4.1.2, 342 it should be stressed that if transcoding is performed between G.722 343 and G.711, wideband quality will be lost with fall back to narrow 344 band. This will be perceived as a strong and unacceptable quality 345 degradation by customers experiencing more and more wideband voice 346 calls. It is also important to recall that wideband audio can help 347 persons with hearing impairments to use voice communication over 348 distance and drafts regulations dealing with this requires wide band 349 audio wherever there is voice communication pointing at G.722 as the 350 common codec at least to assure interoperability with wide-band audio 351 between providers. 353 On the other hand, transcoding with OPUS will greatly increase the 354 complexity, now, as mentioned above, G.722 low complexity was a key 355 factor in many applications mandating G.722. 357 4.3.3. Concerns from the browser manufacturers 359 Unlike AMR and AMR-WB, G.722, as G.711, is royalty free. Some 360 concerns about the availability of G.722 PLC were raised. Indeed 361 G.722 and G.711 were initially designed without Packet Loss 362 Concealment (PLC); nevertheless, ITU-T did standardize such 363 functionality as appendices to these recommendations to extend the 364 capabilities of current systems to support new applications and to 365 follow the market demand (for instance when these standards have been 366 widely used in VoIP applications). It has been argued that, unlike 367 the main recommendations, there are non-RF IPR declarations for these 368 PLC appendices (G.711 Appendix I, G.722 Appendices III and IV). It 369 should be recalled that these appendices are only examples and 370 implementers are free to use any PLC solution. For instance in the 371 G.722 case, there are publicly available PLC in the ITU-T Software 372 Tool Library. 374 5. The proposed way-forward 376 It is proposed that the browser manufacturers re-use AMR, AMR-WB and 377 G.722 codecs whenever they are already supported on the device on 378 which the browsers are implemented. 380 AMR and AMR-WB are already supported by millions of devices with 381 license costs and technical costs (implementation, tests...) already 382 paid for these codecs optimized for mobile usage. 384 Android now provides the APIs needed to give access to all the voice 385 and audio features implemented on the hardware that are required to 386 develop a voice service. This especially includes AMR and AMR-WB 387 encoding and decoding, adaptive gain control, echo cancellation and 388 noise reduction. 390 It is therefore technically feasible that browsers offer AMR and 391 AMR-WB as additional RTC Web codecs without re-implementing these 392 codecs and so with very limited additional costs: 394 o For implementation, no codec software code has to be developed, 395 tested or integrated directly in the browser (neither for the 396 encoding/decoding nor for related audio functions). 398 o For licensing, fees are already paid for the hardware 399 implementation. Since no additional codec is implemented on the 400 device with only one active voice call using the codec at a time 401 it cannot be argued that additional license fees have to be paid 402 in that case. However, in order to fully guarantee this, it is 403 made explicit in the proposed text that the support of AMR and 404 AMR-WB is conditional on the fact that no additional license fee 405 is required. 407 This proposed way forward is expected to be a good compromise 408 beneficial to all parties. It will optimize the user experience with 409 limited additional costs: excluding high costs for networks to 410 support transcoding and high additional costs on browsers to support 411 additional codecs. 413 It is consequently proposed the following wording to be added to 414 Section 3 (codec requirements) of [I-D.ietf-rtcweb-audio-codecs]: 416 3. Audio Codecs 418 3.1. Required Codecs 420 To ensure a baseline level of interoperability between WebRTC 421 clients, a minimum set of required codecs are specified below. 423 WebRTC clients are REQUIRED to implement the following audio 424 codecs. 425 * Opus [RFC6716], with any ptime value up to 120 ms 426 * G.711 PCMA and PCMU with one channel, a rate of 8000 Hz and a 427 ptime of 20 - see section 4.5.14 of [RFC3551] 428 * Telephone Event - [RFC4733] 430 3.2. Additional Codecs 431 To ensure an enhanced level of interoperability between WebRTC 432 clients, AMR-WB, AMR and G.722 codecs SHOULD be implemented by 433 WebRTC end-points to avoid transcoding costs and quality 434 degradations towards legacy fixed and mobile devices and allow 435 interworking with enhanced voice quality (rather than fall back to 436 G.711 narrow band voice). 438 WebRTC browsers on devices for which the implementation of AMR is 439 mandatory for voice services MUST allow AMR to be negotiated and 440 used at WebRTC level provided it is ensured that no additional 441 license fees are required. 443 WebRTC browsers on wide-band devices for which the implementation 444 of AMR-WB is mandatory for voice services MUST allow AMR-WB to be 445 negotiated and used at WebRTC level provided it is ensured that no 446 additional license fees are required. 448 WebRTC browsers devices for which the implementation of G.722 is 449 mandatory for voice services MUST allow G.722 to be negotiated and 450 used at WebRTC level. 452 Note: the wording of section "3.2. Additional Codecs" is a first 453 proposal and example to try to capture the general principle 454 explained in this document to improve interoperability while limiting 455 the cost impact on browsers. It is subject to further modifications 456 to reach the best possible compromise. 458 6. Security Considerations 460 7. IANA Considerations 462 None. 464 8. Acknowledgements 466 Thanks to Milan Patel for his review. 468 9. References 470 9.1. Normative references 472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, March 1997. 475 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 476 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 477 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 479 9.2. Informative references 481 [AMR-WB] GSMA, "AMR-WB", 2011. 483 [I-D.ietf-rtcweb-audio] 484 Valin, J. and C. Bran, "WebRTC Audio Codec and Processing 485 Requirements", draft-ietf-rtcweb-audio-01 (work in 486 progress), November 2012. 488 [I-D.ietf-rtcweb-overview] 489 Alvestrand, H., "Overview: Real Time Protocols for Brower- 490 based Applications", draft-ietf-rtcweb-overview-06 (work 491 in progress), February 2013. 493 [I-D.ietf-rtcweb-use-cases-and-requirements] 494 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 495 Time Communication Use-cases and Requirements", 496 draft-ietf-rtcweb-use-cases-and-requirements-10 (work in 497 progress), December 2012. 499 [Information-Papers] 500 GSMA, "Information Papers", 2013. 502 Authors' Addresses 504 Xavier Marjou 505 France Telecom Orange 506 2, avenue Pierre Marzin 507 Lannion 22307 508 France 510 Email: xavier.marjou@orange.com 512 Stephane Proust 513 France Telecom Orange 514 2, avenue Pierre Marzin 515 Lannion 22307 516 France 518 Email: stephane.proust@orange.com 519 Kalyani Bogineni 520 Verizon Wireless 522 Email: Kalyani.Bogineni@VerizonWireless.com 524 Roland Jesske 525 Deutsche Telekom AG 527 Email: R.Jesske@telekom.de 529 Bernhard Feiten 530 Deutsche Telekom AG 532 Email: R.Jesske@telekom.de 534 Lei Miao 535 Huawei 537 Email: lei.miao@huawei.com 539 Marocco 540 Telecom Italia 542 Email: enrico.marocco@telecomitalia.it 544 Espen Berger 545 Cisco 547 Email: espeberg@cisco.com