03 -preparation for

Preparation for DSAM VoIP

Al Ruth, Eugen Takacs, Alex Goloschokin

© 2005 JDSU. All rights reserved. JDSU CONFIDENTIAL & PROPRIETARY INFORMATION2

JDSU VoIP Solutions

DSAM offers two tiers of VoIP test capabilities– VoIPCheck option

• DOCSIS® call quality verification

– PacketCable™ and euroPacketCable™ VoIP test option• PacketCable™ currently works with Time Warner only• euroPacketCable™ works with Casema in a Beta form• Needs to evaluate each operator’s network

– With a VoIP offering questionnaire – Both VoIPCheck and VoIP

• Actively addressing the concerns from the field

Both have specific purposes and targeted tests


VoIPCheck

Uses the DOCSIS® channel to assess the capability of current test point to carry voice traffic

Perform VoIP measurements without requiring user to go through the extensive process of MTA provisioning

Ideal for two types of customers– Those who do not use PacketCable™ to deliver VoIP

• SIP • Vonage (Broadband VoIP)

– Customers that have not yet partnered with JDSU to validate the operability of DSAM eMTA within their VoIP architecture


What does VoIPCheck Test?

Tests two segments of the network– Traffic to the CMTS– Traffic to the Advanced IP (AIP) server (reflector server)

Makes VoIP measurement to the first router in the pipe– Typically the CMTS– Test the HFC portion of the network

• From the CM to the CMTS and back

– Referred to within the DSAM as the CMTS Loop test– Practical to determine whether the HFC drop can support a VoIP

install– Packets exchanged are actual VoIP packets (RTP packets)


What does VoIPCheck Test? – continued

CMTS can de-prioritize packets deemed unimportant (Ping, ICMP)

• If Ping packets were used in the same manner, results may not be representative of actual performance of a VoIP install

• Trilithic does RTP and ICMP, depending on destination of IP data packet

– They sometimes use Ping packets

Voice packets are treated with a higher priority than data packets received from the same cable modem

• Referred to as Quality of Service (QoS)• DSAM VoIPCheck capable of being setup with UGS (Unsolicited

Grant Service) Flow to resemble call QoS


What does VoIPCheck Test? – continued

Customer can choose to install the JDSU Advanced IP (AIP) Server near the Media Gateway– From JDSU, not yet in a deployable package

• Talk to Sales/marketing on the availability

– DSAM can perform VoIP testing to this server– Result determines quality of the entire path to AIP Server

• Segments the network: RF (HFC) and IP • (Media Gateway – Furthest Point of control for MSO)


CMTS Loop

First screen for VoIPCheck Provides packet info

– Packet loss, delay, and jitter– Quality info

• Mean Opinion Score (MOS) • R-Value

Continuously sending/receiving VoIP packets to/from the CMTS

Packet statistics and quality metrics are updated approximately every 2.5 seconds.

Treats every 1.25 seconds as a new ‘call’– MOS and R-Value susceptible to issues

even after the test has been running for long periods

Show quality data of the drop since the test was initiated

– Instantaneous – Current– Average – Avg– Maximum – Max– Minimum – Min


Segmentation

Provides a segmentation view of the system– RF portion to CMTS– IP portion to AIP Server

Allows technicians to determine which ‘legs’ of the network are causing issues

Performed exactly like the CMTS Loop test– alternates between testing with the CMTS and the

Advanced IP Server Check if and where issues with voice services

reside – within the HFC – CMTS Loop– IP Backbone – Server Loop

Show results – ‘Data Menu’ selection– packet statistics – quality values

‘Data Menu’ can be used to select which data results to display

– Current– Average– Extreme – (Max/Min)


VoIPCheck Configuration

IP address and port number of the server must be configured within the DSAM

– Port number entered for the server must match the port number configured on the server

– Port number that is entered here can be utilized when setting up QoS

• Described later Select which CODEC will be simulated

by the test– CODEC affects the values calculated

in the MOS and R-Value– Due to compression and bandwidth

requirements, CODEC’s will have different theoretical max values for MOS and R-Value

• maximum value for MOS on the G.711 protocol is 4.2 instead of the 5.0 that may be expected

Size of the jitter buffer to simulate– Default is 40ms – Approx avg to CMs


Setting up QoS for VoIPCheck

Make VoIPCheck more closely resemble the quality attained on the actual VoIP network– Necessary to employ the same QoS within the two

environments

CM config file for DSAM needs to be created– Force VoIPCheck to utilize a Unsolicited Grant Service

(UGS) flow on the upstream– A guaranteed bandwidth flow on the downstream

See Appendix A from the App Note – DSAM VoIP Offering


PacketCableTM VoIP Overview

Perform full PacketCableTM VoIP test– Provisioning– Signaling– Voice quality testing

Done by using the eMTA within the DSAM DSAM also contains a speakerphone – Mic and Speaker Has the ability to join a PacketCable™ network and function

as a telephone Phone calls can be initiated or received by the DSAM Quality of the call can be quickly assessed


MTA Provisioning

Begins by provisioning the CM within the DSAM

Provisioning the eMTA next Each step along the way is

displayed– Should any step fail, a dialog will

display describing the error information

Once online– eMTA continues by initializing

endpoint(s) with the Call Management System (CMS)

– And obtains a phone number(s) Once all provisioning is complete,

the DSAM will be ‘ready’ to place and receive phone calls

provisioning and signaling steps


VoIP Signaling

PacketCable uses NCS (Network-based Call) Signaling to initiate calls

DSAM capable of exercising signaling capabilities

– DSAM can be utilized to test for dial tone– Make phone calls to test call quality– Proving the signaling paths to all necessary

servers DSAM has the ability to test signaling to both

on-net and off-net destinations – Only difference is the phone number to test– From the DSAM user’s perspective

DSAM will perform Dynamic Quality Of Service (DQoS) setup

– Done during the call setup and teardown portion of the signaling

– Necessary based on the PacketCableTM network configuration

– Same setup that would be required by any MTA on the system

The Call quality statistics the DSAM measures is based on the actual setup of an MTA and experiences a phone call just like an MTA


Voice Quality Testing

DSAM will enter the ‘Ongoing Call’ screen– Once a call has been initiated or

received Measuring packet statistics, and

continuously recording the quality of the call– Provides packet loss, jitter, and delay – Both local (DSAM) and remote endpoints– Gives a picture of upstream and

downstream packet performance MOS allows technicians to quickly

assess call quality from location’s drop– If quality is determined unsatisfactory,

technician analyzes the packet statistics to determine whether the low quality is a product of packet loss, delay, or jitter

– Then take the appropriate action to fix the problem


Required Testing and Setup Done by Operators (I)

PacketCable™ is a complex and developing standard– ‘Gray zones’

• each vendor and/or operator implements setup parameters slightly different than others

– These differences are attributed to vendor’s and/or operator’s own interpretation of the standard

– This is why each operator puts all PacketCable™ (or EuroPacketCable™) network elements together - such as CMTS and MTA - in a lab or controlled environment and test for compatibility

DSAM is a CM, CPE (Customer Premise Equipment) and MTA in one device– Requires some degree of compatibility testing in the lab / control

environment as a new MTA vendor Purpose of this testing

– Meets the specific MSO/operator PacketCable™ VoIP implementation setup – Provide full VoIP test capability in the field while controlling the security risks


Required Testing and Setup Done by Operators (II)

Create DSAM specific config files to meet specific VoIP implementation– Each MTA vendor gets its own config files

Manage test device separately from regular MTA– Provisioning different for DSAM– DSAM is a “Roving” MTA

• Can not be tied to one CMTS or CMTS blade– Handling of phone number and billing


DSAM and MTA Security

Addressed with authentication and encryption processes – Protect the service revenue

• Prevent people from stealing services– Protect service privacy

• Prevent people from listening to other’s conversation– Built into both DOCSIS® 1.1 and PacketCable™ (EuroPacketCable™)– Each certified device has a set of certificates

Only CableLabs® certified devices can go through the security processes and obtain access to services

• When security features are enabled– This makes testing extremely hard

• Test devices do not possess certificates (CableLabs® will not certify)• Test devices are built differently to meet the demands in the field• Do not meet all requirements of consumer-focused DOCSIS® 1.1 and PacketCable™

JDSU/Acterna and CableLabs® have come up with a process for DOCSIS® security– Self-signed certificates

• Meets the testing needs of operators • Keeping the integrity of the security process

– CableLabs® has not yet endorsed Self-Signed certificates for PacketCable™ networks

• Method DSAM uses for PacketCable™ security


DSAM VoIP Provisioning Setup Overview

Process of joining a PacketCable™ voice network is complicated

Multiple sequences the eMTA must complete

Some steps optional depending on how an operator decides to setup and deploy the PacketCable™ network

This table is taken from the PacketCable™ Secure Provisioning spec

– It describes each step involved with an eMTA joining a VoIP network

– Will be referenced throughout the presentation when describing optional steps, or requiring special attention


DSAM VoIP Provisioning Setup – PacketCable MTA Device Provisioning – DHCP

The following DHCP ‘options’ must be present in the offer received by the MTA to continue its provisioning attempt

DHCP options required by the MTA in an ‘offer’– Option 1: Subnet Mask– Option 3: Router / Default Gateway– Option 6: Domain Server– Option 7: SYSLOG Server IP– Option 12: MTA Hostname (FQDN)– Option 15: Domain Name (FQDN)– Option 122 (or 177): As specified in the PacketCable Provisioning

Specification


DSAM VoIP Provisioning Setup – DOCSIS® DHCP

An MTA must join a DOCSIS® network as a CM prior to joining a PacketCable™ VoIP network

A few specifics pertaining to DOCSIS® provisioning will aid the MTA attempting to come online– DHCP

• CM (and MTA) use Dynamic Host Control Protocol (DHCP) to obtain its IP info• MTA will effectively broadcast a request for IP credentials• In this broadcast, the CM and MTA will include a list of the ‘required info’ it needs

to successfully join the network • DHCP Server will reply with an ‘offer’ that contains all info it can supply

– Including Service flow type: Secure, Hybrid, Basic

• PacketCable has defined two DHCP options to allow a CM to support an MTA– DSAM is designed to support either of the two options– Option 177

» This was an early option defined by CableLabs for PacketCable (it is obsoleted by 122)

– Option 122: This is the new definition of the PacketCable DHCP Option


DSAM VoIP Provisioning Setup – DOCSIS® Security (BPI+)

DSAM platform relies on a self-signed security architecture

If DOCSIS® BPI+ is to be implemented on the network, (DSAM and Secure DOCSIS® presentation)

• Preparing DSAM in a Secure DOCSIS® Network


DSAM VoIP Provisioning Setup – DOCSIS® DQOS

PacketCable™ takes advantage of a DOCSIS® 1.1 service - DQOS A CM can request a ‘high Guaranteed Bandwidth’ Service Flow from the CMTS with DQOS The GC (Gateway Controller) within the CMS (Call Management System) is the Policy

Decision Point for this service CMTS must perform an admission check when a resource management request is received Due to complications of the 3rd party handshake, DSAM allows the operator to bypass this

DQOS capability if desired– DQOS Disabled - the simplest of cases

• No special action is necessary in the network• MTA will use the ‘Best Effort’ Service Flow of the CM to pass Signaling and Voice traffic

– “DQOS Lite”• DSAM will dynamically create a UGS • Classifier for voice traffic will be based on IP addresses of source and destination as well as the ports• Config file should be used to create a TOS flow for the signaling

– Typically uses the identifier in the packets to route signaling on the appropriate flow• To inform DSAM what the TOS should be set to, the MTA config file should set the pktcSigDefCallSigTos

value from the pktcSigMib appropriately– Secure DQOS Enabled

• Requires operators have DQOS enabled and Gate Controller functionality• Make sure DSAM is not “tied” to a specific CMTS• DQOS and COPS protocol require the CMS contact CMTS to create a Gate for the MTA to use when creating

a high priority ‘service flow’.• For the DSAM to function throughout a network, across CMTS’s, the GC must be able to determine which

CMTS the DSAM is currently attached through dynamically, and not tie the DSAM to a specific CMTS


DSAM VoIP Provisioning Setup – PacketCable MTA Device Provisioning

MTA Device provisioning focuses on an MTA taking necessary steps to join a VoIP network

This involves the following– obtaining IP configuration– announcing itself to the network– downloading configuration data from provisioning server

Once MTA has successfully joined the network, individual ‘endpoints’ within the DSAM / MTA will initialize


DSAM VoIP Provisioning Setup – PacketCable MTA Device Provisioning – Provisioning Flow

Currently 3 types of provisioning Flows– SECURE, BASIC, and HYBRID

DSAM does not Automatically recognize the PacketCable defined HYBRID provisioning flow. – As such, the DSAM will not automatically recognize the, HYBRID.1

or HYBRID.2 flow descriptions delivered to the MTA in Option 122 sub-option 6

BASIC flow has been shown to work in our Lab– BASIC.1, BASIC.2

PacketCable Secure (default) – Currently supported as the default– Requires additional setup


Provisioning Flows - BASIC

BASIC.1 – Very different from Secure Flow– Has been shown to work in Lab

BASIC.2 – Not much different than BASIC.1 (SNMP communication

at end)


Provisioning Flows - Hybrid

HYBRID.1 – Currently attainable using configurable items in

TPP/FDM

HYBRID.2 – Not much different from HYBRID.1 (TPP Configurable)


DSAM VoIP Provisioning Setup – PacketCable MTA Device Provisioning – Flow Options

Once an MTA is online, no difference between Secure, BASIC, or HYBRID mode when testing voice quality

If DSAM can be provisioned, all tests will be valid representations of voice quality that is being experienced by the MTA


DSAM VoIP Provisioning Setup – PacketCable MTA Device Provisioning – Provisioning Flow – Security

Kerberos: Additional security to avoid eavesdropping Kerberos Disabled

– DSAM can support configurations where operator chooses to bypass Kerberos security

– In such a scenario, DSAM will bypass steps 9 – 14 as defined in the Embedded-MTA Secure Power-on Initialization Flow

Kerberos Enabled– Flow

• DSAM can support configurations when the operator chooses to enable Kerberos security

• In such a scenario, DSAM will perform steps 9-14 as defined in the Embedded-MTA Secure Power-on Initialization Flow

– Authentication:• DSAM relies on a self-signed security architecture• If Kerberos security is to be employed, the KDC server must be

configured to recognize DSAM as a trusted entity


DSAM VoIP Provisioning Setup – PacketCable MTA Device Provisioning – Provisioning Flow – SNMP

SNMPv2c– DSAM has capability to use SNMPv2c and bypass the security involved in

the SNMPv3 spec– SNMPv2c used by DSAM to send the enrollment INFORM to the

provisioning and subsequently by the provisioning server to set the config file name within DSAM

– The community used to access all data can be set either through the config of DSAM, or by sending the community name in the CM config file

– To set the community name in the CM config file, set the docsDevNmAccessCommunity MIB to appropriate community name

– DSAM will use the first Read-Only and the first Read-Write communities specified in the CM config file for the MTA

SNMPv3– DSAM supports the SNMPv3 provisioning flow as defined in the Embedded-

MTA Secure Power-on Initialization Flow

SNMP: Simple Network Management Protocol


DSAM VoIP Provisioning Setup – PacketCable MTA Device Provisioning –MTA Endpoint Provisioning

MTA authenticates itself to the CMS and establishes a security association with call server– Security Association could be no security– Has to be completed successfully to permit further call

signaling

MTA Signaling - Media Gateway Profile– Operators will typically want to create a Media Gateway

Profile specifically for DSAM on the network


DSAM MTA Summary

Not Simple setup process

Requires collaboration from both Cable Operators and JDSU

Best in-depth VoIP troubleshooting tool available

03 -preparation for

Documents