Veraz ControlSwitch Product Description

ControlSwitch Product Description
Release 5.5.5
Version 1.0
Veraz Networks, Inc.

926 Rock Ave., Suite 20
San Jose, CA 945131
Phone: (408) 750-9400

E-mail: info@veraznet.com
www.VerazNetworks.com
Veraz Networks ControlSwitch and the Veraz Networks corporate logo are
trademarks of Veraz Networks, Inc.
All other trademarks are the property of their respective owners.
Copyright 2000, 2001, 2002, 2003, 2004, 2005 Veraz Networks Inc. All rights
reserved.
Information in this document is subject to change without notice.

November, 2005
Table of Contents
Preface
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Organization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Documentation Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xiii
Online Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Contact Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
CHAPTER 1
Introduction
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2
CHAPTER 2
New Functionality Added in Release 5.5.5

EMS Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-2
EMS Disaster Recovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-2
Event Relay Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-2
Combined EMS CDR Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-2
Bulk Provisioning Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-2
Operational Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-2
Test Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-2
IN Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-3
INAP CS-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-3
SIP Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-3
SIP High Availability Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-3
Session Timer Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-3
Answer Offer Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-3
Prack Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-4
Tel URL Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-4
Update Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-4
Hong Kong ISUP Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-4
Veraz Networks ControlSwitch Product Description
Table of Contents
CHAPTER 3
ControlSwitch Solutions
ControlSwitch Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2
Packet Toll/Tandem Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2
Integrated Voice-Data Access for Businesses . . . . . . . . . . . . . . . . . . . . . . . . .3-4
SIP Internet Working Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-5
H.323 Internet Working Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-7
Universal Port RAS Gateway Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8
Internet Call Diversion/Off Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-10
Voice-Data Traffic Groomer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
CHAPTER 4
Veraz ControlSwitch General Description

General Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2
Signaling Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3
Signaling Gateway Variants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3
Call Control Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4
Service Execution Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4
Policy Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6
Events Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-7
CDR Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-7
Element Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-8
IP Call Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-8
SS7 Access Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9
ControlSwitch Element Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9
Scalability for Large Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-12
CHAPTER 5
Supported Customer Environments

Class 4/5 Switch Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-2
PBX and RAS / NAS Device Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-2
STP Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-3
IP Network Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-4
ii
Table of Contents
CHAPTER 6
Supported ControlSwitch Configurations

Supported ControlSwitch Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2
Recommended ControlSwitch Element Configurations: Elements and Platforms
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2
Redundant System Recommendations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-3
SG Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-3
CCP/CCE Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-3
SEE Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4
PE Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4
EC Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4
EMS Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4
iii
Table of Contents
CHAPTER 7
EMS and ControlSwitch Infrastructure

System Startup and Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2
Software Upgrades. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2
Software Optionality Control (SOC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2
EMS High Availability - Disaster Recovery . . . . . . . . . . . . . . . . . . . . . . . . . .7-3
Combined EMS and CDR Platform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3
System and Element Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4
User Management: Privileges, Actions, Roles. . . . . . . . . . . . . . . . . . . . . . . . .7-5
User Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-6
EMS GUI Menu Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-6
Role Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-6
Audit Log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-7
Currently Logged in Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-7
Security Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-7
Secure Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-7
DS0 Level Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-7
Fault Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-8
Alarm Severities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-9
Pending Alarm View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-9
Operator Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-10
Alarms Aggregation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-10
Alarm Filtering and Sorting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-10
Operator Settable Alarm Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11
Alarm History View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11
Email Notification for Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-12
Element Status View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-12
Test Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-13
Performance Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-14
Periodic Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-14
Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-16
Report Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-19
Call Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-22
Oracle DB Space Monitoring and Disk Usage Monitoring. . . . . . . . . . . .7-23
System Logs Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-24
SNMP Northbound Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-25
SNMP Management of Media Gateways . . . . . . . . . . . . . . . . . . . . . . . . .7-25
Event Relay Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-26
Automated Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-29
iv
Table of Contents
PL/SQL API for Third Party Management Control . . . . . . . . . . . . . . . . .7-29

Routing Bulk Provisioning Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-29
CHAPTER 8
SS7 Services
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2
SS7 Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2
SS7 MTP Level 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2
SS7 MTP Level 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2
SS7 ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-3
Overlap Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-6
ISUP Segmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-7
Message and Parameter Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-7
Availability Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-8
Connection Fallback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-9
Auto Repeat Attempt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-10
Propagation Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-11
ETSI V1 Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-14
Country Specific ISUP Variant Support . . . . . . . . . . . . . . . . . . . . . . . . . .8-15
Mexico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-15
UK ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-16
Romanian ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-16
Russian ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-16
Singapore ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-16
Hong Kong ISUP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-16
SS7 IN Services - North America . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-17
ControlSwitch Local Number Portability Implementation . . . . . . . . . . . .8-18
SS7 INAP Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-19
Productized Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-19
Global Title Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-22
Supported Variants and Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-22
Ulticom Signaling Gateway Limitations . . . . . . . . . . . . . . . . . . . . . . . . . .8-23
Telesys Signaling Gateway Limitations . . . . . . . . . . . . . . . . . . . . . . . . . .8-23
ISUP and TCAP Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-24
Table of Contents
CHAPTER 9
ISDN-PRI Services
Features Supported for ETSI and NI-2 Variants of ISDN-PRI . . . . . . . . . . . .9-2
ISDN-PRI Messages Supported by ControlSwitch . . . . . . . . . . . . . . . . . . . . .9-3
ISDN-PRI Maintenance Operations Supported by ControlSwitch . . . . . . . . .9-3
Q.SIG Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-4
Q.SIG Trunk Group Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-4
Q.SIG Messages and Information Elements . . . . . . . . . . . . . . . . . . . . . . . .9-5
CHAPTER 10
CAS Services
CAS Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2
MF Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2
DTMF Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2
Signaling Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2
Wink Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-3
Immediate Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-3
Basic PBX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-3
Feature Group D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-3
ANI Over CAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-4
CHAPTER 11
SIP Services
SIP Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2
Target Applications & Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2
General SIP Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-3
SIP Load sharing fail-over and route distribution . . . . . . . . . . . . . . . . . . . 11-5
CHAPTER 12
Policy Element - Supported Policies

Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-2
Re-Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-2
Provisioning Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-2
Re-Route Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-2
Re-Route Treatments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-3
Announcements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-3
vi
Table of Contents
CHAPTER 13
Routing and Digit Analysis

Digit Analysis and Digit Collection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-2
Parameters in DA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-3
Translations, Call Routing, and Routing Plans . . . . . . . . . . . . . . . . . . . . . . .13-5
Numbering Plan Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-5
Call Type Determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-5
Routing and Screening - Plans, Policies, and Parameters . . . . . . . . . . . . .13-6
Route Advance Capability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-17
VoIP Protocol Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-17
Local Gateways, ICE Platforms, and ICE Processes. . . . . . . . . . . . . . . .13-18
IP Trunk Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-19
H.323 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-19
OSP Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-20
SIP Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-20
Route Advance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-21
Enhanced Routing Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-21
Variable Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-21
Settable Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-24
Mark as Billable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-25
Skip Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-25
Satellite Aware Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-25
Translates To Feature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-26
Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-26
Release Cause Override After Announcements . . . . . . . . . . . . . . . . . . .13-27
vii
Table of Contents
CHAPTER 14
Supported Services
Service Trigger Plan Group Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-2
Supported Service Trigger Treatment types . . . . . . . . . . . . . . . . . . . . . . .14-2
Policy Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-3
Account Code Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-3
Provisioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-4
Personal Toll Free . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-5
Provisioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-5
Security Toll Free. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-5
Provisioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-6
C Tone Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-6
Tariff Announcements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-6
International Dialing Service Using Voice Menu . . . . . . . . . . . . . . . . . . . . .14-8
Collect Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-10
Software Optionality Control (SOC) for Services . . . . . . . . . . . . . . . . . . . .14-12
CHAPTER 15
Lawful Intercept Solution for Tandem

Components in the solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-2
viii
Table of Contents
CHAPTER 16
Call Processing
Test Line Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-2
T100 Test Line Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-2
Media Gateway Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-3
ControlSwitch / Media Gateways VoIP Interoperability . . . . . . . . . . . . . .16-3
ControlSwitch / Media Gateways PSTN Interoperability . . . . . . . . . . . . .16-4
AudioCodes Mediant 2000 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-5
VoIP and Related Protocol Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . .16-6
MGCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-6
ISDN User Adaptation - IUA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-6
Stream Control Transmission Protocol - SCTP . . . . . . . . . . . . . . . . . . . . .16-7
MTP3 User Adaptation (M3UA). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-7
H.323 Support and Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-7
H.323 OSP SIP Originating and Terminating IP Address . . . . . . . . . . . . .16-8
H.323 Reconnect Feature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-8
Session Manager Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-9
Reliable UDP - RUDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-9
SIP Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-9
CHAPTER 17
ControlSwitch High Availability

Overload Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-2
Network Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-2
SS7 Network Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-2
IP Network Redundancy between Veraz ControlSwitch Elements . . . . . .17-3
IP Network Redundancy between ControlSwitch and Media Gateway . .17-4
Element/Device Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-5
SIP High Availability Solution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-6
CHAPTER 18
Billing and Event Collector

Event Collection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-2
Overview of Event Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-2
CDR Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-3
iCDR: Veraz CDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-3
BAF CDR Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-5
Record Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-5
Glossary of Terms 9
ix
Table of Contents
Preface
This guide provides an introduction to the ControlSwitch and its architecture. The
following topics are included in this preface:
Audience
Assumptions
Organization
Documentation Set
Documentation Conventions
xi
Audience
This guide is written for system administrators, engineers and operators who will install
and administer the Veraz Networks ControlSwitch.
Assumptions
Users of this guide must be familiar with telecommunications networks and monitoring
equipment.
Organization
This guide is organized as follows:
xii
Chapter 1, Introduction, provides an introduction to the new ControlSwitch functionality.
Chapter 2, New Functionality Added in Release 5.5.5, provides details on new functionality added in this release.
Chapter 3, ControlSwitch Solutions, provides details on the ControlSwitch solutions.
Chapter 4, Veraz ControlSwitch General Description, providesa general description

of the Veraz ControlSwitch
Chapter 5, Supported Customer Environments, describes the supported customer

environments for the ControlSwitch.
Chapter 6, Supported ControlSwitch Configurations, provides details on the

supported ControlSwitch configurations.
Chapter 7, EMS and ControlSwitch Infrastructure, describes the EMS and

ControlSwitch Infrastructure.
Chapter 8, SS7 Services, describes SS7 Services.
Chapter 9, ISDN-PRI Services,describes ISDN-PRI services.
Chapter 10, CAS Services, describes CAS services.
Chapter 11, SIP Services, describes SIP services.
Chapter 12, Policy Element - Supported Policies, describes the Veraz Networks
supported PE policies.
Chapter 13, Routing and Digit Analysis, provides details on Digit Analysis and
Routing.
Chapter 14, Supported Services, provides details on all supported services.
Chapter 15, Lawful Intercept Solution for Tandem, describes the Veraz Networks
Lawful Intercept solution.
Chapter 16, Call Processing, provides details on call processing.
Chapter 17, ControlSwitch High Availability, provides details on the Veraz

Network high availability solutions.
Chapter 18, Billing and Event Collector, provides details on Billing and Event
Collector.
Glossary of terms
Index
Documentation Set
The ControlSwitch documentation set includes the following publications:
ControlSwitch Product Description

The ControlSwitch Product Description provides an description of the ControlSwitch
features and functionality.
ControlSwitch System Requirements and Environment Guide

The ControlSwitch System Requirements and Environment Guide provides hardware,
software, and network requirements information.
ControlSwitch Installation Guide

The ControlSwitch Installation Guide provides instructions on how to install, upgrade
and re-install ControlSwitch.
ControlSwitch Provisioning Guide

The ControlSwitch Provisioning Guide provides instructions on how to provision a
new ControlSwitch (initial provisioning).
ControlSwitch Reference Guide

The ControlSwitch Reference Guide provides information and field definitions for the
all EMS screens.
ControlSwitch Lawful Intercept Guide

The ControlSwitch Lawful Intercept Guide provides information on the Veraz
Networks Lawful Intercept solution and configuration details..
ControlSwitch Maintenance Guide

The ControlSwitch Maintenance Guide provides instructions for periodic maintenance activities, such as back-up and making changes to the initial setup.
xiii
EMS Disaster Recovery Guide

The EMS Disaster Recovery Guide provides detailed instructions for the Veraz
Networks Disaster Recovery feature.
ControlSwitch Release Notes

The ControlSwitch Release Notes provide information on new features, changes from
the previous release, and any known issues.
ControlSwitch Patch Release Notes

The ControlSwitch Patch Release Notes provide information on issues, resolved from
the previous release, and instructions on how to apply the patch.
Online Documentation
The following PDF files of the ControlSwitch documentation guides that make up the
ControlSwitch documentation set can be found in the /cdrom/cdrom0/doc directory:
pdd.pdf
environment.pdf
install.pdf
provision.pdf
reference.pdf
maintaintenance.pdf
lidap.pdf
disasterrecovery.pdf
relnote.pdf
patch.pdf
After installation of your ControlSwitch software, these same PDF files of the
ControlSwitch documentation guides that make up the ControlSwitch documentation set
can be found by selecting Documents from the Veraz View login display shown in the
following figure.
xiv
Online Documentation
Note To view PDF format files, you must have an Adobe Acrobat Reader.
See http://www.adobe.com for information on obtaining the Adobe Acrobat
Reader software.
Documentation Conventions
The following typographical and style conventions are used in this guide.
Table 2-1
Typographical Conventions
Convention
Description
italics
Emphasis, or variable values in command line or code

examples.
courier font
Command line or code examples, directory names,

paths, and filenames used in text.
<>
Variable values in command line or code examples.
Initial Capitals
Buttons, icons, menu items, field names, components

and elements.
xv
Contact Information
For more information about Veraz Networks, please contact us:
Veraz Networks, Inc.
926 Rock Avenue, Suite 20
San Jose, CA 945131
Phone: (408) 750-9400
E-mail: info@veraznet.com
Web: http://www.VerazNetworks.com.
Technical Assistance Centers (TACs)

USA
Tel: +1-214-6473397
Email: noc@cmsnoc.net
Israel
Tel: + 972-3-9287077
Fax: +972-3-9268999
xvi
Introduction
Chapter 1
This chapter provides an introduction to Veraz Networks.The following topics are

covered:
Introduction
11
Chapter 1: Introduction
Introduction
Veraz Networks, the leading independent softswitch vendor provides a best-of-class solution that meets the challenge of converging current and future telecommunications capabilities onto a single Multi-Service Access Network.
Communication service providers face a complex set of challenges. Worldwide deregulation has increased the level of competition, forcing service providers to find new
approaches to attract and retain profitable customers. While the ubiquity of the Internet
has resulted in new opportunities for interactions with anyone, anywhere, the new competitive environment and the rise of the Internet has reduced the profitability potential of the
traditional public voice network. At the same time, businesses and consumers are moving
towards always-on digital connectivity through broadband and Web-enabled wireless
devices to better take advantage of this connected world. These digitally empowered users
are increasing the demand for customized communication services. Service providers
require new efficiencies to serve today's Internet users and new flexibility to attract and
retain tomorrow's profitable broadband users. To succeed, service providers must overcome the technical and financial hurdles of moving to increasingly efficient packet-based
technologies and services while still leveraging existing circuit-switched voice networks.
In an environment replete with vendors offering two-tier and three-tier vertical solutions,
Veraz Networks has elected to concentrate the full weight of their experience and effort
toward the development of next generation softswitch solutions. Veraz Networks is
committed to providing open and interoperable solutions consistent with the intent of the
IETF, ITU, the International Softswitch Consortium, and other proponents of distributed
architecture principles and systems concepts. The Veraz Networks softswitch provides a
true best-of-class solution meeting all of the requirements of the complete next generation
three-tiered reference model.
At the media transport level, the Veraz I-Gate 4000 media gateways and media device
partners provide toll quality transmission of voice and fax traffic between the packet
network and the PSTN. For the control and signaling level, the Veraz ControlSwitch and
its suite of applications provide fully distributed softswitch functionality that transforms
the traditional central office into a distributed Network Office. The resulting complete
solution makes possible the deployment of flexible subscriber services from anywhere in
the service provider's network, lowering network investment and operating costs. As a
result, the service provider can quickly deliver high-value, differentiated new services for
their specific markets boosting their revenues and profits.
The Veraz ControlSwitch is a next-generation carrier-class softswitch system that

empowers service providers to rapidly deploy new, revenue-generating services, while
providing a smooth migration path from existing voice networks to next-generation packet
networks. Built around distributed, highly scalable, high availability architecture with
open interfaces to media devices, application servers and back-office systems, the Veraz
ControlSwitch platform acts as an operating system for the new public network. The same
ControlSwitch can be used to deploy multiple solutions as described in the following
sections.
12
Veraz Networks' world-class engineering team brings together voice and data expertise
drawn from leading service providers, telecommunications companies and data
networking companies. Veraz Networks is privately funded by leading venture capital
firms, Kleiner Perkins Caufield & Byers, Norwest Venture Partners and Battery Ventures.
The company is headquartered in San Jose, CA.
Veraz Networks' products provide far-reaching advantages to a service provider in the
migration of their public voice networks to more efficient and flexible packet technology
based networks. While capitalizing on existing installed infrastructure investments the
service provider is able to solve current network challenges and prepare to capture new
revenue opportunities through a new generation of differentiating services.
13
Chapter 1: Introduction
14
New Functionality Added in

Release 5.5.5
Chapter 2
This chapter provides an introduction to the new functionality added in release 5.5.5 to the
ControlSwitch.The following topics are covered:
EMS Enhancements
EMS Disaster Recovery
Event Relay Server
Combined EMS CDR Platform
Bulk Provisioning Enhancements
Operational Tools
IN Services
Test Call
INAP CS-1
SIP Enhancements
SIP High Availability Solution
Session Timer Compliance
Answer Offer Model
Prack Method
Tel URL Compliance
Update Method
Hong Kong ISUP Compliance
21
Chapter 2: New Functionality Added in Release 5.5.5
EMS Enhancements
EMS Disaster Recovery
This feature allows for the ControlSwitch to offer a cold standby EMS system for disaster
recovery scenarios. The high availability solution relies on Oracle Dataguard RDBMS 9.2.
Using dataguard, the EMS will receive updates from the EMS of all configuration information at regular intervals (settable from real-time to periodic) to allow for an activity
switch at any time.
Event Relay Server

The Event Relay Server (ERS) is a software module that is loaded on the ControlSwitch.
It allows third-party applications - Event Monitoring Agents (EMA) to subscribe to and
receive call related events over a TCP connection. Multiple EMAs can subscribe to a
receive events. All events are encoded in XML
This functionality is typically deployed with back office traffic monitoring systems that
want to track real time call status. Alternately, this application can also be used by operators wishing to record traffic patterns in real-time.
Combined EMS CDR Platform

EMS and CDR processes can now be combined on one Sun Solaris platform. Two database instances will reside on this combined platform; one for high transaction rate CDR
process and the other for persistent EMS process. Veraz will advise whether a network
topology allows having such a platform depending on call rate and size of network.
Bulk Provisioning Enhancements

Bulk provisioning enhancements in Release 5.5.5 provides an efficient way to reduce
routing data loading time when provisioning Policy Engine. This feature will reduce data
loading time by replacing current policy data with new data provided in an excel file
Operational Tools
Test Call
Test call support allows the operator the ability to place an on demand test call from the
EMS GUI. This is effectively an inverted call setup between two endpoints for the
purposes of operational testing of a given circuit or trunk group. Initial support is for SIP
and ISUP based protocol permutations.
22
INAP CS-1
IN Services
INAP CS-1
Release 5.5.5 adds ETSI INAP CS-1 capability with three productized services for immediate deployment;
Pre-paid authentication
Toll Free/Free Phone applications
Local Number Portability
All announcements for services are based on an IP Media Server servicing as an SRF
function under MGCP control.
SIP Enhancements
Release 5.5.5 adds a number of enhancements for SIP to provide a carrier grade SIP solution. The enhancements also extend the compliance of Veraz SIP solution.

High Availability is offered in release 5.5.5 for Veraz SIP solution to address network,
process, and hardware failures. This feature addresses both local and remote failures. The
feature uses standard SIP procedures like Session Timer, Redirect and OPTIONS methods
based on standard RFCs.
Session Timer Compliance

Session Timer is used basically for session pings as well as High Availability solutions.
Session Timer compliance has been added to release 5.5.5. Previously, Veraz SIP gateway
(Local Gateway) did accept Session Timer requests.
In release 5.5.5, Veraz SIP IP Trunk Groups can be configured to send Session Timer
Requests to remote SIP entities. The implementation complies with RFC4028.
Answer Offer Model

Answer Offer Model as recommended by RFC 3264 suggests methods of exchanging
multimedia capabilities (SDP) between two endpoints until a resolution is reached.
Employing Answer Offer Model an endpoint can either offer or request SDP in an
INVITE message. In subsequent messages the other endpoint can respond to the offer.
More exchanges can happen until the call is established using provisional messages or
provisional messages responses (18X and Prack).
23
Chapter 2: New Functionality Added in Release 5.5.5
Prack Method
SIP Messaging comprises provisional and final responses to an INVITE message. The
provisional responses are not mandatory in a call flow. Provisional responses are used for
alerting and ringing an endpoint e.g. 180 Alerting, 183 Session Progress (18X). The final
response is 200 OK. Acknowledging a final response 200 OK using ACK is mandatory
but acknowledging provisional messages is optional. A provisional message is acknowledged using PRACK (abbreviated for Provisional Acknowledge).
Release 5.5.5 implements PRACK message accepting as well as generation per standard
RFC 3262. In previous releases, PRACK is only sent out by Veraz when requested by
remote entity.
Tel URL Compliance

Per SIP standard RFC2806, Tel URL specifies that a PSTN phone ('tel'-ephone) is being
used for SIP calls. URLs are used to `locate' resources, by providing an abstract identification of the resource location. Every SIP call is addressed to a SIP URL that like an
email comprises user name or number like sip:verazattendant@veraznetworks.com.
Similar, Tel URL looks like tel:+14087509400@veraznetworks.com.
Tel URL feature is particularly used when interworking with PSTN network. Many
scenarios using Tel URL are defined in RFC3398. Release 5.5.5 supports tel URL format.
Update Method
Update Method is implemented in release 5.5.5 per SIP standard RFC 3311. UPDATE
allows a client to update parameters of a session (such as the set of media streams and their
codecs) but has no impact on the state of a dialog. In that sense, it is like a re-INVITE, but
unlike re-INVITE, it can be sent before the initial INVITE has been completed. This
makes it very useful for updating session parameters within early dialogs.
Veraz uses update both in High Availability solution as well as Answer- Offer Model.
UPDATE behavior can be configured on per trunk group basis.
Hong Kong ISUP Compliance

Hong ISUP compliance is provided in release 5.5.5 per ITU Q.764, Q.762, Q.784.1 and
HKTA2202 Issue 3. Veraz SS7 framework is being leveraged to provide Hong Kong
Variant support. With this support, service providers will be able to connect with domestic
Hong Kong SS7 traffic.
24
Chapter 3
The ControlSwitch is an open standards based multi protocol, multi solution converged
service platform.The following topics are included in this chapter:
Packet Toll/Tandem Solution
Integrated Voice-Data Access for Businesses
SIP Internet Working Services
H.323 Internet Working Services
Universal Port RAS Gateway Control
Internet Call Diversion/Off Load
Voice-Data Traffic Groomer
31
Chapter 3: ControlSwitch Solutions
The ControlSwitch is an open standards based multi protocol, multi solution converged
service platform. All functionality enabled by the ControlSwitch is available in the
product and does not require different software for each application. To enable a new
feature, it only need be configured in the network. Consequently, service providers can
add new features and solutions without having to run multiple disparate networks or incur
downtime to reconfigure the network. They only need enable the new feature and add any
processing capacity needed for the new traffic load.
Packet Toll/Tandem Solution

Figure 3-1: Veraz ControlSwitch Packet Toll/Tandem Solution
The Veraz ControlSwitch Packet Toll/Tandem Solution enables routing of tandem and
long-distance voice traffic over a packet network, while seamlessly interoperating with
today's PSTN. This allows service providers to alleviate congestion in their traditional
PSTN network and cap their investment in legacy infrastructure, while enabling convergence to a single, more cost-effective packet network for both voice and data traffic. The
Veraz ControlSwitch provides the call control, routing and signaling needed for VoIP/
ATM internet working with both SS7 IMTs and ISDN-PRI or CAS trunks (for PBX enterprise locations or in markets where IMTs are unavailable to the service provider). Thus,
using this solution, service providers can route voice calls on a call-by-call basis over a
traditional TDM network or a packet network and offer revenue-generating long-distance
services and direct access ISDN-PRI or CAS connections to enterprise customers.
32
The open, multi-vendor architecture of the Veraz ControlSwitch provides service

providers with the flexibility to deploy best-of-breed media gateways from multiple
vendors. In addition, advanced routing capabilities - including support for LNP, 8XX/
Toll-free services, Voice VPN and multi-national numbering plans - combined with multinational SS7/PRI signaling support enable deployment of long-distance voice services
over national and/or multi-national packet networks. Policy-based routing and screening
and XML-based Digit Analysis provide a high level of flexibility and customization in
deploying these services. Open interfaces to third-party application servers combined with
simple web-based tools enable rapid creation and deployment of new enhanced services
over a packet network. Call detail records are generated and made available in a very flexible format for integration with carrier billing and network performance evaluation
systems. A robust, production-ready management system with a web-based GUI and open
management interfaces based on SNMP, PL/SQL API and CORBA provides the operational support needed for large-scale deployments.
Key Benefits:
Significantly lower costs through convergence to a common packet network for

voice and data services
Advanced routing capabilities to immediately enable revenue-generating toll/

tandem services
Multi-national SS7/PRI signaling support to enable global VoIP/ATM network

deployment
Built on the open, multi-service, carrier-grade ControlSwitch architecture
33
Integrated Voice-Data Access for Businesses

Figure 3-2: Veraz ControlSwitch Integrated Voice-Data Access for Businesses
The Veraz Networks solution for Integrated Voice-Data Access, based on the Veraz
ControlSwitch softswitch platform along with Integrated Access Devices (IADs) and
high-density Media Gateways (MGs) from multiple partner vendors, enables integration
of enterprise voice and data traffic onto a common packet network right from the customer
premises. Voice and data traffic is integrated using an IAD at the customer premises in
conjunction with existing PBXs and Key Systems. On-net calls between different locations are routed through the packet network. Calls that need to go off-net are routed to a
media gateway that provides connectivity to the PSTN through SS7 IMTs, ISDN PRIs or
CAS trunks. Routing policies can be defined to keep off-net calls within the packet
network as long as possible. The multi-vendor IADs and media gateways are both
controlled by the Veraz ControlSwitch, which allows for both flexibility and cost-effectiveness in deploying best-of-breed solutions. Advanced routing features including policybased routing, Voice VPN, 8xx (toll-free) dialing and LNP are supported for both on-net
and off-net calls. Open interfaces to third-party application servers and application developers enable rapid creation and deployment of new enhanced services over a packet
network.
This solution leverages existing voice infrastructure in business locations by supporting a
number of different interfaces (CAS, PRI, Analog Trunks, etc.) from the IADs to existing
PBXs and Key Systems. On the network side, the IADs support several different WAN
interfaces such as E1/T1, NxE1/T1, SDSL and ADSL, thus enabling service providers to
target both small/medium and large business segments. Furthermore, the addition of application servers to support Line-side Services enables extension of integrated voice and data
services to smaller branch locations and remote sites without a PBX.
34
Key Benefits:
High-margin, high-value bundled voice and data services for enterprises
Significantly lower costs through converged packet network right from customer
premises
Investment protection for legacy PBX systems
Seamless evolution to extend integrated voice and data services to smaller branch
locations without PBX
Built on open, multi-service, carrier-grade Veraz ControlSwitch platform
SIP Internet Working Services

Figure 3-3: Veraz ControlSwitch SIP Internet Working Services
Through open interfaces to multi-vendor SIP-based network elements including application servers, proxy servers and SIP end-points, the Veraz ControlSwitch enables service
providers to broaden the set of enhanced communications services available to their business and residential customers. Leveraging the standards-based SIP interfaces of the
Veraz ControlSwitch platform, service providers can rapidly deploy enhanced services
such as IP Call Centers, IP Conferencing, Unified Messaging and Pre-paid/Calling Card
Services, leading to new revenue opportunities, enhanced customer retention and competitive differentiation.
35
Veraz ControlSwitch's unique ability to mediate between various packet and circuit-based
protocols such as MGCP, H.323, SIP, H.248 and global PSTN signaling variants gives
service providers the flexibility to deliver a wide variety of enhanced services to
subscribers served through any type of network. For instance, an IP Conferencing service
provided by a SIP-based application server can be offered to SIP devices served by SIP
networks, H.323 clients served by H.323 networks, POTS phones connected to broadband
IADs and to POTS phones served by the PSTN. This allows service providers to deploy a
common services infrastructure for service delivery over different types of networks,
leading to lower costs, wider market reach and uniformity of service for all subscribers
In addition to support for basic SIP call control messages, the ControlSwitch SIP interface
also supports enhanced SIP call control messages to enable advanced features such as
third-party call control from SIP servers. Furthermore, the ControlSwitch SIP interface
also offers connectivity to SIP proxy servers serving SIP end-points and support for SIPto-SIP calls between two independent SIP networks thus allowing them to be controlled
and billed using a single platform.
Veraz Networks has created a SIP-based application server toolkit that has enabled its
application server partners to quickly achieve full interoperability between their products
and the ControlSwitch platform. The toolkit includes an interoperability specification, SIP
call flows for interoperation between application servers and the Veraz ControlSwitch,
and an interoperability testing process that supports remote testing via the Internet
followed by in-lab testing of the complete solution. By expediting the interoperability
testing process with multi-vendor application servers, this toolkit empowers service
providers to rapidly respond to changing customer needs and exploit new revenue opportunities.
Key Benefits:
36
High-margin enhanced services deployment leveraging SIP application servers

from multiple vendors
Improved customer acquisition, customer retention and competitive differentiation through delivery of enhanced services
Common infrastructure for delivery of services to subscribers served through

different types of networks - leading to lower costs, wider market reach and
uniformity of service across multi-protocol, multi-vendor networks
SIP-based application server toolkit to expedite interoperability testing with application servers, enabling rapid response to new customer needs and revenue opportunities
H.323 Internet Working Services

Figure 3-4: Veraz ControlSwitch H.323 Internet Working Services
The Veraz ControlSwitch solution for H.323 Internet working seamlessly bridges existing
H.323 networks to more scalable MGCP/ SS7-based networks and to emerging SIP and
H.248-based networks, with no changes or upgrades required to the H.323 networks. This
seamless interworking is accomplished using a unique approach that makes the
ControlSwitch appear as an H.323 Gateway to H.323 Gatekeepers that are already in
place. For service providers with existing H.323 networks, this solution enables them to
efficiently scale their networks while protecting their existing investments. For carriers
without existing H.323 networks, this enables inter-carrier traffic exchange with other
carriers who have H.323 networks. For instance, a carrier building a highly scalable
MGCP-based VoIP network with PSTN/SS7 connectivity could generate revenues by
providing long distance transport and origination/termination services to regional H.323based service providers.
In addition, this solution supports interworking with H.323-based feature servers for
delivery of enhanced services such as Unified Messaging, IP Call Centers and Presence
Services. Thus, by leveraging the Veraz ControlSwitch's ability to mediate between
various packet and circuit-based protocols, service providers can offer H.323-based
enhanced services to users on H.323 networks as well as to users on MGCP-based
networks, H.248-based networks, SIP networks or the PSTN. The ControlSwitch supports
a standard H.323-based application interface that allows for rapid integration, testing and
deployment of new application servers.
37
Key Benefits:
Seamless migration from H.323 networks to more scalable MGCP/ SS7-enabled

and to emerging H.248 and SIP-based networks; provides investment protection
Revenue-generation through long distance transport services to regional H.323based service providers
High-margin enhanced services deployment using H.323 application servers
Built on open, multi-service, carrier-grade ControlSwitch platform
Universal Port RAS Gateway Control

Figure 3-5: Universal Port RAS Gateway Control: Integrated Dial-up Access and
VoIP Services
Until now, supporting both dial-up access and voice applications required two separate
networks for both access and transport. In traditional circuit-switched access networks,
explosive growth in dial-up access has led to increasing congestion of Class switches,
requiring increased investments in expensive circuit-switched infrastructure along with
massive Remote Access Server (RAS) farms. In the backbone, voice and data traffic is
typically transported over different overlay networks resulting in large capital and operational costs. The Veraz ControlSwitch, in conjunction with new or upgraded RAS with
Universal Port capabilities, provides a cost-effective, next-generation solution that allows
service providers to deploy a more efficient common network infrastructure for both dialup access and VoIP Toll/Tandem applications.
38
Service providers currently offering dial-up access can leverage their existing RAS infrastructure and point-of-presence (POP) space to offer new VoIP services and expand their
market coverage. By off loading dial-up data traffic from congested Class switches and by
enabling routing of voice traffic over a packet network, this ControlSwitch solution allows
service providers to cap investment in legacy infrastructure, rapidly enter new markets
without additional Class-switch expenditures and evolve to a converged packet network
for both voice and data traffic. Leveraging the universal port capabilities of partner gateways, this solution provides call-by-call support for any service - data, voice or fax - on
any gateway port, thus leading to more efficient use of network infrastructure and invested
capital.
The open, multi-vendor, multi-service architecture of the ControlSwitch provides service
providers with the flexibility to deploy the optimal combination of gateways for each
application and target market. For instance, service providers can deploy universal portenabled RAS gateways in some markets for modem wholesale and VoIP Tandem applications, while deploying high-density media gateways in other markets for VoIP wholesale
and PRI off load applications. With both types of gateways being controlled by the Veraz
ControlSwitch, a common management, operations and billing infrastructure can be more
easily leveraged.
Advanced routing capabilities - including support for Voice VPN, LNP, 8XX/Toll-free
services and multi-national numbering plans - combined with multi-national PSTN/SS7
signaling support enable deployment of carrier-grade VoIP services over national and/or
multi-national packet networks. Open interfaces to third-party application servers and
application developers combined with simple web-based tools enable rapid creation and
deployment of new enhanced services over a packet network.
Key Benefits:
Leverages existing RAS infrastructure for new revenue-generating voice over IP

services, in addition to modem wholesale services
Significantly lower costs through convergence to a common packet network for

voice and data services
Alleviates congestion and caps investment in legacy TDM infrastructure
Open, multi-vendor, multi-service ControlSwitch architecture that allows choice

of optimal gateway for different market segments and enables seamless evolution
to support new services
39
Internet Call Diversion/Off Load

Figure 3-6: Veraz ControlSwitch Internet Call Diversion/Off Load
Explosive growth in data dialup traffic over the last few years has led to increasing
congestion in the existing circuit-switched voice network. This has led to increased call
blocking requiring large investments for more circuit-switched infrastructure. The Veraz
ControlSwitch Internet Call Diversion (ICD) solution provides a cost-effective nextgeneration solution to this problem. By off loading dial-up data traffic from congested
local tandem and Class switches, the ControlSwitch ICD solution enables service
providers to extend the life of their installed infrastructure, expand services in existing
markets and rapidly enter new markets without additional Class-switch expenditures. The
ControlSwitch ICD solution delivers two different lucrative services that can be offered to
ISPs: Modem Wholesale Services and PRI Leasing Services.
Modem Wholesale Services:
In this application, dial-up data traffic over SS7 IMTs is routed directly to a partner
Remote Access Server (RAS) under control of the Veraz ControlSwitch. The
ControlSwitch provides the call control and signaling needed for the RAS to terminate the
SS7 IMTs. This enables service providers to enter new markets and offer modem wholesale services to ISPs at a fraction of the cost of legacy infrastructure, while alleviating
congestion in their existing Class switches.
310
PRI Leasing Services:

In this application, dial-up data traffic over SS7 IMTs is routed to a partner media gateway
under control of the Veraz ControlSwitch. The ControlSwitch provides the call control
and signaling needed for the media gateway to terminate SS7 IMTs and switch the data
calls onto PRIs going to an ISPs RAS. This enables service providers to offer PRI leasing
services to ISPs in new markets at a fraction of the cost of legacy infrastructure, while
leveraging the ISPs' existing RAS infrastructure.
Key Benefits:
Immediate revenue generation through modem wholesale and PRI leasing

services to ISPs
Investment protection for existing RAS infrastructure
Open, multi-service, carrier-grade ControlSwitch architecture that enables seamless evolution to support new services
Voice-Data Traffic Groomer

Figure 3-7: Veraz ControlSwitch Voice-Data Traffic Groomer
311
Explosive growth in data dialup traffic over the last few years has led to increasing
congestion in the existing circuit-switched voice network. This has led to increased call
blocking requiring significant new investments for additional circuit-switched infrastructure. The Veraz ControlSwitch Voice-Data Traffic Groomer Solution provides a costeffective next-generation solution to this problem. The Veraz ControlSwitch in conjunction with a partner media gateway (MG) off loads data traffic from the PSTN before it hits
a legacy TDM switch and forwards the voice traffic to a circuit switch or PBX for further
processing. This solution enables calls on any type of ingress trunk (IMT, PRI, CAS) to be
routed over any type of egress trunk (IMT, PRI, CAS). Voice and Data traffic coming in
over IMTs can be groomed into PRI data traffic going to ISPs, PRI or CAS voice traffic
going to enterprise PBXs and voice traffic over IMTs to a TDM switch.
This solution enables service providers to offer lucrative PRI/CAS services for voice and
PRI services for data. PRI/CAS services for voice enable a Direct Access Line offering to
enterprise customers with a PBX. PRI wholesale services for data enable an Internet Call
Diversion offering to ISPs. Advanced routing capabilities like 8XX/Toll-free services,
LNP, policy-based routing and screening and XML-based Digit Analysis are supported
for both voice and data calls.
Furthermore, with an upgrade to the Veraz ControlSwitch Packet Toll/Tandem Solution,
voice traffic can also be selectively routed to a VoIP/ATM packet network, thereby
enabling convergence to a next-generation packet network for both voice and data.
Key Benefits:
312
Immediate revenue generation through low-cost PRI data offering for ISPs and
PRI/CAS voice offering for enterprise customers
Open, multi-service, carrier-grade ControlSwitch architecture that enables seamless evolution to support new services
Veraz ControlSwitch General

Description
Chapter 4
This chapter provides a general description of the Veraz ControlSwitch. The following
topics are included in this chapter:
General Description
Signaling Gateway
Call Control Element
Service Execution Element
Policy Element
Events Collector
CDR Element
Element Management System
IP Call Element
SS7 Access Server
ControlSwitch Element Interactions
Scalability for Large Networks
Veraz Network ControlSwitch Product Description
41
Chapter 4: Veraz ControlSwitch General Description
General Description
The Veraz ControlSwitch product is a distributed software system that executes on a
number of SUN computer hardware (typically carrier-grade SUN Netra platforms) platforms interconnected over an underlying IP data network. The ControlSwitch is designed
with a highly scalable architecture. A service provider can elect to start with a small
system and grow it to a very large one, spanning multiple geographic centers, by adding
components as the traffic and end-user volume increases. At a high level the
ControlSwitch can be described as a distributed IP-network-based system providing traditional switch functions of call control, call routing, signaling gateway, and media device
control in addition to back office functions in support of provisioning, billing, and network
operations. The ControlSwitch consists of several software elements:
Signaling Gateway (SG),
Call Control Element (CCE),
Policy Element (PE),
Events Collector (EC),
CDR Element (CDRE) or CDR Manager
Element Management System (EMS).
IP Call Element (ICE)
Service Execution Element (SEE)
Figure 4-1: Veraz ControlSwitch
42
Signaling Gateway Variants
A brief description of each ControlSwitch element follows. Further operational details are
available later in this document.
Signaling Gateway
The Signaling Gateway (SG) allows the ControlSwitch system to access and utilize the
STP and SCP resources of the SS7 network for PSTN call signaling and for intelligent
networking services. These resources are available at two levels.

The ControlSwitch supports multiple signaling gateways to suit various applications. The
two types are as follows:
Ulticom Signaling Gateway
There are two types of Ulticom Signaling Gateways: ISUP and TCAP. Both an ISUP and
a TCAP SG can be configured to reside on the same SG platform.
The ISUP Signaling Gateway in combination with a CCE performs trunk side signaling
for the purpose of call setup and tear down. This pair of elements receives ISUP messages
from the SS7 network and acts as an SSP in the ControlSwitch system. The CCE is then
able to process call setup, maintenance, and tear down for the local side as well as for the
remote side via these ISUP messages. The SG supports multiple SS7 variants. The details
of these supported variants are discussed later in this document.
The TCAP Signaling Gateway acts as a conduit for SS7 TCAP messages to a Service
Control Point (SCP) in the PSTN network. The ControlSwitch gains access to the PSTN
SCP resident databases via TCAP and provides select AIN line services such as toll-free
translations (in North America also referred to as 8xx number translations) and local
number portability using the AIN 0.1 call model.(Extensions to support ETSI compatible
intelligent network services are in development.)
For variant support and limitations, please see the SS7 Services section.
Telesys Signaling Gateway
The Telesys signaling gateway is used in conjunction with the ControlSwitch M3UA
support. The Telesys iSTP interfaces to the SS7 network through TDM A-links and Flinks. It terminates MTP layer 1, 2, and 3 traffic. ISUP traffic is then forwarded to the
ControlSwitch via M3UA.
Logically, the iSTP functions as the SG/SGPs with respect to M3UA and communicates
with the Veraz SS7 Access Server (SAS), which contains as the AS/ASPs.
43
The Telesys iSTP are deployed in a redundant pair, with each pair representing a physical
point code. Logically the iSTP can represent multiple point codes hence appearing as an
STP to the network if required. This allows for more efficient use and management of the
network resources. The Telesys iSTP functions as an STP only for the point codes
managed by the ControlSwitch. It does not function as a standalone STP for legacy
switches.
From the perspective of the SS7 network, the iSTPs local point code is seen as the adjacent point code for routing to all configured point codes supported by a given A-link or Flink pair. Upon receiving messages for a logical point code, the iSTP will forward hem to
the appropriate M3UA ASP based on the configured routing key. For more information,
please see the section on the ControlSwitch SS7 Application Server (SAS).
For variant support and limitations, please see the SS-7 Services section.
Call Control Element

The Call Control Element (CCE) resides on a platform called the Call Control Platform
(CCP). The CCE provides protocol processing and resource management functions that
allow call legs to be controlled within the system however does not manage the state
machines for the calls and services. In short, the CCEs primary responsibilities fall into the
following categories;
Protocol Processing
Protocol mediation between network facing protocols (MGCP, ISDN, SS7 etc.)
and the internal generic call processing protocol
Resource Management (TGs, channels, gateways, etc.)
The CCE interfaces with the Signaling Gateway, Service Execution Element, Policy
element, Element Management System, Event Collector and media gateways via an IP
network. The Call Control Element supports a variety of protocols both for PSTN
signaling as well as packet network signaling.

The Service Execution Element is a SLEE compliant services execution environment.
Utilizing the Veraz Services Execution Environment (SEE), enhanced user services can be
realized and rapidly brought to market. The SEE follows the same modular and distributed
architecture as that currently used in the ControlSwitch for tandem services. Developed in
C++ and XML, the SEE is optimized for performance to allow more efficient processing
over a Java based solution however follows all architectural considerations of the industry
accepted J-SLEE specification.
44
The SEE is similar to the existing ControlSwitch elements in that it is a modular component that can be added to the network as required by the operator. It follows the same
distributed design as has been production proven in numerous networks, guaranteeing
maximum availability and unlimited scalability.
The SEE uses a C++ engine with flexible adapters allowing the ControlSwitch interface
with both next generation and legacy external service platforms. This includes:
Legacy Signaling
SS7
PRI
CAS
IP protocols
H.323
SIP
MGCP
The direct protocol interface to the network is via the CCE which mediates the messages
to a generic inter-call call processing language that the SEE uses for service execution.
This allows the SEE to operate as a protocol agnostic engine hence services can be created
irrespective of the underlying framework. Effectively generic inter-call call processing
language and clean separation of call control and services function through the SEE allow
the ControlSwitch to support a completely programmable services model. On other hand,
protocols interworking get more flexible too. Since it is no longer dependent on call /
services model, new protocol addition or protocol modification requires only development
/ modification of adapter.
The following diagram illustrates the interface between other elements:
45
Figure 4-2: SEE Architecture
Integrated services include:
Tandem State machine for equivalent pre 5.5 functionality
Re-Routing capability
Announcement support
Account Codes
Personal Toll Free Service and other pin based services
Off-board Authentication (such as OSP)
For more information, please see details in the Services section of the document.
Policy Element
The Policy element (PE) is a generic policy engine allowing it to be leveraged for service
association and network policy administration. At the simplest level this element responds
to call related queries with treatments based on a database of provisioned policies. The PE
supports a real time in memory hierarchical database to enable call-processing transactions to occur at a high rate.
46
At the beginning of any call (that is determined to be process-able), the policy element is
queried by the SEE for call treatment. Once received by the policy element along with an
indication of what policy tables to query, the policy engine queries the appropriate database(s) to determine the call handling attributes for associated services and returns those to
the SEE. The most base illustration would be for routing - upon receiving a query indicating a route request, the PE queries the indicated routing policies and returns the appropriate routes (or release treatments).
The policy element can support multiple policy queries and executions within the context
of a single call enabling multiple trigger driven services. To achieve this, the PE supports
user configurable Service Trigger interface. This is modeled in a similar fashion the interface used for routing however treatments identify a service to be executed. The Service
Trigger Plan Group is modeled after the AIN 0.2 call model and uses standard trigger
detection points and trigger types to identify a Point in Call. Multiple Services can be triggered for any call.
For more information, please see section Policy Element - Supported Policies
Events Collector
The Events Collector (EC) is responsible for collection and storage of billing and callrelated events from the various ControlSwitch elements.
The Events Collector receives events associated with a call and its progress through the
system. These events are received by the EC from ControlSwitch CCE elements. The EC
indexes and stores these events for operational report generation and for use by billing
systems.
CDR Element
The Call Detail Record (CDR) element is responsible for the ControlSwitch billing and
data analysis functions. The CDR Element handles the billing data formatting and transporting functions.
Due to the need to accommodate a wide variety of customer billing applications, the
ControlSwitch billing solution generates a text-based generic Call Detail Record (ICDR)
that can be fed into billing mediation solutions that specialize in supporting custom interfaces to billing and customer care applications. Furthermore, the ControlSwitch billing
solution can also generate billing records according to the Bellcore AMA Format (BAF).
47

The Element Management System (EMS) is responsible for provisioning all the components of a ControlSwitch system. In addition it proactively monitors the status of the
system's elements. At the provisioning level, the EMS sets up and initializes all of the
components in a ControlSwitch system, including the CCE, SG, PE, EC, and CDR. In
addition to setting up individual element, the EMS ensures that all these elements of the
system are brought up in the proper sequence, and that the appropriate relationships are
enabled among the elements.
The EMS supports multiple aspects of system monitoring, including real-time alarms, call
tracing and diagnostics, performance statistics and traffic reports and browsing of Call
Detail Records stored in the CDR Manager. The EMS is designed to give the network
administrator all the necessary information to properly monitor and operate the system.
The EMS also serves an important role in ensuring high availability of ControlSwitch
functionality. It performs sanity checks as well as rebinding operations of elements after
an element failure is detected and its functional failover to an alternate element has
occurred.
The EMS user interface is a Web browser-based GUI. The screens are logically laid out
and enable the user to intuitively provision the system. Additionally, event alarms are
displayed in near real time on the GUI.
IP Call Element
The IP Call Element (ICE) can be viewed as a sub element (or sister element) to the CCE
in that it uses common modules for resource management and functions as the interface
for call processing. The ICE however is optimized for management of VoIP based protocols (H.323 and SIP) as opposed to resource management protocols and PSTN protocols
as is the case with the CCE. As with the CCE, the ICE provides protocol processing and
resource management functions that allow call legs to be controlled within the system
however does not manage the state machines for the calls and services. In short, the ICEs
primary responsibilities fall into the following categories;
Protocol Processing
Protocol mediation between network facing protocols (MGCP, ISDN, SS-7 etc.)
and the internal generic call processing protocol
Resource Management (TGs, channels, gateways, etc.)
For IP based protocols. The ICE may exist as a standalone element processing only the
VoIP leg of calls and interface to the other CCEs/ICEs for the other leg of the call or may
be installed on the same platform as CCEs. The decision is a function of network planning.
The ICE will support both H.323 and SIP simultaneously and can interface to multiple
networks of either type as distinct gateways to each network.
48
SS7 Access Server

The SS7 Access Server (SAS) is a logical process that is used to support M3UA in the
ControlSwitch network. Its functional role can be summarized as follows:
Arbitrate provisioning requests from the EMS
Manage ASP processes
Implements the ASP redundancy logic
Provides ISUP encode-decode functionality
Report events to the EMS
The SAS creates and manages the M3UA AS/ASP processes and functions in an active/
standby pair. The redundant ASP pair in turn represents a single local point code and
manages traffic for multiple routing contexts configured for that local point code. The
association between the SAS and the ASPs is many to one, meaning that a single SAS will
parent ASPs based on the number of local point codes the switch represents. Each SAS
has a redundant mate, which in turn has redundant ASPs.
The ASPs associated with a given SAS (or SAS pair) will initiate and terminate the M3UA
traffic to and from their mate SGP process (which in turn interfaces to the SS-7 network).
The SAS then manages the ASPs as well as the ASP activity (failover etc.).
The SAS can reside on a separate platform from other ControlSwitch elements, or can be
combined with a CCE process or processes. When combined with the CCE, there is an
inherent performance impact on the platform. Due to the fact that there is no fixed association between the SAS (and ASP resources) and a given CCE, the performance impact
cannot be determined unless explicitly engineered to have a deterministic relationship.
Consequently, it is recommended that production applications deploy the SAS element on
a separate hardware platform. Currently, the SAS is only supported on a separate hardware
platform.
ControlSwitch Element Interactions

To understand the relationship between the various ControlSwitch elements let us
consider the case of a call dialed by a user whose telephone is connected to a local carrier's
Class 5 switch located in a CO. For this example let us consider a call dialed to another
PSTN-based telephone. Typically, the Class switch to which the caller is connected uses
the dialed phone number and the calling subscriber's information to select an outgoing
bearer IMT to send the call on to the new generation infrastructure represented by the
ControlSwitch and associated media gateways. The Class switch sends the call-related
signaling over the SS7 network to the ControlSwitch SG.
49
Figure 4-3: ControlSwitch Element Interactions
Upon receiving the call's parameters in an SS7 IAM message, the SG generates a unique
call identifier. The SG selects the appropriate CCE (the ingress CCE that manages the
media gateway to which the incoming call's bearer IMT is connected) using OPC-DPCCIC values included in the IAM, and then sends the call parameters to the ingress CCE
over the IP network. The ingress CCE now becomes aware of the incoming call and
carries out the following tasks:
1. Communicates with an PE to request a route(s) to send the call to its destination
2. Communicates with the ingress media gateway using MGCP/H.248 to request that an
ingress call end-point be established on the media gateway; this end point serves as
the end of the first call leg from the calling phone to the ingress media gateway.
Upon receiving a route from the PE (a route includes the identity of the egress CCE and
the egress trunk group to be used for the call) the ingress CCE passes the call parameters
(as well as the unique call identifier) to the egress CCE. The egress CCE then carries out a
number of tasks:
3. Selects an available channel on the indicated egress trunk group and requests (via
MGCP/H.248) that the egress media gateway establish an end point for the egress leg
of the call to the destination phone
4. Passes the call parameters to an egress SG.
The egress SG uses the SS7 network to instruct the terminating switch to ring the destination telephone.
410
With endpoints established at both ingress and egress media gateways, the two CCEs now
exchange the RTP port numbers of the endpoints, enabling a VoIP path between the
ingress and egress call legs.
The CCEs generate call events during the call setup as well as throughout the entire call.
These events are sent to the Event Collector where they are suitably indexed and stored.
Stored call events are later used by the CDR Element to generate call detail records.
System operational reports such as traffic and network utilization are also generated from
these call events. These interactions can be represented in the call flow shown below:
Figure 4-4: CCE Call Flow
411
Scalability for Large Networks

The ControlSwitch's distributed design allows carriers to start with small deployments and
scale the system up by the addition of particular elements as traffic-induced loading is
experienced by these particular elements or as the number of trunks/ports to be managed is
increased. Furthermore, a considerable amount of network design flexibility is permitted
by the distributed design.
Depending on the nature of operational methodology and/or facilities distribution, a
service provider might choose to locate the EMS, PE, EC and CDRE in a location close to
the network operations and IT systems while the call control and signaling elements could
be located in various switching centers selected for convenience of the switching plant and
related personnel. Media gateways can be added in the various points-of-presence (POPs)
depending on the provisioning of trunks to the PSTN and to customer sites. The media
gateway control of these media gateways can be assigned to appropriate SG/CCE based on
load distribution and signaling link disposition. The only requirement is that between any
two elements there is a redundant IP network path of sufficient bandwidth and quality for
the operational and real-time interaction of the various ControlSwitch elements to be
transported reliably and with low delay.
When more media gateways and/or bearer trunks are added, to the extent that all CCEs are
running at full capacity, the service provider can install additional CCEs for handling
these added media devices and the related call traffic. The interrelationships of the new
elements with previously operational ones are set up from the user-friendly EMS GUI.
Similarly, SG elements can be added as the amount of SS7 traffic grows beyond the
capacity of already operational SG. The same scaling principle applies for the PE and EC.
The modular growth of the ControlSwitch system allows service providers to start out
with a modest investment and gradually grow the installed system as traffic demand and
revenue opportunities justify further investments
412
Supported Customer
Environments
Chapter 5
This chapter describes the various supported customer environments.The following topics
are included in this chapter:
Class 4/5 Switch Interfaces
PBX and RAS / NAS Device Interfaces
STP Interfaces
IP Network Interfaces
51
Chapter 5: Supported Customer Environments
Class 4/5 Switch Interfaces

The ControlSwitch can interface to a PSTN element such as a Class 5 switch via SS7,
ISDN-PRI, or channel associated signaling (CAS). This set of interfaces has the following
possible components:
Signaling interface - SS7: This interface will be A-links (with an intervening STP
between Class switch and ControlSwitch), or F-links (no STP between Class
switch and ControlSwitch). When F-links are used to carry SS7 signaling to the
ControlSwitch SG, the appropriate DACS function is needed to separate the
signaling links and the bearer links. The Veraz I-Gate 4000 or I-Gate 4000 PRO
can provide this DACS function if they are deployed in the network. The
signaling links are then connected to the ControlSwitch SG; the bearer links are
connected to the appropriate media gateway(s). The protocol suite for the
signaling interface is ISUP for call processing, MTP3 for the transport layer and
addressing, and MTP2 for the link layer. At the physical layer, a T1/E1 interface
is used, terminating on signaling cards at the ControlSwitch SG. Specifics of the
signaling interface are covered in subsequent sections of this document.
Bearer interface - IMT: This interface is used for conveyance of audio between
the PSTN switch and the media gateways that the ControlSwitch manages. The
ControlSwitch supports a variety of interfaces including E1, T1, DS-3, STM-1,
OC-3 Interface support on media gateways is a function of the media gateway
itself.
Signaling interface - PRI: This interface is E1, T1 or T3 lines between the Media
Gateway and the Class switch. A designated number of DS0 channels in these
lines are used for transporting Q.931/Q.921 signaling. The Q.921 signaling terminates at the Media Gateway, whereas the Q.931 is tunneled over IP to the
ControlSwitch. Specifics of call processing on the signaling interface are covered
in subsequent sections of this document.
Bearer interface - PRI: This interface is E1, T1 or T3, and the bearer channels are
bundled in the same physical interface as the signaling channels. The majority of
DS0s in the E1, T1 or T3 line are for conveyance of bearer audio between the
Class 5 switch and the media gateways that the ControlSwitch manages.
PBX and RAS / NAS Device Interfaces

The ControlSwitch and Media Gateways interface with a PBX or a RAS/NAS via ISDNPRI. This interface has two components:
52
Signaling interface - PRI: This interface is T1 or T3 lines between the Media

Gateway and the PBX or RAS/NAS. Designated DS0 channels in these lines are
used for transporting Q.931/Q.921 signaling. The Q.921 signaling terminates at
the Media Gateway, whereas the Q.931 is tunneled through over IP to the
ControlSwitch. Specifics of call processing on the signaling interface are covered
in subsequent sections of this document.
Bearer interface - PRI: This interface is E1, T1 or T3, and the bearer channels are
bundled in the same physical interface as the signaling channels. The majority of
DS0s in the T1 or T3 line are for conveyance of bearer audio between the PBX
and the associated media gateway controlled by the ControlSwitch.
Signaling interface - CAS: This interface uses T1 lines between the Media
Gateway and the PBX. Each DS0 channel in these lines is used for the transportation of telemetric robbed-bit signaling. Additional signaling is facilitated for MF
and DTMF variants of CAS, using specified tones. The CAS telemetric signaling
terminates at the Media Gateway, and is conveyed over IP to the ControlSwitch
for call processing. Specifics of call processing on this signaling interface are
covered in subsequent sections of this document. Orientation of the CAS interface
can either be as a trunk group, or as multiple individual subscribers bound to each
DS-0.
Bearer interface - CAS: This interface uses T1 and the bearer channels are
bundled in the exact same physical interface as the signaling channels. The DS0s
in the T1 line are used for conveyance of bearer audio between the PBX and the
media gateways that the ControlSwitch manages.
Signaling Interface - Analog FXS: This interface can be two-wire FXS using loop
start or ground start signaling. The analog telemetric signaling terminates at the
Media Gateway, and is conveyed over IP to the ControlSwitch for call processing.
Specifics of call processing on this signaling interface are covered in subsequent
sections of this document.
Bearer Interface - Analog FXS: This interface can be two-wire analog interface
for connection directly to a black phone or interface that appears as a black phone.
The bearer is used to transfer voice band audio information across an IP network
using RTP.
STP Interfaces
The ControlSwitch SG is capable of interfacing with A-links from an STP. This interface
is for SS7 signaling only. This interface uses T1 lines between the ControlSwitch SG and
the STP. Designated DS0 channels in these lines are used for the A-links (a single DS0 is
a single A-link) - not all the channels in the T1 need to be utilized as A-links. No bearer
traffic is carried on the A-links.
53
Chapter 5: Supported Customer Environments
IP Network Interfaces
The ControlSwitch and Media Gateways interface with an IP network for the purpose of
transporting signaling or bearer signals:
54
Signaling interface: This interface is used for transporting MGCP, SIP, H.323,
SIGTRAN Backhaul, or proprietary signaling messages between individual
ControlSwitch elements, and between the ControlSwitch CCE and media gateways or application servers. Two Fast Ethernet ports are provided on each
ControlSwitch element to communicate over IP. For signal transport over a
WAN, either Ethernet-Frame Relay or Ethernet-ATM routers may be used.
Bearer interface: This interface is used for transporting RTP audio streams
between any two media gateways, in VoIP calls. Fast Ethernet ports are provided
on each Media Gateway to communicate over IP. The bearer IP interface is
usually independent of the signaling IP interface, although for the purpose of dual
network fault tolerance, they may be the same.
Supported ControlSwitch
Configurations
Chapter 6
This chapter describes the supported ControlSwitch configurations.The following topics

Recommended ControlSwitch Element Configurations: Elements and Platforms
Redundant System Recommendations
SG Redundancy
CCP/CCE Redundancy
SEE Redundancy
PE Redundancy
EC Redundancy
EMS Redundancy
61
Chapter 6: Supported ControlSwitch Configurations

As previously noted, the term element refers to a ControlSwitch software component,
while the term platform refers to a computer on which one or more of these elements are
installed and run. This section describes combinations of elements that can co-reside on
the same platform. The actual distribution of elements on platforms for a given service
provider network depends on a number of factors such as:
Call load - both rate and volume to be handled
Geographic distribution of elements/platforms and inter-platform IP network

bandwidth availability
Overall redundancy characteristics desired
Cumulative platforms cost for the system.
Recommended ControlSwitch Element Configurations:

Elements and Platforms
For high volume and high call rates it is recommended that a CCE element reside on a
separate platform. For high volume and high call rates originating or terminating on ISUPsignaling enabled IMT trunks, it is also recommended that a SG element reside on a separate platform. For situations where the call rate is more modest, a single platform can
accommodate both an SG and a CCP element.
As previously noted, there are two types of SG elements: ISUP and TCAP. Both TCAP
and ISUP SG elements can reside on the same platform. One SG platform can support up
to five unique point codes.
The PE can be shared by a number of CCEs. Since the PE is a shared element it is recommended that the each PE reside on its own separate platform.
Similarly, the EC element serves multiple CCE elements. For modest call volumes, the EC
can reside on the same platform as a CDRE. For high call rate deployments it is not
recommended that an EC be co-resident on the same platform with a CDR Manager.
Table 6-1
62
Non-Redundant Configuration Summary
Element
Low Call rate Deployment
High Call Rate Deployment
CCE (Class 4/5)
Alone or Combined with SG or ICE
Alone
ICE
Alone or Combined with CCE
Alone
SG
Alone or Combined with CCE (both

Class 4/5 and Tandem)
Alone
EC
Alone or With CDRE
Alone
PE
Alone or combined with SEE
Alone
EMS
Alone
Alone
SG Redundancy
Table 6-1
Non-Redundant Configuration Summary
Element
Low Call rate Deployment
High Call Rate Deployment
SEE
Alone or combined with PE
Alone
Ability of system elements to be flexibly combined depending on capacity / redundancy

requirements provides basis for network solutions scalability. ControlSwitch can be
scaled up very granularly through addition of hardware platforms of needed performance
and redistribution / addition of new processing elements. Fine granularity of scalability,
provided by ControlSwitch makes service growth very cost effective.
Redundant System Recommendations

For high-availability reasons most service providers install redundant instances of
ControlSwitch elements and platforms. Several possible configurations are permitted as
described below.
SG Redundancy
SG elements are always installed in mated pairs with each of the two SG elements residing
on a different platform. Use of separate platforms ensures that at least one of the two SG
elements is available in the event that one of the platforms fails or becomes disconnected
from the SS7 or IP networks.
Ulticom SG Redundancy
The Ulticom SGs support 1:1 active/standby redundancy. When configured in a redundant
pair, the mates must be co-located to ensure a minimal delay between units.
Telesys SG Redundancy
The Telesys SG supports 1:1 active/active redundancy. The configured redundant pair can
be geographically separated.
CCP/CCE Redundancy
The CCE supports 1:1 redundancy at the process. Deployments/configurations can be
created that are physically N+1 or N+M however failover is on a 1:1 basis for the underlying software process
63
Chapter 6: Supported ControlSwitch Configurations
SEE Redundancy
The SEE supports 1:1 redundancy at the process. Deployments/configurations can be
created that are physically N+1 or N+M however failover is on a 1:1 basis for the underlying software process.
SEE supports active call processing state mirroring between the Active and the Standby.
PE Redundancy
The PE supports both 1:1 and 1:N failover.
EC Redundancy
Redundant EC elements running on separate platforms are required for high availability.
Each CCE is configured to send all call events to two separate ECs. An EC, though, is a
shared element that collects call event notifications from multiple CCEs.
EMS Redundancy
EMS redundancy, if required is supported through a Sun Cluster configuration consisting
of two hosts with a pair of shared and mirrored disk arrays. The pair of hosts acts as a
single logical host with respect to ControlSwitch elements.
64
EMS and ControlSwitch

Infrastructure
Chapter 7
This chapter describes the EMS and ControlSwitch infrastructure. The following topics
System Startup and Upgrade
EMS High Availability - Disaster Recovery
Combined EMS and CDR Platform
System and Element Provisioning
User Management: Privileges, Actions, Roles
Security Management
DS0 Level Management
Fault Management
Performance Management
Automated Provisioning
71
Chapter 7: EMS and ControlSwitch Infrastructure
System Startup and Upgrade

Software Upgrades
Typically, when a ControlSwitch element/platform requires a software upgrade, the operator uses the EMS to force the failover of the elements on the platform to redundant
elements on other platform(s). All current element operations are transferred to the
secondary platform. Following this action, the element/platform that is to be upgraded is
taken out of service and the new software installed.
When installation of the upgrades on the platform is complete, the operator uses the EMS
to restart/bring up the upgraded platform with the new software. Operation is then failed
back from the redundant platform to the upgraded primary one. The redundant unit can
now be taken out of service and be upgraded in the same manner as well.
This approach allows software upgrades to be installed without any service-affecting
consequences.
Software Optionality Control (SOC)

The ControlSwitch uses an encrypted key to unlock features and functionality on the
network. In order to use a given feature, it is required that the software license key support
the feature.
The ControlSwitch supports two types of license keys - a permanent key, and a timed key.
The Permanent key reflects purchased functionality and does not expire. The timed key
reflects a limited time trial for features indicated in the key. Both types of keys can exist
simultaneously hence an existing installation can add trial features for a predetermined
time.
Key entitlements can be viewed from the EMS GUI as can management of the keys themselves. The ControlSwitch also supports notification of impending key expiry or if license
entitlement being exceeded.
In the event that a key expires (or license is exceeded), the ControlSwitch will not interrupt service, but provisioning capability will be disabled.
72
EMS High Availability - Disaster Recovery

This feature allows for the ControlSwitch to offer a cold standby EMS system for disaster
recovery scenarios. The high availability solution relies on Oracle Dataguard RDBMS 9.2.
Using dataguard, the EMS will receive updates from the EMS of all configuration information at regular intervals (settable from real-time to periodic) to allow for an activity
switch at any time. In the event of a catastrophic failure of the primary EMS, the operator
can choose to log into the cold standby and request an activity switch. Upon initiating the
changeover, the redundant system will start all EMS processes and take control of the
network. To assist in avoiding erroneous startup, the redundant will attempt to contact the
primary (master) to ensure the start request was not erroneous. Failover time is essentially
the time required to start the EMS processes
When the failure has been corrected on the primary, the secondary is taken down and a
script is run to synchronize the primary with the redundant. This is required as the database would have changed since the failure (or may have been completely lost in the first
place).
The solution supports geographic distribution. The redundant unit can be introduced at
any time after the upgrade to 5.5.5 and requires matching hardware to the existing EMS.
As this system is intended to be able to take complete control, equivalent hardware is
required on the standby.
Combined EMS and CDR Platform

EMS and CDR platform can be now combined within one Sun Solaris platform. The two
elements have separate database requirements and Oracle settings have been fine tuned to
achieve the following:
persistence of database required for backup and recovery for EMS
high transaction rate for call load for CDR
Thus, two database instances reside on this combined platform; one for high transaction
rate CDR process and the other for persistent EMS process. Veraz will advise whether a
network topology allows having such a platform depending on call rate and size of
network. For high call rate environment such topology will not be recommended.
73
For upgrades of networks with combined EMS and CDR platform, an additional network
interface card is added to the Solaris platform. This is to ensure that billing function
continues since CDR element is upgraded last of all elements during an upgrade. If an
upgrade does not succeed and roll back is required to previous versions, CDR element is
not affected since it not upgraded with EMS (which is typically upgraded before other
elements). With combined system, the upgrade procedures should assign temporary IP
addresses to the production system, which is still running CDR, and move the original IP
to the interim EMS machine. The EMS on the combined platform will remain shutdown
down and disabled until the final upgrade has been applied with the new release loaded
with up-to-date migrated data.
System and Element Provisioning

ControlSwitch elements are automatically provisioned by the EMS over the IP network to
which the elements are connected. Network-based provisioning ensures that all provisioned information is consistent across all the elements of the ControlSwitch system.
The EMS is database-centric in design. One or more network operators can use a Webbased GUI application to enter all ControlSwitch element data into the EMS database.
This data entry can be done even before the relevant element is installed or operational.
While accepting operator-provided input, the EMS ensures that:
Data is correctly formatted, e.g. IP addresses, and phone numbers and point codes
are correctly formatted.
Data values are valid, e.g. duplicate port numbers are not assigned on the same IP
address to two different entities, network element identifiers are unique for a category of network elements.
Only those data changes that can be made effective in the system immediately are
accepted. This ensures that the data recorded in the database and the data shown
by the GUI accurately reflects what is provisioned in the system.
As each element is switched on it attempts to contact the EMS over the IP network to
register itself. After registration has been achieved the EMS transmits the relevant information that must be provisioned into the element for its proper operation.
During the operation of the system, changes to the element's provisioned information are
communicated to the element to maintain this information in an updated state. These
changes could occur either by operator-initiated actions or by other events on the system
such as element failure and consequent fail-over.
74
User Management: Privileges, Actions, Roles

The EMS allows users with appropriate privileges to:
Create new operator accounts and maintain them.
Assign privileges to operators
View the audit log information.
View currently connected user sessions.
The privileges are assigned to operators using a scheme based on Privilege Levels,
Actions and Roles:
A Privilege Level defines the broad scope of an operator's level of access.
Actions and Roles enable an administrator to further fine-tune what an operator

can do within the Privilege Level.
A user can be assigned only one Privilege Level. Privilege Levels are pre-defined and
fixed in the ControlSwitch EMS. An operator cannot modify Privilege Levels. The
following are currently available privilege levels:
Administrative. This level provides access to all the functions of the EMS.
Query. This level provides read-only access to the EMS.
Standard. This level allows the user to perform reads and writes. This level covers
all configuration capabilities. Certain actions, though, such as LOCK and
UNLOCK of elements and START and SHUTDOWN of elements are not available unless assigned by defining further Actions and Roles.
Actions are pre-defined actions that the EMS allows authorized users to perform. The
complete set of actions is listed in a following section. Actions include the LOCK,
UNLOCK, START, SHUTDOWN and FAILBACK actions on different ControlSwitch
elements.
A Role is a grouping of Actions. A user with Administrative Privilege Level can create
new groupings of Actions to define new Roles. Roles can then be granted to individual
users who will then be able to perform the Actions grouped in the various Roles.
Roles operate within the scope of a Privilege Level. For instance, Query level users cannot
be granted Roles that allow writes. Only a pre-defined set of Menu Access Roles can be
granted to Query level users. For example, this can be done to restrict read-only access to
only certain GUI menu items. (See section on GUI menu access control for more details)
As another example, a Standard Privilege Level user can be granted Roles that allow him
to perform the LOCK, UNLOCK, START, SHUTDOWN and FAILBACK actions.
However, he cannot be given the ability to create users and to assign them privileges. Only
Administrative level users can carry out these capabilities.
Roles have no significance for Administrative users, since these have unrestricted privileges and can do everything that is available in the EMS.
75
User Management
The system offers the Administrative user the capability to create new operator accounts
as well as to deactivate operator accounts. Once deactivated accounts do not have the privilege to administer or view the EMS application unless reactivated by an Administrative
account. Any operator/user can change their password.
When an Administrative user creates an operator account, it is assigned one of the three
privilege levels: Administrative, Query or Standard, as well as one or more Roles. The
rights of these privilege levels are pre-defined in the EMS database and are not modifiable. A particular operator/user account's privileges can however be further fine-tuned by
granting roles to it as described above. An account's Roles and Privilege Levels can be
changed at any time by an Administrative user and take effect on the next user session.
EMS GUI Menu Access Control

There is one Menu Access Role per top-level menu item in the EMS GUI. Hence there are
Roles for access to:
Network Elements menu item and its sub-items
Routing menu item and its sub-items
Fault and Diagnostics menu item and its sub-items
Performance and Reports menu item and its sub-items
A Query or Standard account can be given access to these GUI menu items by assigning
the appropriate menu access Role. If a user is not assigned a given menu access Role, then
the corresponding menu item and its sub-items will be grayed out and inaccessible for that
user.
Role Management
The Administrative user can create new roles by grouping together actions (see table of
actions). These roles are a convenient way of assigning a group of privileges to a user.
Query users are restricted to menu access roles by the EMS application. The Standard user
also has to be granted menu access roles for GUI menu items to which he is to be allowed
access. Once granted access to GUI menu items, the Standard user can only perform
LOCK, UNLOCK, START and SHUTDOWN etc. actions for which he has been granted
privileges. In addition, he can perform all read and write operations needed for provisioning.
76
Audit Log
Audit Log
The EMS has the ability to audit predefined critical actions such as Startup/Shutdown/
Lock/Unlock requests for various network elements. The audit log indicates for the logged
action, the application user id and the Oracle user id that performed the action, the object
on which the action was performed (e.g. CCP, trunk group, Media Gateway) and the time
of the action. The Oracle user id and application user id would be the same for GUI users.
However, in future, application users may be different from the Oracle user if an application server logs into the Oracle database and provides a given Oracle session to multiple
application users. The table at the end of this section indicates which actions are logged.
Currently Logged in Users

The EMS also allows a user to see the currently logged in users. It displays the user id and
the time of log in for each user. The operator can query for users of a specific privilege
level.
Security Management
Secure Shell
All Veraz ControlSwitch platforms support Secure Shell. Secure Shell encrypts shellbased interactions between two platforms. It requires that the user invoke Secure Shell
commands instead of standard UNIX commands for remote operations such as telnet, rsh
and rcp. Secure Shell commands are used in ControlSwitch installation scripts, EMS's
OMNI provisioning module MML HANDLER and OMNI peer-to-peer interaction for
configuration exchange. Secure Shell requires authentication keys to be configured on
each platform that uses Secure Shell. ControlSwitch installation provides for the configuration of these authentication keys.
Currently, SSH Version 1.0 is qualified with the ControlSwitch. Please contact Veraz
Networks for support of other versions.
DS0 Level Management

The user can perform the following management operations at DS0 level granularity:
Forced and graceful locks and unlocks on DS0s that belong to ISUP trunk groups.
Forced locks cause the CCE to immediately force a release on ongoing calls on
the selected DS0s and take them out of service. Graceful locks cause the CCE to
wait till a call is released before taking the DS0s out of service. Unlocks make
DS0s available for service.
77
Resets and combined reset and lock operations on DS0s that belong to ISUP trunk
groups. The reset operation causes the CCE to immediately bring the selected
DS0s into the Active Idle state in which they are available for new calls. This may
involve immediately releasing any calls that may be going on the DS0s when the
reset operation was performed. This operation allows the operator to force the
DS0 out of a bad state. When the user requests a combined reset and lock operation the EMS follows the completion of a reset operation with a lock request to the
CCE.
On the fly assignment and unassignment of a range of DS0s from ISUP trunk
groups.
To perform locks, unlocks and resets the user selects a trunk group first. Within the trunk
group the user specifies the media gateway, card, span and, within the span, the range of
DS0s on which he desires to perform the operation. The EMS places the selected DS0s in
a transient administrative state and then submits the request to the CCE. For ISUP trunk
groups, the CCE performs circuit group block, unblock and reset operations (for lock,
unlock and reset respectively) on the corresponding CICs. Once these operations are
complete the active CCE reports completion to the EMS, which updates the administrative
state of the DS0s accordingly. For lock and unlock operations the final administrative state
of the DS0s is LOCKED and UNLOCKED respectively. The reset operation also results
in an UNLOCKED state.
The state of the DS0s in the standby CCE is kept in sync with the active one.
Fault Management
ControlSwitch elements report fault conditions to the EMS by raising alarms. The EMS,
in turn, reports these alarms on its GUI in a pending alarm view and allows the operator to
take actions on them. ControlSwitch elements also report informational events to the
EMS. These events are not necessarily indicative of faults and are not reported in the
pending alarm view. Instead, they can be observed in the event history view (also called
alarm history view). This view displays all the current and past events and alarms of all
types. By separating the pending alarm view from the overall event history view it
becomes possible for the operator to focus only on the pending alarm view for events
requiring his action. In the process of investigating a fault he can refer to the event history
view for information about other occurrences in the system when the fault occurred.
When a fault condition no longer exists on a ControlSwitch element it sends an alarmclearing event to the EMS. The EMS clears the corresponding alarm or alarms from the
pending alarm view. Hence, the operator is ensured that he is only looking at existing
problems in the pending alarm view.
If needed, the operator can also manually clear an alarm.
The following sections provide additional information about this Fault Management.
Fault management has been enhanced by the addition of the following features:
78
Alarm Severities
Alarm Severities
The EMS supports five alarm severities: Critical, Major, Minor, Warning and Informational.
The Critical severity level indicates that service has stopped and immediate
corrective action is required
The Major severity level indicates that a service affecting problem has developed
that could stop service if not addressed immediately
The Minor severity level indicates the existence of a non-service affecting fault
condition and that corrective action should be taken in order to prevent a more
serious fault
The Warning severity level indicates Detection of a potential or impending

service affecting fault before any significant effects have been felt. Action should
be taken to further
The Informational severity level is not treated as a fault and informational events
are not displayed in the pending alarm view. The severity is unknown but the
alarm is significant for it to be logged for the operator's information
Pending Alarm View

The operator is provided with a view of the current outstanding alarms. The following
information about alarms is displayed to the user in this view:
Alarm Severity
Derived Alarm Indicator to show the operator that the given alarm is generated to
summarize multiple alarms.
Time when the alarm is reported to the system.
Name of the alarm
The fully distinguished name of the element having the problem.
The type of the element having the problem
Fully distinguished name of the element reporting the alarm. Note that this can be
different from the element having the problem.
The type of the element raising the alarm.
Additional alarm content to give the operator more information about the probable
cause of the alarm
The operator can obtain further details about a selected alarm. These include
Acknowledged or Un-acknowledged status of the alarm.
Action history. This shows the history of operator actions performed by the operator on the given alarm
79
Operator Actions
The operator can take actions on alarms including
Acknowledge alarms
Un-acknowledge alarms
Clear alarms
Add comments to alarms
The operator acknowledges an alarm to indicate to other users that he is looking into the
problem. While acknowledging the alarm he can add comments to record additional information. An acknowledged alarm can be unacknowledged. Comments can be recorded
while un-acknowledging an alarm.
The operator can clear an alarm to indicate that the problem has been resolved and record
comments at this stage as well.
The operator can simply add comments to an alarm without taking any other action.
For all these actions the time of the action, the operator's login ID, the action and
comments, if any, are logged by the EMS. These are available in the action history per
alarm as mentioned in the previous section.
Alarms Aggregation
In some cases where the number of raised alarms for a given fault can be large the EMS
generates a single derived alarm in the pending alarms view to represent a large number of
actually raised alarms. For instance, alarms reported at the D-link granularity are
promoted to the media gateway level. Hence, if a large number of D-links generates an
alarm the EMS shows only one alarm of that type per media gateway containing the Dlinks. This reduces the number of pending alarms in the pending alarm view by a significant factor. A derived alarm is represented by a special icon on the GUI. The operator can
drill down into the derived alarm and see the actual more granular alarms that correspond
to the derived alarm.
A derived alarm is cleared when all its constituent alarms are cleared.
Alarm Filtering and Sorting

The operator can filter the set of outstanding alarms by specifying filtering criteria. Only
alarms meeting his filter criteria are then shown to the operator. Any new alarms are only
propagated to the operator if they meet his filtering criteria. Alarms can be filtered by the
following criteria or a combination of these. The combination results in an AND-ing of the
individual criteria.
710
Derived - The operator can choose to only view derived alarms, all except derived
alarms, or simply all alarms. Subsequent criteria apply to the alarms that meet the
setting of this criterion
Operator Settable Alarm Properties
Name - The name of the alarm
Severity
Acknowledged, Un-acknowledged or both
Alarm text
Time range within which the alarm occurred
The type, name, or IP address of the alarm source or the resource on which the
alarm occurred
Alarms fetched into the GUI can be sorted by any of the alarm attributes shown in
the pending alarm view.
Operator Settable Alarm Properties

The operator is provided a view through which he can see the currently defined alarms in
the system. The operator is allowed to modify the following properties of an alarm
Severity. The operator can change the severity of a given alarm type. For instance,
an alarm of Critical severity can be made a Major alarm. These definition changes
apply to all outstanding alarms of that type. The operator's pending alarm view is
not updated automatically, however. The change is effective on any new pending
alarm views launched from the GUI. An Informational alarm cannot be promoted
in severity.
Logging. The operator can decide not to log and report a give alarm type. When
this is done, newly generated alarms of that type are neither logged nor reported
by the EMS in its pending alarm view.
Trap forwarding. The EMS forwards all alarms as SNMP traps on its northbound
SNMP interface. The operator can turn off trap forwarding for given types of
alarms.
Name. The operator can modify the name of an alarm.
Alarm History View

The alarm or event history view displays all the current and past events and alarms of all
types. This view proves useful when the operator wants to determine the time of a particular event or the order of a set of events in the past. For example, he may use event history
to see when a given element was started. The alarm attributes displayed in this view are
the same as those displayed in the pending alarms view.
This view can be automatically refreshed if desired. Additionally, the operator can apply a
filter to this view to only see events meeting the specified criteria. The set of criteria available for filtering are the same as those mentioned above for the pending alarm view.
711
Email Notification for Alarms

Email notification can be sent to a configured email address when an alarm is raised on the
system. Certain files on the EMS platform need configuration for doing so. The email sent
will include following details of the alarm:
Log Id
Event Time
Event Name
Event Severity
Source (Type, FDN, Name, Hostname, IP Address)
Reported (Type, FDN, Name, Hostname, IP Address)
Additional Text
Event Content
The operator should ensure that the SMTP server is reachable from EMS. Necessary
routes should be added if the SMTP server is not reachable. The alarms trigger can be set
for any of the above parameters. The default configuration file is configured for email to
be sent based on alarm severity.
Element Status View

An element status view is provided in which all the ControlSwitch elements including
EMS, CCPs, SGs, PEs, ECs, CDR Managers, ICEs and Media Gateways are displayed
along with the following attributes:
Highest severity level of all pending alarms on the element
The Operational State of the element
The Admin State of the element
The Control Status of the element indicating whether the element has been manually shut down or not
The count of currently pending alarms of each severity further grouped by how
many of each severity are acknowledged and how many are not acknowledged
Host or platform information about the element such as its primary and secondary
IP address
For the EMS, PE and CCP a drill down capability is provided which allows the operator to
view the status of entities contained within these higher-level entities. For the EMS, the
drill down provides the status of individual EMS processes such as the MML Handler, the
SNMP Manager and the EMS core; for the PE the drill down provides the status of its
database links for replication; and for the CCP the drill down provides the status of individual CCEs configured on the CCP.
712
Test Call
Test Call
Test call support allows the operator the ability to place an on demand test call from the
EMS GUI. This is effectively an inverted call setup between 2 endpoints for the purposes
of operational testing of a given circuit or trunk group.
Through the GUI, the operator can select the trunk groups that are to be used to place the
call in both directions as well as call related parameters to be signaled out each side.
Once a test call is complete, the operator may directly view a call trace of the associated
messages and end result.
CDRs will be generated as normal however will be marked as Test Call.
The operator may also receive test calls from an ISUP network. In this case, normal
routing is used to determine the destination and the CDR is marked accordingly.
Supported Protocols
The following protocols are currently supported for test call;
ISUP to ISUP
SIP to ISUP
ISUP to SIP
The target functionality with this capability is primarily to use a SIP based test head to
connect a test based call to a far end switch operator over ISUP. Alternately, it can be used
to place a call between two ISUP based trunk groups.
Signaled Parameters
Through the GUI, the operator can select the following parameters;
Signaling Permutation
Trunk Group for each associated endpoint
Phone numbers to be used for presentation to each side
Circuit Id Code (CIC) if applicable
File definition for other signaled parameters
All other signaled parameters can be modified via an XML definition file.
When placed, for ISUP trunk groups, the call type will reflect test call.
713
Performance Management
Performance management capabilities of the EMS consist of:
Periodic monitoring of statistics
Reports
The data collected for the above statistics and reports is derived from the following
sources:
CDR: Scheduled jobs that, typically nightly, extract data from the CDR database
for certain reports. CDR data is also used for some live reports that report real
time data.
DAS and DCA mechanism: DAS is Data Analysis Server that resides on the EMS
platform. It receives data collected by DCA Data Collection Agent, a process that
is attached to Network Elements like the Call Control Platform, Policy element or
Event Collector. The DAS collects the raw data from the DCA and as necessary
performs calculations and logs the data into the database. e.g. for ASR Reports
(Answer to Seizure Ratio), DAS receives number of Answered calls and
Attempted calls; it performs the calculation to derive ASR from this data.
Periodic Monitoring
At a configurable frequency, which can be changed on the fly, network elements report the
following kinds of statistics to the EMS:
CPU utilization
Call Statistics seen for both Trunk Groups and for Span level
Failed Call Statistics for both Trunk Groups and Span Level
OMNI statistics
For the latter two categories, at the beginning of every reporting interval all counts are
reset to zero by the reporting network elements. At the end of the reporting interval, the
new counts are reported to the EMS and reset again for the next interval. The EMS logs
these statistics to its database. The user can observe these using the GUI, which refreshes
itself to show updated statistics every reporting period. The EMS periodically purges this
data from the database.
CPU Utilization
Percentage CPU utilization is reported periodically by all processes. These processes use a
UNIX system call to obtain the utilization. The EMS reports this data for CCP, PE, EC,
CDR and SS7 Gateway. When multiple elements are running on the same platform, the
reported utilization is the overall utilization of the platform, not the percentage of the CPU
used by the individual elements. The data shown on the CPU Utilization Reports and
Statistics is processed by the DAS and DCA framework.
714
Periodic Monitoring
The user can select the elements for whose platforms he wants to observe CPU utilization.
By default, data for all network elements of the above-mentioned types is shown.
Total Call Statistics at Trunk Group Level
The user can select the trunk groups for which he wants to observe periodic call summary
statistics. By default the latest counts from all trunk groups will be shown. The counts
include the following:
Reporting time
Completed calls
Attempted calls
Terminated calls
Abandoned calls
Overflow calls
Failed calls
Maximum busy DS0s on the trunk group over the reporting interval
Total Call Statistics at Span level

The user can select the span or a span list for which he wants to observe periodic call
summary statistics. Span list is a user-defined collection of spans that are often queried.
The counts in the span level statistics include the following:
Originated, Completed and Terminated Incoming calls
Originated, Completed and Terminated Outgoing calls
Abandoned Calls
Failed Calls
ACD (Average Call Duration)
Incoming and Outgoing ASR (Answer Seizure Ratio)

Failed Call Summary at Trunk Group level
Failed call summary statistics give a breakdown, by reason of failure, of the failed calls
count mentioned above. There are up to fourteen possible failure reasons that are reported:
User Busy
No Answer
No Circuit Available
No Route to Destination
Circuit Group Congestion
715
Continuity Failure
Unallocated Number
No User Responding
Call Rejected
Resource Unavailable
Bearer Capability Not Available
Bearer Capability Not Implemented
Recovery on Timer Expiry
Other Reasons
Failed Call Summary at Span Level

The user can select the span and the Media Gateway for which he wants to observe periodic call failure statistics. The list of reasons for failure is the same as in the previous
section.
OMNI Statistics
The EMS provides the means for the operator to examine the performance data from
OMNI. OMNI collects this data over several minute intervals. The operator can request
for the following types of statistics:
TCAP
ISUP
SCCP
MTP
The operator can specify the time period of interest. The EMS will get the requested statistics, store them temporarily in a table and display them through the GUI.
Reports
The EMS offers two formats of reports - user requested .pdf format reports, and automatic
text based reports.
The EMS provides the user the ability to obtain the following reports:
716
Call Attempts by Direction
Abandoned and Overflowed Call Attempts
Call Setup Time
Call Duration
Failed Call Attempts
Reports
Maximum Resource Busy
Busy Hour Call Attempts
Slow Release Trunks
Killer Trunks
Always Busy Trunks
Utilization for CPU, Trunk Groups, and Spans.
All these reports are run on user request. These are not scheduled. However, there are
scheduled jobs that, typically nightly, would extract data from the CDR database for
certain reports. The reports that use nightly CDR reports are Utilization reports based on
Trunk Groups and Spans, and Call Setup Time report. The Slow Release, Killer and
Always busy trunk are live reports and obtain data directly from CDR on user demand.
The remaining reports are obtained from the DAS and DCA mechanism. In all cases the
report output is in the PDF format.
The above list of reports can be both generated at a trunk group level as well as at a span
level. Slow Release Trunks, Killer Trunks and Always Busy Trunks applies only to Trunk
Groups. When span level reports are generated, the parameter used for generation is either
a particular span on a Media Gateway or a pre-defined span-list. A span list is a userdefined collection of spans.
User Requested Reports
Reports can be requested and viewed from the EMS GUI. All these reports are run on user
request. These are not scheduled. However, there are scheduled jobs that, typically
nightly, would extract data from the CDR database for certain reports. The remaining
reports are obtained either from the periodic statistics counts recorded in the EMS database as described in the section above or, in the case of the three abnormal trunk reports,
from the CDR database on user demand. In all cases the report output is in the PDF
format.
Exportable Text Based Reports
The EMS can be configured to provide comma delimited text based traffic reports on a
daily basis. The traffic report is run from EMS every night along with the purge job. It
generates rows of comma-separated information, one for each trunk group.
The following is a list of fields generated for each trunkgroup:
DATE (Date for which the report is run)
TG_ID (Trunk Group ID)
TG_NAME (CLLI Name of the Trunk Group)
ORIGINATED_ATTEMPTS (Number of Originated Call Attempts for the day)
TERMINATED_ATTEMPTS (Number of Terminated Call Attempts for the day)
TOTAL_ATTEMPTS (Total Number of Call Attempts for the day)
717
718
CALLS_ABANDONED (Total number of Abandoned Calls)
CALLS_OVERFLOWED (Total number of Overflowed Calls)
NO_OF_IN_CALLS (Number of Incoming Calls)
MAX_IN_SETUP_TIME (Maximum Call Setup Time for incoming calls)
MIN_IN_SETUP_TIME (Minimum Call Setup Time for incoming calls)
AVG_IN_SETUP_TIME (Average Call Setup Time for incoming calls)
NO_OF_OUT_CALLS (Number of Outgoing Calls)
MAX_OUT_SETUP_TIME (Maximum Call Setup Time for Outgoing Calls)
MIN_OUT_SETUP_TIME, (Minimum Call Setup Time for Outgoing Calls)
AVG_OUT_SETUP_TIME (Average Call Setup Time for Outgoing Calls)
TOT_FAILED_CALLS (Total number of Failed Calls)
FAIL_CALLS_1 (Calls failed due to User Busy)
FAIL_CALLS_2 (Calls failed due to No Answer)
FAIL_CALLS_3 (Calls failed due to No Circuit Available)
FAIL_CALLS_4 (Calls failed due to No route to destination)
FAIL_CALLS_5 (Calls failed due to Circuit Group Congestion)
FAIL_CALLS_6 (Calls failed due to Continuity Failure)
FAIL_CALLS_7 (Calls failed due to Unallocated Number)
FAIL_CALLS_8 (Calls failed due to No user responding (No ACM))
FAIL_CALLS_9 (Calls failed due to Call Rejected)
FAIL_CALLS_10 (Calls failed due to Resource unavailable - unspecified)
FAIL_CALLS_11 (Calls failed due to Bearer capacity not Authorized)
FAIL_CALLS_12 (Calls failed due to Bearer capacity not Implemented)
FAIL_CALLS_13 (Calls failed due to Recovery on timer expiry)
FAIL_CALLS_14 (Calls failed due to Other Reasons)
TOTAL_DS0s (Total Number of DS0s configured)
MAX_BUSY_DS0s (Maximum number of DS0s busy for the day)
BUSIEST_HOUR (Busiest Hour of the Day)
BUSIEST_HOUR_ATTEMPTS (Total Call attempts during the Busiest Hour)
MAX_TG_PERCENT_UTIL (Maximum percentage utilization of the Trunk

Group)
MIN_TG_PERCENT_UTIL (Minimum percentage utilization of the Trunk

Group)
Report Descriptions
AVG_TG_PERCENT_UTIL (Average percentage utilization of the Trunk

Group)
Report Descriptions
The following section outlines each of the reports.
Call Attempts by Direction
This report is based on the periodic statistics recorded in the EMS database. The user specifies the start and end date for the reporting period. The EMS produces a report showing
by day, trunk group by trunk group, total call termination attempts, total call origination
attempts and total call attempts over the reporting period. It also reports these totals across
all trunk groups for each day.
Call Attempts by Direction Report can also be run based on span level instead of Trunk
Group. Both E1 and T1 span can be used as a criterion for generating this report. A span
list can also be used as a criterion.
Abandoned and Overflowed Call Attempts
This report is based on the periodic statistics recorded in the EMS database. The user specifies the start and end date for the reporting period. The EMS produces a report showing,
by day, trunk group by trunk group, total overflow calls and total abandoned calls. It also
reports these totals across all trunk groups for each day.
Abandoned and Overflowed Call Attempts Report can also be run based on span level.
Both E1 and T1 span can be used as a criterion for generating this report. A span list can
also be used as a criterion.
Call Setup Time
This report is based on data that is obtained nightly from the CDR log tables in the CDR
database. The user specifies the start and end date for the reporting period and also if he
wants to group results by trunk group. If the Group by Trunk Group option is not
chosen, the report displays, by day, trunk group by trunk group, the total number of
successful calls; number of successful incoming calls and the maximum, minimum and
average set up time for incoming calls; number of successful outgoing calls and the
maximum, minimum and average set up time for outgoing calls on the trunk group and the
overall average call setup time on the trunk group. It also displays, for the whole day and
across all trunk groups the max, min and average setup times just mentioned.
When the user chooses the Group by Trunk Group option, the report displays for each
trunk group, day by day of the reporting period, the same kind of data as mentioned above.
Since the timestamps of different signaling event messages as recorded in the database are
up to the second, sub-second setup times show up as zero.
Call Setup Time Report can also be run based on span level. Both E1 and T1 span can be
used as a criterion for generating this report.
719
Failed Call Attempts

This report is based on the periodic statistics recorded in the EMS database. The user specifies the start and end date for the reporting period and also if he wants to group result by
trunk group. The EMS produces a report showing, by day, trunk group by trunk group, and
the number of call failures for each of the fourteen reasons mentioned above. It also
reports these totals across all trunk groups for each day.
When the user chooses the Group by Trunk Group option, the report displays for each
trunk group, day by day of the reporting period, the same kind of data as mentioned above.
All cause codes are exposed.
Call Duration
This report is based on the data collected from the DAS and DCA. The user specifies the
start and the end date for the reporting period. Further, a user can specify whether the
report should be generated for Trunk Groups or for Spans. When Span level is used, span
list can be used. Span list is a user pre-defined collection of spans.
When Trunk Group option is chosen, the report displays Trunk Group name, ASR and
ACD for that trunk Group, total number of calls, and the total duration.
Likewise, when span option is chosen with a specific gateway and card (or a span list is
chosen), the report displays the span details and the ACD, ASR, total number of calls and
the call duration associated with it.
Maximum Resource Busy
This report is based on the periodic statistics recorded in the EMS database. The user specifies the start and end date for the reporting period. The EMS produces a report showing,
by day, trunk group by trunk group, total DS0s in the trunk group, max busy DS0s in the
trunk group over the day and the percentage of the total DS0s that the Max DS0s are.
Busy Hour Call Attempts
This report is a derivative of the Call Attempts by Direction report. The user specifies the
start and end date for the reporting period. The EMS produces a report showing, by day,
trunk group by trunk group, the busiest hour of the day and the number of calls made in
that hour. It also shows the busiest hour of the day across all trunk groups.
Slow Release Trunks
This report is based on killer trunk detection performed by the CDR Element. The CDR
Element writes the different kinds of killer trunks out to a table in its database. On user
demand, the EMS retrieves the data from the CDR database to produce a report. The user
specifies the start and end date for the reporting period. The report shows, by day, trunk
group by trunk group, the Media Gateway, Card, Span and channel number of the DS0s
that matched the configured slow release threshold parameters. Total call attempts and
average call duration are shown for each DS0 in the report.
720
Report Descriptions
For slow release trunks, the average call duration threshold must be exceeded for a
number of calls greater than a set threshold. These thresholds are configurable. Change of
thresholds may take several hours to take effect.
Killer Trunks (Quick Release Trunks)
This report is based on killer trunk detection performed by the CDR Element. The CDR
Element writes the different kinds of killer trunks out to a table in its database. On user
demand, the EMS retrieves the data from the CDR database to produce a report. The user
specifies the start and end date for the reporting period. The report shows, by day, trunk
group by trunk group, the Media Gateway, Card, Span and channel number of the DS0s
that matched the configured killer trunk threshold parameters. Total call attempts and
average call duration are shown for each DS0 in the report.
For quick release trunks, the average call duration must be below a set threshold for a
number of calls greater than a set threshold. These thresholds are configurable. Change of
thresholds may take several hours to take effect.
Always Busy Trunks
This is a special case of the Slow Release Trunk. The threshold values are such that over a
set period, there is only one call attempt, and the call duration spans the reporting period.
The input and output of the report are otherwise the same.
Utilization Reports
Utilization reports are based on the periodic recorded statistics. The user specifies the start
and end date for the reporting period. The EMS produces a report showing Utilization by
day (and by hour if specified), maximum, minimum and average. Utilization is shown for
the following:
CPU Utilization Report: This report is based on periodic statistics recorded in the
EMS database. The user can specify time period and network elements for which
the report is required. It also highlights the maximum CPU utilization for the day
and for the report. When the option to group by network element is checked then
each report page shows for one network element CPU utilization by day, and
optionally, by hour within a day.
Trunk Group Utilization Report: This report is based on data that is obtained
nightly from the CDR log tables in the CDR database. The user specifies the start
and end date for the reporting period, whether he wants to have the report hour by
hour within each day and if he wants to group results by trunk group. If the
Group by Trunk Group option is not chosen, the report displays, by day, trunk
group by trunk group, the maximum, minimum and average trunk group utilization in percentage.
If the Group by Trunk Group option is selected without the group by hour
option, then the report shows by trunk group, for each day of the reporting period
721
the max, min and average percentage utilization. The report also highlights the
maximum and minimum utilization across all days of the reporting period.
The by hour and Group by Trunk Group option produces a more detailed
report which for a given trunk group, shows hour by hour, by direction, the total
number of calls in the hour, the total call seconds, and trunk group utilization in
CCS, Erlang and percentage.
Span Utilization: This report is based on data obtained from CDR. The user specifies the start and end date for the reporting period, whether he wants to have the
report hour by hour within each day and if he wants to group results by span list.
If the Span List option is selected by hour option, then the report shows by each
span in that list, for each day of the reporting period the max, min and average
percentage utilization. The report also highlights the maximum and minimum
utilization across all days of the reporting period.
Alarm Summary Report

This report is created every 24 hours. It gives a summary of the following by alarm
severity:
Alarms Raised
Alarms Cleared Automatically
Alarms Cleared Manually (by operator)
Alarms Acknowledged by Operator
This report is only available as a text based report.
Call Tracing
Call tracing on the Call Control Element is supported. The operator is able to trace calls
via the EMS based on one or any combination of the following:
722
CPN
Ingress Trunk Group
Ingress Media Gateway
CPN and DN
Ingress trunk group and DN
Ingress Media Gateway and DN
DN
Card, Span and Media Gateway
Oracle DB Space Monitoring and Disk Usage Monitoring
Both the CPN-based trace and the DN-based trace are broadcast to all CCEs in the system.
Either exact match or a prefix of the CPN or DN can be used as a criterion for tracing a
call. Any CPN or DN can be specified. One consequence to be aware of is that since the
CPN and DN based traces are placed on all CCEs, they limit the maximum number of total
trace criteria that can be active on an element at the same time. In other words, if the
maximum number of allowed trace criteria is set to ten then the operator would not be able
to place additional trace requests if ten CPN- or DN- based traces are active system wide.
The user can set the maximum call traces criteria permitted per ControlSwitch element by
assigning the appropriate value to the MAX_CALL_TRACE_PER_NE Application
Parameter. This can be accessed from the EMS GUIs Administration/Application Parameter menu item. The operator has the ability to view active calls via the EMS, including
viewing TDM trunk groups and various call parameters. For CPN and DN based traces
the user is allowed to specify ingress CCP or Gatekeeper. This can be used to limit the
number of trace criteria active in the system.
Additionally, spans can be selected as a criterion for call trace when Media Gateway is
chosen for tracing. The user starting the call trace can choose Media Gateway, card and
span.
Oracle DB Space Monitoring and Disk Usage Monitoring

The Veraz ControlSwitch has elements that use the Oracle database. The ControlSwitch
supports monitoring of the space utilization of Oracle database objects on the following
database platforms
EMS
CDR
The ControlSwitch monitors and generates various severities of alarms (minor, major and
critical) when applicable thresholds are reached. It monitors the database segments, Oracle
table space, and Oracle disk space usage.
Oracle extents monitoring
Oracle internally allocates space in extents for each object like table and index and also
has a maximum number of extents for each object. When an object grows and nears its
maximum extents, alarms are raised and once the problem is taken care of, a clearing
alarm is sent. The default low threshold is set to 70% and high threshold is set to 85%.
Total disk space taken by a tablespace
Oracle has physical .dbf files, which are the space holders for all objects. A table-space is
a logical entity for holding objects. When this table-space grows significantly occupying
more than the threshold percentage of the physical file, alarms are raised. Again, these
alarms are cleared, once that percentage comes below the threshold. Default low threshold
is set to 70% and high threshold is set to 85%.
723
Total disk space taken by physical data files

The physical file that holds the data can grow out of proportion and fill up Unix disk
space. ODMON also monitors this Unix file system usage and raises alarms indicating the
file name when one or more files grow up taking more than the threshold percentage of a
Unix file system like /u01, /u02, /u03 etc. As in other cases, alarms are cleared once the
percentage comes below the threshold. Default low threshold is set to 70% and high
threshold is set to 85%.
Oracle Database Backup and Recovery
The Veraz ControlSwitch system uses Oracle database management software to store data
on EMS, PE, EC and CDR, since these elements need a database backup method to
backup all the data files to ensure the data integrity. The backup/recovery software
supports the following types of backup that Oracle database system offers to backup the
database to disk location.
Hot backup
Taken while the database is open.
More traditional and popular backup method for online backup.
Cold backup
Taken while database is close by shutting down the database.
Also known as Offline backup.
RMAN backup (Oracle Recovery Manager backup)
Taken when the database is open.
Takes up less space compared to hot backup/cold backup and is a recent addition to oracle database backup methods.
Archive log backup
Only backs up archived log files. (Veraz ControlSwitch HOT and RMAN
backups also backup all the archive log files, so this is optional)
The backup can be run manually or scheduled as UNIX cron jobs through an EMS menu
driven interface. It is highly recommended that online backups for EMS and PE databases
are performed on a regular basis (as often as daily) and cold backups performed before
major upgrades to the elements.
System Logs Enhancements

The Solaris operating system uses syslog functionality to log OS and application level
messages with various severity into the system log files, typically in /var/adm/messages
files.
724
SNMP Northbound Interface
All the ControlSwitch network elements send the system logs through setting of syslog
daemon running on each Solaris platform to the EMS. A server process 'syslogmgr'
running the ControlSwitch EMS logs all the system logs as alarms or info events based
upon the severity of each log message into the EMS alarms database which can viewed by
the FMS.
The Syslog manager allows configuring only the interested messages to be put into the
EMS alarms tables. The Operator can put these messages with a pattern into the
'syslogmgr.cfg' file.
SNMP Northbound Interface

One of the modules in the EMS is the SNMP agent. This agent allows SNMP managers
such as HP Openview to perform SNMP management operations on the EMS and hence
the ControlSwitch.
The EMS MIB is an SNMP-V2 MIB that exposes ControlSwitch configuration and operational and administrative states to SNMP managers. Only read access is provided through
the SNMP interface. Configuration and control operations are not supported. Simultaneous access by multiple SNMP managers is supported.
The agent forwards all alarms received by the EMS from ControlSwitch elements as
SNMP traps to SNMP managers. All traps of critical and major severity received from
media gateways are also forwarded. The agent allows multiple managers to register for
traps. A manager can also request the agent to send traps received in the last 24 hours.
SNMP Management of Media Gateways

The EMS has the capability to act as an SNMP manager for media gateways. It has the
following SNMP management features:
MIB browsing. This allows a user to select a media gateway from the EMS GUI
and read any attribute in the gateway's SNMP MIB. This capability exists for all
the gateways supported by the Veraz ControlSwitch. SNMPv1 and SNMPv2
MIBs are both supported.
Trap receiving. Through the EMS GUI, the user can ask the EMS to register with a media
gateway to receive traps generated by the media gateway. The EMS is pre-configured to
recognize most traps that are deemed useful. For the MGX 8260, a user may also select for
the EMS to receive traps of only certain categories. The EMS provides a separate screen
for viewing media gateway traps. Critical and major traps received from the gateway are
also reported as generic media gateway alarms on the EMS alarm screen. Trap receiving
support exists for all the gateways supported by the Veraz ControlSwitch.
725
Event Relay Server

The Event Relay Server (ERS) is a software module that is loaded on the ControlSwitch.
It allows third-party applications - Event Monitoring Agents (EMA) to subscribe to and
receive call related events over a TCP connection. Multiple EMAs can subscribe to a
receive events. All events are encoded in XML
This functionality is typically deployed with back office traffic monitoring systems that
want to track real time call status. Alternately, this application can also be used by operators wishing to record traffic patterns in real-time.
ERS mainly interacts with two main elements, EC and EMA. The general mechanism of
interaction and processing among these three elements is the following. As the calls are
processed by the ControlSwitch, EC collects these call events and persists them in a
specific location for ERS. ERS picks up the events, formats and filters the event contents,
sends the events to the EMA client and marks the events as consumed. EC will later clean
up the consumed events.
Figure 7-1: System Block Diagram
ERS process resides on the generic platform process called ControlSwitch Platform
(CSP). CSP is generic software process CSP (ControlSwitch Platform) introduced in
release 5.5.3. This generic platform also houses ICE (IP Call Control Element) and
LIDAP (Lawful Intercept) processes. In future, all ControlSwitch processes will reside on
CSP
726
Event Relay Server
Supported Events
The following events are currently supported:
Call Setup
Connect/Answer
Release
Release Complete
Checkpoint for long duration calls
Audio Packet Stats
Charge Message Indicator
Service Event
All associated messages received in the signaled messages are encapsulated in the event.
The ERS is supported for all ingress signaling protocols - ISUP, CAS, PRI, H.323, SIP
Message Structure
The following gives an example of an event from the ERS. This example is from a PRI
Release message.
<Event From="CCE" To="CEC" label="REL_RLC_PCA" Class="Operational"
version="5300">
<CecId label="CECId" version="4">
<word32 label="Id" value="1"/>
</CecId>
<GlobalCallId label="GlobalCallId" version="4">
<ByteArray label="GlobalCallId" value=" 34 23 65 92 45"/>
</GlobalCallId>
<NetworkElementType label="NetworkElementType" version="800">
<Enum label="TypeId" value="EC"/>
</NetworkElementType>
<NetworkElementId label="NetworkElementId" version="4">
<word32 label="NetworkElementId" value="1"/>
</NetworkElementId>
<DirectionIndicator label="Direction" version="720">
<Enum label="Value" value="Ingress"/>
</DirectionIndicator>
<CcpId label="CCPId" version="4">
<word32 label="CcpId" value="1"/>
</CcpId>
<EventTime label="SendTime" version="4">
<word32 label="Secs" value="39030"/>
727
<word32 label="Nsecs" value="39030000"/>

</EventTime>
<EventTime label="TimeRELReceived" version="4">
</EventTime>
<EventTime label="TimeRLCSent" version="4">
</EventTime>
<CauseValue label="CauseValue" version="4">
<boolean label="Present" value="1"/>
<Enum label="CauseValue" value="NoRouteToDestination"/>
<Enum label="GeneralLocation" value="LocalPrivateNetwork"/>
<Enum label="CodingStd" value="ANSI"/>
<Enum label="CauseValueClass" value="NormalEvent"/>
<byte label="Diagnostic" value="237"/>
</CauseValue>
<PhysicalChannelId label="PhyChanId" version="700">
<word32 label="GatewayNum" value="3"/>
<word32 label="CardNum" value="17"/>
<word32 label="SpanGroupNum" value="1"/>
<word32 label="SpanNum" value="16"/>
<word32 label="ChannelNum" value="1"/>
</PhysicalChannelId>
<PriDChannelId label="PriDChanId" version="5">
<word64 label="Pridcid" value="62929492"/>
</PriDChannelId>
<PSTCallId label="PriCallRef" version="4">
<word16 label="PstCallId" value="27403"/>
</PSTCallId>
<InternalCauseCode label="InternalCauseCode" version="820">
<Enum label="SubsystemId" value="ICA"/>
<Enum label="CauseCode" value="EndpointUnknown"/>
</InternalCauseCode>
<Word64Value label="Sequence" version="4">
<word64 label="Value" value="64000"/>
</Word64Value>
</Event>
728
PL/SQL API for Third Party Management Control
ERS Scaling
The ERS is a software element of the ControlSwitch and is modular like all processes on
the product. Installation of the ERS is a function of network call volume and platform
sizing is in accordance with network load. For small installations, the ERS can be installed
on the same hardware as the ECs. For larger installations, the ERS will be installed on it's
own separate hardware.
Automated Provisioning
PL/SQL API for Third Party Management Control
The EMS exposes a PL/SQL API to enable the operator to perform automated configuration of the EMS through an external application. The PL/SQL API consists of groups of
PL/SQL stored procedures. These stored procedures provide the same configuration functions that are available through the EMS GUI. Using this API an application can configure
ControlSwitch elements such as CCP, PE and EC in the EMS database. It can also
configure trunk groups and all the routing policies.
For more information on the PL/SQL API, please contact Veraz Networks.
Routing Bulk Provisioning Feature

Bulk provisioning enhancements in Release 5.5.5 provides an efficient way to reduce
routing data loading time when provisioning Policy Engine. This feature will reduce data
loading time by replacing current policy data with new data provided in an excel file. The
data in the policy engine will have fields that can be easily translated to excel spreadsheets
like delimiters used in the spreadsheet or a csv file.
To achieve quicker provisioning, profiles can be created on the EMS GUI. Profiles
comprise rules that represent repetitive patterns in the routing policy. For example,
Rule 1: If CPN begins with <CPNPrefix>
Rule 2: If NatureOfAddress = <NOA>
Rule 3:
Route using <EgressTrunkGroupA>
Rule 4: Else
Rule 5:
Reject using <ReleaseCause>
Another example:
As per the below diagram, rules are divided into four profiles. Profile1 is the main profile
representing a record in excel file. Profile 2 to profile 4 are else profiles which have
different reject cause codes associated and should be repeated for each record of profile1.
729
There are two types of routing profiles: MAIN Profile and ELSE Profile. Routing profiles
are similar to a policy type as in prior releases. Each routing profile contains rules structure with the order of execution.
Different profiles may be combined together to create a profile group. Routing policy
must be created as of type advanced or of type profile group. When it is of type profile
group, all rules in a policy must adhere to structure defined in one of the profile in that
profile group.
This will also be quite useful for generating an excel file from a policy data.
Figure 7-2: Profile Group Example
The GUI for a specific profile shown below illustrates another example when
730
an ATP (Access Transport Parameter) is matched to a string
no else rule is used
column number for the data in excel spreadsheet is 4
delimiter is a space
Routing Bulk Provisioning Feature
Figure 7-3: Routable Parameters Screen
731
732
SS7 Services
Chapter 8
This chapter describes SS7 services. The following topics are included in this chapter:
Overview
SS7 Services
SS7 IN Services - North America
SS7 INAP Services
Supported Variants and Limitations
81
Chapter 8: SS7 Services
Overview
Beginning in release 5.4, the ControlSwitch supports an SS7 framework. The SS7 framework is essentially an XML front end that allows for complete customization of all ISUP
and TCAP parameters. This includes adding additional messages to the protocol and
defining the logic for interpretation/handling. Using the SS7 framework, the
ControlSwitch can be customized to any local country variant, internal carrier specific
variant, or legacy switch variant. This in turns means rapid time to market with new
feature as well as entry to new markets.
All logic is built in the XML framework and compiled into runtime code. The
ControlSwitch does not use a text interpreter for the logic hence ensuring maximum
performance. Using the framework, messages can be defined, modified, abstracted to
routing and policy logic, and abstracted to billing.
This unique ControlSwitch capability reduces customization cycle time from months to
weeks. Furthermore, as the framework is de-coupled from the core elements, the level of
risk involved in introducing new features and the associated required testing is minimized.
SS7 Services
SS7 MTP Level 2
MTP Level 2 is equivalent to the OSI Data Link Layer, ensuring accurate end-to-end
transmission of a message across a signaling link. MTP Level 2 implements flow control,
message sequence validation, and error checking. When an error occurs on a signaling
link, the message (or set of messages) is retransmitted.
Within the ControlSwitch, MTP 2 is implemented on the Signaling Gateway using the
Ulticom or Telesys SS7 stack depending on the SG variant. MTP 2 is co-processed by an
signaling card, reducing the burden of running this part of the protocol stack on the
Signaling Gateway.
The ControlSwitch has received Illuminet certification for MTP Level 2 and has been
Telcordia tested.
SS7 MTP Level 3

MTP Level 3 is equivalent in function to the OSI Network Layer. MTP Level 3 provides
message routing between signaling points in the SS7 network. The routing label is
comprised of the destination point code (DPC), originating point code (OPC), and
signaling link selection (SLS) field. When the destination point code in a message indicates the receiving signaling point, the message is distributed to the appropriate user part
(e.g., ISUP or SCCP) depending on whether the message is ISUP or TCAP.
82
SS7 ISUP
Multiple CCEs can have the same point code, allowing a single SG to support multiple
CCEs.
Within the ControlSwitch, MTP 3 is implemented on the Signaling Gateway using the
Ulticom or Telesys SS7 stack. MTP 3 is co-processed by the signaling card, reducing the
burden of running this part of the protocol stack on the Signaling Gateway.
The ControlSwitch has received Illuminet certification for MTP Level 3 and has been
Telcordia tested.
SS7 ISUP
The following Telcordia specifications cover the primary aspects of ANSI ISUP of the
ControlSwitch ISUP interface for toll/tandem applications:
GR-246 base specification
GR-905
GR-317
GR-394
The ControlSwitch supports ETSI ISUP v2 based upon the following specifications as
required for the services supported:
ETSI ETS 300 356-1 ed.1,
ITU-T Q.761
ITU-T Q.762
ITU-T Q.763
ITU-T Q.764
Standard functionality that is supported includes normal call processing flows, standard
and non-standard release conditions and their associated release codes, inbound and
outbound loop back continuity tests (COT), inbound and outbound transponder COT tests.
For more detailed compliance information, please contact Veraz Networks.
Protocol support for ISUP is provided on the Signaling Gateway of the ControlSwitch.
ISUP processing is divided into two parts:
Raw message reception and delivery - performed by the SS7 stack.
Call processing of ISUP messages, including state machine and timers performed by Veraz software.
ISUP messages arriving at the Signaling Gateway are dispatched from the stack to Veraz
components, where they are applied to the call processing application.
The ControlSwitch supports multiple interface cards with varying number of links per
card. Each SG can support multiple cards hence allowing the SG to scale to support many
SS7 links. The traffic handling capacity per link is around 25 to 35 calls per second - this
limitation is imposed by the bandwidth on each link (48, 56 or 64 kb/s).
83
The Signaling Gateway supports redundant A-links, E-links or F-links on its primarysecondary pair. In the case of F-links, a separate digital cross connect is required to peel
the bearer traffic from the signaling traffic (bearer traffic cannot be processed by the
Ulticom cards). Traffic from the adjacent node is dispatched to the Signaling Gateway on
both the links uniformly. The signaling gateway ensures that the traffic arriving on the two
links is consolidated prior to be used for call processing. When one of the links is taken
down, a backward message is delivered by the active link to the adjacent node, upon
receipt of which the node starts sending all of the traffic on the active link. The Signaling
Gateway is tolerant of outages on either the primary or the secondary sets of links (pulling
of cable, etc.). An outage on both sets of links at the same time will take the Signaling
Gateway out of service.
Ulticom SP-4 support
The upgraded Ulticom software SP-4 package will provide enhanced functionality like
scaling of the SS7 network and some SS7 functional enhancements.
SS7 link connectivity will now scale to 1024 signaling links per Signaling Gateway for a
total of 4096 signaling links in a four-CE cluster. A Signaling Gateway can be deployed in
a small-scale configuration, thus minimizing the initial investment in capital equipment
while providing tremendous potential for future growth. As more signaling bandwidth is
required, links and Signaling Gateways can be added as required to meet the increased
demands on the network. Currently, online addition od hardware to Signaling Gateway is
not supported. This will be supported in subsequent release.
Also, SP-4 package has been enhanced to support the handling of messages and parameters that may be unique to country variants of ITU ISUP. Thus, ISUP applications developed as per the ITU standard can easily be adapted to support any number of ITU country
variants.
ISUP Congestion Control Procedures
The Congestion Control Procedures in ISUP make use of Automatic congestion Level
parameter (ACL) in the Release message (REL). ANSI networks define three levels of
congestion, and ETSI networks define 2 levels of congestion.
ControlSwitch supports the following for SS7 congestion control:
Processing of ACL in received Release messages, and setting Congestion states at

a per trunk group level based on the ACL value received.
Regulation of calls origination on egress trunk groups based on the above Congestion level.
Setting of ACL parameters in outgoing Release messages based on the Overload

state of the Control Switch.
When a far end switch sends ACL parameter in a release message to indicate that it is
congested, ControlSwitch marks the trunk group congested with appropriate level on
which it received the ACL parameter. For each congestion level, the operator can provision X% of calls to be suppressed from getting routing out on that trunk group.
84
SS7 ISUP
ControlSwitch sends different ACL values in REL message based on the current CPU
level of the CCP. The default settings are 70% CPU for ACL=1, 75% CPU for ACL=2
and 83% CPU for ACL=3. For example, when the CPU utilization of the CCP goes over
70%, ControlSwitch starts sending ACL parameter with value 1 in subsequent REL
messages.
ATP Parameter Enhancements
The Access Transport Parameter (ATP) in ISUP is used for carrying connected party
information per Q.767 and Q.699 ITU specifications. It has several fields one of which is
Called Party Subaddress. Some carriers use the called party subaddress field of the ATP
parameter to pass on routing information between switches because the ATP parameter
can carry ASCII strings. In this release Veraz ControlSwitch will allow manipulation of
such strings in DA and will make the ATP parameter available to routing GUI.
In DA, the following functions will be provided
Addition of string
Modification of string
Removal of string, before leaving the network since other switches might not need
it or understand it
In routing, the ATP parameter will be available in the rule configuration of the routing
GUI. The embedded string can be used as a parameter to make decision on routing. In a
rule node, an operator can configure a check for embedded string (using the subaddress
field in ATP), and then select the appropriate trunk.
INR/INF Support
Information Request Message and Information Message (INR/INF) provide a mechanism
to query and to negotiate certain call parameters that may not be locally available at a
switch. These parameters include:
Calling party number
Calling party category
Charged party number
Hold (no release) request
Malicious caller identification request
85
Handling INR/INF messages will be implemented only until routing of a call is

completed. In other words, we expect to receive an INR from the succeeding switch before
the first backward message that determines route establishment i.e., ACM, ANM or CPG,
and not after such a message is received. Only one INR will be allowed to propagate at
any given time. If the ControlSwitch does not have all the information requested in the
INR, it will propagate the INR to the preceding switch requesting the information that was
not available locally. A timer (ITU-T T33) will determine the time-out waiting for an INF.
If an INF is received before the timer expires, the ControlSwitch will determine if the
response contains the requested information/parameters, and hence if it would be possible
to continue processing the call. If the INF is a response to an INR that was not originated
by the ControlSwitch, it would be propagated to the next switch along with any other
parameter(s) requested in the INR that were locally available.
Initiation of an INR when necessary from the ControlSwitch is controlled entirely by the
Trunk Group property Request Calling Party Information at Ingress.
The ControlSwitch would initiate an INR when necessary and allowed, upon receiving an
IAM from the preceding switch. If the Trunk Group property is set, an INR is initiated
only if the Calling Party Number parameter in the IAM is unavailable.
The ControlSwitch would not send a call setup message to the succeeding switch until
either an INF is received in response to the INR or the T33 timer expires.
If an INF is received before the timer expires and the Calling Party Number is included,
the call will be further processed. If this information is not included in the INF message,
the ControlSwitch will determine whether the call can be processed without the Calling
Party Number. Otherwise, the ControlSwitch will release the call. If the timer expires
before an INF can be received, the ControlSwitch will treat the event identical to the
receipt of an INF without the requested information above. If the ControlSwitch propagates an INR that is originated by a succeeding switch, the timer will not be started since
the call would not be released when the timer expires. This is to allow the originator of the
INR to take action that it deems appropriate.
Overlap Signaling
Two kinds of dialed digits signaling are supported in ITU/ETSI ISUP: En-bloc signaling
and Overlap signaling. En-bloc means that all the called party address digits (the dialed
digits) are included in the IAM and the call can be routed on this called number information. Overlap signaling means that the IAM can contain some but not all of the called party
address digits. Digits can be received after the IAM in a Subsequent Address Message
(SAM). ANSI ISUP only supports En-bloc signaling. Only ITU ISUP supports Overlap
signaling. A few other protocols such as R2 also support overlap signaling, but ITU/ETSI
ISUP is the only major protocol that we use that supports overlap.
86
ISUP Segmentation
If overlap signaling happens on a call coming into Veraz ControlSwitch, all egress protocols will be affected by the support of overlap signaling. In some cases (ANSI ISUP)
overlap signaling is not supported in the protocol so minor changes will be needed to
receive a set up request from the ingress call half and possibly wait for more digits before
sending the call out the egress protocol. In the case of PRI, H.323, and CAS, the protocol
does support overlap signaling, but the ControlSwitch does not support the messaging to
allow this, so these will be treated as an 'enblock' signaling protocol for now.
ISUP Segmentation
A Segmentation message (SGM) can be received if a number of ISUP messages carry
extra information that would have caused the message to go over its maximum size if
included in the original message.
For example, when overlap signaling happens, the message for which segmentation is
needed is the IAM. If an IAM includes the Optional Forward Call Indicator (OFCI)
parameter with the 'simple segmentation' bit set to true, then an SGM message is expected
containing additional information that would normally be included in the IAM. SGM and
SAM messages can be received in any order at the ingress ISUP trunk group.
Message and Parameter Compatibility

Message and parameter compatibility is a procedure for solving a long standing problem
with ISUP. Since switching software has a long life-span and may sometimes not be modified for years at a time, a problem developed between switches with newer and older
versions of ISUP not being compatible. The Message and Parameter Compatibility work
adds a universal system for telling how a switch should handle received messages or
parameters that it does not understand.
When ITU defined Message and Parameter Compatibility, it designated a release of specs
(Blue Book, approximately 1988) as a baseline. For any new messages or parameters
added after 1988, a message compatibility parameter and a parameter compatibility
parameter must be included in each previously existing message and for if any new parameter was added to a message that existed before Blue Book ISUP. Below is an example of
few entries from Q.761 that contain the list of messages and parameters that do not require
a message or compatibility parameter.
87
Figure 8-1: Q.761 Example
Following are broad categories of actions that can be performed on receiving a message or
a parameter
Release call
Transit interpretation (Type B switch)
End node interpretation (Type A switch)
Send notification
Discard parameter
If a message or a parameter is not understood by Veraz Signaling Gateway and has been
discarded and the previous switch has requested for notification, the Signaling Gateway
should send a Confusion CFN message to the previous switch.
Availability Control
User Part Availability is the process in the SS7 world by which MTP3 and ISUP work
together to communicate with far-end switches about whether the ISUP layer is active or
not.
User Part Availability consists of three messages:
88
UPU (MTP3),
UPT (ISUP), and
UPA (ISUP).
Connection Fallback
On the ControlSwitch, we will consider ISUP to be out of service when the application is
not registered with the base Ulticom layer.
The UPU message is sent by MTP3 when it receives an ISUP message from the network
whose ISUP user part is down. When the other switch receives UPU it knows that the
ISUP is out of service at the other switch. The far-end switch sets a timer and at regular
intervals sends a UPT (User Part Test) message to the other switch. If the ISUP is still
down at the other switch, then no response is sent. If the ISUP user part is up at the
receiving switch a UPA (User Part Test Ack) message is sent back to the switch that sent
UPT.
In release 8.02, Ulticom does not support sending of the UPU message for sending or
receiving. Ulticom does support this message in release 9.02 so we will have access to that
functionality in a future release.
However, the UPT/UPA exchange (which usually starts as a result of a UPU being
received) can also be received independent of the UPU message. For now, ControlSwitch
will support what can of User Part Availability by supporting the ability to send a UPA in
response to a received UPT. ControlSwitch will not originate the UPT message.
Connection Fallback
The standard PSTN voice path uses 3.1 kHz audio sampling to produce what is known as
telco quality voice. ISDN allows for certain high-end phones to allow transmission of
voice with higher quality that encode audio into 7 kHz audio. One important aspect of this
specialized high-end phone system is that it requires that the 7 kHz audio format be
supported by the phones at both ends of the connection. So the higher quality voice might
only be usable in large business or government organizations where a large number of
high quality phones are in use. When this special phone terminal places a call that terminates to the PSTN or to another system that does not support 7 kHz audio data, the call is
dropped back to normal speech or 3.1 kHz voice quality to complete the call. This procedure is called Connection Fallback procedure and it employs Bearer Capability negotiation. The fallback bearer capabilities are 'speech' and '3.1 kHz audio'. The preferred bearer
capability can be only be the 7 kHz Audio bearer capability (also known as UDI-TA).
The Veraz ControlSwitch can receive the bearer capabilities in ITU ISUP parameters
Transmission Medium Requirement (TMR) parameter and the User Service Info (USI)
parameter. TMR is intended for use by exchanges transiting the information without
needing the more complicated BC details that can be passed in a USI. USI is used to carry
bearer capability for the terminating endpoint. In general, the TMR is a scaled-down
version of the information in the USI. In simple ISUP calls using one bearer capability and
only speech or 3.1 KHz, sometimes the TMR will be included but the USI could be
included or left out.
To follow Bearer Capability Fallback procedures in the Veraz ControlSwitch, an ETSI
Trunk Group can be configured on the EMS GUI
89
If the egress trunk group doesn't have of 64k preferred option checked (e.g. ETSI
v1), the bearer capability is supposed to fallback to speech/3.1 by filtering out the
higher bearer capability. To inform the preceding exchanges about this change
backward message sent by ControlSwitch (ACM) will that carry information.
If the egress trunk group is capable of handling 64k preferred, both bearer capabilities will be sent out to the far end switch and it will be up to the far end to decide
whether it wants to fallback or not. In addition, the far end switch will send the
backward message ACM comprising information if the fallback has been
performed or not.
Auto Repeat Attempt

Most of the Automatic Repeat Attempt work on the ControlSwitch is already available in
the ControlSwitch whereby retries to next available circuit is attempted incase of failure.
The new Auto-repeat Attempt item is the reattempt when an unreasonable message is
received in response to an IAM. When an unreasonable message is received in response to
IAM, with Auto Repeat Attempt feature, an RSC is sent to the circuit and the next available circuit is retired.
ITU Q.764, section 2.8.1 says an automatic repeat attempt should be done on receipt of
an unreasonable message during call set-up. Section 2.9.5 elaborates that when an unexpected message is other than REL, RLC, or SGM and:
if the circuit is seized by a call, before receipt of a backward message required for the call
set-up, the Reset Circuit Message is sent. If the circuit is seized by an incoming call, any
interconnected circuits will be released. If the circuit is seized by an outgoing call, an automatic repeat attempt is provided on another circuit.
810
Propagation Delay
If received immediately after call setup IAM, the following messages should cause an
automatic-repeat attempt:
1. SUS/RES - The Suspend and Resume messages are only meaningful when a far-end
party has been connected in the call and then disconnects again. These messages are
meaningless as a first response after IAM and signal that something is wrong with the
relations between the two switches on this circuit. When this occurs, the originating
side should send an RSC on this circuit and expect to receive an RLC in response. At
the same time the RSC is sent, the call will be reattempted on another circuit in the
same trunk group.
2. COT - The Continuity message is always sent in the forward direction on the call.
Never in the backward direction on a call. If received in response to an IAM, a COT
message probably means that dual seizure occurred and somehow the received IAM
from the other switch (which included a cot test) was lost. Any time a COT is received
in response to IAM, the call will be released with an RSC and reattempted on another
circuit in the same trunk group.
3. SAM - The Subsequent Address Message should only be received after IAM in the
same direction as the IAM. Never as a response to an IAM. The receipt of SAM in this
scenario is invalid and will cause an RSC and reattempt from the originating side of
the call.
4. USR - The User-to-user signaling message is only intended for use after UUS
Signaling service 3 has been agreed to by both sides of the call in the call setup IAM
and call answer ANM messages. Therefore, USR can only be sent after ANM so it is
invalid as a response to IAM. If USR is received after IAM, an RSC will be sent and
the call reattempted on another circuit.
Propagation Delay
Propagation Delay Determination (PDD) procedures are intended to simply gather an estimate of the total delay in the call at each node in the forward call direction and later send
that estimated total delay back to the originating switch in the backward direction. PDD
procedures are intended to be used with an improved version of echo control procedures to
only enable echo cancellers when sufficient delay has occurred in the call in order to make
the most efficient use of the echo cancellers.
In ISUP a Propagation Delay Counter (PDC) parameter is sent in each IAM and the estimated delay between each node and the next is added to the total number of milliseconds
in the PDC at each switch. Then at the terminating switch, the total propagation delay
value from the received PDC is put into the ANM or CON in the Call History parameter
and sent backward to the originating node.
Currently, the support is for static configuration of the Propagation Delay on a trunk
group. Extensibility of this feature for proactive calculation based on media delays and
using it for echo control will be addressed in a future release.
811
ETSI Charge Framework

The ControlSwitch handles the charge procedures for the India and Israel ISUP variants.
Additionally, it will handle ETSI charge procedures.
There are two types of entities in the SS7 networks that are concerned with the charging
procedures. The first entity involves itself with the mechanism to generate the CDRs and
invoke Advice of Charge mechanism. These are typically done at the Charge Registration
or Charge Generation Points (CRP/CGP). The charge registration point is a functionality
of the exchange where the charge information is collected to actually charge the call. The
charge generation point is the functionality where the conversion of the tariff information
to the actual currency amount is performed. These functions are typically done at the origination exchange.
The second entity is called the Charge Determination Point (CDP). This is the functionality of the exchange in the network that determines what tariff/add on charge should be
applied to the call. The ControlSwitch will play the role of the CDP. The ControlSwitch
will be provisioned with the tariff policies and will send the charge information to the
CRP/CGP in the network. The TAX switches in the Indian ISUP networks usually assume
this functionality.
Currently, the charge and time band elements are provisioned in the PE and embedded
with the routing framework The PE has been selected to hold the charge and time band
elements to minimize the number of PE lookups and an RE dip is made for every call
coming into the system.
The following are salient features of the charge framework:
The ControlSwitch will be provisioned with the charge information that can be
used to send the CRGT/Add-On Charging (AOC) messages to the SS7 network.
A separate PE plan - Tariff Plan will provide the ETSI charge plan information.
The charge plan information is similar to the Israeli/India charge plans already
supported on the system
The charge band information will be associated with time band information to
give a charge plan.
The time bands for tariff information will not span 24 hours. It could start from
00:00 hours of a day and end at 23:59 within the same day. The time band resolutions should be hours: minutes. There will not be a second's resolution.
The minutes portion of the start time of a time band should be at:00,:15,:45
minute boundaries.
Example of a time band could be 00:00 - 08:29, 08:30 - 15:59, 16:00 - 19:14,
19:15 - 22:44 and 22:45 - 23:59.
For every call, a service trigger plan will determine if the tariff plan needs to be
dipped, the SEE will launch request for tariff information. Once the CCP gets this
information it will pass to the Signaling Gateway that will send out an APM
(message type CRGT/AOCRG to the SS7 network.
Charge messages sending and receiving options:
812
Propagation Delay
IAM message with ATP parameter comprising APP parameter comprising CRGT
parameter
ACM, ANM, CPG messages with ATP parameter comprising APP parameter
comprising
APM message with ATP parameter comprising APP parameter comprising CRGT
parameter
The following diagram shows tariff changes across time line. When these time splices are
traversed new Charge message or parameter should be sent
Figure 8-2: Sample Time Dependent Tariff Data
The following example shows the tariff that contains the sub-tariff information for
different time slices. The sub tariff information exists between the main tariff splices. In
this case as well, charge related message should be sent on crossing over sub-tariff time
splice.
813
Figure 8-3: Tariff data with sub-tariff information
ETSI V1 Modeling
In SS7 ISUP signaling, ITU Q.767 ISUP is considered 'ISUP Version 1' and Q.764 ISUP
is considered 'ISUP Version 2'.
The current ControlSwitch implementation of ETSI/ITU ISUP is closer to Q.764/ETSI V2
since it contains some functionality that is not included in Q.767/ETSI V1 ISUP.
By configuring certain parameters in an ISUP trunk group, an operator can configure an
ISUP v1 trunk group that can signal in Q.767/ETSI V1 and prevent Q.764/ISUP V2
messaging,
Some of the procedures that are allowed on Q.767 but not in Q.764 are as follows:
Bearer capabilities speech, 3.1 and 64 k/bits unrestricted
CLIP/CLIR, COLP/COLR, CUG, Sub-addressing and Terminal Portability
Some of the procedures that are allowed on Q.764 but not in Q.767 are as follows:
814
SCCP
Message and Parameter Compatibility Procedures
Hop Counter
Segmentation
Country Specific ISUP Variant Support
Bearer Capability Negotiation
Call Forwarding related information in the call (Original Called Number, Redirecting Number, Redirection Information)
In addition, the following services are supported in Q.767
Continuity check
Overlap Signaling
Echo Control
Closed User Group
Automatic Congestion Control
Country Specific ISUP Variant Support

Germany
The ControlSwitch supports German ISUP variant G-ISUP based on
TZ 163 TR 76.97, Application Specification for the Signaling System No. 7

Gateway ISDN User Part (G-ISUP), 1997
India
India ISUP support is based on ITU Q.764 ISUP and ETSI 300-356 ISUP base specification with variations for local requirements. Current support is for the following features:
Charge Message (CRG) passes through per
No. SP CCS 001 JUN 93, Department of Telecommunications Engineering

Centre, National CCS7 Specification for Local/Tandem Exchanges
No. SP CCS 002 JUN 93, Department of Telecommunications Engineering

Centre, National CCS7 Specification for Transit Exchanges
This is a message pass through function only. This information is logged into the CDR
records for accounting purposes.
The ControlSwitch will map India specific CPC values to the ITU equivalent.
Mexico
The ControlSwitch supports Mexican ISUP based on the following specification:
Norma Official Mexicana NOM-112-SCT1-1999, Telecomunicaciones-Interfazparte de usury de servicios integrados del sistema de senalizacion por canal
comun, 2000
815
UK ISUP
The ControlSwitch supports UK ISUP based on the following specifications:
PNO-ISC/SPEC/005 (also known as ND1005:2000/08), C7 Interconnect

Message Transfer Part
PNO-ISC/SPEC/007 (also known as ND1007:2001/07), ISDN User Part
Romanian ISUP
The ControlSwitch supports Romanian ISUP as it falls under base spec ETSI ISUP V2
(ETS 300 356-1 (1995).
Russian ISUP
The ControlSwitch supports Russian ISUP based on the following National Directives:
Message Transfer Part (MTP) Technical Specification for national Network of

Russia (based on ITU White Book recommendations
ISDN User Part (ISUP) Technical Specification for the National Network of
Russia (Based on Q.767 (International ISUP) and ETSI 300 121 (ETSI International ISUP) with national specific changes.)
Singapore ISUP
The ControlSwitch supports the following extension for Singapore
IRI/ORI parameter support and routing
N-Tiered routing for per carrier traffic distribution
Hong Kong ISUP

Hong ISUP compliance is provided in release 5.5.5 per ITU Q.764, Q.762, Q.784.1 and
HKTA2202 Issue 3. Veraz SS7 framework is being leveraged to provide Hong Kong
Variant support.
Following features are supported specifically for Hong Kong ISUP Variant support:
Support for the following Bearer Capabilities
Speech
3.1 kHz Audio
64 k/bits unrestricted
This means that speech, voice band data (modem calls), and pure data calls will be
allowed on HK ISUP networks. If any other bearer capability is received in a
816
Hong Kong ISUP
TMR (Transmission Requirements) parameter, the call should be released with

cause 65 (Bearer capability not implemented).
INR/INF: INR or Information Request message is sent to the preceding switch to

request for certain information that is required to proceed with the call request.
For Hong Kong the only request that can be sent to a preceding switch is for
sending across CPC (Calling Party Category)
ATP sub-addressing: This information is supported in IAM for the sub-addressing

service. ATP (Access Transport Parameter) should be passed transparently.
The following features are disabled for Hong Kong trunk groups since they are not
required in Hong ISUP networks
Overlap Signaling
CQM/CQR
Segmentation Message
COT Message (Continuity Check indicators set to 00)
Hop Counter
Bearer Capability Negotiation
ACC (Automatic Congestion Level)
Charging Procedures (charge indicator set to no charge)
Satellite Indicator (set to 0)
The following features are mentioned in Hong Kong specifications are not currently
required or used in the network.
DRS (Delayed Release)
SS7 IN Services - North America

The ControlSwitch uses TCAP to query an SCP to determine the routing number(s) associated with a dialed 8xx (in North America) or other toll-free call number as well as for
LNP lookups
When the ControlSwitch sends a routing request to the PE, the PE looks up its routing
tables. If the dialed number is flagged as toll free or LNP in the routing tables, the PE
sends a message to the TCAP SG, which in turn sends a query to the SCP. The SCP uses
TCAP to return a response containing the routing number(s) (or an error or reject component) back to the originating SG which in turns passes the information back to the PE that
initiated the original request message.
The TCAP services that are supported in the current ControlSwitch release are:
Toll free
817
The ControlSwitch TCAP implementation is based upon the following specifications and
related services:
GR-2892
GR-2902
The ControlSwitch TCAP implementation is AIN 0.1 compatible.
ControlSwitch Local Number Portability Implementation

The ControlSwitch supports LNP in a number of different applications as follows:
Tandem Switch Application
In the Tandem Switch application, the Control Switch serves as the LNP-Capable Intermediate Switch and routes ported call only by LRN to the Recipient Switch. In SS7
network, the LRN is populated in the Called Party Number parameter (CdPN) and the
actual dialed digits (plus implied Area Code) are in the Generic Address Parameter
(GAP). The Forward Call Indicator (FCI) parameter in the ISUP IAM will be used to indicate whether an LNP query was performed. The ControlSwitch also supports AIN LNP
trigger. It can detect whether the NPA-NXX of the Called Party Number is open for portability and will query SCP for the LRN of the dialed digits if no query has been performed
yet.
Originating/Terminating Switch Application
In the Originating/Terminating Switch application, the ControlSwitch may serves as
Donor Switch and/or Recipient Switch for the ported Directory Number (DN). The
ControlSwitch can either route the ported call out of switch by LRN to the Recipient
Switch or route the ported call within the switch by DN if ControlSwitch is the Recipient
Switch itself. To determine whether it is the Recipient Switch of a ported call, the
ControlSwitch need to examine the LRN of the ported call to see if there is a match with
its own LRN (Home LRN). It the LRN of the ported call match its Home LRN then the
call should be terminated on the ControlSwitch and be routed by the DN.
Terminating Trunk Group
When the Control Switch serves as the Recipient Switch of a ported DN in an open NPANXX, it may still route non-ported traffic of that NPA-NXX out of switch while terminating ported DN to itself. To distinguish between the tandem route to the Donor Switch
for that NPA-NXX and the local route of the ported DN from that open NPA-NXX, a
Terminating Flag is provisioned for the local terminating trunk group. With the Terminating Trunk Group flag, Operator won't need to break up the provisioned NPA-NXX
range in the routing policy to exclude the ported DN ranges.
818
Productized Services
SS7 INAP Services

ETSI INAP CS-1 is supported per the following specifications;
ETS 300 374-1 Intelligent Network (IN);Intelligent Network Capability Set 1

(CS1);Core Intelligent Network Application Protocol (INAP);Part 1
Q.1600 Signalling System No. 7 - Interaction between ISUP and INAP
All announcements for services are based on an IP Media Server servicing as an SRF
function under MGCP control.
Services are productized based on market requirements. A list of currently supported
services for production applications can be found in the subsequent section
The following lists all services that are currently productized for production applications.
It should be noted that the entire CS-1 stack is implemented and additional services can be
added based on customer demand;
Pre-paid authentication
INAP implementation of Pre-paid service enables a centralized network element, namely
SCP to store the validation information for pre-paid users. User dials a pre-paid toll free
number to invoke the service. The operator configures the triggering points within a call
for which the INAP based service needs to be run. PE provides the necessary information
(like Service Node Information, service key, TCAP Gateway id, etc.) to identify the SCP,
and the service to be invoked on the SCP (In this case, the Pre-paid service). SEE communicates with the TCAP Gateway to send the request to SCP. SEE processes the messages
from SCP and map the INAP messages to internal messages to CCE for desired behavior.
For the pre-paid service the user is prompted to enter validation information. Once the
SCP validates the user, it directs the control switch to route the call to the desired destination party.
The SCP directs the SEE to indicate what announcements need to be played for collecting
digits from the user. The SCP can request reporting of call processing events and can
direct the SSP (SEE) to block on certain events.
819
Toll Free/Free Phone applications

INAP implementation of Free phone service enables a centralized network element,
namely SCP to store the Toll free numbers, and their corresponding Directory number
mapping. The user dials a destination number, once the destination number is collected,
SEE will check for any active triggers by sending request to PE. PE based on provisioning
identifies whether or not a SCP needs to be involved to map the destination number. If
SCP has the mapped number information, the response from PE indicates Service Node
treatment (Special Trigger type identified as FreePhoneService) which enables SEE to
communicate with the TCAP Gateway to send the request to SCP. The response from SCP
determines the Mapped number for the original called party number. This number is then
used to route the call to the destined party.
INAP implementation of LNP service enables a centralized network element, namely SCP
to store the ported number information. The user dials a destination number, once the
destination number is collected, SEE will check for any active triggers by sending request
to PE. PE based on provisioning identifies whether or not a SCP needs to be involved to
port the destination number. If SCP has the ported number information, the response from
PE indicates Service Node treatment (Special Trigger type identified as LNP) which
enables SEE to communicate with the TCAP Gateway to send the request to SCP. The
response from SCP determines the ported number. This ported number is further used to
route the call to the destined party.
820
Supported Messages
Table 8-1
Supported Messages
Message Name
Comments
ActivateServiceFiltering
The following parameters will be decoded but ignored

by the ControlSwitch:
sFBillingChargingCharacteristics
Other limitations described above
ActivityTest
Fully supported
ApplyCharging
Not supported
ApplyChargingReport
Not supported
AssistRequestInstructions
Not supported
CallGap
Supported with notes
CallInformationReport
Fully supported
CallInformationRequest
Fully supported
serviceInteractionIndicators will be decoded but ignored
by the ControlSwitch
Cancel
Fully supported
CollectInformation
Not supported
Connect
The following parameters will be decoded but ignored

by the ControlSwitch:
correlationId
scfId
cutAndPaste
redirectionInformation
alertingPattern
serviceInteractionIndicators
ConnectToResource
serviceInteractionIndicators will be decoded but ignored

by the ControlSwitch
Continue
Fully supported
DisconnectForwardConnection
Fully supported
EstablishTemporaryConnection
Not supported
EventNotificationCharging
Not supported
EventReportBCSM
Fully supported
FurnishChargingInformation
Not supported
821
Table 8-1
Supported Messages
Message Name
Comments
InitialDP
ControlSwitch will never provide the following optional

parameters:
iPAvailable
iPSSPCapabilities
serviceInteractionIndicators
highlayerCompatibility
All other parameters will be provided if present in the

ingress IAM (or equivalent) message
InitiateCallAttemp
Not supported
PlayAnnouncement
Limitations mentioned above, plus:
PromptAndCollectUserInformation
requestAnnouncementComplete will be decoded

but is not supported as we do not support sending a
SpecializedResourceReport message
Supported with notes. The following are unsupported

fields:
voiceInformation
voiceBack
ReleaseCall
Fully supported
RequestNotificationChargingEvent
Not supported
RequestReportBCSMEvent
Fully supported
ResetTimer
Fully supported
SendChargingInformation
Not supported
ServiceFilteringResponse
Fully supported
SpecializedResourceReport
Not supported
Global Title Support

Currently, global title is supported for Called Party Number. Calling party number is
addressed by PC/SSN
Supported Variants and Limitations

The Ulticom and Telesys SGs vary in their limitation (theoretical and tested in the
ControlSwitch). Once these supported limits are reached, additional signaling gateways
can be added to the network to allow the network to scale and grow.
822
Ulticom Signaling Gateway Limitations
Ulticom Signaling Gateway Limitations

Ulticom Gateway Limitations
Table 8-2
Representation
SSP
Backhaul
ControlSwitch SS7 over IP
Cards Supported
4 port, 8 port, 16 port
Local Point Codes per SG pair
5 LPCs
Destination Point Codes per LPC
3500
(17500 per SG pair)
Link Types
A, E, F
Links per Pair
255 (with up to 1 A CLS and 7 E CLS per

point code)
Max number of SS7 cards per SG
Max links per SG/SG pair
48/96
Max number of SG pairs per

ControlSwitch
Unlimited
Protocols Supported
ISUP, TCAP
Geographic Distribution of pairs
No, collocation required
Telesys Signaling Gateway Limitations
Table 8-3
Telesys Gateway Limitations
Representation
Logical STP interface to SSP
Backhaul
M3UA draft version 5
Cards Supported
2-T1 and 4-T1
Local Point Codes per SG pair
10 LPCs
Destination Point Codes per LPC
5000
Link Types
A, F
Links per Pair
128
Max number of SS7 cards per SG
Max links per SG/SG pair
64/128
Max number of SG pairs per

ControlSwitch
Unlimited
Protocols Supported
ISUP
Geographic Distribution of pairs
250 mSec round trip delay
823
ISUP and TCAP Support
Table 8-4
ISUP Support
ANSI
Telesys
Supported
Supported
ETSI C7
Supported
Not Supported
Japan J7
Supported - for field trials
Not Supported
UK
Supported
Not Supported
Singapore
Not Supported
Germany
Not Supported
Mexico
Supported
Not Supported
India
Supported
Not Supported
Table 8-5
824
Ulticom
TCAP Support
Ulticom
Telesys
ANSI - Toll Free
Supported
Not Supported
ANSI - Local Number Portability
Supported
Not Supported
ISDN-PRI Services
Chapter 9
This chapter describes SIP services. The following topics are included in this chapter:
Features Supported for ETSI and NI-2 Variants of ISDN-PRI
ISDN-PRI Messages Supported by ControlSwitch
ISDN-PRI Maintenance Operations Supported by ControlSwitch
Q.SIG Services
91
Chapter 9: ISDN-PRI Services
The ControlSwitch supports ISDN Q.931 call processing. Q.931 is the ISDN network
layer that facilitates call setup and tear down transactions. The state machine and timers to
support these transactions are maintained within the ControlSwitch. In a number of cases,
an incoming SS7 call will need to terminate on ISDN equipment, and an incoming ISDN
call will terminate on the SS7 side. The mapping between transactions on the SS7 and
ISDN sides follow the Telcordia SR-444 specification, for ANSI.
As of Release 5.2, the following ISDN-PRI variants have been supported:
National ISDN 2 (NI-2), applicable to North America
ETSI PRI (EuroISDN), applicable to Europe
Features Supported for ETSI and NI-2 Variants of ISDN-PRI

The table below describes the features that are supported for ISDN-PRI for both ANSI and
ETSI:
Table 9-1
92
Features Supported for ETSI and ANSI Variants of ISDN-PRI
Parameter
ETSI
NI2
Switch Type
STEI
N12
Type of interface
E1
T1
Bearer Capability- Codec
A-law
Mu-Law
Bearer Channels per span
30
24
D-Channel position in span
16
24
NFAS support
No
Yes, depending on NFAS

configuration
Backup D-Channel support
No
Yes, depending on NFAS

configuration
Automatic Restart Option
No
No
Overlap Signaling
Yes
No
ISDN-PRI Messages Supported by ControlSwitch

The ControlSwitch supports the following Q.931 messages:
Table 9-2
Q.931 Message Support
Message
ETSI
NI2
Setup
Setup Ack
Call Proceeding
Alerting
Connect
Connect Ack
Progress
Disconnect
Release
Release Complete
Status
Status Enquiry
Restart
Restart Ack
Call Establishment and Clearing
Maintenance
ISDN-PRI Maintenance Operations Supported by

ControlSwitch
The ControlSwitch supports Q.931 maintenance operations, via the Restart and Restart
Ack messages. The following tables indicate the operations that are supported:
Table 9-3
Q.931 Maintenance Operations for NI-2
Operation
Restart Indicator
Channel Id
Interface Id
Reset one DS0 or

Bearer Channel
Indicated Channel
Bearer Channel
Number
None
Reset Span
Single Interface
None
Interface Number
for Span
Reset Entire
NFAS group
All Interface
None
None
93
Table 9-4
Q.931 Maintenance Operations for ETSI
Operation
Restart Indicator
Channel Id
Interface Id
Reset one Bearer

Channel
Indicated Channel
Bearer Channel
Number
None
Reset Span
Single Interface
None
Interface Number
for Span
Q.SIG Services
Q.SIG is a variant of ISDN D-Channel Signaling. It is becoming the standard for PBX
interoperability in Europe and North America. Q.SIG provides the means to exchange
signaling information for the control of Supplementary Services over a Private Telecommunication Network (PTN). These Supplementary Services could relate to existing basic
calls or could be entirely independent of any existing basic calls.
This section describes the supported functions of the Layer 3 Protocol for signaling for the
support of circuit mode bearer services and supplementary services as defined by Q.SIG
specifications.
The Veraz ControlSwitch together with its associated media gateways appears to the traditional Q.SIG PBXs as a distributed transit PTNX (Private Telecommunication Network
Exchange) that can establish calls to any PBX, non-Q.SIG PBX, or other telephony
endpoint served by the ControlSwitch, including non-Q.SIG endpoints. When originating
and terminating on Q.SIG endpoints, the Q.SIG messages are passed transparently across
the network; the PBXs are responsible for processing and provisioning the supplementary
services. When linking Q.SIG and non-Q.SIG endpoints served by the ControlSwitch,
only basic calls are supported. In addition, all switched voice connections must be established and torn down in response to Q.SIG control messages.
Q.SIG Trunk Group Provisioning

To support Q.SIG signaling, an ISDN trunk group has to be provisioned as Q.SIG. The
Q.SIG trunk group provisioning will be similar to ETSI PRI or NI2 PRI trunk group provisioning, with the following differences:
Q.SIG trunk groups can be configured on T1 or E1 interfaces. But a mix of T1 and

E1 interfaces in the same trunk group will not be supported in this release.
Q.SIG trunk groups do not support NFAS signaling.
The following table shows Q.SIG-supported gateways and interfaces:
94
Q.SIG Messages and Information Elements
Table 9-5
Q.SIG Supported Gateways and Interfaces
Supported Interfaces
Gateway Type
T1
E1
BRI
MGX8850
Yes
Yes
No
AS5300
Yes
Yes
No
2600 IADs
Yes
Yes
No
3600 IADs
Yes
Yes
No
I-Gate 4000
Yes
Yes
No

The following Q.SIG messages are supported:
Table 9-6
Supported Q.SIG Messages
Supported
Message Type
Send
Receive
SETUP
Yes
Yes
SETUP ACK
Yes
No
CALL PROCEEDING
Yes
Yes
ALERTING
Yes
Yes
PROGRESS
Yes
Yes
CONNECT
Yes
Yes
CONNECT ACK
Yes
Yes
DISCONNECT
Yes
Yes
RELEASE
Yes
Yes
RELEASE COMPLETE
Yes
Yes
RESTART
Yes
Yes
RESTART ACK
Yes
Yes
INFO
No
Yes
STATUS
Yes
Yes
STATUS ENQUIRY
Yes
Yes
SEGMENT
No
No
Note Overlap receiving is supported, but on the egress side it will always be
en-bloc signaling. Thus, even if the dialed digits are received in SETUP followed by one or more INFO messages at the ingress side, all the digits will be
sent together in a single SETUP message at the egress side.
95
The following Q.SIG Supplementary services messages are supported:

Table 9-7
Q>SIG Supplementary Services
Supported
Message Type
Send
Receive
FACILITY
Yes
Yes
NOTIFICATION
Yes
Yes
In a Q.SIG network, the ControlSwitch will act as a Transit PTNX, meaning that it will
not initiate any Supplementary Service by itself, but will pass any signaling information
for control of Supplementary Services between the originating PTNX and the terminating
PTNX.
ControlSwitch will not interpret the Supplementary Service message contents, but it will
just allow transfer of those messages between end PTNXs.
The ControlSwitch will support only Call Associated Supplementary Services.
Non-Call Associated Services are not currently supported in this release.
The transfer of Application PDUs for Supplementary Services will be supported in
Facility IE and/or Notification Indicator IE in the following messages:
Table 9-8
96
Application PDUs for Supplementary Service
Message Type
Facility IE Supported
Notification Indicator IE
Supported
SETUP
Yes
Yes
ALERTING
Yes
Yes
PROGRESS
Yes
Yes
CONNECT
Yes
Yes
DISCONNECT
Yes
Yes
RELEASE
Yes
No
RELEASE COMPLETE
Yes
No
FACILITY
Yes
No
NOTIFICATION
No
Yes
97
98
CAS Services
Chapter 10
This chapter describes CAS Services. The following topics are included:
CAS Services
MF Signaling
DTMF Signaling
Signaling Protocols
101
Chapter 10: CAS Services
CAS Services
Beginning with Release 5.2, the ControlSwitch has supported CAS signaling on certain
media gateways as described earlier in this document. CAS is a telemetric signaling
format, where call processing events are conveyed via the A and B bits as part of robbedbit signaling, as well as via MF and DTMF tones. This type of signaling, which also
known as In-Band is signaling, call setup and signaling use the same path of the bearer.
There are two types of signaling methods used for CAS, Multi-Frequency (MF) and DualTone Multi-Frequency (DTMF).
The primary focus of CAS support is for direct access line applications either from a
remote media gateway to the end user, or via a customer premises device such as an IAD
on the customer site.
The ControlSwitch supports MF and DTMF signaling as follows:
MF Signaling
Multi-frequency signaling uses two combinations (and only two) of six frequencies in the
voice band. The six frequencies are: 700 Hz, 900 Hz, 1100 Hz, 1300 Hz, 1500 Hz and
1700 Hz. This gives a combination of 15 frequencies for digits 0-9 and control or information signals like KP, ST, KP1, and KP2 etc.
DTMF Signaling
DTMF signaling provides 16 distinct signals in the voice band, generated as a harmonic of
the following tones: 697Hz, 770 Hz, 852 Hz, 941 Hz, 1209 Hz, 1336 Hz, 1477Hz and
1633 Hz. This is used to generate digits 0-9, *, #, A, B, C and D.
Signaling Protocols
There are three different types of CAS signaling protocols that will be supported in this
release. There are subtle variations between them. The MGCP gateway has packages that
notify protocol specific events to the Call Agent. When a channel is idle, a continuous
2600 Hz tone is played. Trunk Seizure is reported by interrupting the tone for a specified
period of time. Control signals (like Off-Hook and Wink) are generated by using different
interruption timings on the 2600 Hz tone.
102
Wink Start
Wink Start
In Wink Start signaling, when a PBX at one end wants to make a call, it sends an offhook signal over the trunk. The Gateway recognizes this and replies back with a Wink
signal. Following this, the PBX will send digits encapsulated inside KP and ST for MF
trunks and just the digits for DTMF trunks.
Immediate Start
In Immediate start, the Wink signal will not be sent in response to the off-hook.
However for certain DTMF trunks, the Gateway needs to play dial tone on the channel
when off-hook is detected.
Basic PBX
For a Basic PBX type trunk, when off-hook is detected, the GW needs to play dial tone
and also when the remote party hangs up, if the near party is still off-hook, dial tone needs
to be played.
Feature Group D
When CAS trunks are used as interconnects, the information exchanged between the
nodes are limited but more than what would be exchanged on a simple MF trunk interconnect between a PBX and an EAEO; So, the information is sent in two stages and multiple
winks are exchanged between the offices. Later sections describe the format and the
sequence in which the information is exchanged between nodes. The following information is sent across switches:
Called Party Number
Calling Party Number
ANI II digits
Carrier Identification code
ZZ digits
Country Address Field
Some other special codes like 1NX, 01R etc.
Feature Group D support is available with the exception of the following subsections to
FG-D:
Operator Services Signaling
Operator positions will not be available on the ControlSwitch.
103
Chapter 10: CAS Services
Carrier Presubscription for endpoints (Primary InterExchange, InterLata,

IntraLata carrier presubscription) Carrier Presubscription for endpoints is required
if ControlSwitch acts as an EAEO providing connectivity to analog, ISDN, SIP or
H323 endpoints.
Abbreviated dialing options. EAEOs that support FGD offer 3 different abbreviated dialing options to End Users to access the carriers; these features are
explained in detail in the GR690. ControlSwitch solution need not support these
as it does not act an EAEO.
FGB-over-FGD
Test Calls
Call Gapping
FG-D support is per the following specification with exceptions noted above;
Compatibility Information for Feature Group D Switch Access Service - Bell

Core Technical Reference TR-NPL-000258. Issue 1, October 1985
MGCP CAS packages - RFC 3064 February 2001
Exchange Access Interconnection FSD 20-24-0000 - Bell Core GR-690-CORE
ANI Over CAS

ANI over CAS is a CAS access variant typically used on DTMF trunks that allows for out
pulse or reception of the following signaling information not normally available on CAS
links;
Called Party Number
OLI
The ControlSwitch supports ANI over CAS with configurable delimiters ("*" or "#") as
well as the ability to populate defaults when the information is not received.
104
SIP Services
Chapter 11
This chapter describes SIP Services.The following topics are included:
SIP Services
Target Applications & Services
General SIP Architecture
SIP Load sharing fail-over and route distribution
111
Chapter 11: SIP Services
SIP Services
SIP is gaining momentum in the industry as the protocol of choice for VoIP networking
with enhanced services (application servers). The Veraz ControlSwitch supports the applications such as:
Enhanced services/features (Unified Messaging, Voicemail, single number reach

etc.)
Pre-paid and calling card services
Interconnect for ASP/Voice Portals
Connection to SIP Proxies controlling SIP end points
PSTN inter-working via MGCP gateways
Extended protocol inter-working for SIP (e.g., to H.323)
Some of these applications are enabled through partnerships with industry-leading partners providing application and media servers as well as feature servers.
Target Applications & Services

SIP applications appeal to any carrier offering enhanced services and interconnection to
ASP services (such as voice portals). Such applications constitute an early source of added
revenue and margin enhancement.
SIP Connectivity
When a Call Control Element is provisioned to support SIP, the ControlSwitch appears as
a SIP user agent (UA) to other SIP devices/servers on the network. In addition, each nonSIP endpoint that is either directly or indirectly controlled by the ControlSwitch (PSTN
phone, H.323 endpoint etc.) effectively appears as a SIP UA as well.
A SIP-enabled Call Control Element can communicate with SIP application servers,
feature servers, proxy servers, as well as directly to other SIP UA.
PSTN Interworking
The ControlSwitch provides PSTN inter-working via MGCP or other control protocols.
Outbound PSTN signalling support includes PRI, SS7, and CAS via all supported trunking
gateways (e.g., MGCP, H.248 or H.323). SIP calls can be made between any gateway
controlled by a Veraz ControlSwitch regardless of the call control protocol and interface
type. In the SIP world, the Veraz ControlSwitch appears as a SIP-PSTN Gateway.
112
SIP - SIP
Support for SIP-SIP calls is provided for calls between two different SIP networks. This
enables users/servers on two independent SIP networks to communicate if interconnected
by the ControlSwitch system. This functionality permit peering between multiple SIP
networks while exercising controls on this intercommunication (filtering function) as well
as to offer a single billing platform.
High Availability for SIP
The SIP-enabled CCE supports high availability through a load-sharing failover scheme
using alternate routes. Failure of a single element in a high-availability configuration does
not affect current calls in progress or successive calls, nor does it impact billing records.

This figure illustrates the Veraz reference architecture.
Figure 11-1:Veraz Reference Architecture
113
SIP Trunk Groups

Analogous to the PSTN trunk groups, SIP connectivity in the ControlSwitch is provisioned via SIP Trunk Groups. A SIP trunk group is provisioned for each remote IP address
that represents the far-end SIP entity. There are several advantages when trunk groups
concept is used. The main advantage is that operations are performed and reported on
trunk groups.
1. Operations like maintenance lock, unlock
2. Versatile routing and rerouting configuration usually applied to trunk groups can be
used
3. Trunk group based information like reports, alarms
4. Parameters based on each trunk group for media or protocol specific
If load sharing or a certain routing algorith is required for the remote trunk groups routing
can be configured to do so. This is described in section SIP Load sharing fail-over and
route distribution
Authorization of calls on SIP trunk groups is performed by verifying the contact header
and via header so that calls from SIP servers or end points behind a proxy server will be
accepted by ControlSwitch.
SIP Trunk Group Parameters
On every SIP Trunk Group configuration is provided for certain parameters to expedite
interoperability with a third party SIP device. The following parameters and values are
provided today:
114
3XX Redirection (Y/N)
Call Transfer Method Supported (None, cc-transfer-02, cc-transfer-03, cctransfer-04)
DTMF Option (None, Vendor specific)
Early Media Option (Default, Answer-Offer) Release 5.5.5
InCall CIC to TNS Mapping (Y/N)
InCall Request Prack (Y/N)
Informational Response Option (Pass As Is, 180/183 options)
OutCall Add CC to CIC (Y/N)
OutCall Require Provisional Response (Y/N)
Privacy RFC Compliance (Y/N)
Send Reason Header Format (Q.850/SIP)
Send 180 with SDP (Y/N)
Send back CPG upon 3XX (Y/N)
SendRecv - Support Reason Header (Y/N)
Support Privacy in Request (Y/N)
Support Privacy in Response (Y/N)
Suspend Resume Handling (Y/N)
SIP Third-Party Call Control

As an extension of the enhanced call support, the Veraz ControlSwitch supports thirdparty call control from an external SIP device. Using the enhanced SIP call support, an
external platform is allowed to control two independent calls per session through the
ControlSwitch and redirect / manipulate the RTP path as needed.
To further enhance this capability, the ControlSwitch supports Info requests to relay
DTMF digits between SIP devices and the far-end PSTN device.

As previously mentioned, the SIP element performs failover through diverse routes. When
multiple ControlSwitch SIP elements are used, routes are distributed between the
elements based on an operator/administrator-defined distribution. Upon failure of an
element, the route distribution is recalculated and calls continue to be processed on the
remaining elements.
The SIP element also supports upstream load distribution across multiple upstream SIP
elements with the same destination address (phone number). This is performed using route
distribution and functions in conjunction with the previously described load share failover.
The following figure illustrates this concept:
115
Figure 11-2:SIP Load Sharing
Also see for updates SIP High Availability Solution on SIP High Availability in release
5.5.5.
116
Policy Element - Supported

Policies
Chapter 12
This chapter describes the Veraz Policy Element and its supported policies. The following
topics are included:
Routing
Re-Routing
121
Chapter 12: Policy Element - Supported Policies
Routing
The PE provides the call routing functions of the ControlSwitch system. At the simplest
level this element responds to queries for possible destination routes based on a database
of call routing information and policies.
The PE incorporates a very flexible framework for numbering plan. Any fixed or custom
numbering plan can be enabled on a trunk group by trunk group basis. Multiple
Numbering plans are supported concurrently.
The ControlSwitch PE incorporates a very flexible framework for supporting any set of
call routing and call screening policies. These can be specified via a web-based GUI interface and customized at any time to meet customer service and network performance/optimization requirements. These policies can utilize a broad set of call related parameters,
network resources information, as well as dynamic parameters such as time-of-day, dayof-week, etc. Alternate routes are selected and traffic can be distributed on a percentage
basis among various alternate paths for congestion control purposes. The call routing policies can be multi-tier with no built-in limit on the number of tiers in such policies. Please
see detailed sections on routing for more information
Re-Routing
Re-Routing policies allow the operator to control the ControlSwitch call processing
behavior in the event of a far end call failure (far end release) after call setup.
Provisioning Interface
Logic for provisioning re-routing policies and plans uses the same flexible interface as the
base routing provisioning interface. All structure of plans, policies, and decision logic is
identical with the addition of Release Cause related logic Using release cause, the operator can provision per release cause behavior in re-routing.
Re-Route Triggers
Re-Route policies are traversed when the ControlSwitch receives a far end release on an
unsuccessful call setup if provisioned to be used. For example an IAM is sent to a far end
switch and the far end releases immediately with Resource Unavailable.
Provisioning Hierarchy
An index to a given re-route policy can be made at 3 levels of hierarchy as follows;
122
Routing Plan
Routing Policy
Re-Route Treatments
Routing Treatment
A treatment level index takes precedent over policy level and policy level takes precedent
over plan. Upon encountering a trigger (far end release), the ControlSwitch will check to
see if there is an associated re-routing policy and if so, take the highest precedence indicate.
Re-Route Treatments
The re-route treatment tells the ControlSwitch how to deal with the trigger. There are 4
possible treatments that can be provisioned as follows;
Route: Route advance to the next route in the original route list
Announcement: Send to an announcement. The operator provisions an announcement to
be played and an Announcement plan to be used to determine the logic for playing the
announcement.
Redirect: This allows the operator to provision a re-directing number. This redirecting
number will then be used to collect a new set of routes to be used to process the call.
Reject: This will reject the call to the originator. The operator may choose to override the
release cause, cause location, and coding standard.
Announcements
Announcement support is available on the ControlSwitch for treatments as well as service
execution (for supported services). Announcements are played from an off board Media
Server or Media Gateway (if capable). For a list of supported announcement servers,
please see the current interoperability matrix.
123
Chapter 12: Policy Element - Supported Policies
124
Routing and Digit Analysis
Chapter 13
This chapter describes the Veraz Routing and Digit Analysis processes.The following
Digit Analysis and Digit Collection
Translations, Call Routing, and Routing Plans
VoIP Protocol Routing
Enhanced Routing Feature
131
Chapter 13: Routing and Digit Analysis
Digit Analysis and Digit Collection

Digit Analysis and Collection or pre/post translations are used to verify, modify, format,
and/or translate any supported call parameter (see list in subsequent section). The Digit
Collection process is executed at the ingress point of a call and the Digit Analysis process
is executed at the ingress and egress point.
All digit analysis/collection rules are created in XML and are assigned to the
ControlSwitch on a per trunk group basis. Each trunk group allows for distinct ingress and
egress rule sets hence giving maximum flexibility and customization to each interconnect.
At the ingress point, the Digit Analysis capability is primarily used to format incoming
call parameters to match the format used in routing as defined by the operator within the
routing policies/plans. This however is not a requirement, but rather a decision made by
the network planner. If the choice is made to use a fixed number structure such as E.164
international for example, digit analysis would re-format all inbound numbers and nature
of address parameters to match this format. Alternately, the operator can build routing
tables to deal will all or some such combinations. Digit analysis will also be used to
extract call parameters that are to be passed to routing such as NOA, CIP, TNS, Bearer
Cap, etc. A more detailed list of available parameters is available below.
In the ingress direction, digit analysis is also used for other purposes such as verify call
parameters, modify call parameters, populate empty parameters or release non-conformant
calls. The rules are purely logic based and allow for action based on operator-defined rules
rather than fixed rules.
In the egress direction, digit analysis is used primarily to format the outbound call parameters to match the requirements of the interconnect and/or the far end destination. This
may entail operations such as setting the number formats to a fixed type, suppressing
parameters the operator does not want sent, or removing parameters used within the
ControlSwitch network that are not valid outside (such as pseudo CIC, ANI, etc.).
Digit Collection and Analysis are extensively customizable. The custom digit plan and
related processing can be specified in a scripting language is based on XML. The specified
scripted plan performs pattern matching and string/number insertion, removal, and modification. Scripting language examples include switch, case, extract-feature, insert-after,
insert-before, and statements. Digit plans can be customized for general system-wide use
or for use on specific trunk groups for providing special value added services to particular
customers.
132
Parameters in DA
Parameters in DA
The following is a list of the primary parameters that can be manipulated in Digit Analysis:
Message Contents
IAM/Setup
REL/Release
Number - present, equal, range, value, type
Calling party Number
Called Party
Redirecting Number
Charge
LRN (Location Routing Number)
Ported Number
GAP (Generic Address Parameter)
NOA (Nature of Address)
TON (Type of Number)
FCI translated number (Forward Call Indicator)
Original Number
Bearer Capability
Carrier
CIC
TNS
CSI
Redirection
Reason
Original Reason
Counter
VPN
Number
ID
Screening Indicator
Presentation Indicator
133
Call Type
FCI, BCI
ISUP Preference Indicator
Orig. Line Info
Calling Party Category
Interworking Indicator
IP Address
IP Port
Local ISUP variants Parameters
ISUP and ISDN access indicator
Segmentation indicator
SCCP method
LATA Zone
LATA ID
Echo Suppression
Sat Indicator
Protocol
Circuit Type
Treatment Type
Cause Value and class
Internal Cause Code
For a complete list of available parameters as well as information on manipulating the

parameters, please see the customer documentation or contact Veraz Networks.
134
Numbering Plan Format
Translations, Call Routing, and Routing Plans

When the ControlSwitch receives a call it goes through a sequence of routing steps that
includes:
Verifying required ingress call parameters as defined by the operator
Translating/Analyzing call parameters into appropriate internal format as defined

by the operator
Determining a treatment for the call (Route or Reject)
Formatting the egress call parameters as provisioned by the operator
Numbering Plan Format

The ControlSwitch is number format/plan agnostic. Numbers are treated as a series of
digits and analyzed using the rule set defined by the network administrator. This allows
the ControlSwitch to connect to any countries' network without requiring customization to
the local numbering plan. Numbering plans are only used for the purposes of call type
determination where applicable (see later).
For this reason, the operator is not constrained to any structure for routing. Routing can be
set up for any structure required - International, National, Local, or Private. Routing
analyzes digits and parameters with no preset interpretation.
Call Type Determination

When a call is received, the default call type is Unknown. When processed through
Digit Analysis (DA), the user has the option of setting the call type in the DA rule logic.
This allows maximum flexibility for international implementations.
If the call type is not set in DA, the Policy element (PE) managing the call will use default
rules to determine a call type. For non-US calls, this entails a simple determination of
International or not. All non-International calls are set to Long Distance.
For US based call originations, the PE will analyze the full call type based on the Country
Code table, LATA and LATA zone information provisioned in the system. Based on this
information, the following call types can be determined:
Local
International
Long Distance (Inter-LATA)
Local Toll (Intra-LATA
Operator
Operator Long Distance
Operator Local Toll
135
Operator International
In order to define the call type the following parameters are taken into consideration:
NOA, after the DA translation
Dialed Number's Country Code, when the call is not destined for the US
Ingress Point's LATA Zone, when the call is destined for the US
Dialed Number's LATA Zone, when the call is destined for the US
After determining call type (either through calculation or DA), the call is passed to routing
where it can be used as a routable attribute. As part of the end call treatment, the call type
can be overridden / changed as an egress call parameter. For Call Type override, the available options include the above list as well as Emergency and Directory Assistance.
Due to the numbering plan agnostic nature of the PE and the variance of these number
formats in International implementations automated determination cannot be performed.
Note With Release 5.5, call type will become a settable parameter in routing
as with any other variable.
Routing and Screening - Plans, Policies, and Parameters

Overview
The ControlSwitch makes no differentiation between routing and screening. It is purely an
analysis of a defined set of call parameters with a resulting treatment. This treatment can
either be to Route or Reject. Each treatment has associated attributes that go with it.
Routing Plans
A plan is a logical grouping of policies. The base routing plan is the system plan. This is
no different from any other routing plan except that it applies to the entire network when
no other plans are associated with a trunk group. It can be viewed as the default plan. Only
one system plan can be active in the network at any time.
Plans can be bound to trunk groups or to a dialed number (DN) hence allowing custom
routing plans on a per trunk group or per number basis. Plans can have no association to
any entity (trunk group or system) but can be called as routing logic from other plans/
policies.
The following diagram illustrates the selection of a routing plan for a call:
136
Figure 13-1:Flow diagram illustrating the selection of a routing plan
137
Policies
As mentioned above, routing is no more than a series of logic strung together that result in
a treatment of either route (routing), or reject (screening). This logic is grouped together in
a policy (whose structure is completely up to the provisioning operator). A routing plan
contains one or more routing policies and are executed based on the provisioned execution
order of the policy.
Policy Types
Each policy supports a type attribute. This can be either structured or unstructured
(advanced).
An advanced policy has no pre-set logic structure and the operator may mix any and as
many routable parameters as required. The logic embedded in the policy can be as
complex or simple as the operator chooses. When using this type of policy, there is no API
available to modify the routing logic as there is no fixed structure that would allow automated changes.
A structured policy follows repetitive logic however the logic used in the policy is
completely user provisionable. For example, if the structure was set such that the
following logic was used:
Check NOA
Then Calling Party Number
Then CIC
Arrive at a treatment.
The structure of the policy would always follow this defined logic. The order of the
parameters would be fixed and only those parameters could be used in the policy. This
fixed structure allows for a well known API to be created. This API can then be used to
interface to backend systems for automated route updates/changes/additions/deletions.
Note that although the structure in policy is fixed, it can vary across policies within a plan.
Furthermore, plans can contain a mixture of structured and advanced policy types.
Following figure is a screen shot of the Plan configuration screen.
138
Figure 13-2:Plan Configuration Screen
Routing Logic
Routing logic is completely free-form and only takes on the constraints defined by the
operator. Routing logic is created in a tree-based hierarchy via a web-based GUI. The
logic is interpreted in an If, Then, Else logic with support for embedded Ifs. Each
decision point is called a Rule Node. For example, a Rule Node could be IF NOA =
National.
The policy element will traverse the logic tree and descend one rule node horizontally if
the rule node returns a True and one node vertically if a rule node returns a false.
The following picture shows a logical picture of some of some arbitrary logic to illustrate
the concept:
139
Figure 13-3:Logical Representation Routing Example
The policy element will traverse the Rule Nodes until either 1) a treatment is encountered,
2) the tree is exhausted within the vertical column being traversed, or 3) A different point
in logic is called via Goto or GoSub (see below). From a provisioning perspective, policies
are traversed until a treatment is found. If no treatment is found, the routing engine enters
the next policy as configured in the execution order. In reality, the organization is really to
allow logical provisioning. The policy element actually compiles all routing policies in a
given plan into a first match tree for optimal transaction performance. If a route cannot be
found, the default clearing cause is No Route to Destination
The following figure provides a picture of the operator interface to provision routing logic
for a policy.
1310
Figure 13-4:Policy Configuration Screen
Routable Parameters
To offer maximum flexibility, the policy element exposes as many parameters to the operator as practically possible. The following is a list of the most common parameters used in
routing. For a more comprehensive list please consult the Customer Documentation or
contact Veraz Networks.
Call Processing Parameters
Bearer Capability (Of Ingress Point)
Call Reference
Called Party Number
Called Party Number - Nature Of Address (NOA)
Called Party Number - Number Or Network Indicator
Called Party Number - Number Plan
Caller Selected Carrier
Caller Selected Carrier - Present Flag
Calling Party Category
1311
1312
Calling Party Number - Nature Of Address (NOA)
Calling Party Number - Number Plan
Calling Party Number - Present Flag
Calling Party Number - Presentation Indicator
Calling Party Number - Screening Indicator
Carrier Selection Info
Charge Number
Charge Number - Nature Of Address (NOA)
Charge Number - Number Plan
Charge Number - Present Flag
DPC
FCI M Bit
GAP (Non-Ported) - Nature Of Address (NOA)
GAP (Non-Ported) - Number Plan
GAP (Non-Ported) - Present Flag
GAP (Non-Ported) - Type Of Address
GAP Number (Non-Ported)
Generic Digits
Generic Name
Generic Number
Generic Reference
IRI
IRI - Present Flag
IP Address
IP Port
ISUP Indicator
Location Number
MLPP Precedence
Network Specific Facility
OPC
Optional FCI
Orig ISC PointCode
Original Called Party Number
Original Called Party Number - Nature Of Address
Original Called Party Number - Number Plan
Original Called Party Number - Present Flag
Originating ISDN Access Indicator
Origination Line Information (OLI)
Ported Dialed Number
Ported Dialed Number - Nature Of Address (NOA)
Ported Dialed Number - Number Plan
Ported Dialed Number - Present Flag
Redirection Number
Redirection Number - Nature Of Address (NOA)
Redirection Number - Number Plan
Redirection Number - Present Flag
Remote Operations
Transit Network Selection (TNS)
Transit Network Selection Present Flag
Type Of Call
Time Based Parameters
Day of Month
Day of Week
Day of Year
Month of Year
Time of Day
Week of Month
Location Based Parameters
Ingress Point Country Code
Ingress Point National Destination Code
Ingress Point Time Zone
Ingress Point Type
Ingress Trunk Group
1313
Ingress ICE
CLLI - Local
CLLI - Remote
Media Gateway ID
Media Gateway Type
Logical Parameters
VPN - Present Flag
VPN ID
Special Parameters
Connection Request
Egress Service
Else Case
Go Sub
Go To
Random Percent
Return
Special Processing Request
Service Activation
Service Code Indication
Transaction Request
Special Parameters - Goto, GoSub, Return
To add flexibility as well as allow the operator to add structure to the routing tables, the
policy elements supports two extremely powerful parameters - Goto and GoSub.
When constructing routing logic, each Rule Node can be assigned a logical name. Once
defined, this point in logic can be called from any other point using Goto or GoSub.
When a Goto is called in routing logic, the jump is final - the policy element will continue
executing the routing logic from the indexed rule node as if it was any other logic - there is
no return to the calling point. The point indexed by the Goto can be at any point in logic in
any policy in any plan. This capability is primarily used to call repetitive or common
routing logic from an initial policy. For example, the root plan and policy may make an
initial qualification of a series of parameters and based on the result, it would call other the
root rule node of another policy in another plan.
A more explicit example is illustrated in the following figure.
1314
Figure 13-5:Example use of GoTo
In this example, the routing plan and policy in yellow is bound to Trunk Group X. This
plan performs a check to determine if the Calling Party Number is a known subscriber
number. If it is, it jumps to another plan that looks at dialed number and Carrier Code. If
not, it jumps to a different point in logic in another plan/policy that deals routing or
rejecting unknown Calling Party numbers.
GoSub performs a similar function however uses a Return statement to jump back to the
point in logic that called it.
The structure of this is completely arbitrary and up to the operator. The decision to use
Goto or GoSub and how they are used is primarily driven by the operators decision on
how to structure the routing logic.
Directory Lists
To again simplify repetitive provisioning, the ControlSwitch supports the concept of
Directory Lists in routing. This is list of numbers that are logically addressed by an operator configured name. This allows for routing logic to perform a check against a directory
list to determine if the number belongs to that group. This is extremely useful in the implementation of logic for functions such as subscriber checking, screening, and white lists.
Treatments - Route and Reject
At the end of any routing logic comes a treatment. In Release 5.4, the treatment is to either
Route the call or Reject the call.
1315
If the treatment is Reject, the operator can configure the cause code to return to the ingress
network.
For a treatment of Route, the operator can provision a number of route related attributes as
follows:
Egress Point
An egress point is a list of trunk groups that are to be used for the call. There is no
maximum number of trunk groups that can be added and all trunk groups in the network
are available in a pick list for routing the call. This includes IP-based routes via the ICE.
Features - Traffic Type
This is used to select whether the call is a modem call or voice call. This feature allows for
support of Universal Gateways.
Features - Codec List
This allows the user to provision a list of codecs supported for the call. All codecs are
available from the pick list and the operator may choose as many as desired. A weight may
also be added to allow a deterministic order of preference.
Note that at call time, the CCE uses the provisioned list from routing as well as the codec
lists associated with the actual physical trunk group to determine an intersection of valid
codecs for the call.
Egress Properties - Priority and Weight
When the policy element sends a route response, an ordered list of trunk groups is sent to
the requesting CCE. The CCE interprets the preference of the trunk groups as the order
they are sent in.
Priorities can be given to each trunk group in the egress point list. The policy element will
treat these as absolute priorities in that the highest priority trunk groups are always
returned with preference over lower priority trunk groups in the route response. If more
than one trunk group is assigned equal priority, the distribution across trunk groups in a
route will be equal over time.
Alternately, weights can be added to trunk groups within a given priority. This allows the
operator to control the distribution across trunk groups. Note however that priority is the
primary determining factor in trunk group preference, followed by weight, which controls
distribution within a priority.
1316
Route Advance Capability
The ControlSwitch is also capable of allocating a weighted random percent distribution

across treatments. This allows the operator to distribute calls across a number of treatments in a deterministic fashion, then within the treatment, distribute across trunk groups.
To illustrate, Home carrier could have trunks connecting to 3 carriers - X, Y, and Z. Each
carrier connection has multiple trunk groups connecting to Home carrier. A treatment
node could be provisioned for each carrier (X, Y, and Z) with each treatment specifying
the appropriate trunks and weight distribution to the trunks for the given carrier. Then,
using the weighted random distribution, traffic could be deterministically divided across
each carrier. For example, Carrier X gets 30% of all traffic, Carrier Y gets 50%, and
Carrier Z gets 20%. These distributions will be guaranteed to be accurate within one call.
Further, the distribution of traffic for the given carrier will also follow the provisioned
distribution.
Call Type
The call type option allows the operator to override the existing call type used when the
call is sent out the egress.
Charge Band
The charge band feature is used in India ISUP to set the time based charging parameters
for the calls.
VPN Support
VPN plans are fully supported on the ControlSwitch. Due to the number-agnostic nature
of the routing engine, the operator need only set the rules for the VPN numbering plan.
Route Advance Capability

The ControlSwitch now supports route advancing on H.323 and SIP calls. In the event the
far end rejects the call setup, the ControlSwitch will continue attempting subsequent
routes in the route list until it is either exhausted or a valid route is found. Carriers
performing least cost routing commonly use this feature.
VoIP Protocol Routing

The ControlSwitch supports full VoIP protocol routing for H.323 and SIP. The routing is
performed based on PSTN address when required (in H.323, a Gatekeeper may replace
this capability). To achieve this, Local IP Gateways are created trunk groups are associated with the local gateways. Once the local gateway association is made, the IP trunk
group becomes a completely routable entity within the PEs routing policy's and services.
1317
Local Gateways, ICE Platforms, and ICE Processes

To support IP routing, the system must have at lease one ICE platform. The ICE platform
is merely a physical host for ICE processes. The physical device can also represent other
elements such as CCPs.
Once the ICE Host is defined, ICE elements are created. These are actually the software
processes managing the protocol stacks and resources. There are 3 types of ICE elements;
IP Gateway -H.323 or SIP gateway / UA
OSP client - OSP authentication client
OSP Gateway - H.323 gateway that uses OSP authentication
Local Gateways (SIP or H.323) are then defined and associated to the ICE process created.
These represent logical gateways (either SIP UAs or H.323 Gateways) on an IP network
that can process calls.
IP trunk groups are then associated with local gateways for call management and routing.
Multiple trunk groups can be associated with a single LGW. The IP trunk group contains
trunk group call management parameters similar to that of a PSTN trunk group (such as
codec list, customer routing plan, digit analysis rules etc.). For call routing, the IP trunk
groups are used exactly as any PSTN trunk group.
Figure 13-6:Software Based LGW
1318
IP Trunk Groups
IP Trunk Groups
For call routing and call management purposes, an IP trunk group is created and bound to
a provisioned LGW or list of LGWs (with weight and priority across the list). The trunk
group configuration contains all the call processing related options such as custom routing
plan, codecs, digit analysis scripts etc. Once created, the trunk group becomes a call
processing capable entity that can have policies applied (routing, re-routing, etc.). Effectively the trunk group becomes the call processing entity within the ControlSwitch.
In the context of IP trunk groups, as mentioned above, multiple LGWs can be associated
with the TG along with weight and priority. This allows the operator to provision a predetermined call distribution across LGWs without have to provision it in routing. Alternately, a single LGW can be used in each TG then distribution can be provisioned in
routing.
H.323 Routing
Local Gateways are provisioned as mentioned in the previous section. The operator then
provisions whether the LGW is connecting to a Gatekeeper managed network or direct
signaled network.
GateKeeper Managed Network Routing
In a gatekeeper-managed network, the ControlSwitch (or ICE) acts strictly as an H.323
gateway. Consequently, for all calls going from the ControlSwitch to an H.323 destination
(LGW associated Trunk group is the egress trunk group), the gatekeeper is queried for
admission to the network as well as for the end IP address of the far end gateway. In this
configuration, routing is only performed in the ControlSwitch to determine the egress
LGW where the egress gateway is the ingress to the H.323 network (which is managed by
another entity - the gatekeeper).
GK discovery is supported and Alternate GK lists can either be provisioned locally or
from the GK.
Non GateKeeper Managed Network Routing
When the H.323 gateway is connected to an H.323 network that is not managed by a gatekeeper, the ControlSwitch makes all routing decisions. In this case, the trunk group is
provisioned with the Remote Gateway (RGW) destination IP address and port. When a
call is being sent to a far end H.323 network, and no gatekeeper is provisioned to manage
the network, the policy element will have destination IP address information of the far end
gateway and is consequently providing routing services across the H.323 network as well
for call from the ControlSwitch only.
Note, routing services are not provided to non- ControlSwitch entities. Other H.323 gateways that exist in the network cannot request routing services from the ControlSwitch.
Each non-ControlSwitch gateway will be required to receive routing services from
another point (or internally). Alternately, all calls from non ControlSwitch managed Gateways can send all calls to the ControlSwitch for processing and routing.
1319
OSP Routing
OSP or Open Settlements Protocol is a client-server protocol defined by the ETSI
TIPHON to establish authenticated connections between gateways, and allow gateways
and servers to transfer accounting and routing information securely. OSP allows service
providers to roll out VoIP services without establishing direct peering agreements with
other carriers. The protocol specifies a method for an originating gateway at a subscriber
carrier to request a termination point from the OSP server at the clearinghouse organization.
Veraz ControlSwitch offers OSP solution by providing an OSP client. The OSP client
communicates with an external OSP Server (e.g. Transnexus).
In an offered OSP solution following are the components involved
OSP Server: The OSP server provides a secure token-based signature to certify to
a terminating gateway that the call has been authorized and will be settled. The
OSP server provides a secure link between the gateways and server to transfer
accounting and routing information. The OSP server is an external component.
Veraz currently inter works with Transnexus OSP Server. However, any OSP
compliant server should be compatible with Veraz's OSP client.
OSP Server will augment the routing capabilities of ControlSwitch by using the
external server for routing information. It can also be used to provide authentication for call admission into ControlSwitch. In addition the OSP Server can be
used as a third party billing engine.
OSP Client: This is a Veraz Network Element. An OSP Client is an instance of the
Transnexus stack. Functionally it is similar to a Local Gateway as it resides in an
ICE platform.
Capability Exchange Server: This is a external component logically adjunct to a

OSP Server. Its responsibility is to determine to perform health checks on the OSP
client.
OSP Trunk Group: OSP trunk group is similar to a Gatekeeper Trunk group.
Similar functions like lock and unlock can be performed on the Trunk Group.
OSP capable H.323 gateways: A local gateway that is capable of communicating

with an
SIP Routing
SIP routing is identical to non-GK managed call routing except the call processing
protocol is SIP. Effectively, each trunk group is provisioned with LGW/RGW pairs. In the
case of SIP, the RGW could be the far end UA or a Proxy in the network.
1320
Route Advance
Route Advance
To ensure the highest call completion rates possible, full configurable route advance is
supported in the ControlSwitch through the Re-Route policy. Available parameters for reroute decision are the same as those available in base routing however the trigger for rerouting is a far end release after a call setup. For more information see Supported Policies.
Enhanced Routing Feature

Variable Support
Variable support will allow the operator to check routable parameters against a variable
instead of simply against static data. This will apply to all plans in routing.
Variables will be provisioned by the EMS. When a user creates a variable he will be able
to give it a name, an event type, a data type. Variables can also be marked as billable this
is described in the subsequent section. There are three steps of using this feature
Step 1: Create a variable (either inherit from existing routing parameter or create a new
parameter)
Step 2: Incase it is an altogether a new parameter, in a rule node policy assign the value of
the variable
Step 3: In another rule node policy use the variable for making decisions.
Example 1 'New Variable':
A new variable 'SLA' can be defined as a variable with values 'Gold', 'Silver' and 'El
Cheapo'. These are string values. Alternatively, numerical values can also be given.
1321
Figure 13-7:Example 1 New Variable
When defining a policy rule node, to use the variable support option, 'Assigning variable
to parameter' must be checked. Doing so, an operator can assign the value of the parameter
from the user defined values.
Once the values of the variables have been assigned in a rule node (e.g. based on which
trunk group the call came in), this variable can be used as a parameter in any rule node to
make routing decision for example if:
SLA='Gold' then route the calls to very high quality PSTN Trunk Groups
SLA='Silver' then route the call to low quality Trunks ISUP
SLA='El Cheapo' then route the calls to H.323 trunk groups
If the variable passed to any of these operators has a different type than expected the rule
node will return false; otherwise these rule nodes will return true.
Example 2 'New variables for Existing parameters'
Variable support feature can also be used for modifying values of routable parameters. A
list of these parameters is mentioned in Settable Parameters section. In this example,
Carrier Selection Info is changed. The user can define a variable 'Modified CSI'.
1322
Variable Support
Figure 13-8:Example 2 New Variables for Existing Parameters
When defining a policy rule node, to use the variable support option, 'Using variable' must
be checked. Doing so, an operator can assign the value of the parameter from the
supported parameter values for example if:
Traffic came in via Trunk Group A then CSI can be set to Pre-subscribed and not
input by party
Traffic came in via Trunk Group B then CSI can be set to Pre-subscribed and
input by party'
1323
Figure 13-9:Rule Node Configuration Screen
Settable Parameters
The following parameters can be set within routing in the Routing GUI:
Bearer Capability
Called Party Number
Charge Number
GAP
Ported Dial Number
Redirecting Number
TNS
VPN ID
Carrier Selection Info
Original Called Party Number
These parameters can be set using variable support as illustrated in the Example 2 of Variable Support
1324
Mark as Billable
Mark as Billable
An operator will be able to mark any of the variables he has declared as billable.
Upon processing routing or service trigger requests, the Policy Engine will check to see if
any variables have been marked variable. It will send a string to the SEE with the
following format (italicized variables will be replaced with actual data):
<Pol>
<GrpId-PlanId-PolicyId
NodeId_VarName="xxx" NodeId2_Var2Name="xxx" />
(repeat as necessary for multiple policies)

</Pol>
This data will eventually be incorporated into CDRs.
Skip Routing
This feature enables skipping unwanted nodes of the Routing tree without having to delete
the unwanted nodes. This feature provides operational convenience for routing administration.
Skip routing is achieved by deactivating a rule node. An admin state will be added to all
rule nodes and treatment nodes. When deactivated the rule node icon will be bordered in
red. If a rule node is deactivated, the Policy Engine will process its sibling node (just as if
the rule node had returned false). If a treatment node is deactivated the Policy Engine will
behave as if no treatment node has been reached in the policy.
Satellite Aware Routing

Trunk groups now have a new flag: Satellite. This flag can be configured in the EMS
and it indicates if that given Trunk Group link should be considered a satellite hop.
Using this feature, the Policy Engine will be aware of the number of satellite hops the call
has already gone through.
The new sat hop count will either be the original sat hop count or the original sat hop
count with one incremented to it depending on whether the egress trunk group is marked
as a satellite TG or not.
In routing, a new routable parameter has been added - SatHops. Any of the normal
numeric operators can be used on this parameter. The SatHops parameter will contain
whatever integer was passed in the Routing request.
This new routing feature tells the PE the maximum amount of sat hops that can be taken. If
the new sat hop count is greater than the max sat hop count the PE will remove that trunk
group from the list of valid egress points.
Satellite hop values can be following:
00 No satellite circuit in connection
01 One satellite circuit in connection
1325
02 Two satellite circuit in connection
03 Three or more satellite circuits in connection
Translates To Feature
The Translates To operator can be used on any phone number (Called Party Number,
Calling Party Number, Charge Number, Redirecting Number, GAP, and ODN). This
feature requires a new table type to be provisioned in the EMS.
An example entry in the table will looks like:
Table 13-1 Table Type for Translates To Feature
Orig
Number
Orig
NumberPlan
Orig NOA
New
Number
New
NumberPlan
New NOA
1408111000
ISDN
Intl
14081110001
ISDN
Intl
1408999999
ISDN
Intl
16501234567
ISDN
Intl
When the 'Translates To' operator is called, the Policy Engine will check to see if the
number it is checking (CPN, ODN etc.) is present in the translation table. If it is, the Policy
Engine will modify that routable parameter to match the new entry (Digits, Numbering
Plan, and Nature of Address (NOA)).
Class of Service
This feature addresses prevention of call looping back when calls are routed by
ControlSwitch. This looping of calls occurs for the Inter Exchange Carriers since their
ingress and egress routes sometimes belong to the same carriers. An IXC typically
attempts to avoid such loop back calls within a carrier by implementing COS or Class of
Service feature.
In ControlSwitch, COS is implemented using exclusion list on a Trunk Group. The exclusion list (like a PSTN hand off list) can be provisioned by an operator. One can select the
Trunk Groups to be excluded during the routing. Additionally, in the treatment node the
exclusion can be overridden if required.
1326
Release Cause Override After Announcements
Release Cause Override After Announcements

This feature allows an operator to change the release cause sent out after an announcement
has been played. Currently, after an announcement is played 'normal clearing' is sent out
as the release cause. In 5.5.3, an operator can use Routing GUI to override the release
cause when configuring announcements for release causes. Two new treatment fields will
be added to the already existing 'reject' treatment - announcement plan and announcement
name. These features are not required, and, if set, the user will hear an announcement
before the call is released with the cause code set in the reject treatment. The
ControlSwitch will not send out a REL until the announcement is completed. This function is present in every plan group type except for Announcement plans.
1327
1328
Supported Services
Chapter 14
This chapter provides details about services supported by Veraz Networks. The following
Service Trigger Plan Group Interface
Account Code Services
Personal Toll Free
Security Toll Free
C Tone Service
Tariff Announcements
International Dialing Service Using Voice Menu
Collect Call
Software Optionality Control (SOC) for Services
141
Chapter 14: Supported Services
Using the Services Execution Environment, services can be created through XML.
Services are created by linking Service Building Blocks or SBBs. SBBs are essentially
XML logic created within the scope of the ControlSwitch Services API. An SBB can be as
complex or as simple as required - for example, an SBB could define something as simple
as playing an announcement or as complex as a complete IVR system. SBBs are then
linked together to create a higher layer Service to the end user. The amount of complexity
in an SBB is primarily a function of the desired long term extensibility required by the
SBBs. Ideally, SBBs are created in such a way that their function is generic (like playing
an announcement) however when linked within the context of a service, become unique.
SBBs and Services are currently created and supported by Veraz Networks or accredited
third party and not exposed for end user manipulation.
Service Trigger Plan Group Interface

Services are triggered through the Policy Element. The policy element can support
multiple policy queries and executions within the context of a single call enabling multiple
trigger driven services. To achieve this, the PE supports user configurable Service Trigger
interface. This is modeled in a similar fashion to the interface used for routing however
treatments identify a service to be executed. The Service Trigger Plan Group is modeled
after the AIN 0.2 call model and uses standard trigger detection points and trigger types to
identify a Point in Call. Multiple Services can be triggered for any call.
Currently the supported service trigger plan types are:
OFFHOOK_DELAY
SHARED_IO_TRUNK
ORIGINATION_ATTEMPT
Service trigger plans are provisioned in the same way as routing and support all of the
parameter options and flexibility available in routing. However, rather than identify trunk
groups to route a call too, the Service Trigger plan identifies a service to execute (although
this service could also identify routing).
Supported Service Trigger Treatment types

The following are the currently supported treatments in service trigger plans;
142
ROUTE Route the call with optional Routing Plan.
REDIRECT Redirect the call to the new number
REJECT Reject the call with the CauseValue
ANNOUNCEMENT Play the Announcement and release the call.
ACCOUNTCODE Do the AccountCodeCollection
SECURITYPIN Do the SecurityPinCollection
Policy Execution
PERSONALPIN Do the PersonalPinCollection
OSP Do the OSP Authentication
Policy Execution
When a call request is passed to the PE, policies are traversed in the following fashion;
Triggers Plan's
Custom Service Triggers
System Service Triggers
Routing Plan's
Custom Routing Plans
System Routing Plans
Failure to encounter a match at any policy will lead to traversal of the next priority policy.
Account Code Services

Three types of account code services are available as follows;
Non-Authorized
Non-authorized account codes are a 2 stage dial application whereby the end user is
prompted an announcement / tone (specified in the APB) after DN dialing has completed.
At this point, the user is to enter an account code. The account code is then logged in the
CDR and the call is processed.
Authorized
This is the same as Non-Authorized however the dialed account code is compared against
a list of provisioned account codes. If the account code matches, the call proceeds and the
account code information are logged in the CDR.
If authorization fails, an error announcement is played and the user is re-prompted. Failures can take place a provisionable number of times (provisionable against an account
code list/group). Any subsequent failures will result in the call being disconnected. The
CDR should indicate account code authorization failure.
Authorized With Pin
It is the same as Authorized, however in addition to Account code Pin is entered and validated against the Account code policy.
143
Provisioning
Account codes are provisioned through the EMS GUI through Authorization Services.
Account Codes are administratively configured in a hierarchical fashion beginning at the
business level. Within the context of the business, there are business units. A business can
contain as many business units as required.
Business Units contain service groups (which can be mapped to concepts such as division
or department). Business Unit is simply a logical grouping of Service Groups for flexibility in management. A BU can contain as many Service Groups as required
A service group is one or more account code and (if required), pins associated the account
code or set of account codes. The relationship allows 1 to 1, many to 1, 1 to many, or
many to many associations.
The provisionable attributes at each level are;
Business
Name
Description
Admin State
Max Attempts
Business Unit
Name
Description
Admin State
Max Attempts
Service Group
Name
Description
Admin State
Account Code(s)
144
Authorization Pin(s)
Provisioning
Personal Toll Free

Personal toll free allows a caller to dial a pre-determined toll free number. A PIN is
entered (after an announcement / tone or before an announcement / tone) and authenticated. Upon verification, the called party number is translated to an associated real DN
and the call is processed through routing. The mapping of toll free number to Pin is 1 to
many
Provisioning
The root of all provisioning begins at the toll free number assigned. Each toll free number
has an administrative state and associated name for record keeping. Below toll free
number is a list of PINs, each with an associated translated number that the toll free
number and pin combination match.
The provisionable attributes at each level are;
Toll Free Number
Name
Admin State
Max Attempts
Pin
Account Number
Translated Number
Nature of Address
Numbering plan
Admin State
Routing will be done on the Translated number.
Security Toll Free

This is similar to personal toll free however the toll free number is unique to the end
customer. A given unique toll free number is dialed and a PIN is entered. Upon successful
authentication, the call is processed either using a translated number and subsequent route
lookup OR directly mapped to a trunk group using the original dialed number. Optionally,
original dialed number can be carried in the Generic Address Parameter if required.
145
Provisioning
Administratively, the service is identical to Account Codes with the exception of the
Service Group Level (see account codes).
Service Group
Name
Description
Admin State
Toll Free Number
Pin(s)
Translated Number
Nature of Address
Numbering Plan
Original Dialed Number Handling
C Tone Service
C Tone service generates a specific tone towards the originating side when a call is
connected to enable billing. This service is used in Hotel PBXs that need this tone to start
billing. The service will be enabled per trunk group basis for which such tones need to be
generated.
Tariff Announcements
Tariff service comprises playing tariff announcements for national or international long
distance calls. The announcement is played during the 'ringing' period of a call and it
comprises per minute charge, charge after specified interval of time, and setup fee.
Tariff announcement can be based on Time of the Day, Day of the week, and Dial Codes
(A combination of country code and area code).
The following diagram shows the flow of this service:
146
Provisioning
Figure 14-1:Tariff Announcement Call Flow
147
International Dialing Service Using Voice Menu

This service allows valid consumers to place international calls by using a voice menu. A
consumer can place calls using a premium or a toll-free number. Voice menu guides the
user to listen to service information, place a new call and handle error scenarios.
A few salient features of the service:
Every Premium number allows a set a International Destinations
Billing starts immediately
No PIN numbers necessary
User friendly voice menu guides the user
When an invalid country is dialed voice menu prompts for the new Premium
number to be dialed
The voice menu also has a help option
A consumer will register online with ones credit card information and choose the destinations with desired rates. Doing so, one gets a premium or toll free number.
The diagram on the following page shows the service flow:
148
Provisioning
Figure 14-2:International Dialing Service Using Voice Menu
149
Collect Call
Collect call service entails a user calling a toll-free number. The user is greeted with a
welcome message and is prompted to press the DTMF digits for the destination party.
Once the destination party is connected, it hears a message with the calling party's name
on the phone and chooses to accept or reject the call. The Billing for such calls has a
reverse charge indication for the called party charging.
An operator option is also provided following the greeting message. This option can be
used incase a person wants to use an operator to dial the collect call. For this option, the
ControlSwitch simply forwards the call to a pre-configured number or a trunk group.
A call flow diagram for the service is shown in the following page.
1410
Provisioning
Figure 14-3:Collect Call - Call Flow
1411
Software Optionality Control (SOC) for Services

Currently, licensing is provided on the ControlSwitch for the media gateways, protocols,
and scale. The EMS GUI allows only the licensed models to be selected to create gateways. Similarly only licensed signaling protocols are allowed to be used in Trunk groups.
In addition, enhanced services will be licensed to the customers.
The following entities will be controlled by SOC to license the enhanced services
Front Pages that use Service Building Blocks (SBBs)
Policy Engine Plan Types.
Policy Engine Treatment Types
Veraz Networks will re-issue all customer licenses and proper care needs to be taken to
enable the licensed services that are needed for tandem calls. The following services are
available and can be licensed for enabling each:
1412
Collect Call
International Dialing with interactive menu
Charge/Tariff announcements
Lawful Intercept Solution for

Tandem
Chapter 15
This chapter describes the Veraz Lawful Intercept solution for Tandem. The following
Components in the solution
Veraz ControlSwitch Components:
MGW Component:
Verint Components:
Functional Description
Solution's Capabilities
151
Chapter 15: Lawful Intercept Solution for Tandem
Lawful Intercept Solution will be provided by ControlSwitch in this release for tandem
networks.
Veraz is providing Lawful Intercept solution using Verint as a partner. Verint's StarGate
product provides connectivity to the legal enforcement agency (LEA) and to the surveillance administration. ControlSwitch connects to StarGate with two interfaces: TDM based
loop via the Verint Loop Device for call delivery and IP based interface for provisioning
of interception targets.
An operator provisions Lawful Interception related information to the Verint StarGate.
The StarGate then provisions Veraz ControlSwitch with necessary interception data.

Veraz ControlSwitch Components:
Lawful Intercept Data Access Point (LIDAP)

LIDAP is a new network element managed by Veraz ControlSwitch, introduced to
perform interception functionality. LIDAP communicates with Verint StarGate mediation device for assignment of the target information into a database. It replies to
queries from Service Execution Elements (SEE) whether the call shall be tagged for
interception. LIDAP stores the target information into a database.
Policy Engine (PE)

The Policy Engine provides the Routing information about trunk groups forming
connection to Verint Loop Device
Element Management System (EMS)

The EMS manages all the elements of the ControlSwitch, including LIDAP. It provisions the PE with the trunk group information for Routing to the Verint Loop Device.
Service Execution Element (SEE)

The ControlSwitch SEE queries the LIDAP whether a call shall be tagged for interception. Lawful Interception is configured as a service in ControlSwitch. To implement the service, the Services Framework is used with XML logic on the SEE and
service data and service triggers provisioned on the PE.
Call Control Element (CCE)

CCE provides media control, signaling, call control, services and billing functionality
for VoIP network. It instructs the Media Gateway (under control of the SEE) to
connect the call through the Verint Loop Device.
ControlSwitch Signaling Gateway (SG)

SG interfaces with the Verint Loop Device using SS7 ISUP protocol.
MGW Component:
152
Media Gateway
Media Gateway provides media conversion between circuit and packet switching
networks. If the call is a subject for interception in it through-connects the call to
Verint Loop Device under control of CCE. Required Media Gateway functionality is
based on Veraz I-Gate 4000 series gateway.
Verint Components:
Loop Device (LD)

LD is a switching matrix device that assigned with its own SS7 signaling Point Code
(PC). It receives tagged calls via dedicated trunk group and is capable of rerouting
them back to the ControlSwitch while splitting voice path and SS7 signaling toward
StarGate Mediation Device (MD) for formatting and delivery.
StarGate Mediation Device (MD)

MD consists of two major elements. Call Data Delivery Function (CDDF) and Call
Content Delivery Function (CCDF). CDDF analysis SS7 signaling messages received
from ControlSwitch via Loop Device, extracts Call Data information and delivers it to
LEA and controls the CCDF. CDDF receives interception related information from
Surveillance Administration Subsystem and it is responsible to assign targets in the
LIDAP.
The CCDF is a switching matrix that passes the SS7 signaling to the CDDF, and if
required by CDDF through-connects the call to LEA.
Surveillance Administration Subsystem (SAS)

SAS provides centralized control over system administration and system maintenance.
It comprised of two optional modules: Global System Administration Server (GSA)
that controls system administration, target assignment and security functions; and
Maintenance and Fault Management Server (MFM) that oversees system operation.
The MD and LD components are illustrated in the diagram below
153
Figure 15-1:MD and LD Components
Functional Description
This section explains how a call is intercepted in the solution.
154
Figure 15-2:LIDAP Diagram
Lawful Interception is implemented as a service.With every call attempt (call request), the
ControlSwitch checks whether the calling/called numbers matched the complete number
or prefix in target database. In case of a match, the ControlSwitch connects the call to the
LI Loop Device as well as the destination network. The service flow is as follows
155
Call Flow
1. The EMS provisions the PE with the trunk group information for routing to the Loop
Device
2. Mediation Device provisions the target information to the LIDAP.
3. LIDAP stores the target information into a database.
4. The ControlSwitch SEE queries the LIDAP whether current call is a subject for interception.
5. If the call is tagged as a subject for interception, SEE requires the information about
trunk group forming connection to Loop Device from PE
6. SEE instructs corresponding CCE to establish a call.
7. CCE instructs the SG and MGW(s) to connect the call through the Loop Device.
8. SG interfaces with the Loop Device using SS7 ISUP protocol. Loop Device sends all
SS7 messages back to the SG just replacing information in routing label.
9. The Originating media gateway sets a connection with Media Gateway that has trunks
dedicated for connection to the Loop Device. The Loop Device sends the call back to
the LI Media Gateway in another trunk.
10. The Loop Device duplicates signaling and media flow on internally created loop and
delivers the information to the Mediation Device. The MD collects the SS7 signaling,
analyzes it and extracts valuable information required to create Call Data (CD). The
MD then delivers the CD and when necessary the Call Content (CC) to the proper
Legal Enforcement Agency, in compliance with the ETSI or CALEA standard.
(ControlSwitch sends Call Content and Call Data together and MD decides whether to
deliver a) Call Data only b) Call Content + Call Data)
When the call comes back from the Loop Device, normal call treatment and routing
continue.
Solution's Capabilities
Table 15-1 Solution Capabilities
156
Number of targets per SAS
20.000
Number of targets per MD
4,000
Table 15-1 Solution Capabilities

Number of targets Veraz can be
provisioned with
100,00
Calls/second
4
This is the call rate between Veraz and
Verint after the calls are filtered on the
Veraz ControlSwitch.
Requests per second
2000 on Netra240 for 100,00 targets

This is the rate of requests between the
LIDAP and the SEE components of the
Veraz ControlSwitch.
Maximum Concurrent calls per MD
480
Security Considerations
The following functional areas have special security considerations for Lawful Interception:
Billing
For a call that is traced within ControlSwitch, no information regarding interception
should appear in the billing records in both iCDR and BAF.
Provisioning
Access and administration to LI related components in the Veraz EMS GUI is
restricted to users other than the ones with privilege for LI administration. Once an LI
user is created, only that user is allowed to
Access to LI admin menu
Provisioning and administration of LI menu
Administering LI TG
Call Trace
For a call that is traced within ControlSwitch, no information regarding interception
should appear in the call traces.
Physical isolation of LI platform

The platform communicating with Verint MD should have capability of being physically isolated. Thus, LIDAP can be physically isolated platform with all necessary
hardening measures applied.
Standard Specifications Reference:

TS 201 331. Lawful Interception (LI). Requirements of Low Enforcement Agencies.
ETSI, 2001
ES 201 158. Lawful Interception (LI). Requirements for network functions. ETSI, 2002
157
ES 201 671. Lawful Interception (LI). Hand over interface for the lawful interception of
telecommunications traffic. ETSI, 2001
ANSI/J-STD-025-A-2003, Lawfully Authorized Electronic Surveillance. ANSI, 2003
158
Call Processing
Chapter 16
This section describes the fundamental call processing functions that take place in the
system. The ControlSwitch interacts with multiple components during normal operation.
Interactions with media gateways and the PSTN occur over standardized interfaces, such
as MGCP, H.248/MeGaCo, H.323, SIP, SS7, ISDN and CAS. The important interactions
among these are described in this section. The following topics are included in this
chapter:
Test Line Operations
Media Gateway Support
VoIP and Related Protocol Conformance
161
Chapter 16: Call Processing
Test Line Operations

The ControlSwitch is able to terminate test line operations, but not originate them. The
ControlSwitch and an attached media gateway terminate these tests coming from other
PSTN switches. Other test-line tests exist, but only tests - 100, 102, 108 are typically
supported by media gateways. Other tests may be added in later releases on a customerrequest basis as and when these capabilities are supported by partner media gateways.
Support for test line operations has a dependency on media gateways.
T100 Test Line Operation

100-Type Test Line - Quiet termination: This test involves a call being made from one
switch to another to create a voice path. After the voice path is connected on the terminating switch, the terminating switch plays a 1000 Hz tone for 5.5 seconds to measure
one-way loss, balance, and noise. Then only silence is heard to measure balance and noise
until the originating line completes the test and disconnects.

102-Type Test Line - Milliwatt: This test involves a call being made from one switch to
another to create a voice path. After the voice path is connected on the terminating switch,
the terminating switch plays a 1004 Hz tone to measure one-way loss. The 1004 Hz tone is
started and stopped at regular intervals until the originating line completes the test and
disconnects.

108-Type test Line - Non-inverting Loop back: This test involves a call being made from
one switch to another to test the voice path. At the terminating switch a loop back is
connected using a 64kbps clear signal in which the position of all bits in the digital signal
are preserved. The originating switch can test many bearer capabilities over this line by
sending a signal and expecting to receive the same signal back via the loop back. This test
can be used to test bearer capability using 56kbps, 64kbps restricted, or 64kbps clear
connections.
162
ControlSwitch / Media Gateways VoIP Interoperability
Media Gateway Support

The design of the ControlSwitch system has been based on an envelope-free objectoriented substrate that was especially crafted to permit the incorporation of new media
control protocols. The underlying call models are implemented with disciplined adherence
to a philosophy of independence from the signaling and media gateway control protocols.
This combination of an object-oriented design and a protocol-independent call model,
makes it possible to incorporate new protocols into the ControlSwitch system with relative
ease. This has allowed us to focus our attention on the more significant issues of call
interoperability between media devices based on the older and newer emerging protocols.
ControlSwitch / Media Gateways VoIP Interoperability

The following table lists the media gateways, feature servers, and their associated VoIP
protocols tested with the ControlSwitch. In some cases, additional QA testing would be
required to ensure alignment with the latest vendor software release.
163
Figure 16-1:Media Gateways and their associated VoIP protocols
ControlSwitch / Media Gateways PSTN Interoperability

The following table lists the media gateways, feature servers, and their associated PSTN
protocols tested with the ControlSwitch. In some cases, additional QA testing would be
required to ensure alignment with the latest vendor software release. Please contact Veraz
Networks for information on software releases and updates needed.
164
AudioCodes Mediant 2000 Support
Figure 16-2:Media Gateways, feature servers and their associated PSTN protocols
AudioCodes Mediant 2000 Support

Mediant 2000 Media Gateway is controlled via MGCP and can be configured on the EMS
GUI. The ports on the Mediant 2000 will be supported for PRI and ISUP terminations.
Both E1s and T1s will be supported. The maximum number of spans supported are 8 of
each. Following are salient features of the support
IUA over SCTP will be used for PRI session control
upto 8 D-Channels on a single Mediant 2000 gateway
NFAS D-Channels will be supported for NI-2 PRI. Also, primary and backup Dchannels shall reside on the same gateway
MGCP 1.0 will be used for controlling the media gateway
Pooling of upto 50 Mediant 2000s per MGCP port will be allowed
165
ISUP COT will be supported
Exceptions:
Fax will not be supported with MGCP-fxr package. Inband fax will depend on
interoperability (t.38 will be supported for calls between Mediant 2000 and
IGate4000/PRO)
Announcements will not be supported
CAS packages are not supported
Testline will not be supported
ControlSwitch will communicate with Mediant 2000 with single or dual IP

address
Mixing of E1s and T1s will not be allowed
Mid-Call DTMF shall be supported for H.323 and SIP interworking
Local Ring back will be supported for H.323 and SIP interworking
Codec list supported for Mediant 2000 shall be same as that of I-Gate 4000
VoIP and Related Protocol Conformance

MGCP
The ControlSwitch complies with the following MGCP standards where applicable for the
application;
MGCP version 0.1 (draft-huitema-megaco-mgcp-v0r1-01.txt)
MGCP version 1.0 RFC 2705.
Cisco Systems: IOS MGCP Interface Specification, ENG-64903, Rev. G.
draft-foster-mgcp-nas-03.txt
RFC-3064 - MGCP CAS Packages. B. Foster. February 2001
draft-foster-mgcp-basic-packages-06.txt
draft-foster-mgcp-returncodes-00.txt
ISDN User Adaptation - IUA

IUA is supported per rfc-3057 IETF standard. This is used for back hauling of Q.921 user
messages (Q.931) for termination and processing of the ISDN layer 3 D-channel
messages. This includes support for both standard and NFAS groups.
The following figure illustrates the protocol model.
166
Stream Control Transmission Protocol - SCTP
Figure 16-3:ISDN User Adaptation -IUA
Stream Control Transmission Protocol - SCTP

The ControlSwitch supports SCTP based on IETF standard rfc-2960 for giving reliable
transport to IUA protocol. Please see the section on IUA for an illustration of the protocol
model.
MTP3 User Adaptation (M3UA)

The ControlSwitch supports M3UA based on IETF draft version 5 of rfc3332. This
protocol is used to back haul MTP3 user messages (ISUP and SCCP) between a Signaling
Gateway and the ControlSwitch SAS element. Current interoperability support can be
found in Section 11.4.
H.323 Support and Interworking

The ControlSwitch supports the following H.323 standards for interworking between
H.323 networks and other networks and appears as a gateway in the network.
H.323 v4
The intent of H.323 interworking is to enable peering between H.323-based systems and
those based on the next generation media protocols such as MGCP, H.248, and SIP. More
specifically, this capability provides call control interoperation between two VoIP
networks (although these can be on the same IP network). Support is basic call support
between two media gateways, one under H.323 control, and one controlled using MGCP
or SIP (or other gateway control protocol). It is possible to also use the ControlSwitch for
H.323 to H.323 call routing. This would primarily be done for billing consolidation or GK
off load.
167
The ControlSwitch can function in a GK managed or unmanaged network. In a GK

managed network, all routing decisions from the ControlSwitch (ControlSwitch to H.323)
are made by the GateKeeper. In an unmanaged network, the ControlSwitch policy element
makes all routing decision locally and determines the end H.323 Gateway destination IP
address.
Note H.323 support does not imply interoperability. Due to the varied level of
H.323 compliance from vendor to vendor, interoperability can only be ensured
through qualification within Veraz Networks test environment. Please contact
Veraz Networks to determine if a given vendor, model, and software release is
currently supported.
H.323 Incoming ECS support
ControlSwitch will now accept incoming ECS messages. Incoming ECS or Empty Capability Set is applicable in cases such as call hold for protocol interoperability.
H.323 OSP SIP Originating and Terminating IP Address

For OSP terminating or originating calls, the billing indication will carry SIP source or
destination IP address if the call connects to SIP Application server on the SIP side.
This IP address can be used in the OSP server for billing purposes.
H.323 Reconnect Feature

In H.323 trunking deployments, we see scenarios where H.323 calls are terminated to SIP
based application servers such as the calling card application. Such applications on SIP
typically involve features such as call transfer after the media session has been established. Thus the SIP application answers the H.323 originated call, sets up the media path
and then subsequently transfers the call to another destination. This requires the SIP application to send a modified SDP or media description back to the originating H.323 edge so
that the media session can be appropriately be re-established. Reconnect feature exactly
address this.
This feature is invoked after the media session is already established for a H.323 call. For
example, a SIP-H.323 call that is in answered state, if SIP sends a re-INVITE containing
an SDP with a different codec that the one used on the active media session, the H.323
ICE needs to tear down the existing H.245 media session and establish a new session as
per the modified SDP information. Before, such a session can be established the
ControlSwitch shall make sure that the new SDP conforms to the negotiated codec list for
this call.
168
Session Manager Protocol
Session Manager Protocol

The ControlSwitch supports redundancy at the device level as well at the network level.
Session Manager manages the multiple network paths between the ControlSwitch and the
media gateways, using session groups. Within each session group, there will be a primary
session and a backup. If the RUDP connection on a given session is lost, Session Manager
will automatically switch traffic to the backup session on the redundant network. Likewise, if the primary ControlSwitch fails, Session Manager transfers control of the entire
session group on that platform to the secondary ControlSwitch.
The ControlSwitch will support multiple session sets, to allow a higher messaging rate
between the controller and the media gateway than a single session set would allow.
The ControlSwitch uses Session Manager and RUDP on one leg, and MGCP on the other
leg for the interfaces between itself and the media gateways. For the interfaces between its
own elements, it uses SCTP. Additionally, Session Manager and RUDP are not coupled
with MGCP traffic, which is sent independently between the ControlSwitch and media
gateways. To this extent, Session Manager and RUDP traffic will not be exercised in
many call flow scenarios, such as VoIP, VoATM, and IMT to IMT tandem.
Reliable UDP - RUDP

RUDP is used to give reliable transport to the Session Manager protocol when controlling
ISDN links on Cisco based Media Gateways. The base reference for RUDP is:
draft-ietf-sigtran-reliable-udp-00, 25 February, 1999
However, significant extensions to the base RUDP specification have been implemented
per the Cisco Corsair interface specification.
The actual implementation of RUDP by Cisco and by the ControlSwitch is slightly
different from that specified in this specification.
RUDP is a connection-oriented protocol that offers a greater level of reliability than UDP,
using mechanisms for flow control, sequenced packet delivery and retransmissions on
error. Its level of reliability is comparable to that of TCP. It differs from TCP in that
packet boundaries are well defined, and there is no need to perform byte counting.
When RUDP detects an irrecoverable error, it performs a session reset, and sends an indication to Session Manager, which then proceeds to transfer the traffic to the alternate
session in the same session group (i.e. on the redundant network), or to a session group on
an standby platform, if the entire session group is down (due to platform failure, for
example).
SIP Support
The ControlSwitch supports SIP standards where applicable for the application acting as a
User Agent Client/Server:
RFC
169
RFC3261 Base SIP RFC
RFC2806 URLs for telephone calls
RFC297 INFO Method
RFC3262 PRACK
RFC3311 UPDATE Method
RFC3323 SIP Privacy
RFC3324 Short Term Requirement for Network Asserted Identity
RFC3325 Trusted Private Networks and SIP
RFC3326 Reason Header
RFC3264 Answer Offer model
RFC3372 SIP(T)Comply (Translation method)
RFC3398 ISUP to SIP mapping
RFC3515 Refer Method
RFC3824 Using E.164 numbers with SIP
RFC3840 Indicating user agent capabilities
RFC4028 Session Timer
IETF DRAFTS
draft-levy-sip-diversion-07 Diversion with Privacy
draft-ietf-sip-session-timer-12 Session Timer Implementation
draft-ietf-sip-privacy-04 Simple privacy with remote-id
draft-ietf-sipping-3pcc-05 Best Practices
draft-ietf-sipping-mwi-04 Message waiting interaction
draft-ietf-sipping-realtime-fax-01 Best Practices for fax
draft-ietf-sip-cc-transfer-02 to -04 Call Transfer Method 2-4
draft-yu-tel-url-07 Tel URL draft
draft-ietf-sipping-mwi-04 Message waiting interaction
SIP support is added for bridging PSTN users to SIP feature servers, and application
servers. Note that the above specification support is to the extent required for supported
applications. Please contact Veraz Networks for more detailed information if required.
1610
SIP Support
Note SIP support does not imply interoperability. Due to the varied level of
SIP compliance from vendor to vendor, interoperability can only be ensured
through qualification within Veraz Networks test environment. Please contact
Veraz Networks to determine if a given vendor, model, and software release is
currently supported.
SIP Transaction Layer
SIP Transaction Layer Enhancement is an architectural change to the ICE platform which
enables ICE to handle multiple transactions at the same time. The most useful application
of transaction layer is the capability of handling more than one transaction before session's
establishment. Thus, if a call is still being established and the ICE receives a new request
with new media information, with transaction layer implementation the ICE can accept
and act on the new request appropriately.
This handling of multiple requests is particularly useful for SIP methods like UPDATE
per RFC3311, PRACK per RFC3262 and Offer-Answer model per RFC3264. The
following features will be enabled because of transaction layer in the subsequent release
PRACK method receiving and sending
UPDATE method
Answer Offer Model
Reason Header
SIP error codes are represented by 4xx methods or messages. These error codes are sent in
response to a SIP request sent to the far end. 4xx is sent in response to INVITE, or another
request.
However, to send cause codes within a release of a call or within a CANCEL (initiated by
the party the initiated the call), reason header is used. SIP Reason header is with CANCEL
and BYE messages. This feature will allow the SIP ICE to both accept a reason header as
well insert a reason header in BYE or CANCEL message. Configurability on the trunk
group will be provided to provide Q.850 mapping or SIP mapping for cause codes.
1611
Diversion Support
Veraz support for SIP Diversion is being enhanced in this release. A redirect server in the
SIP terminology is defined as A user agent server that generates 3xx responses to
requests it receives, directing the client to contact an alternate set of URIs
When 3XX is received by ControlSwitch it is required to perform certain actions. These
actions are described in detail in draft-levy-sip-diversion-08 . The following operations
will be performed:
Diversion header will be copied from the 3XX into the new outgoing INVITE
Relevant parameters will be mapped to the PRI or the ISUP side. These parameters include redirection number, Original Called Party Number, Original redirection reason, redirection counter, presentation indicator, and screening indicator
Redirection
RFC3398 Section 1.6.15 explains mapping of ISUP and SIP call processing particularly
when redirect is received from the SIP remote end. The 3XX redirection ought to be
mapped to a CPG message with relevant mapping of the event codes. For example, a CPG
should be sent out to the PSTN side comprising information that the call is being
forwarded.
For interoperability purposes this behavior is configured on a SIP Trunk Group.
Privacy Updates
Privacy is basically restricting passing on identity of a person (and related personal information) in a SIP dialog. Privacy in today's SIP network is implemented based on
the newer IETF RFCs using asserted identity or
the older draft-ietf-sip-privacy-04.txt based privacy headers
Privacy on the Veraz ICE is being enhanced to adhere to the latest privacy RFCs
(RFC3323 and RFC3324) for SIP and also be backward compatible with already
supported privacy defined in draft-ietf-sip-privacy-04.txt.
The term asserted identity is derived from RFC3324 and RFC3323; the following extracts
from the drafts make it clearer:
RFC3323 When a user voluntarily asserts an identity in a request, they are claiming that
they can receive requests sent to that identity in that domain. Strictly speaking, privacy
entails the restriction of the distribution of a specific identity and related personal information from some particular party or parties that are potentially recipients of the message
RFC3324 A Network Asserted Identity is an identity initially derived by a Session Initiation Protocol (SIP) network intermediary as a result of an authentication process. This
document <RFC3324> describes short term requirements for the exchange of Network
Asserted Identities within networks of securely interconnected trusted nodes and to User
Agents securely connected to such networks.
1612
SIP Support
A SIP Trunk Group will have configurability for seamless interoperability with different
privacy implementation on the remote SIP endpoints/servers. The options available are:
request privacy/asserted identity
accept privacy/asserted identity
which privacy mechanism is supported
PSTN Interworking Updates From RFC3398

RFC3398 (7.2.1.1, 8.2.1.1) describes how many of the ISDN parameters present on the
PSTN side can be still retained in an INVITE on the SIP side. Preserving these parameters
provides SIP-T translation functionality. Veraz ICE is responsible for translating these
parameters when calls are transferred across PSTN and SIP domains.
The following parameters will be translated across SIP when received at the PSTN side
CIC (Carrier Identity Code)
CPC (Calling Party Category)
npdi=yes is sent.
If internal GAP parameter was received then it is sent out in rn=
If this Trunk Group flag is set then Nature of Address from the Called Party
Number received internally is sent out in ss7-noa=
OCN (Original Called Party Number)
If the Trunk Group flag indicates to send LNP parameters, and if the internal
Forward Call Indicator is present and indicates the Called Number being translated one, then LNP parameters shall be sent as follows.
NOA (Called Party Number)
If the Trunk Group flag indicates true then this is sent as ss7-cpc=
LNP (Local Number Portability)
If the internal message has CarrierIdentCode or TransitNetworkSelection

(because of the PSTN protocol) present and if this flag is true then CIC is sent out
as cic=
If this property is set and original called party number was received internally,
then the To header user part will contain this number, which may be different
than one in the Request-URI.
OLI (Origin Line Info)
If this property is set in Trunk Group and Original Line Info is received internally
then the value is sent in ss7-oli=
OLI and CPC are sent in From header whereas others are sent in Request-Line.
OCN is sent in To header.
1613
CIC, LNP (npdi & rn), NOA are sent in Request-Line.

For the parameters that are received from the SIP network
CIC
CPC
If incoming SIP Request-Line has this parameter (cic=) in the telephone url part
(user portion of sip uri), then this shall be retrieved. When this parameter is
present, then Carrier Ident Code and Transit Network Selection are set with
appropriate values such as the length of the cic (such as 3 digit or 4 digit parameter).
Retrieved from From header of any incoming SIP message present as ss7cpc=. When present then this value will be set in the Calling Party Category
value that will be passed internal to the ControlSwitch.
LNP
The npdi= is retrieved from the Request-Line of incoming SIP Request.
If present then Forward Call Indicators are set to values indicating that Called
Number has been translated.
If then rn= is present, then the current called party number which would
have been in the primary user part (xxxxx shown below) of the Request-URI
is stored into the GAP parameter indicating the ported dialed number and the
value in the rn= is placed as the called number to be processed/routed. If
however the rn= is not present then there is nothing to be set in GAP and the
called number to be processed would be the one taken from Request-URI
primary user part (xxxxx shown below)
Request-Line is sip:xxxxx;npdi=yes;rn=yyyyy@domainname;user=phone
NOA (Called Party Number)
The ss7-noa= is retrieved from the Request-Line of incoming SIP Request.
OCN
If the called party number retrieved from the Request-Line primary user part is
different from the user part phone number of To header, then the latter will be
stored as Original Called Party number and sent internally.
OLI
1614
If this is present and if GAP exists (already retrieved from LNP parameters),
then the nature of address of GAP is set with this value else the actual Called
Party Number Nature of Address is set with this value.
Retrieved from From header of any incoming SIP message present as ss7oli=. When present then this value will be set in the Origination Line Info parameter that will be passed internal to the ControlSwitch
SIP Support
SIP Fax t.38 Support

For SIP calls that terminate to PSTN or IP networks, ControlSwitch now supports SIP fax
based on the IETF recommendation draft-ietf-sipping-realtimefax-01.txt.
For any call is SIP originated or terminated and fax t.38 is sent, either the Media Gateway
IGate4000 PRO or the far end SIP device senses the fax tones. When the IGate 4000 PRO
senses the fax then it sends out MGCP Notify message. This notify is translated to Reinvite towards the SIP side.
Conversely, when far end SIP devices senses the fax tones it sends a re-invite.
Both the above methods above inform IGate 4000 PRO and the far end SIP device that
mode should be shifted to t.28 fax. In doing so, the call that is originally set up as a voice
call changes into a data call.
Before the call gets released the call reverts to voice path.
The devices qualified for SIP fax are Cisco 5300 series gateways. For other devices
interoperability will have to be performed.
Please see section SIP High Availability Solution.
SIP Session Timer
The session timer is responsible for a particular session and governs how often a session
timer refresh should be sent. The refresh can take form of Re-INVITE or UPDATE
request. Veraz SIP implementation uses Session Timer for session pings as well as High
Availability solutions.
Before release 5.5.5, Veraz SIP gateway (Local Gateway) accepted Session Timer
requests. In release 5.5.5 Veraz SIP IP Trunk Groups can be configured to send Session
Timer Requests to remote SIP entities. The implementation complies with RFC4028.
The session timer request generation is controlled via SIP Trunk Group SIP parameters
GUI. If the session timer is configured as 0 seconds then no requests are sent. If a non-zero
value is configured, then the session timer requests are either accepted or sent based on
recommendations of RFC4028. When both Veraz and the far-end initiate session timer
request negotiations based on RFC4028 will take place to determine whose request should
hold.
1615
SIP Tel URL

Tel URL is implemented per spec RFC2806. URLs are used to `locate' resources, by
providing an abstract identification of the resource location. Tel URL specifies that a
PSTN phone ('tel'-ephone) is being used for a SIP call. Tel URL feature is particularly
used when interworking with PSTN network. Many scenarios using Tel URL are defined
in RFC3398.
Typically, addressing in SIP is done using sip URL (Uniform Resource Locator) which
appears like:
sip:Singh@veraz.com or sip:7509400@veraz.com
Tel URL specifies URL for a voice call typically in a PSTN network that is handed over to
IP network (and vice versa). Tel URL appears like:
sip:+14085550002@veraznet.com; user=phone
OR
tel:+16175550002@veraznet.com
According to RFC2806, country code should be prepended based on Nature of Address. If
the Trunk Group has Tel URL configured in the SIP parameters list and if the country
code field is provisioned, the country code will be prepended to the phone number.
SIP Answer Offer Model
Answer Offer Model as recommended by RFC 3264 suggests methods of exchanging
multimedia capabilities (SDP) between two endpoints until a resolution is reached.
Employing Answer Offer Model an endpoint can either offer or request SDP in an
INVITE message. In subsequent messages the other endpoint can respond to the offer.
In the model, one participant offers the other a description of the desired session from their
perspective, and the other participant answers with the desired session from its perspective. This offer/answer model is most useful when information from both participants is
needed for the complete view of the session.
The applications that use this feature commonly in networks are
services like call forward or call conference when session capabilities of the
endpoints are not known
web based call initiation (for an end user in IP Centrex or VoIP subscriber)
Answer Offer model uses the following two messages
1616
PRACK - Provisional Acknowledgement
UPDATE - Update any session before or after call establishment.
SIP Support
Prack Support
SIP Messaging comprises provisional and final responses to an INVITE message. The
provisional responses are not mandatory in a call flow. Provisional responses are used for
alerting and ringing an endpoint e.g. 180 Alerting, 183 Session Progress (18X). In a
typical call where the call is actually answered, the final response is 200 OK. Acknowledging a final response 200 OK using ACK is mandatory but acknowledging provisional
messages is optional. A provisional message is acknowledged using PRACK (abbreviated
for Provisional Acknowledge).
Release 5.5.5 implements PRACK message accepting as well as generation per standard
RFC 3262. In previous releases, PRACK is only sent out by Veraz when requested by
remote entity.
Prack and Answer Offer Model

PRACK allows for acknowledging the provisional responses as well. Since PRACK can
carry SDP as well, it becomes a useful message for Answer Offer model whereby call
entities can update the SDP before call establishment. A call flow with PRACK is shown
below:
1617
Update Method
Update Method is implemented in release 5.5.5 per SIP standard RFC 3311. UPDATE
allows a client to update parameters of a session (such as the set of media streams and their
codecs) but has no impact on the state of a dialog. In that sense, it is like a re-INVITE, but
unlike re-INVITE, it can be sent before the initial INVITE has been completed. This
makes it very useful for updating session parameters within early dialogs.
Veraz uses update both in High Availability solution as well as Answer- Offer Model.
UPDATE behavior can be configured on per trunk group basis.
1618
ControlSwitch High Availability
Chapter 17
The Veraz ControlSwitch is a carrier-grade system implementing multiple fault protection

schemes to ensure five-9's reliability. The following capabilities are discussed in this
chapter:
Overload Protection
Network Failure
Element/Device Failure
171
Chapter 17: ControlSwitch High Availability
Overload Protection
The ControlSwitch supports protection against CPU overload. When call processing
activities load the CPU to a configured threshold, the ControlSwitch releases some
incoming calls to prevent further processing burden, thus preventing the CPU load from
ever reaching 100%.
Subsequently, when the CPU load level falls below another predefined threshold, the
ControlSwitch allows additional incoming calls to go through the system.
Overload Management (OLM) is available on the following real-time elements;
CCP
SG
PE
ICE
EMS
SEE
Network Failure
SS7 Network Failure
The ControlSwitch supports fault tolerance on its SS7 links. The Signaling Gateway (SG)
must be configured as a mated pair, with dedicated signaling links for each individual SG.
Traffic from an adjacent switch to the SG pair arrives on both sets of signaling links.
Traffic arriving on the links connected to the secondary SG is automatically sent on to the
primary SG via the IP connection between the two SG.
When an SS7 link goes down on one of the SG (for example, SS7 cable disconnected), the
other SG sends a backward SS7 message to the adjacent switch on its active link, and
instructs the switch to discontinue traffic on the failed link. From that point on the adjacent
switch will send all of its SS7 traffic on the remaining active links.
When the failed link is restored to service, the SG automatically starts to receive traffic on
both the primary and secondary links. This operation occurs automatically and does not
need to be initiated from the EMS.
172
IP Network Redundancy between Veraz ControlSwitch Elements
Figure 17-1:SS7 Network Failure
IP Network Redundancy between Veraz ControlSwitch Elements

The ControlSwitch supports network redundancy between its own elements, using the
SCTP protocol. Failure of a primary network Ethernet interface card, or removal of an
Ethernet cable (or any other failure that renders a data network to be unavailable) on one
or more devices will result in seamless switchover of traffic to the secondary Ethernet
interface, without loss of data or service interruption.
Network redundancy is supported on the following Veraz ControlSwitch elements:
Call Control platform
Signaling Gateway
Policy element
IP Call Element
Events Collector
CDR Manager
SAS
173
All of these elements should be set up with two Ethernet interfaces, and independent IP
addresses. With SCTP, an association is created on primary and secondary networks
whenever any two devices need to communicate. If a network outage occurs at one or
more nodes, traffic ceases to flow on that association. SCTP automatically switches traffic
from that association to the sister association on the redundant network.
Retransmission and buffering mechanisms ensure that the switchover of traffic occurs
without any loss of data. Steady state operations (quiescent calls) as well as transient operations (calls being set up or terminated) complete normally.
Once the network link is restored, SCTP ensures that all of the devices that were communicating on the secondary network revert back to the primary network.
IP Network Redundancy between ControlSwitch and Media Gateway

The ControlSwitch supports a number of mechanisms for network redundancy between
the CCP and the Media Gateways via both physical interfaces and through protocol
support.
The CCP supports both dual and quad network interfaces. When configured with dual
network interfaces, both interfaces are used as a redundant pair (Ethernet) for accessing
media gateways and other ControlSwitch elements. If a given interface is down for
communication to another device, the CCP will use the alternate interface.
In a quad interface configuration, one pair of interfaces is used for communication
between ControlSwitch elements as described above. The second pair of interfaces is used
for communicating with Media Gateways and only transmits and receives call processing
and gateway health related messages. This configuration allows the operator to isolate call
processing and media gateway traffic from inter- ControlSwitch traffic. This support is
useful when communicating over a public network when accessing media gateways.
For all traffic, each CCP has 2 links (one from each interface) to the media gateways for
each D-channel termination. For a redundant pair of CCPs this implies 4 links per Dchannel hence ensuring maximum availability between the ControlSwitch and the Media
Gateways
In the case of PRI traffic, links are delivered over SCTP or RUDP depending on the media
gateway vendor. By using SCTP (or RUDP in the case of Cisco media gateways) the
failure of a primary network Ethernet interface card, or removal of an Ethernet cable
results in seamless switchover of traffic to the secondary Ethernet interface.
For MGCP traffic, the messages are delivered over UDP however the ControlSwitch
supports re-transmission and keep-alives between the gateway and the CCP at the MGCP
layer. If there is any loss of communication between the gateway and the CCP, the CCP
will failover the secondary association and link. In the reverse direction, the media gateways support multiple call agent addresses hence allowing them to maintain association
between the primary and secondary CCPs redundant interfaces (two interfaces per CCP
hence four associations).
174
Support for redundant links between a media gateway and the ControlSwitch is dependent
on the media gateway vendor's support of multiple call agent addresses. For this reason,
the operator should verify support of this functionality when investigating support for new
media gateways. For media gateways currently supported by the ControlSwitch, please
contact Veraz for more detail on this capability.
Element/Device Failure
The ControlSwitch supports element/device level fault tolerance for the following
elements:
Call Control Platform
Signaling Gateway
Policy Element
Events Collector
The system is designed to tolerate catastrophic hardware or software failures, and to automatically switch operations from the failed device to one or more standby units. There is
no requirement for the standby device to be in an idle state for failover - it can be
processing its own set of calls. The standby units, though, must have adequate CPU
processing capacity to absorb the operations of the failed unit.
Many of the ControlSwitch elements support load shared failover. A single element in the
ControlSwitch can have more than one designated standby element. If the primary
element fails, its load can be distributed to these multiple standby units. The load shared
failover does not apply to the Signaling Gateway since SGs are deployed in mated pairs.
Below is a summary of the failover support available on the ControlSwitch Elements:
Figure 17-2:Failover Support on the ControlSwitch
175

SIP standards based High Availability implementation ensures that active calls are
preserved over a process, network or platform failure. This feature addresses failure
related to Veraz SIP entities software and hardware termed as 'local failure'. This feature
also addresses failure related to the remote SIP entities termed as 'remote failure'. Typically vendors use Virtual IP solution that does not address geographical redundancy.
Virtual IP solution uses mirroring IP addresses across two platforms. The two hardware
platforms need to be co-located thus not providing geographical redundancy. With Veraz's
SIP HA solution geographical redundancy is provided since no such co-location limitation
is imposed.
SIP High Availability solution is achieved by providing call state mirroring in the ICE
process to the extent that active calls are maintained over a failure but mid-call events like
DTMF will not work for such calls over a failover.
Provisioning Aspects
Every SIP Trunk Group will have 4 remote IP addresses configured. These four
can be provisioned in any order. Typically, the first two can represent two IP
addresses of the remote primary platform and the latter two can represent the two
IP addresses of remote secondary platform. The assumption of course is that the
far end gateway/Application Server comprises two hardware platforms with two
IP addresses each. In case the far end gateway/Application server uses IP
mirroring (virtual IP across two platforms), only one IP address will be configured
on the SIP trunk group in EMS.
A generic software process CSP (ControlSwitch Platform) was introduced in

release 5.5.3. ICE process resides on this generic platform instead of ICE platform
as in previous releases. This generic platform also houses ERS (Event Relay
Server) and LIDAP (Lawful Intercept) processes. In future, all ControlSwitch
processes will reside on CSP.
Each CSP platform will be associated with a backup CSP platform.
Each ICE process will be associated with a backup ICE process
Each LGW will be associated with ICE process.
To address both local and remote failures, below mentioned mechanisms are employed.
176
Local Failure
Veraz ICE/LGW/CSP failover is addressed on four levels

1. Process: Whenever a primary process fails, the secondary ICE process, residing on
secondary platform, gets enabled.
2. Platform: Whenever the primary Sun Solaris primary platform powers off due to
power failure or catastrophic event, the secondary platform will take over. This
scenario addresses simultaneous failures of ControlSwitch Platform (CSP), ICE, and
LGW (Local Gateway).
3. Network: Every ICE platform has two network interfaces. If the network interface
fails the egress traffic will go out through the secondary interface. The remote end will
be updated with newly available interface IP address. In addition, this feature
addresses failure of the entire primary network (Router failure).
4. Intermediate Network: Failure within the network that can be only discovered using
application level ping are also addressed using SIP OPTIONS method.
For the above failures, the following mechanisms are offered:
For existing sessions, a Re-INVITE with the new Contact information (new IPaddress of the recently enabled ICE) will be sent. The far end will be expected to
accept the new contact with the secondary ICE platform IP address. The IP address
update can take form of a Re-INVITE or an UPDATE message depending on trunk
group parameter setting for a particular SIP remote gateway.
Independent of call sessions, an OPTIONS message will be sent to the far end SIP
device. This is only for SIP application level ping purposes and all that is expected is
any kind of SIP response. This feature is particularly useful when
a. No calls are present in the network
b. Some IP leg between intermediate routers fails that only an application level ping
can identify.
If the OPTIONS message has not been acknowledged, the next priority Trunk Group
IP addresses will be used to send the outgoing messages.
It is possible that the far-end keeps sending new call requests to an ICE process/CSP
platform that has failed. In case the failed ICE has recovered to a standby state, it will
be send out a message '302' message with the new active ICE IP address so that the far
end sends the subsequent requests to the newly activated ICE.
177
Remote HA
Veraz ICE failover will address far end failure as long as ICE process is updated with the
secondary platform's IP address
1. For existing sessions, ICE will accept a new UPDATE or Re-INVITE with the new
information and continue communicating with the secondary IP address
2. For new sessions, ICE will honor the 3XX message with multiple contacts. Incase the
primary IP address can not be reached, it will try the alternative IP address provided in
the contact field within the session context. This is particularly relevant to Application
Servers like Broadsoft.
3. Independent of call sessions, Veraz ICE will respond with 200OK or
501NotImplemented to an OPTIONS sent by the remote end. Only active ICE will
respond to the OPTIONS requests. The standby ICE will ignore them.
4. If the remote SIP entity uses Virtual IP then the remote failover is transparent to Veraz
Session Timer and High Availability
This release also introduces complete session timer implementation used for High Availability solution. The implementation is based on the RFC4028. The session timer is
responsible for a particular session and governs how often a Re-INVITE or an UPDATE
request should be sent, depending on what is configured on the trunk group.
Figure 17-3:Session Timer High Availability
178
Billing and Event Collector
Chapter 18
This chapter describes Billing and the Event Collector Element. The following topics are
included in this chapter:
Event Collection
CDR Manager
BAF CDR Generation
181
Chapter 18: Billing and Event Collector
Event Collection
The ControlSwitch Event Collectors (EC) collect events for all calls. These events are
stored in the EC persistent storage. The data collected by an EC is used for both Billing
and for Performance Analysis.
To achieve a high degree of scalability, the ControlSwitch Event Collection functionality
is based on a distributed architecture where multiple Event Collectors can be used within a
ControlSwitch network to allow the network to scale in response to increasing call load.
The ControlSwitch CDR Manager uses the data in the Event Collector database to
generate CDRs in either VerazCDR (ICDR) or BAF formats. The CDR manager is also
responsible for correlating the billing information from multiple Event Collectors as well
as for providing persistent storage for CDRs.
A ControlSwitch call event message contains information that reflects the usage of equipment and inter-connecting networks. These call event messages are designed for consistency with the PacketCable Event Message format developed by the Packet Cable Forum.
Overview of Event Data

The Veraz ControlSwitch has defined several points in the call that trigger billing/performance event collections. These can be summarized as follows:
Signaling Start
Data Base Query
Create Connection.
Call Routing Attempt or Address Complete
Call Answer.
Delete Connection
Signaling Stop
Call Check Point (for long duration calls)
These events are stored in the EC databases and are used for the creation of billing records
as well as for reports.
182
iCDR: Veraz CDR
CDR Manager
The CDR Manager is the mediation subsystem between the Event Collectors and the
external billing application. The CDR manager generates the required output records to
interface with the various Billing Mediation servers in either ICDR or BAF Format.
iCDR: Veraz CDR

File Format
ICDR contains call data collected in the VerazCDR format and is generated in ASCII
format. In this format each call record is a text string containing a sequence of data. An
end-of-line character is inserted at the end of each ICDR.
Record Format
ICDR is a generic record that is designed to support billing for all call types/services
supported by the Veraz ControlSwitch. ICDR contains all billing related data collected by
the Event Collector. An example summary list of fields included in an ICDR is provided
below. A more comprehensive document is available upon request.
Zone ID
Sequence number for the record
Sequence number for the CDR file.
Global call id (uniquely identifies a call)
Last update time.
Call status: 'S': CDR created successfully; 'I': in progress; 'F': free on inquiry; 'E':
error encountered in creating CDR; NULL: unknown
Calling party number
Charge number
Dialed Number
Nature of address for DN
Time when the origination CCP receives the first message after a caller finishes
dialing
Time when voice trunks are set up
Time when the called person's phone starts ringing
Time when the called person picks up their telephone
183
Release Direction in CDR

This feature is relevant to the billing and diagnosing issues since direction of release in
CDR will determine which entity in a call actually releases a call. The entity can be the
calling party or the called party or the network or the switch itself. This is particularly
important when call is released at the same time by different entities. Since each call is
reported as two half calls in a CDR, the release cause will be associated with a half call.
The release can be originated by the following entities when one half call leg is under
consideration
Network Initiated (if the half call's network side released the call)
Remote Half Call (If the other half call's network side released the call)
Internal (if the softswitch/media server releases the call)
The release direction shall appear in the CDR as described in Table 18-1.
Table 18-1 Release Direction
Release Source
Ingress Half Call Record
Egress Half Call Record
Ingress
Network Initiated
Remote Half Call
Egress
Remote Half Call
Network Initiated
Internal (Ingress)
Internal
Remote Half Call
Internal (Egress)
Remote Half Call
Internal
Release Collision
Network
Network
MGW Failure (Ingress)
Remote Half Call
Remote Half Call
MGW Failure (Egress)
Remote Half Call
Remote Half Call
CDR Audit
A billing system that processes iCDR can use the cdr_count and the checksum in iCDR
file footer to detect network transport problems occurred when iCDR files were transmitted from CDRE to the billing system.
In addition, the second field in every iCDR is the Record Sequence field. The Record
Sequence is maintained across iCDR files. A billing system can use the Record Sequence
to find out whether there is a loss of iCDRs.
The File Sequence contained in the iCDR file name is a sequence apart from the Record
Sequence. A billing system can use the File Sequence to detect loss of iCDR files. If an
iCDR file is renamed for some reason, the billing systems can always reply on the File
Name tag in the header of an iCDR file to find out the original iCDR file name, and hence
find out the File Sequence of the iCDR file.
184
Record Format
BAF CDR Generation

BAF (Bellcore AMA Format) is a standard developed by Telcordia/Bellcore. It is the most
commonly used billing standard in USA. This section outlines the BAF call types and
structure codes generated by the Veraz ControlSwitch. It is intended for a reader with a
clear understanding of BAF concepts. Please refer to GR1100- Core for description of the
BAF related terminologies.
Record Format
ControlSwitch produces BAF records for the following call types.
BAF Record Call Types
Table 18-2 BAF Records
Call Type
When it is created
714
When the DN is not toll-free and the call is not a directory assistance call and
the call originated on a DAL/PBX trunk.
720
When call is received over connecting network access incoming trunk.
008
When the DN is toll-free.
033
When call is Directory Assistance.
Call Type 720

The BAF record for call type 720 contains one structure with code 0625.
The BAF record for call type 720 may contain the following modules depending the
various services involved in a call.
Table 18-3 Call Type 720
Code
Module Name
When Created
022
Long duration Connection
This module is attached in all continuation CDRs for long duration

calls.
028
Additional Digits Dialed
When the dialed number is international and the total number of

digits are more than 10 then the extra digits are stored here.
164
E.164/X.121
This module is attached when the Calling Party Number (CPN) is

present. The module contains information on CPN.
Number Module
720
LNP Module
Produced when an LNP query is performed by the Veraz

ControlSwitch to determine the recipient switch. This module is
also produced when LNP query is performed before the call
reached the Veraz ControlSwitch as indicated in JIP.
000
Final Module
Always attached if one of the above modules is present.
185
Call Type 714

Code
Module Name
When Created
022
Long duration Connection
This module is attached in all continuation CDRs for long duration

calls.
028
Additional Digits Dialed
When the dialed number is international and the total number of

digits are more than 10 then the extra digits are stored here.
164
E.164/X.121
This module is attached when the Calling PArty Number (CPN) is

present. The module contains information on CPN.
Number Module
720
LNP Module

000
Final Module
Call Type 008

Code
Module Name
When Created
720
LNP Module

000
Final Module
Call Type 033

various services involved in a call
186
Record Format

Code
Module Name
When Created
720
LNP Module

000
Final Module
187
188
Glossary of Terms
Glossary of Terms
ACD:
Average Call Duration
ADSL:
Asymmetric Digital Subscriber Loop
AIN:
Advanced Intelligent Network
ANI:
Automatic Number Identification
APB:
Announcement Profile Block Association
API:
Application Programming Interface. A hook into software, or a set

of standard software interrupts, calls, and data formats that
application programs use to initiate contact with network services,
mainframe communications programs, and telephone equipment.
Standardization of APIs at various layers of a communications
protocol stack provides a uniform way to write applications.
AS:
Application Server
ASP:
Application Server Process
ASR:
Answer to Seizure Ratio
ATP:
Access Transport Parameter
BAF:
Bellcore AMA Format
BEARER CHANNEL:
Also known as B Channel. This is a communications channel used to

transmit aggregate signals generated by multichannel transmission
devices. The B Channel is used to transport user information rather
than signaling information.
CALEA:
Communications Assistance for Law Enforcement Act
CAS:
Channel Associated Signaling
CCA:
Call Control Agent
CCDF:
Call Content Delivery Function
Glossary9
Glossary of Terms
CCP:
Call Control Platform
CDATA:
Character Data, part of an SGML or XML document, that is not

parsed and may therefore contain almost any character sequence.
CDDF:
Call Data Delivery Function
CDR:
Call Detail Record.
CDRM:
Call Detail Record Management Element, also known as CDR

Manager
CIC:
Carrier Identification Code, is currently used to identify a customer

who purchased Feature Group D access services.
CIC:
Circuit Identification Code
CIP:
Carrier Identification Parameter
CLASS 4:
A type of equipment, also known as tandem switch or toll

switch, that provides interconnection for Class 5 Switches and long
distance via Class 3 InterExchange Carriers (IECs). Optional direct
connection to higher volume Class 4 sites.
CLASS 5:
A type of equipment, also known as circuit switches, that provides

aggregation and service creation to local Customer Premise
Equipment and local switching. Capacity typically is up to 1000, 000
lines.
CLI:
Command Line Interface
CLEC:
Competitive Local Exchange Carrier
CO:
Central Office
CODEC:
COder-DECoder. A digital device for the coding and decoding of

video and/or audio signals usually to permit them to be transmitted
in compressed and/or encrypted form.
CPC:
Carrier Portability Code
CPE:
Customer Premise Equipment. Telecommunication equipment

phones, IADs, etc. that reside at customers site (end-users home or
office).
CPN:
CQM:
CSP:
ControlSwitch Platform
DA:
Digit Analysis
DAL:
Direct Access Line
Glossary10
DAS:
Data Analysis Server
DN:
Dialed Number
DNS:
Domain Name Server
DOM:
Document Object Model: DOM is a platform- and language-neutral

interface, that provides a standard model of how the objects in an
XML object are put together, and a standard interface for accessing
and manipulating these objects and their inter-relationships.
DSL:
Digital Subscriber Loop
DTD:
Document Type Definition, Schema specification method for SGML

and XML documents. DTDs are either contained in the document or
belong to its external subset and are then referenced from within the
document's document type declaration per URI.
DTMF:
Dual-Tone Multi-Frequency. The type of audio signals that are

generated when you press the buttons on a touch-tone phone.
E1:
Abbreviation for the European equivalent of DSI (T1) (ITU-T Rec.

G.703 and G.732), 2.048 Mbps.
E.164:
A public network addressing standard utilizing up to a maximum of

15 digits. ATM uses E.164 addressing for public network
addressing.
EAEO:
Equal Access End Office
EC:
Events Collector
ECHO CANCELLATION:
A technique used with voice circuits to isolate and filter unwanted

signal energy which accompanies analog transmissions.
ECS:
Empty Capability Set
EMA:
Event Monitoring Agent
EMS:
EO:
End Office
ERS:
Event Relay Server
ETSI:
European Telecommunications Standard Institute
FCI:
Forward Call Indicator
FXS:
Foreign Exchange Station
GAP:
Generic Address Parameter
GATEWAY:
Hardware or software that converts between algorithms, protocols or

standards. May also act as a means of access from one network to
another.
GK:
Gate Keeper
Glossary - 11
GSA:
Global System Administration Server
GSM:
GSM originally stood for Groupe Speciale Mobile but has been
anglicized to Global system for Mobile Communications, an
international digital cellular standard. South Africa was one of the
first to implement Phase 2 of GSM.
GT:
Global Title
GTT:
Global Title Transaction
GUI:
Graphical User Interface
H323:
Signaling protocol for the transmission of real-time audio, video,

and data over packet-based networks.
HA:
High Availability
HTML:
HyperText Markup Language, a subset of SGML, commonly used

for Internet Web-page design.
HTTP:
Hyper Text Markup Language
IAD:
Integrated Access Device. A device which supports voice, data, and

video information streams over a single, high-capacity circuit.
ICD:
Internet Call Diversion
ICDR:
Veraz CDR
ICE:
IP Call Element
ILEC:
Incumbent Local Exchange Carrier
IMT:
Inter-Machine Trunk
INAP:
Intelligent Network Application Part
INVERTED CALL:
IP:
Internet Protocol, packet transmission standard for the Transmission

of data, voice, video, and other information over the Internet.
IPCCP:
IP Call Control Protocol
ISDN:
Integrated Services Digital Network. A switched digital service

using 16Kbps D channel for signaling and two or more 64 Kbps or
56 Kbps (some US) B channels for data transmission.
ISP:
Internet Service Provider
ISTP:
Internet Enabled Signal Transfer Protocol
ISUP:
ISDN User Part. ISUP provides the signaling functions necessary to

basic bearer services and supplementary services for voice and nonvoice applications in the Integrated Services Digital Network. ISUP
is defined within the Signaling System 7 (SS7) specifications as a
communications protocol used to set-up manage, and release trunk
Glossary - 12
circuits that carry voice and data over the Public Switched
Telephone Network (PSTN).
ITU:
International Telecommunications Union.
IVR:
Interactive Voice Response
KBPS:
Kilobits (thousands of bits) per second.
KP:
Key Pulse
LA:
Lawful Authorization
LAN:
Local Area Network, for the ControlSwitch this is Ethernet. Highspeed, low error data network covering a relatively small geographic
area. LANs connect workstations peripherals, terminals, and other
devices in a single building or other geographical limited area.
Ethernet, FDDI, and Token Ring are widely used LAN technologies.
LATA:
Local Access and transport Area, a telecommunications tariff aspect

in the USA.
LD:
Loop Device
LEA:
Lawful Enforcement Agency
LEC:
Local Exchange Carrier
LG:
Local Gateway
LGW:
Local Gateway
LI:
Lawful Interception
LIDAP:
Lawful Intercept Data Access Point
LNP:
Local Number Portability (keep the same number when you change
carriers). Provides subscriber ability to port to another service
provider.
LPC:
Local Point Code
LRN:
Local Routing Number
M3UA:
MTP-3 User Adaptation (Layer
MBPS:
Megabits (million of bits) per second.)
M7C:
Mach7 Controller
MD:
Mediation Device
MEDIA GATEWAY:
See Trunking Gateways.
MF:
Multi-Frequency
MFM:
Fault Management Server
MG:
Media Gateway
Glossary - 13
MGCP:
Media Gateway Control Protocol: developed by Telcordia and Level

3 Communications, is one of the proposed control and signal
standards to compete with H.323 for the conversion of audio signals
(carried on the PSTN) to data packets (carried on packet networks).
MIB:
Management Information Base (SNMP)
MS:
Media Server
MTP:
Message Transfer Part
NAMP:
North American Numbering Plan
NAS:
Network Access Server
NGN:
Next Generation Network
NIC:
Network Interface Card
NNI:
Network-to-Network Interface
NOA:
Nature of Address
NPA:
Numbering Plan Area
OLM:
Overload Management
OPS:
Oracle Parallel Server
OSP:
Open Settlement Protocol
OSS:
Operation Support System
PACKET:
A form of data transmission breaking the information into many

small packets, each including information such as source,
destination, protocol, and packet length information. The concept is
used for the Internet where a given transmission facility is shared by
many different users, with packets removed or added as appropriate
at different locations.
PBS:
Platform Build Specification
PBX:
Private Branch Exchange.
PCDATA:
Parsed Character Data
PDN:
Packet Data Network.
PDU:
Protocol Data Unit
PE:
Policy Engine
PIC CODE:
Primary Interexchange Carrier Code
PRI:
Primary Rate Interface
PSTN:
Public Switched Telephone Network. This is the regular phone lines

that just about everybody uses.
PTNX:
Private Telecommunication Network Exchange
Glossary - 14
QOS:
Quality of Service
RAS:
Remote Access Server.
RC:
Routing Context
RE:
Routing Element
RELEASE:
A set of packages delivered together.
RMAN:
Recovery Manager
RTP:
Real-time Protocol
RTSP:
Real Time Streaming Protocol.
RUDP:
Reliable Universal Datagram Protocol
SAS:
Signaling Access Server
SAS:
Surveillance Administration Subsystem
SBB:
Service Building Block
SCCP:
Signaling Connection Control Part
SCP:
Service Control Point
SCTP:
Stream Control Transmission Protocol.
SDP:
Session Description Protocol
SDSL:
Symmetric Digital Subscriber Loop
SEE:
SG:
(SS7) Signaling Gateway
SGML:
Standard Generalized Markup Language, the super set from which

HTML was derived.
SGP:
Signaling Gateway Process
SILENCE SUPPRESSION:
Technology used in voice transmission to free up bandwidth on the

voice channel. Silence is not digitized, allowing extra bandwidth to
be used by speech or data from another channel.
SIP:
Session Initiation Protocol
SNMP:
Simple Network Management Protocol
SOC:
Software Optionality Control
SS7:
Signaling System 7: a method of out-of-band signaling for telephone

circuits. Simply put, out-of-band means that s special separate line is
used to carry signaling, such as dialed tones, ringing signals, busy
tones (everything but the actual voices/conversation).
SSP :
Service Switching Point
Glossary - 15
STP:
Signal Transfer Point
T1:
The AT&T Bell System level 1 digital transmission system operating

at 1.544 Mbps (1.536 Mbps excluding framing). T1 is commonly
used to refer to DS1.
TCAP:
Transmission Capabilities Application Part (part of SS7)
TCP:
Transmission Control Protocol
TDM:
Time Division Multiplexing. A Technique for transmitting a number

of separate data, voice, and/or video signals simultaneously over one
communications medium by quickly interleaving a piece of each
signal one after another.
TE:
Terminal Equipment
TG:
Trunk Group
TGW:
Trunking Gateway
TNS:
Transit Network Selector
TON:
Type of Number
TRUNKING GATEWAY:
Equipment that provides Trunking capability to the PSTN.

Responsible for converting packet voice to TDM and vice versa.
UA:
User Agent
UM:
Unified Message
URL:
Uniform Resource Locator
VCE:
Voice Call Element
VOIP:
Voice over Internet Protocol: the transmission of a packet-voice

stream across packet networks using the Internet Protocol.
VPN:
Virtual Private Network
WAN:
Wide Area Network
XML:
eXtensible Markup Language, descends from SGML and is a

standard for the exchange of structured and network data on the
Web. XML documents can define their own tags, providing
outstanding flexibility.
Glossary - 16
Index
Index
Release Direction 18-4

CDR Element 4-7
CDR Manager 18-3
Charge Band 13-17
Class 4/5 Switch Interfaces 5-2
Class of Service 13-26
Codec List 13-16
company information 2-16
Connection Fallback 8-9
Contact Information 2-15
ControlSwitch
Configurations 6-2
Element Configurations 6-2
Element Interactions 4-9
General Description 4-2
Solutions 2-1
CPU Utilization 7-14
customer service 2-16
Alarm
Aggregation 7-10
Email Notification 7-12
Filtering 7-10
History 7-11
Pending 7-9
Properties 7-11
Severities 7-9
Sorting 7-10
ANI Over CAS 10-4
Announcements 12-3
ATP Parameter 8-5
audience 2-12
AudioCodes 16-5
Audit Log 7-7
Auto Repeat Attempt 8-10
Automated Provisioning 7-29
Availability Control 8-8
BAF 18-5
BAF CDR
Record Format 18-5
BAF CDR Format
Record 18-5
BAF CDR Generation 18-5
Basic PBX 10-3
Billing 18-1
Bulk Provisioning 7-29
Bulk Provisioning Enhancements 2-2
C
Call Control Element 4-4

Call Tracing 7-22
Call Type 13-17
CAS
DTMF Signaling 10-2
MF Signaling 10-2
Signaling Protocols 10-2
CAS Services 10-2
CDR
Audit 18-4
Device Failure 17-5

Directory Lists 13-15
Disaster Recovery 7-3
Disk Usage 7-23
Diversion Support 16-12
Documentation
Online 2-14
Set 2-13
documentation 2-13
DSO Level Management 7-7
E
Egress Point 13-16

Egress Properties 13-16
Element Failure 17-5
Element Management System 4-8
Element Provisioning 7-4
Element Status View 7-12
EMS and CDR 7-3
EMS CDR Platform 2-2
EMS Disaster Recovery 2-2
EMS GUI Menu Access 7-6
ETSI 9-2
Charge Framework 8-12
V1 8-14
Event Collection 18-2
Event Data 18-2
Event Collector 18-1, 18-2
Event Data 18-2
Event Relay Server 2-2, 7-26
Message Structure 7-27
Scaling 7-29
I-1
Index
Supported Events 7-27

Events Collector 4-7
F
Failed Call Summary

Span 7-16
Trunk Group 7-15
Failure
Device 17-5
Element 17-5
Fault Management 7-8
Fax t.38 16-15
Feature Group D 10-3
G
General Description 3-1

Getting Assistance 2-15
Global Title 8-22
GoSub 13-14
H
H.323
OSP SIP 16-8
Reconnect 16-8
Routing 13-19
Support and Interworking 16-7
H.323 Internet Working 3-7
High Availability
EMS 7-3
SIP 17-6
Hong Kong ISUP 2-4
I
ICDR 18-3
iCDR 18-3
File Format 18-3
Record Format 18-3
iCDR Format
File 18-3
Record 18-3
ICE
Platforms 13-18
Processes 13-18
Immediate Start 10-3
IN Services 2-3
INAP 8-19
Productized Services 8-19
Services 8-19
INAP-CS-1 2-3
INR/INF 8-5
Internet Call Diversion 3-10
IP Call Element 4-8
Index-2
IP Network Interfaces 5-4

IP Network Redundancy 17-3
ISDN User Adaptation 16-6
ISDN_PRI
Messages 9-3
ISDN-PRI 9-2
Maintenance 9-3
ISUP
Hong Kong 2-4, 8-16
Romanian 8-16
Russian 8-16
Segmentation 8-7
Singapore 8-16
UK 8-16
ISUP Congestion 8-4
IUA 16-6
L
Lawful Intercept 15-2

Components 15-2
LNP 8-18
Local Number Portability 8-18
M
M3UA 16-7
Mark as Billable 13-25
Media Gateway 16-3
PSTN Interop 16-4
VoIP Interop 16-3
Message and Parameter 8-7
Mexico 8-15
MGCP 16-6
Modem Wholesale Services 3-10
MTP3 User Adaptation 16-7
N
Network Failure 17-2

SS7 17-2
NI-2 Variants 9-2
O
OMNI Statistics 7-16

Operator Actions 7-10
Oracle DB 7-23
Originating 8-18
OSP
Routing 13-20
Overlap Signaling 8-6
Overload Protection 17-2
P
Packet Toll/Tandem Solution 3-2
Index
Performance Management 7-14

Periodic Monitoring 7-14
PL/SQL API 7-29
Policy Element 4-6
Prack
Support 16-17
Prack Method 2-4
PRI Leasing Services 3-11
Priority and Weight 13-16
Privacy Updates 16-12
Propagation Delay 8-11
Provisioning Interface 12-2
PSTN Interworking 16-13
Route Advance Capability 13-17

Route and Reject 13-15
Routing 12-2
Bulk Provisioning 7-29
H.323 13-19
OSP 13-20
Satellite Aware 13-25
SIP 13-20
Skip 13-25
Variable Support 13-21
VoIP 13-17
RUDP 16-9
Satellite Aware Routing 13-25

Scalability 4-12
SCTP 16-7
Secure Shell 7-7
Security Management 7-7
Service Execution Element 4-4
Session Manager Protocol 16-9
Session Timer 2-3
Settable Parameters 13-24
Signaling Gateway 4-3
SIP
Answer Offer Model 2-3, 16-16
Architecture 11-3
Connectivity 11-2
Fax t.38 16-15
High Availability 2-3, 11-3, 16-15, 17-6
Internet Working 3-5
Load sharing 11-5
PSTN Interworking 11-2
Services 11-2
Session Timer 2-3, 16-15
Support 16-9
Target Applications 11-2
Tel URL 16-16
Transaction Layer 16-11
Trunk Groups 11-4
SIP Internet Working Services 3-5
SIP Routing 13-20
SNMP
Gateway Management 7-25
Northbound 7-25
SOC 7-2
Software Optionality Control 7-2
Software Upgrades 7-2
Space Monitoring 7-23
SS7
ISUP 8-3
MTP Level 2 8-2
Q.SIG 9-4
Messages 9-5
Trunk Group 9-4
R
Reason Header 16-11

Record Format
BAF Call Types 18-5
Call Type 008 18-6
Call Type 033 18-6
Call Type 714 18-6
Call Type 720 18-5
Redirection 16-12
Redundancy
CCE 6-3
CCP 6-3
EC 6-4
EMS 6-4
PE 6-4
SEE 6-4
SG 6-3
Redundant System 6-3
Release Cause 13-27
Release Direction 18-4
Reliable UDP 16-9
Reports 7-16
Descriptions 7-19
Text Based 7-17
User Requested 7-17
Re-Route Triggers 12-2
Re-Routing 12-2
Anouncements 12-3
Provision Interface 12-2
Treatments 12-3
Triggers 12-2
Role Management 7-6
Route Advance 13-21
I-3
Index
MTP Level 3 8-2

North America 8-17
Overview 8-2
Services 8-2
SS7 Access Server 4-9
Startup 7-2
STP Interfaces 5-3
Stream Control Transmission Protocol 16-7
System Logs 7-24
Translates To 13-26
Treatments 13-15
Trunk Group
Q.SIG 9-4
Terminating 8-18
Trunk Groups
IP 13-19
SIP 11-4
U
Tandem Switch 8-18

Target Applications 11-2
technical support 2-16
Telesys 4-3
Terminating 8-18
Terminating Trunk Group 8-18
Test Cal 2-2
Test Call 7-13
Signaled Parameters 7-13
Supported Protocols 7-13
Test Line
T100 16-2
T102 16-2
T108 16-2
Total Call Statistics 7-15
Span 7-15
Trunk Group 7-15
Traffic Type 13-16
Index-4
UK ISUP 8-16
Ulticom 4-3
Ulticom SP-4 8-4
Universal Port RAS Gateway 3-8
Update Method 2-4, 16-18
Upgrade 7-2
upport 8-15
URL Compliance 2-4
User Management 7-5, 7-6
V
Variable Support 13-21

Veraz CDR 18-3
Voice-Data Access for Businesses 3-4
Voice-Data Traffic Groomer 3-11
VPN support 13-17
W
Wink Start 10-3

Veraz ControlSwitch Product Description

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Veraz ControlSwitch Product Description

Hochgeladen von

Copyright:

Verfügbare Formate

ControlSwitch Product Description

Veraz Networks, Inc.

Phone: (408) 750-9400

Information in this document is subject to change without notice.

New Functionality Added in Release 5.5.5

Veraz Networks ControlSwitch Product Description

Veraz ControlSwitch General Description

Supported Customer Environments

Veraz Networks ControlSwitch Product Description

Supported ControlSwitch Configurations

Veraz Networks ControlSwitch Product Description

EMS and ControlSwitch Infrastructure

Veraz Networks ControlSwitch Product Description

PL/SQL API for Third Party Management Control . . . . . . . . . . . . . . . . .7-29

Veraz Networks ControlSwitch Product Description

Policy Element - Supported Policies

Veraz Networks ControlSwitch Product Description

Routing and Digit Analysis

Veraz Networks ControlSwitch Product Description

Lawful Intercept Solution for Tandem

Veraz Networks ControlSwitch Product Description

ControlSwitch High Availability

Billing and Event Collector

Veraz Networks ControlSwitch Product Description

Veraz Networks ControlSwitch Product Description

Veraz Networks ControlSwitch Product Description

Chapter 1, Introduction, provides an introduction to the new ControlSwitch functionality.

Chapter 3, ControlSwitch Solutions, provides details on the ControlSwitch solutions.

Chapter 4, Veraz ControlSwitch General Description, providesa general description

Chapter 5, Supported Customer Environments, describes the supported customer

Chapter 6, Supported ControlSwitch Configurations, provides details on the

Chapter 7, EMS and ControlSwitch Infrastructure, describes the EMS and

Chapter 8, SS7 Services, describes SS7 Services.

Chapter 9, ISDN-PRI Services,describes ISDN-PRI services.

Chapter 10, CAS Services, describes CAS services.

Chapter 11, SIP Services, describes SIP services.

Veraz Networks ControlSwitch Product Description

Chapter 14, Supported Services, provides details on all supported services.

Chapter 16, Call Processing, provides details on call processing.

Chapter 17, ControlSwitch High Availability, provides details on the Veraz

ControlSwitch Product Description

ControlSwitch System Requirements and Environment Guide

ControlSwitch Installation Guide

ControlSwitch Provisioning Guide

ControlSwitch Reference Guide

ControlSwitch Lawful Intercept Guide

ControlSwitch Maintenance Guide

Veraz Networks ControlSwitch Product Description

EMS Disaster Recovery Guide

ControlSwitch Release Notes

ControlSwitch Patch Release Notes

Veraz Networks ControlSwitch Product Description

Emphasis, or variable values in command line or code

Command line or code examples, directory names,

Variable values in command line or code examples.

Buttons, icons, menu items, field names, components

Veraz Networks ControlSwitch Product Description

Technical Assistance Centers (TACs)

Veraz Networks ControlSwitch Product Description

This chapter provides an introduction to Veraz Networks.The following topics are

Veraz Networks ControlSwitch Product Description

The Veraz ControlSwitch is a next-generation carrier-class softswitch system that

Veraz Networks ControlSwitch Product Description

Veraz Networks ControlSwitch Product Description