Alcatel-Lucent IP Telephony R9

Expert Presales

REFERENCE DURATION

PS00TE901US METHODS

hours days

DELIVERY LANGUAGE

English (course material in English)
Virtual self-paced training on the computer. 12 hours before c-learning Traditional classroom or practical sessions with tutorials (TAP LAB) Tutored virtual training sessions accessible via an internet connection
MAXIMUM NUMBER OF PARTICIPANTS 12 PUBLIC
Presales Engineers, Solution Designers

OBJECTIVES

At the end of the course, the participant will be able to: Address a RFP (Request For Proposal) based on a Complex OmniPCX Enterprise Solution and an advanced OmniVista A4760. Design an Architecture with Distributed Call Control and VoIP Solution Use Traffic calculation tools for dimensioning Generate a complex offer using ACTIS Quote an OmniVista Suite using ACTIS Find appropriate SD specific Documentation & Tools The participant will learn how to design and quote a standard Solution from end-to-end. A Global Case Study using traffic calculation, recommendations and rules, dimensioning tools and all Presales documents available will be done at the end of the session.

PREREQUISITES

To have attended the Alcatel-Lucent IP Telephony Essential Presales training course (Ref: PS00TE900US) To have attended the 2h Enterprise Security Overview (Free I-learning course 3EY0SA050) 3 months minimum on-site practice after the IP Telephony Essential Solution Designer course The participant will bring is own laptop for hands-on, with the latest ACTIS version.
REQUIRED TECHNICAL CONFIGURATION

For i-learning

Access to the Business Partner Web Site. Internet Explorer version 5.5 or better, Macromedia Flash 7 and Acrobat Reader version 6 or better. Virtual Microsoft Java Machine (MSJVM).
All Rights Reserved 2008, Alcatel-Lucent

PROGRAM DESCRIPTION

Phase 1: i-learning 12 hours
Mandatory to seat the c-learning Session. This I-Learning session aims to provide enough comprehensive technical knowledge on an advanced OmniPCX Enterprise Solution, Networking, VoIP and Industry Specific Solutions to make the most of the C-Learning session. Architecture with Distributed Call Control Corporate ABC Networking Infrastructure o Private Network Configurations and Scalability o Private ABC Networks using TDM Leased Lines o ABC Virtual Private Network on ISDN Networks o VoIP Networking ABC Network Features o Private Numbering Plan (Moving a User in an ABC Network) o Network-Wide Telephone Features (Conferences, DISA, Callback, Forwarding ) o User Group (Associate, Forwarding, Manager-Assistant, Supervision, Hunt Groups, Twin Set) o Mobility (DECT Roaming, Remote Forwarding, Substitution, Ubiquity) o Centralized or Distributed Attendants o Centralized, Distributed or Shared Voice Messaging Systems (A4645, A4645) o Adaptive Routing o Alternate Route Selection ARS (Force On-Net, Break Out, Multiple Carrier Selection) o Partial Rerouting for External Call forwarding o Management ( Centralized management, Voice Mail, Alarms; Audit; Broadcast) Heterogeneous Networking (QSIG, DPNSS, ISVPN, H323, SIP) H323 Architecture Peer-to-peer networking Communication with H323 devices Direct RTP Integrated GateKeeper
Session Initiation Protocol (SIP) Environment Alcatel-Lucent and SIP o Marketing SIP o SIP and OmniPCX Enterprise o Supported SIP Standards Integration of SIP End-points o Low Cost Compatible SIP End Points (Thomson ST 2030, FCI IP Ranger) o Registration o Basic SIP Call via the OXE SIP proxy (SIP to SIP, Other to SIP, SIP to Other, Fax Machines) o RTP Flow o Call made to TDM Trunks o Supplementary Services o Voice Mail Account o Authentication/Verification
SIP Trunking o Public SIP Trunking o Private SIP Trunking Supported Telephony features & limitations o User o SIP Public Trunk o SIP Private Trunk Additional IP Services (TFTP, DHCP, AVA, NTP, SNMP, QOS ) VoIP Network Compliance Assessment Process Security Available Security Levels(SSH, SSL, 802.1x) Phone Protection against Toll Fraud Encryption & Security Modules OmniVista 4760 Full Pack Performance & Traffic Analysis VoIP Performance Audit SIP Device Management Network Maintenance Topology Directory OmniVista 4760 MCS Edition Industry Specific Solutions Finance Healthcare Hospitality Local Authorities & Government Agencies Comprehensive Call Routing Call Restriction for Alarms & Emergencies Priority Calls Multi Level Precedence and Pre-emption Multi-Tenants Users Profiles Overview of the Out-of-the-box solutions from Professional Services
Phase 2: c-learning 4 days

The c-learning Session aims to address a RFP (Request For Proposal) based on a complex OmniPCX Enterprise Solution using all Solution Designers tools available. The participant will learn how to design a distributed Architecture with distributed Call Control, a VoIP Solution and an and how to quote the solution using ACTIS. List of topics covered Architecture with Distributed Call Control Corporate ABC Networking Infrastructure o Private Network Configurations and Scalability o Private ABC Networks using TDM Leased Lines o ABC Virtual Private Network on ISDN Networks o VoIP Networking ABC Network Features o Private Numbering Plan (Moving a User in an ABC Network) o Network-Wide Telephone Features (Conferences, DISA, Callback, Forwarding ) o User Group (Associate, Forwarding, Manager-Assistant, Supervision, Hunt Groups, Twin Set) o Mobility (DECT Roaming, Remote Forwarding, Substitution, Ubiquity) o Centralized or Distributed Attendants o Centralized, Distributed or Shared Voice Messaging Systems (A4645, A4645) o Adaptive Routing o Alternate Route Selection ARS (Force On-Net, Break Out, Multiple Carrier Selection) o Partial Rerouting for External Call forwarding o Management ( Centralized management, Voice Mail, Alarms; Audit; Broadcast) Heterogeneous Networking (QSIG, DPNSS, ISVPN, H323, SIP) Architecture with Distributed Call Control VERSUS Architecture with Centralized Call Control H323 Architecture Peer-to-peer networking Communication with H323 devices Direct RTP Integrated GateKeeper
SIP Trunking o Public SIP Trunking o Private SIP Trunking Supported Telephony features & limitations o User o SIP Public Trunk o SIP Private Trunk Additional IP Services (TFTP, DHCP, AVA, NTP, SNMP, QOS ) VoIP Network Compliance Assessment Process Security Available Security Levels(SSH, SSL, 802.1x) Phone Protection against Toll Fraud Encryption & Security Modules OmniVista 4760 Full Pack Performance & Traffic Analysis VoIP Performance Audit SIP Device Management Network Maintenance Topology Directory OmniVista 4760 MCS Edition Industry Specific Solutions Finance Healthcare Hospitality Local Authorities & Government Agencies Comprehensive Call Routing Call Restriction for Alarms & Emergencies Priority Calls Multi Level Precedence and Pre-emption Multi-Tenants Users Profiles Overview of the Out-of-the-box solutions from Professional Services Global Case Study using traffic calculation recommendations and rules, dimensioning tools and all SD documents available.

Project Deliverable

IST - 6th FP Contract N 026442
D B4.4 MMBB integrated lab trial evaluation report
alcega@tid.es Cristina Pea Angela Pueyo pueyo@tid.es Telefnica I+D, S.A. Unipersonal Parque Tecnolgico Walqa, Ctra Zaragoza N330-A, Km 566, 22197 Cuarte (Huesca), Spain Bjoern.Nagel@t-systems.com Bjoern Nagel T-Systems Enterprise Services Goslarer Ufer 35, 10589 Berlin, Germany edith.gilon@alcatel-lucent.be Edith Gilon Jeroen Hoet Jeroen.hoet@alcatel-lucent.be Raf Huysegems rafael.huysgems@alcatel-lucent.be Nico Verzijp nico.verzijp@alcatel-lucent.be Alcatel-Lucent Bell Copernicuslaan 50, 2018 Antwerpen, Belgium Karsten.Oberle@alcatel-lucent.de Karsten Oberle Alcatel-Lucent Deutschland Lorenzstrasse 10, 70435 Stuttgart, Germany arnaud.maillet@thomson.net Arnaud Maillet Thomson Grass Valley France Rue du Clos Courtel, 35517 Cesson-Svign, France Bart.DeVleeschauwer@intec.ugent.be Bart De Vleeschauwer Steven Latre Steven.Latre@intec.ugent.be Pieter Simoens Pieter.Simoens@intec.ugent.be Wim Van de Meerssche Wim.VandeMeerssche@intec.ugent.be IBBT IBCN: Gaston Crommenlaan 8 (Bus 201), 9050 Gent Belgium Identifier: Class: Version: Version Date: Distribution: Responsible Partner: Filename: Deliverable D B4.4 Report V08 26/03/2008 Public ALCB, ALCS, THON, TID, DT MUSE_DB4.4p_v08.doc
DB4.4 Multimedia Broadband 1/97 integrated lab trial evaluation report

Public

DOCUMENT INFORMATION
Project ref. No. Project acronym Project full title Security (distribution level) Contractual delivery date Actual delivery date Deliverable number Deliverable name Type Status & version Number of pages WP / TF contributing WP / TF responsible Main contributors Editor(s) IST-6thFP-026442 MUSE Multi-Service Access Everywhere Public 31/03/2008 26/03/2008 D B4.4 MMBB Integrated Lab Trial Evaluation Report Report VWPB4 Cristina Pea ALCB, TID, DT, THON, THOB, ALCS Cristina Pea, Angela Pueyo, Bjoern Nagel, Edith Gilon, Jeroen Hoet, Raf Huysegems, Nico Verzijp, Bart De Vleeschauwer, Steven Latre, Pieter Simoens, Wim Van de Meerssche, Karsten Oberle, Arnaud Maillet Pertti Jauhiainen Lab trial, access multiplexer, multi-service edge router, TV over IP gateway, Residential Gateway, service gateway, multimedia enhancements, service enablers. The deliverable D B4.4 MMBB integrated lab trial evaluation report reports the operation and test results of the SPB lab trials built with the different network elements developed in WPB1 and WPB3 during the second phase of MUSE. The offered services improve the basic triple-play offer for data, voice and video with a special attention to the broadband multimedia applications.
EU Project Officer Keywords
Abstract (for dissemination)
DB4.4 Multimedia Broadband 2/97 integrated lab trial evaluation report

DOCUMENT HISTORY

Version V01 V02 VQR1 V04 V05 Date 21/01/2008 06/02/2008 08/02/2008 12/02/2008 21/02/2008 Comments and actions Template based on MB4.3 Update of sections 2.1, 2.2, 3.4.Added chapter 4 & annexes Status Draft 2.4, Draft
Version without test suite for quality Semi-final review Final (for internal quality review) Draft
Minor corrections after internal quality Draft review. Added annex with cross SubProject lab trials. Update document information sheet Final and minor correction in session mobility use case Completion of last tests (RTP Final retransmissions, MPEG4 transrating, RGW management, RGW security)

22/02/2008

26/03/2008

TABLE OF CONTENTS

DOCUMENT INFORMATION....2 DOCUMENT HISTORY....3 TABLE OF CONTENTS.....3 LIST OF FIGURES AND TABLES....5 ABBREVIATIONS....8 REFERENCES.....11 EXECUTIVE SUMMARY....2 INTRODUCTION....14 LAB TRIAL SET-UP OVERVIEW...16 2.1 Alcatel-Lucent lab trial....16 2.2 Telefnica lab trial....18 2.3 T-Systems lab trial...19 2.4 Broadband Europe lab trial...22 SERVICES AND USE CASES...24 3.1 High-speed Internet access...25

DB4.4 Multimedia Broadband 6/97 integrated lab trial evaluation report
Table 8: D-SBC voice quality results (Berlin)...76 Table 9: D-SBC performance for voice tests...77 Table 10: Perceived QoS with SIP B2BUA between an analogue phone and a softphone.87 Table 11: Cross SP lab trials...95
DB4.4 Multimedia Broadband 7/97 integrated lab trial evaluation report

ABBREVIATIONS

ACNM ACS ADSL AM ANTMA API APlane ASI ATM B2BUA BBE BER BRAS BSCP CAPEX CP(E) CSCF CWDM CWMP DHCP DPI DSBC DSL DSLAM DSLF EFM FARPP FEC FTP GigE GRE GSB GSM GUI HD HDTV HSI HW ICMP IEEE IETF IGMP IMS IMX IP IPTV IPv4, IPv6 KPlane LAN LT Autonomic Communications and Management Auto Configuration Server Asymmetric Digital Subscriber Line Access Multiplexer Access Network TCP Monitoring Algorithm Application Programming Interface Action Plane Asynchronous Serial Interface (in context of DVB) Asynchronous Transfer Mode Back-to-Back User Agent BroadBand Europe (conference) Bit Error Rate Broadband Remote Access Server Base Station Control Protocol Capital Expenditure Customer Premises (Equipment) Call Session Control Function (P-CSCF = Proxy CSCF, S-CSCF = Serving CSCF, I-CSCF= Interrogating CSCF) Coarse Wavelength Division Multiplexing CPE WAN Management Protocol Dynamic Host Configuration Protocol Deep Packet Inspection Distributed Session Border Controller Digital Subscriber Line Digital Subscriber Line Access Multiplexer DSL Forum Ethernet in the First Mile Fast Access Ring Protection Protocol Forward Error Coding File Transfer Protocol Gigabit Ethernet Generic Routing Encapsulation Global System for Broadband communications Global System for Mobile communications Graphical User Interface High Definition High Definition TeleVision High Speed Internet Hardware Internet Control Message Protocol Institute of Electrical and Electronics Engineers Internet Engineering Task Force Internet Group Management Protocol IP Multimedia Subsystem IP Multimedia Exchange Internet Protocol IP TeleVision IP version 4, IP version 6 Knowledge Plane Local Area Network Line Termination
DB4.4 Multimedia Broadband 8/97 integrated lab trial evaluation report
MMBB MOS MPEG MPlane MSER NA(P)T NGN NOC NSP NT OBR OPEX OSGi PBX PC PDA PESQ PPPoE QoE QoS RGW RTCP RTP RTT SBC SD SEPIA SER SIP SP SP STB TCP TFTP TR (e.g. TR69) TS TVoIP UDP UMA UNC UPnP VDSL VLAN VLC VoD VoIP VPN VQT VRF WAC WBS WiFi
MultiMedia Broadband Mean Opinion Score Motion Picture Experts Group Monitoring Plane Multi Service Edge Router Network Address (Port)Translation Next Generation Network Network Optical Communication (conference) Network Service Provider Network Termination OSGi Bundle Repository Operational Expenditure Open Services Gateway Initiative Private Branch eXchange Personal Computer Personal Digital Assistant Perceptual Analysis of Speech Quality Point-to-Point Protocol over Ethernet Quality of Experience Quality of Service Residential Gateway Real Time Control Protocol Real Time Protocol Round Trip Time Session Border Controller Simple Definition Service Enabling Platform for Intelligent Access SIP Express Router Session Initiation Protocol Service Plane Sub Project Set-top Box Transmission Control Protocol Trivial File Transfer Protocol Technical Report (released DSL Forum document) Transport Stream TV over IP User Datagram Protocol Unlicensed Mobile Access UMA Network Controller Universal Plug and Play Very high speed Digital Subscriber Line Virtual LAN Video LAN Client Video on Demand Voice over IP Virtual Private Network Voice Quality Testing Virtual Router Forwarding Wireless Access Controller WiMAX Base Station Brand name of alliance for WLAN deployment

[16] E. Gilon, J. Hoet, H. Dequeker, R. Huysegems, E. Six, W. Van de Meerssche, P. Siemoens, B. De Vleeschauwer, C. Pea, B. Nagel, P. Vetter, Service Rich Access Networks: The Service Plane Solution, Broadband Europe Conference, Antwerp, December 2007. [17] Y. Royon, P. Parrend, S. Frnot, S. Papastefanos, H. Abdelnur, D. Van de Poel, S. Frnot, Multi-service, Multi-protocol Management for Residential Gateways Home Network Management, Broadband Europe Conference, Antwerp, December 2007. [18] Autonomic QoE Optimization in the Access Node Knowledge Plane, B. De Vleeschauwer, P. Simoens, W. Van de Meerssche, S. Latr, F. De Turck, B. Dhoedt, P. Demeester, S. Van den Berghe, E. Gilon, T. Van Caenegem, Broadband Europe Conference, Antwerp, December 2007. [19] Netfilter: http://www.netfilter.org
DB4.4 Multimedia Broadband 12/97 integrated lab trial evaluation report

EXECUTIVE SUMMARY

DB4.4 Multimedia Broadband Integrated Lab Trial Evaluation Report explains the lab trials built with the different network elements developed in WPB1 (aggregation network) and WPB3 (residential network) during the second phase of MUSE and reports the tests that have been carried out in order to evaluate the functionality, performance and interoperability of such SPB achievements. A large range of use cases were defined, set-up and integrated in lab trials. A first integration was achieved in Antwerp in the Alcatel-Lucent lab to de-risk the integration at the operators. The network elements were then set-up and integrated in two operator environments: the Telefnica (Huesca) and the T-Systems (Berlin) labs. Finally, In December 2007, SPB also demonstrated several use cases at the Broadband Europe Conference. Including all the set-ups, the operational use cases were the following: IPTV use cases: MPEG-2/4 SD/HD reception, TS processing and transmission; IPTV with MPEG2/MPEG4 transrating; IPTV with support of different source signals/multiple HD streams at home; IPTV with enhanced Pro-MPEG FEC. Multi-Service Edge Router: seamless Session Mobility with MSER between SIP/IP devices; seamless Session Mobility with MSER across heterogeneous access network technologies. Service plane use cases: start, stop and upgrade of service on the service plane; distributed SBC (D-SBC) on service plane; TCP monitoring on service plane; RTP/RTCP monitoring on service plane; QoE improvement with knowledge and service planes; WiMAX access controller on service plane; RTP retransmissions. Home network related use cases: residential SIP Server; TR-069 Remote Management; Secure OSGi Deployment; NetConf / TR-069 proxy; UPnP / TR-069 network proxy. Each of these use cases were tested at the operators labs, with special emphasis in functionality, management, and performance. In order to use the resources efficiently, not all use cases were tested in both labs: Telefnica analysed the use cases based on the SIP protocol and T-Systems took care of all the TV and video uses cases. The use cases proved the concept of several aspects studied in Taskforce TF1 and TF3: The service plane concept allowed implementing service enablers studied in TF1.7. The D-SBC is one of the use case investigated in TF1.7 and implemented in WPB1. The TCP and RTP/RTCP monitoring are two other examples of service enablers aiming at a controlled user QoE. The IPTV use cases demonstrated the evolution of the video distribution in a distributed model. The FEC studied as service enabler for reliable video transmission in TF1.7 was also implemented and set-up and showed the possible improvement. The MSER use cases demonstrated an example of Fixed-Mobile Convergence like studied in TF1.8. The residential gateway developed in WPB3 and integrated in the lab trial is in line with the specifications of TF3. One use case specifically evaluates the IMS proxy as defined in TF3.3. Several use cases address different aspects of multiprovider management as addressed in TF3.4.

The reader can notice that in fact there are only three Residential Gateways. By lack of prototypes, the same Residential Gateway was used for the Bob and Davids homes. We decided to have four homes to ease the participants understanding. More information can be found in sections 3.2 and 3.3 for Alice and Bobs use cases and in sections 3.4 for Carla and David. There are as such no tests carried out on this set-up. Section 4.6 gives more info on the demos shown and a picture of the SPB booth.
DB4.4 Multimedia Broadband 23/97 integrated lab trial evaluation report

3 SERVICES AND USE CASES

The lab trials presented in the previous section allows testing a large range of use cases. This chapter presents each use case separately and systematically answers the following questions: What is the service offered? Which network elements are involved? What are the innovations? What are the advantages? This chapter starts with the data service followed by the TV & video services. The innovations brought by the MSER and service plane are then detailed. The chapter concludes with the Residential Gateway enhancements. Service or use case High-speed Internet access IPTV with MPEG2/4 SD/HD IPTV with MPEG2/4 transrating (with or without FEC) IPTV with support for different source signals: live or differed events processing/multiple HD streams at home. IPTV with enhanced Pro-MPEG FEC Seamless communication with MSER & without GSM gateway Seamless communication with MSER & with GSM gateway Service Plane start, stop & upgrade Distributed SBC TCP monitoring RTP/RTCP monitoring Quality of Experience improvement with knowledge and service planes Wimax Access Controller SIP communication RGW features Fixed mobile convergence RGW TR-069 remote management Secure OSGi Deployment UPnP/AV Management Inside the Home NetConf / TR-069 proxy TR-069 / UPnP proxy

Table 1: Use cases list

Where DT DT DT DT DT TID BBE07 TID, DT TID, DT DT DT BBE07 ALCB TID, DT THOB TID ALCB ALCB ALCB BBE06
DB4.4 Multimedia Broadband 24/97 integrated lab trial evaluation report
High-speed Internet access
Service offered or use case The user can access the Internet at very high speeds. The service is only enabled for VDSL2 based home network and use a PPPoE connection to a legacy BRAS. Network elements involved Data source: web server or FTP server Access multiplexer which supports VDSL2 EFM lines Residential access gateway developed in WPB3 Client PC Innovation To support this use case the new RGW platform with a VDSL2 EFM interface and a performance optimized System-on-Chip is required. A software IP acceleration framework will need to be developed to support these high upstream and downstream bandwidths. Advantages The high upstream and downstream bandwidth can be used to enable new services such as high download speeds, high speed peer to peer applications, multiple HD streams, etc.

Objective: The objective is to evaluate the capabilities of transrating functionality which is implemented in the TVoIP headend. Procedure: The transrating function was enabled for different available streams / channels and a specific maximum bandwidth was adjusted over the management application (see Figure 30). In the meantime the FEC functionality was enabled and disabled. On the TV sets the quality of the different channels was observed. DB4.4 Multimedia Broadband 53/97 integrated lab trial evaluation report Public
Figure 30: Transrate configuration
Results: During the evaluation phase a decreasing by 30% bandwidth for MPEG2 and MPEG4 SD streams could be obtained - with and without FEC. On low bit rate MPEG2 streams the video quality is not sufficient anymore, but this is not due to the transrating algorithm but rather to the final rate after transrating (see also Figure 31). The bandwidth decreasing for high bit rate streams doesn't leads to a decreasing of experienced video quality.
Figure 31: transrating of low bit rate MPEG2 stream
4.2.3 Forward Error Correction
Objective: The objective is to evaluate the capabilities of Forward Error Correction functionality which is implemented in the TVoIP headend.
DB4.4 Multimedia Broadband 54/97 integrated lab trial evaluation report
Procedure: Two different kinds of packet loss were inserted into the network at the one hand bursty packet loss (5s no loss followed by 1s loss) and to the other hand random packet loss. The disturbed streams were displayed over two STBs - one with FEC capabilities and another without - and the experienced quality was compared. The amount of packet loss was increased over test duration. Results: The implemented FEC algorithm is able to correct up to 5% random packet loss in aggregation and/or home network. In Figure 32 two different results of network packet loss are displayed which were completely recovered by the implemented algorithm. For random packet loss the recovering algorithm works very stable.
Figure 32: TV screen shots with 1% and 4% random packet loss and no FEC
The bursty packet loss (see also Figure 33) can not be completely recovered by the algorithm. The reason is the current configuration of FEC algorithm which allows a recovering capacity of 10 consecutive packets loss each 100 packets (maximum configurable capacity being 20 consecutive packets loss each 100 packets ) and the injected bursty packet loss leads to a burst of 285 packets loss each 1425 packets. The result is a frozen screen for a short time. Unfortunately it was not possible to change the setting for bursty packet loss during test period.

Figure 33: capture of a stream corrupted with periodic packet loss
DB4.4 Multimedia Broadband 55/97 integrated lab trial evaluation report

MSER tests

The objective of these tests is to evaluate the ability of the Multi-Service Edge-Router to support session mobility and to measure the QoS of the videoconference service provided by the MSER prototype in the seamless communication with MSER and without GSM gateway use case scenario (c.f. section 3.3.1 for detailed description).
4.3.1 Integration in the MUSE multimedia broadband access network
Objective: Integrate the MSER prototype within the MUSE multimedia access laboratory. Procedure: The test-bed includes all the elements needed to test the MSER environment: 3 Innomedias videophones, 2 ADSL routers, 1 Alcatel-Lucent DSLAM, 1 ethernet aggregator with VLAN support and 1 MSER. Results: This activity allowed debugging several minor development failures in various MUSE prototypes that were reported to vendors iteratively solved.
4.3.2 Testing of the MSER authentication system
Objective: testing and debugging the authentication system Procedure and results: At the beginning, some problems were found when authenticating the SIP-Phones in the MSER. As this could be a problem with the test-bed infrastructure, some network elements were removed from the set-up to avoid/identify problems. The new testbed scenario was composed by: 3 Innomedias SIP Phones, 1 switch without VLAN support, and the MSER. After reconfiguring the Innomedia SIP Phones without the DHCP configuration, and setting up static IP addresses the problem continued.

Hub/Switch

(linksys SD208)

IMX P2P MSER

Figure 34: Simplified MSER set-up to debug the authentication system
The error sequence was the following: 1. Bob sends a REGISTER without authentication field in SIP header. 2. The proxy answers with a 401 UNAUTHORIZED 3. Bob sends a REGISTER completed 4. The proxy answers with a 200 OK
DB4.4 Multimedia Broadband 56/97 integrated lab trial evaluation report

1. 2. 3. 4. 5.

Alice sends a REGISTER without authentication field in SIP header. The proxy answers with a 403 FORBIDDEN Alice sends a REGISTER without authentication field in SIP header. The proxy answers with a 403 FORBIDDEN. the same in an infinite loop.

4.3.4 Functional test of session mobility I: user side
Objective: To verify the correct functionality of the session mobility manager implemented in the MSER. The correct and expected behaviour is: a) A user, previously registered in a SIP phone, establishes a call with another remote client. b) Then, the user moves and registers to another physical terminal in the same access network (same technology). c) The session is seamlessly transferred across different access networks supporting NAT and firewalls Procedure and results: The functional tests verify this behaviour. Being more specific, a call is established between Alice (home1, NSP1) and Bob (home2, NSP2). The SBC monitor shows that the MSER acts as a middleman in the communication, in fact there are established 2 different active half-calls to communicate Alice (1001) and Bob (2001), the first between Alice and the MSER (via the AS), and the second between the MSER and Bob. When Alice wants to move and change her physical terminal in the same access network (Alice2), before putting down the first terminal (so as not to loose the session), Alice picks up the second terminal and dials the phone number of Bob. Then a third half-call is established between Alice2, with the same public identifier that Alice1 (1001), and the MSER (c.f. Figure 36).
DB4.4 Multimedia Broadband 58/97 integrated lab trial evaluation report
Figure 36: SBC Monitor screenshot showing the moment when the nomadic user has two active half-call towards the MSER.
In this moment Alice can hear Bob from both physical terminals, but she only receives the video flow in the first videophone. Thanks to the intermediate MSER the session has been seamlessly transferred from Alice1 to Alice2. When, Alice hangs up the first terminal, the correspondent half-call of Alice1 disappears on the SBC monitor, so Alice continues the video call from the second terminal. Figure 37 shows the received flow in Bob during the process of session mobility. The process has been completely transparent for Bob; he continues the communication without knowing if Alice is in one terminal or another. Hence, the solution for nomadic services implemented by the MSER fulfils the privacy requirements.
Figure 37: Signalling at Bob (movement of Alice is invisible for him)
DB4.4 Multimedia Broadband 59/97 integrated lab trial evaluation report
Another advantage is that the user may have different private IDs for his physical devices/clients but he is always reachable with his single public ID.
4.3.5 Functional test of session mobility II: network side

[root@macumba]# nmap -T Aggressive -A -v 9.0.0.3 Scanning 9.0.0.3 [1714 ports] Completed Service scan, 3 services on 1 host. Interesting ports on 9.0.0.3: Not shown: 1711 closed ports PORT STATE SERVICE VERSION 21/tcp open ftp WU-FTPD wu-2.6.1 23/tcp open telnet Linux telnetd 80/tcp open http monit httpd 4.6 | HTTP Auth: HTTP Service requires authentication |_ Auth type: Basic, realm = monit |_ HTML title: 401 Unauthorized MAC Address: 00:E0:0C:00:04:FD (Motorola) Device type: general purpose Running: Linux 2.6.X OS details: Linux 2.6.13 - 2.6.20 Nmap done: 1 IP address (1 host up) scanned in 514.129 seconds Raw packets sent: 1741 (77.364KB) | Rcvd: 1730 (80.220KB).

Figure 49: Nmap scan

The Nessus vulnerability scanner allows featuring high-speed discovery, configuration auditing, asset profiling, sensitive data discovery and vulnerability analysis of the security posture. Nessus uses plug-ins to do security checks, they are implemented in NASL (Nessus Attack Scripting Language). In order to perform a deep scan of the Sepia board with Nessus, all dangerous plugins were enabled with default settings. DB4.4 Multimedia Broadband 69/97 integrated lab trial evaluation report Public
The results (output of Nessus program) were: ftp (21/tcp): Port is open. An FTP server is running on this port. The remote FTP server is prone to format string vulnerability. Related holes: o The remote host is running wu-ftpd 2.6.2 or older. There is a bug in this version which may allow an attacker to bypass the 'restricted-gid' feature and gain unauthorized access to otherwise restricted directories. Risk Factor: High. The remote Wu-FTPd server seems to be vulnerable to an off-by-one overflow when dealing with huge directory structures. An attacker may exploit this flaw to obtain a shell on this host. Risk factor: High. The remote Wu-FTPd server seems to be vulnerable to a remote overflow. This version contains a remote overflow if s/key support is enabled. The skey_challenge function fails to perform bounds checking on the name variable resulting in a buffer overflow. With a specially crafted request, an attacker can execute arbitrary code resulting in a loss of integrity and/or availability. It appears that this vulnerability may be exploited prior to authentication. It is reported that S/Key support is not enabled by default, though some operating system distributions which ship Wu-Ftpd may have it enabled. Risk factor: High. The remote Wu-FTPd server seems to be vulnerable to a remote flaw. This version fails to properly check bounds on a pathname when Wu-Ftpd is compiled with MAIL_ADMIN enabled resulting in a buffer overflow. With a specially crafted request, an attacker can possibly execute arbitrary code as the user Wu-Ftpd runs as (usually root) resulting in a loss of integrity, and/or availability. It should be noted that this vulnerability is not present within the default installation of Wu-Ftpd. The server must be configured using the 'MAIL_ADMIN' option to notify an administrator when a file has been uploaded. Risk factor: High. The remote FTP server is vulnerable to a flaw which allows users to access files which are outside the FTP server root. An attacker may break out of his FTP jail by issuing the command: CWD \.\. Risk factor: High. The remote FTP server is vulnerable to a flaw which allows users to access files which are outside the FTP server root. An attacker may break out of his FTP jail by issuing the command : CWD C: Risk factor: High.

Note that anonymous logins are allowed on the remote FTP server.
DB4.4 Multimedia Broadband 70/97 integrated lab trial evaluation report
telnet (23/tcp): A telnet server is listening on the remote port. Using telnet is not recommended as logins, passwords and commands are transferred in clear text. An attacker may eavesdrop on a telnet session and obtain the credentials of other users. Solution: Disable this service and use SSH instead. http (80/tcp): Port is open. A web server is running on this port. The remote web server type is: monit 4.6. This test gives some information about the remote HTTP protocol - the version used, whether HTTP Keep-Alive and HTTP pipelining are enabled, etc. This test is informational only and does not denote any security problem. Warnings: o The remote host answers to an ICMP timestamp request. This allows an attacker to know the date which is set on your machine. This may help him to defeat all your time based authentication protocols. Solution: Filter out the ICMP timestamp requests and the outgoing ICMP timestamp replies. The remote host implements TCP timestamps, as defined by RFC1323.A side effect of this feature is that the uptime of the remote host can sometimes be computed.
Interpretation. These results showed that the AM is not exposed to any security risk due to the installation of the Service Plane. The three security problems found are not such, as they are only a matter of configuration and once identified can be easily corrected without affecting the performance and functionality of the Service Plane. FTP, telnet and http were not protected during the MUSE lab trial, as they were not the target of the trials.
4.4.6 Distributed SBC tests
4.4.6.1 Signalling evaluation
Objective: Check the path followed by the RTP flow and SIP signaling of a call between two users. Procedure: Monitor the network using tcpdump software from different locations in the network to be able to draw the path followed by the traffic. Results: After starting the tcpdump on the management PC (located in front of the edge router), and the tcpdump on the SIP server (Edge server behind the edge router), a call between a SIP phone of NSP1 and a SIP phone of NSP2 is established. The management PC captures 4036 bytes more than the Edge server, it means that RTP flow is routed on the edge router, it does not need to reach the SIP server. However SIP signaling is provided by the SIP server, so signaling flow is captured on the management PC and on the SIP server.
DB4.4 Multimedia Broadband 71/97 integrated lab trial evaluation report

DHCP SIP Server openSER

Figure 50: Paths followed by RTP flow and SIP signalling 4.4.6.2 Network provisioning

Objective: Verify network provisioning of each NSP. Procedure: Access by telnet to each RGW and verify whether they receive the correct IP address from their correspondent Network Service Provider. Results: As it is shown in Figure 51 and Figure 52, it is possible to check that each RGW belongs to different network providers and are properly configured.
[root@macumba ~]# telnet 192.168.1.254 Trying 192.168.1.254. Connected to 192.168.1.254 (192.168.1.254). {Administrator}=>ip {Administrator}[ip]=>iplist Interface Type IP-address P-t-P 2 LocalNetwork Ethernet 192.168.1.ipInternet Ethernet 11.1.1.loop Internal 127.0.0.1 Figure 51: Configuration of RGW belonging to NSP1 {Administrator}=>ip {Administrator}[ip]=>iplist Interface Type 2 LocalNetwork Ethernet 1 ipInternet Ethernet 0 loop Internal
IP | Mask 255.255.255.0 255.255.255.0 255.255.255.255
IP-address P-t-P 192.168.1.254 12.1.1.64 127.0.0.1
Figure 52: Configuration of RGW belonging to NSP1
The IP address 11.1.1.59 belongs to the DHCP server of NSP1, whereas 12.1.1.64 belongs to the DHCP server of NSP2. Users connected to the RGWs receive private IP address (192.168.1.0/24) because the RGWs implement NAT.
DB4.4 Multimedia Broadband 72/97 integrated lab trial evaluation report

4.4.6.3 Reliability

Objective: Verify the correct functionality of the D-SBC in various difficult situations and making comparison with the traditional SBC. Procedure: Switch off the SIP phone and switch on again for trying to carry on the call, that way it is checked whether previous session and configuration established is still maintained. After that, the phone is connected behind a RGW that implements NAT and firewall to verify if DSBC still works correctly. Results: DSBC supports NAT and firewalls like traditional SBC. DSBC works in normal operation with RGWs that implement NAT and a firewall. Configuration established is kept after switch off the phone, but not the call established.
4.4.6.4 Voice Quality of service
Objective: Scoring and measure QoS parameters required for VoIP service. Procedure: Monitor the links with a sniffer program (wireshark) to check packet loss statistics, delay, jitter and set-up times. Try to establish several communications simultaneously to verify also the network availability and blocking probability. Repeat the trials to measure the statistics required. Results: According to TF4 Test Suite, the VoIP expected requirements are: Delay <200ms jitter <20 ms BER, Packet loss rate < 1E-3 network availability >99% application set-up time < 2s connection set-up time <300ms blocking probability (<1%). The QoS was evaluated before and after the Service Upgrade. Figure 53 shows that the delay before the Software Upgrade was less than 200ms, so it carries out the specifications.

DB4.4 Multimedia Broadband 73/97 integrated lab trial evaluation report

delay_time 2 0

46 ,,,,,,,,,,04

delay (ms)

time (seconds)
Figure 53: RTP flow delay in the network before the upgrade
The jitter, i.e. is the maximal variation of the delay, is 11,173 ms. Less than 20 ms required. According to the Wireshark captures, RTP flow bandwidth is 12683,258 bytes per second. So data bandwidth obtained is 101,466 Kbps approximately, enough for a VoIP call. Figure 54shows the bytes send each interval of time:
Figure 54: Throughput of a call before the upgrade
Logically, after the software upgrade the delay requirements are fulfilled too. As Figure 55 shows, it is less than 200ms.
DB4.4 Multimedia Broadband 74/97 integrated lab trial evaluation report
This time the jitter is 10,57 ms, less than 20 ms required. The bandwidth is 20113,961 bytes per second, so 160,912 Kbps approximately, enough for a VoIP call. Figure 56 shows the bytes send each interval of time
During the measured time no packet drop occurs. As for the network availability and blocking probability, the requirements are carried out, logically because there is a network exclusively for the uses cases in the lab trial. Application set-up time in this case is the delay between the caller dials the number of the callee, and the caller listens the first ringing tone on the phone. This time measured is approximately 2 seconds, less than 3 seconds as it is defined in the TF.4.
DB4.4 Multimedia Broadband 75/97 integrated lab trial evaluation report

64 ,,,,,,,,,,9

Figure 55: RTP flow delay with upgraded service
Figure 56: Troughput of a call with the service upgraded
Connection set-up time is the delay between the caller pick-up the phone and listen tone on the phone. Users have the feel that the system is reacting simultaneously, so connection setup time is less than 0.1 seconds. AUDIO MOS One-way echo Call NSP1->NSP2 (without upgrade, version 1) Call NSP1->NSP2 (upgraded, version 2) Hairpinning 5 AUDIO MOS One-way

Background noise

AUDIO MOS Two-way interaction 4
AUDIO MOS Mean value 1,33 3,33 4,33
Table 7: Perceived VoIP QoS (Huesca)
Table 7 shows the Mean Opinion Square (MOS) measured for two versions of the D-SBC. The version 1 was bad on purpose to show the easiness of upgrading services. It was straightforward to hear it. The experience with the second version was much better but MOS measurements gave a value of 3.3 that is somewhat below expectation. As the service plane is designed to easily upgrade services, ALCB provided an updated version 2 where the ratelimiting threshold was set higher. This upgrade was quite easy to perform and new measurements could be carried out with VQT. Table 8 shows a MOS value of around 4 that is very good. average MOS listening quality 1.76 4.03 4.0

DB4.4 Multimedia Broadband 88/97 integrated lab trial evaluation report
The following ports were open at the beginning of the scan but are now closed: Port Port Port Port 1723 was 443 was 23 was 80 was detected as being open but is detected as being open but detected as being open but detected as being open but now unresponsive. is now closed. is now closed. is now closed. the following administrator detected the may need to
This might be an availability problem related which might be due to reason: This Vulnerability Scanner has been blacklisted by the system or by automatic intrusion detection/prevention systems which have vulnerability assessment. This is a very good thing. In any case, the audit of the remote host might be incomplete and be done again. Risk Factor: none.
8. domain (53/udp): A DNS server is running on this port. If you do not use it, disable it. Risk Factor: low. 9. domain (53/tcp): A DNS server is running on this port but it only answers to UDP requests. This means that TCP requests are blocked by a firewall. This configuration is not RFC-compliant. Contrary to common belief, TCP transport is not restricted to zone transfers (AXFR): Answers bigger than 512 bytes are always transmitted over TCP. For all other requests, UDP is only 'preferred' for performance reasons, i.e. RFC1035 (STD0013) does not forbid a DNS client from issuing its queries directly over TCP. Whether the DNS server will never return answers bigger than 512 bytes and that the client software prefers UDP (which is nearly certain), you may disregard this message. Read RFC1035 (STD0013) for more information. Risk Factor: none. These results must be compared with the output obtained for RGW without B2BUA, in order to conclude whether these vulnerabilities have been caused by the added B2BUA functionalities or not. NESSUS results for RGW without B2BUA informed the following differences with respect of the previous case: o o FTP port (21) is also open, but there is not any hole. The service closed the connection after 0 seconds without sending any data. It might be protected by some TCP wrapper. The only port which is closed after scanning with NESSUS is the port 443.
We have monitored the web interface of RGW during the scan with NESSUS, to verify security mechanisms implemented by the RGW with B2BUA. Intrusion detection mechanisms are supposed to protect against:
DB4.4 Multimedia Broadband 89/97 integrated lab trial evaluation report
fragment_sweep, zero-length_fragment_size, small_fragment_size, fragment_size_overrun, fragment_overlap, fragment_out-of-order, ip_protocol_scan, tcp_port_scan, tcp_syn_scan, stealth_tcp_null_scan, stealth_tcp_fin_scan, stealth_tcp_xmas_scan, stealth_tcp_full_xmas_scan, stealth_tcp_vecna_scan, stealth_tcp_syn-fin_scan, udp_port_scan, ping_sweep_scan, tcp_syn_flood, udp_flood, ping_flood, icmp_unreachable_storm, smurf_broadcast_attack, smurf_storm_attack, fraggle_broadcast_attack, fraggle_storm_attack, land_attack, tcp_null_port, tcp_data_on_syn_segment, tcp_invalid_urgent_offset, udp_null_port, icmp_type_unknown, icmp_code_unknown, ip_zero_payload, tcp_rate_limiting, udp_rate_limiting, icmp_rate_limiting, ip_rate_limiting. During the scan with NESSUS the counters of some intrusions are increasing in real time, till: tcp_syn_scan = 1. udp_port_scan = 1. udp_flood = 3. tcp_null_port = 3. icmp_code_unknown = 3. tcp_rate_limiting = 6809. It means that RGW is detecting these attacks in its system. However, in the final part of the scan, the web interface freezes and does not function in a normal way. Finally, when the scan with Nessus software is finished, all counters suddenly reset and are equals to zero, without any interaction of users or the administrator. A user, that monitors the counters after the scanning, may think that no intrusion has attacked the system. This is because the automatic intrusion detection of the RGW has detected the vulnerability assessment and has closed some ports temporarily to protect the system. This results are very good since they mean that the security mechanisms of RGW with B2BUA are protecting properly against this attempt of intrusion.

DB4.4 Multimedia Broadband 93/97 integrated lab trial evaluation report
The service plane concept allowed implementing service enablers studied in TF1.7. The D-SBC is one of the use case investigated in TF1.7 and implemented in MB1.8. The TCP and RTP/RTCP monitoring are two other examples of service enablers aiming at a controlled user QoE. The IPTV use cases demonstrated the evolution of the video distribution in a distributed model. The FEC and RTP retransmission server, which were both studied as service enabler for reliable video transmission in TF1.7, proved to be valuable solutions to improve the QoE for IPTV services. The MSER use cases demonstrated session continuity with privacy assurance as studied in TF1.8 on Fixed Mobile Convergence.
DB4.4 Multimedia Broadband 94/97 integrated lab trial evaluation report

ANNEX A

CONTRIBUTION TO CROSS SP TRIALS
In order to verify the compatibility of the solutions developed by Sub-Projects SPB, SPC, SPD and SPE, some interoperability tests were carried out within Task-Force TF4. This Annex summarizes how SPB contributed to these cross-SP trials. MUSE consortium developed solutions for a low-cost full-service access and edge network, which enable the ubiquitous delivery of broadband services to every European citizen. Due to the large size of the consortium, experimental solutions were implemented in different Sub-Projects (SPB, SPC, SPD and SPE) that are all to be compliant with a common architecture being developed in Sub-Project SPA. Each subproject tested its own solution in individual lab-trials. In order to verify the compliance of all these solutions to MUSE architecture and their interoperability, three cross Sub-Projects lab trials were carried out (c.f. Table 11). Lab trial Cross SP lab trial 1 Cross SP lab trial 2 Cross SP lab trial 3 Activity Interconnection of CWDM optical system of SPD/SPE with SPB platform (via IST MUPBED test bed) Interconnection of SPB and SPC platforms (via IST MUPBED test bed) Interoperability of SPB Residential Gateway with SPC platform Place DT and HHI (Berlin) Public demo at NOC 2006 DT (Berlin) and Acreo (Kista) TNO (Delft)
Table 11: Cross SP lab trials
Interconnection of CWDM optical system of SPD/SPE and SPB platform