Course: IPX15

GENBAND IPX Solution

Operations and Maintenance
Revision: 01.01
Publication Date: July 2015

Student Guide

GENBAND
2801 Network Boulevard, Suite 300
Frisco, TX 75034
All rights reserved.

Disclaimer of GENBAND:
Material contained in this document is subject to change without notice. The material
herein is solely for information purposes and does not represent a commitment by
GENBAND or its representatives. GENBAND has prepared the information contained in
this document solely for use by its employees, agents and customers.
Copyright 2000-2013 GENBAND
All rights reserved. All copy, reproduction, derivatives (including, without limitation,
translation), modification, distribution, republication, transmission, re-transmission
and public display or showing of this document, whether in whole or part, is strictly
prohibited, without the prior written permission of an authorized GENBAND
representative. This document, and any software of GENBAND mentioned in this
document, whether delivered electronically or via other media, are the sole property
of GENBAND and are available only under and pursuant to license agreement.
GENBAND and the GENBAND corporate logo are registered trademarks of GENBAND
and its affiliates. All other brand and product names are trademarks or registered
trademarks of their respective holders.

Warning
For training purposes only. Always refer to the procedures described in the GENBAND
standard documentation that are appropriate for the system and software release
that you support. Failure to use the appropriate documentation can result in serious
technical difficulties and damage to your system. For additional information about
referenced documentation, visit www.genband.com or contact your local GENBAND
sales office or account representative.

GENBAND products and services are produced using a TL 9000 certified Quality
Management System.

CERT-0056636

Revision History
Issue

Date

01.00

December 2014

01.01

July 2015

Changes Incorporated
Initial Course Release
Rebranding

References
Document
Number

Document Name

630-00453-07

G9 Converged Media Gateway Engineering Guide

630-00454-01

G9 Signaling Gateway Engineering Guide

630-00469-01

G9 Converged Media Gateway Events and Alarms Reference

Guide

630-00479-01

G9 Converged Media Gateway Maintenance Guide

630-01193-01

G9 Fault Management and Troubleshooting Guide

630-00524-01

G9 Converged Gateway Product Description

630-00643-01

G9 Converged Media Gateway Command Line Interface

Introduction

630-01234-01

G9 Converged Media Gateway Command Line Interface

Reference Guide

630-00648-01

G9 Converged Media Gateway GUI Client Installation

630-00664-01

G9 Software Installation and Commissioning Procedures

630-00724-01

G9 Media Gateway Feature Description

630-00857-01

G9 Converged Media Gateway GUI Administration Guide

630-01012-01

G9 GenView EMS Performance Management Guide

NN10205-511

Gateway Controller Configuration

NN10602-002

Configuration C20 on GENiUS-Based Networks

SEB 08-00-102

C20 G9 Engineering Rules

630-01036

Session Border Controller (SBC) Operations Guide

630-01037

GENView Real-time Session Manager Operations Guide

Courseware Contents
Lesson 1

Introduction and Overview to

GENBAND IPX Solution

Lesson 2

C3 and G9 Hardware

Lesson 3

C3 G9 Operations

Lesson 4

C3 G9 Diagnostics and Testing

Lesson 5

SBC Basic Configuration

Lesson 6

Media, Realms and End Points

Lesson 7

Basic Troubleshooting and High Availability

Lesson 8

Call Flows

Lesson 9

Review Logs and CDRs

Lesson 10 Events, Alarms and Performance

10

11

12

13

Introduction to IP eXchange (IPX)

The rapid growth of LTE networks, cost efficiencies of IP, and changing regulatory requirements
are fueling the rise of an all-IP communications world. However, the inherently flexible nature of
IP causes many incompatibilities to arise when service providers attempt to connect to other IP
networks.
The advantages to IPX are:
Any-to-Any Interworking
IPX will allow to connect from legacy networks, like TDM to the newer IP centric networks
allowing for Any-to-Any Interworking.
Border Security
Smart capabilities that ensure robust security and network-wide quality and performance of
IP sessions at every interconnection point in the network including the borders of the
network.

Advanced Routing and QoS Assurance

Network intelligence with advanced reporting, routing, and policy enforcement under a single
management umbrella, simplifying management and enhancing service visibility.
Transcoding
Broad support for interconnecting beyond IPX, including multiple other IP and legacy
technologies - IP (H.323, SIP, SIP-I, SIP-T, IMS SIP), Legacy Mobile IP (BICC), and TDM.
IPX Opens networks up for new and expanding technologies like:
Rich Communications Suite (RCS)
HD Voice Over IP
Video Services
WebRTC

14

IPX The Network

Initially IPX was introduced for Mobile Network Operators (NMO) for 4G Long Term
Evolution (LTE) roaming on a global basis while still providing their customers the same
level of service.
IPX The Evolution
IPX has evolved beyond just mobile operators, any service provider or network operator
can connect to the IPX network, if it meets their requirements. Some examples of this
interoperability are:
Content Providers
Fixed Network Operators
Internet Service Providers
Application Providers
Enterprise Services
These are just some examples of the interoperability with IPX.
IPX The End to End Design
IPX is designed and engineered to connect anywhere in the world in 2 hops or less across a
private and secure IP network, with guaranteed end to end quality. This gives the IPX
providers end to end responsibility and end to end control of the network.
A Peering connection is setup between the IPX Providers.
15

16

17

GENBAND IPX Solution

The GENBAND SBC serves as the Session Border Controller, SIP Proxy Server and the IPX
Proxy Server for the GENBAND IPX Solution. The Real-time Session Manager (RSM) acts as
the management element for the SBCs. The SBCs will serve as the endpoints for the
Service Level Agreements (SLA).
The Border Gateway function is served by the GENBAND G9 Media Gateway and is
controller by the GENBAND C3 Media Gateway Controller. The C3 and G9 are managed by
the Genview EMS, which is a software application that runs on a pair of C3 servers.
The Core Routing Engine (CRE) is used to provide an authoritative DNS service and to
support IP to IP calls.

18

SDIN CP (SIP) to SDIN CP (SIP) No Calls Barred

Shown in the diagram is a simple call set up illustrating where all the elements are used.

19

SDIN PSTN (ISUP) to SDIN CP (SIP)

Shown in the diagram is a simple call set up illustrating where all the elements are used.

20

21

22

What is the SBC?

Stands for Session Border Controller (SBC) and is deployed in Voice over Internet Protocol
(VoIP) networks to exert control over the signaling and media streams involved in setting
up, conducting, and tearing down telephone calls or other interactive media
communications which typically uses the following call-signaling protocols:
Session Initiation Protocol (SIP)
H.323
SBCs commonly maintain full session state and offer the following functions:

Security
Malicious attacks such as Denial-of-Service (DoS)
Topology Hiding

Connectivity
NAT Traversal
SIP Message and Header Manipulation
IPv4 to IPv6 Interworking

Quality of Service (QoS)

Traffic Policing
Rate Limiting
Call Admission Control

Regulatory
Emergency Call s prioritization
Lawful Interception

Media Services
DTMF Relay and Interworking
Media Transcoding

Support for Voice and Video Calls

Statistics and Billing Information

23

What is the SBC? (2)

The Session Border Controller (SBC) is deployed in Voice over Internet Protocol (VoIP)
networks to exert control over the signaling and media streams involved in setting up,
conducting, and tearing down telephone calls or other interactive media communications
which typically uses the following call-signaling protocols:
Session Initiation Protocol (SIP)
H.323
Media Gateway Control Protocol (MGCP)
The SBC delivers secure carrier class. With extensive security, policy enforcement, and
session management capabilities, the SBC brings service providers advanced levels of
functionality, flexibility, and performance at IP network borders.
The SBC 2U Server scales up to 64,000 concurrent sessions.
Security
The SBC protects service provider and enterprise networks by providing multi-layer
security against a wide variety of Internet threats meant to disrupt or disable IP networks
including flood attacks, DoS / DDoS attacks, and SIP signaling attacks. Capabilities include
intelligent access and admission control, private-to-public IP network address and port
address translation NAT & NAPT (Network Address Translation & Network Address Port
Translation).
24

What is the SBC? (3)

Based on RFC 3261, A proxy server is an intermediary entity that acts as both a server and
a client for the purpose of making requests on behalf of other clients.
A proxy server primarily plays the role of routing, which means its job is to ensure that a
request is sent to another entity closer to the targeted user. Proxies are also useful for
enforcing policy (for example, making sure a user is allowed to make a call).
A proxy interprets, and, if necessary, rewrites specific parts of a request message before
forwarding it.

25

Session Management
The SBC provides Session Management services like:
Redirects - Points the endpoint to the right location for delivery of services
Billing - Generates Call Detail Records for all sessions managed by the SBC
Registrar - Keeping record of location and authorization of endpoints requesting
service from the SBC
Lawful Intercept - When required by law, enable the delivery of signaling and media
traffic of session to the law enforcement agencies that so require

The SBC also provides Session Management services like:

Session Timers
Allows a periodic refreshing of a SIP session using the RE-INVITE message
The refreshing allows both the user agent and proxy to determine if the SIP session is still
active
The SIP Session Timer is a keep alive mechanism for SIP sessions that allow User Agents
(UA) or proxies to determine the status of a session and to release it if it is not active, even
if a BYE has not been received

Advanced Routing
Routing based on Quality of Service
Routing based on cost
Routing based on policies

26

Network Interworking
Signaling Interworking - Fill in for differences in Signaling protocols on both sides /
endpoints
Protocol Interworking - Need to enable connectivity between elements speaking
different protocols (e.g. SIP vs. H323)
Media Interworking / Transcoding - When there is a different codec being used on
every leg of the call, or DTMF translation is needed
Header Manipulation - Match or adapt differences in session handling between the
networks involved
Service-Level Agreement (SLA)
A Service-Level Agreement (SLA) is a contract between a network service provider and a
customer that specifies, usually in measurable terms, what services the network service
provider will furnish. Items to consider:
Call Admission Control - Protecting and optimizing the network by controlling the
volume of traffic
Bandwidth Management - Administering system resources for availability
Quality of Service (QoS) Metrics - Keeping track of Network performance
Real-time Traffic Monitoring - Based on capabilities above mentioned, how is the
service performing at any particular time

27

28

29

30

SBC Supported hardware

The hardware supported for the SBC 2U SBC and the RSM is based on an Intel Infrastructure.
The Intel Server Chassis provides a flexible and serviceable 2U rack-optimized chassis for
performance intensive and storage-demanding solutions.

31

SBC - QUANTiX Q20 - 2U (2 rack unit)

1:1 high available redundant system with state full call migration of signaling and
media with no loss of service
Up to 625 Call Attempts Per Second (CPS)
Up to 160,000 simultaneous SIP Signaling sessions
Up to 18,000 simultaneous media sessions (G.711)
Up to 28,000 simultaneous media sessions (G.729)
Up to 200,000 SIP registered endpoints
Up to 2M routes and calling plans

32

Ethernet Interfaces Port Break Down

The SBC 2U Server has Gigabit RJ-45 ports on the rear of the server for connectivity to the
network.
One additional full-height PCI-X card with four ports is added for Media. The ports are
designated hk0,0; hk0,1; hk0,2; and hk0,3.
Port allocation is as follows:
Eth0 - Management - used for all non-signaling traffic (CDR Streaming, Administration,
Radius Packets, RSM Integration)
Eth1 - Control Interface - Connected Directly to the redundant peer (heartbeat)
Eth2 - Primary Signaling - Generally Public Facing - dummy IP from 127.0.0.0/8
network
Eth3 - Primary Signaling - Generally Private Facing - dummy IP from 127.0.0.0/8
network
Eth4 - Secondary Signaling or backup Control (bonded)
Eth5 - Secondary Signaling or can be used for Transcoding
Hk0,0 and Hk0,1 - used for Media
Hk0,2 - Future Use - will be available for Lawful Intercept / CALEA
Hk0,3 Spare
33

34

Q21 SBC Server, release 8.4 Rear Panel

Q20 uses purpose-built hardware (ie. Cavium NP3 card) for media processing, whereas
Q21 leverages new Intel DPDK (Data Plane Development Kit) technology and Intel multicore processors to allow media processing to be done all in software.
Q21 can provide high scale integrated media density. Q21 can support 70,000
simultaneous pass-through media sessions when fiber-based media interfaces are used.
The Q21 uses SFP+ interfaces for the media traffic. That means it will auto negotiate to
1Gbps or 10Gbps.
The database in the Q20 can be transferred to a Q21.
Q21 will support onboard transcoding using the same DSP board that is used in the Q20.
Supported codecs are the same as available in SBC release 8.3.

An existing RSM that manages a Q20 can also be used to manage a Q21. However, that
RSM must be at release 8.4 or higher to manage a Q21 on release 8.4. Phase 1 of the Q21
will not support SRTP, LI (Lawful Intercept) and certain other customer specific features.
Phase 2 delivery of the Q21 is expected to have the same feature set as the Q20.

35

36

37

38

39

RSM Freedom

New with release 8.0.2, you can now deploy the GENView RSM software on alternative
server hardware. This type of deployment only supports GENView RSM in a simplex
(standalone) configuration . The following table identifies the minimum and
recommended hardware specifications for a Freedom GENVIEW RSM:

40

Ethernet Interfaces Port Break Down

The SBC 2U has two Gigabit RJ-45 ports mounted on the server board which are accessible on the
chassis back panel and are labeled eth0 and eth1. Two low-profile PCI Express cards, each with two
Ethernet ports are installed to accommodate interfaces eth2 and eth3 (Slot 1) and interfaces eth4
and eth5 (Slot 2). One additional full-height PCI-X card with four ports is added for Media in PCI-X
Slot 3. The ports are designated hk0,0; hk0,1; hk0,2; and hk0,3.
Eth0 - Management - used for all non-signaling traffic (CDR Streaming, Administration, Radius
Packets, RSM Integration)
Eth1 - Control Interface - Connected Directly to the redundant peer (heartbeat)
Eth2 - Primary Signaling - Generally Public Facing - dummy IP from 127.0.0.0/8 network
Eth3 - Primary Signaling - Generally Private Facing - dummy IP from 127.0.0.0/8 network
Eth4 - Secondary Signaling or backup Control (bonded)
Eth5 - Secondary Signaling or can be used for Transcoding
Hk0,0 and Hk0,1 - used for Media
Hk0,2 - Future Use - will be available for Lawful Intercept / CALEA
Hk0,3 - Future Use
Note: You can configure control links by connecting two systems with two cables connected to
Eth1 and Eth4 and bonding the interfaces together. The single bond0 interface can then be
assigned to an IP Address. If needed, Eth4 and Eth5 can be used for Signaling.

41

42

Cabling the IA-RMS SBC/RSM

It is important to know how to cable your SBC
and RSM properly. The following diagram is for
a typical HA (High Availability) deployment.
Based on your needs / demands, your network
may be configured differently.
IA-RMS Q-series uses the same connection
method.

NSF-NP3

The NSF-NP3 is a 4-port GbE device and supports Copper and Fiber Interfaces and can use
Small Form-factor Pluggable (SFP) transceivers. The NSF-NP3 provides DSP centric
applications such as soft DSP Emulation on the Core and DTMF Detection and Generation.
Note:
The current GA release supports three interfaces (port hk0,0, port hk0,1 and port hk0,2)
with a total of 3 Gbps throughput for media processing. The other interface (port hk0,3) is
for future use.

43

44

45

Hardware Query

To determine which base chassis you are using, run the following linux command:
hwinfo --bios |grep Product
The results will provide information on the actual product which can help you see what
chassis you have in your network.
Possible Results for linux hwinfo command

Product ID

46

Machine Type

SE7520JR22

Jarrell (not supported from 8.1)

S5000PA

Annapolis

FWA-3210

QUANTiX Q10 is the 1U (1 rack

unit)

S2600CO

QUANTiX Q20 is the 2U (2 rack

unit)

Determining Media Card

The linux command, lspci - n |grep 177d can also help you determine which Media Card
you have installed on your SBC. If the output contains ASCII string:
Output

Meaning

177d:0005

The Media Card is a NSF-NP2 (Pass 3) and does

not use the SFP connectors

177d:0005 (rev 03)

The Media Card is a NSF-NP2g

177d:0040 (rev 01)

The Media Card is a NSF-NP3

177d:0040 (rev 0b)

NP3 Q20 - Cavium Octeon CN5860 Multicore

MIPS64 Processor

177d:0090 (rev 0a)

NP3 Q10 - Cavium Octeon II Media Card, 2x 1GB

NSF = Network Service Firewall

NP = Network Processing
47

48

49

The C3/G9 Call Session Controller

The C3 provides multi call processing functionality such as the Signaling Gateway, Media
Gateway Controller and Application Gateway.
A typical deployment with the GENBAND G9 Converged Gateway provides a physical
interface into the PSTN. The G9 is controlled by the C3, which provides the controller
function of the G9 trunk inventory and call processing.
A GENBAND system (C3/G9 deployment) uses two proprietary call processing protocols:

Extensible Gateway Control Protocol (EGCP) for connection management; EGCP is

based on industry-standard Megaco but extended for higher bandwidth efficiency and
functionality.

Extensible Call Control Protocol (ECCP) for signaling event communication. ECCP uses
a proprietary message flow and content based on Q.931.

G9 Converged Gateway as a standalone media gateway, can be deployed in customer

networks under control of a third-party Media Gateway Controller (MGC) softswitch using
the proprietary EGCP interface or standard MEGACO (H.248).
The G9 Converged Media Gateway (MG) is a high-density Multimedia Gateway that scales
from a dozen TDM, IP and ATM ports to almost 90,000 ports.

50

The G9 MG can be co-located with the softswitch or distributed out at different

Points-of-Presence (POPs).

Introduction to GENBANDs C3 Call Session Controller

GENBAND's C3 Call Session Controller - is a multi-application softswitch and media

server/media gateway control platform that enables a new level of reliability, flexibility,
and scalability for network. The C3 reduces cost and operational complexity by integrating
media gateway control, service logic, billing, regulatory, signaling, service creation, and
element management within a common, scalable software and hardware environment.
The C3 software is deployed in high-availability distributed clusters using one or more pairs
of standard, carrier-grade servers. operators. Deployed worldwide and operating with
GENBANDs G9, G6, and G2 IP gateways, the C3 allows operators to cap-and-grow or
replace their TDM switches or provide scalable VoIP in greenfield applications.
Carrier-Grade Platform The C3 software is deployed in high-availability distributed
clusters using one or more pairs of standard, carrier-grade servers.
Integrated GenView Network Management The C3 has an integrated GenView Element
Management System that enables remote and centralized OAM&P control of multiple C3
nodes and gateways via web-based terminals.
High Capacity Platform Architecture Network-proven worldwide, the C3 supports
millions of Busy Hour Call Attempts (BHCA). The highly-scalable C3 operates in small to
large configurations.

51

G9 Converged Gateway

The G9 Converged Gateway can be deployed as a Media Gateway using the GENBAND C3
Media Gateway Controller using GENBAND proprietary Extensible Gateway Control
Protocol (EGCP) and Extensible Call Control Protocol (ECCP) or another type of Media
Gateway Controller (MGC) Call Control using the industry standard H.248 (Megaco)
protocol
The G9 provides simultaneous, any-to-any switching for enhanced flexibility and costeffectiveness, including protocol, interface, security, signaling, and media processing
support in all wireless and wireline, access and core, and IP and TDM environments,
maximizing investment protection as networks migrate.
A powerful IP gateway, the G9 supports Class 4/IP Tandem/IP Trunking and Class
5/subscriber solutions, as well as global applications such as wholesale interconnect. In
converged wireless/wireline networks, the G9 provides advanced solutions for Fixed
Mobile Convergence/femtocells and IP-to-IP multimedia transcoding.
Separate IP and TDM fabrics provide high quality native switching and interworking for IP
to IP and TDM-to-IP applications. The G9s massively scalable backplane and flexible 28slot chassis also provides an efficient card design that allows operators to easily scale TDM
and IP session capacity as well as incremental functions and services.
As a carrier class gateway, the G9 provides multiple levels of redundancy and load-sharing
on critical system components, cards, and network interfaces, in addition to in-service
software upgrades
52

Check Your Knowledge

1. One of the advantages to IPX is to provide support for interconnecting beyond IPX,
including multiple other IP and legacy technologies.
a) True
b) False

2. The C3 Call Session Controller softswitch or Multimedia Gateway Controller also

contains an integrated SS7/C7 Signalling Gateway and the Element Management
System (EMS)
a) True

b) False

3. A GENBAND system (C3/G9 deployment) for connection management, uses:

a) H248 / Megaco
b) Extensible Gateway Control Protocol (EGCP)
c) SIP I
d) SIP T

4. The network processing card is a:

a) 1 port GbE device
b) 2 port GbE device
c) 4 port GbE device
d) 6 port GbE device

53

54

55

56

57

58

59

60

What is The Problem?

IP & TDM Networks
Voice subscribers on IP networks frequently require a connection Voice subscribers on TDM
networks. This is achieved with a Media Gateway that will interwork between the two different
types of network.
The GENBAND G9 is such a Media Gateway.
A Media Gateway is a slave to a Media Gateway Controller. In the GENBAND IPX solution the
GENBAND C3 is the Media Gateway Controller.
Transcoding
Incompatibilities may exist between two endpoint users that make it impossible to establish a
media session due to these incompatibilities.
Both user agents may understand the same session description format (e.g., SDP (RFC4566), but
incompatibilities can be found at the user agent level. At the user agent level, both terminals
may not support any common codec or may not support common media types (e.g., a Cell
Phone and an IP SIP phone). At the user level, the audio stream will be incompatible.

Transcoding is the direct digitaltodigital data conversion of one encoding to another, such as for
AMRWB audio stream with a G.711 audio stream.
In order to make communications possible in the presence of incompatibilities, user agents need
to introduce intermediaries that provide transcoding services to a audio session.
The G9 (MRFP) will transcode (translate) the incompatible codecs between the two endpoint
61
users to create an RTP IP Media audio stream.

Transcoding Overview
The Transcoding logic is integrated with the S-CSCF. The Transcoding of media (RTP) is done by
the Media Resource Function (MRF). In this implementation, the MRF is split into separate
Control and Transport plane components:
MRFC: The GENBAND C3 product is deployed as the Media Resource Function Controller
(MRFC) and acts as the control plane for MRF. The MRFC is responsible to control the MRFP
media resources. The MRFC is deployed in the IMS core sites, in the same location as the SCSCF.
MRFP: The GENBAND G9 product is deployed as the Media Resource Function Processor
(MRFP) and acts as the transport plane for the MRF. The MRFP holds the DSP resources and
performs the media Transcoding.
Separation of the media processing and control functions enables Verizon Wireless to reduce the
amount of signaling traffic and processing delay between the IMS Core and MRFC by co-locating
the C3 MRFC close to the Core, while preserving RTP bandwidth by placing MRFPs close to the
location of the user elements. Additionally this separation of media processing from the control
function allows independent and more flexible scaling when the volume of traffic requires it.
The S-CSCF introduces the MRF into the media path when it determines that the two
communicating endpoints do not support a common codec. The S-CSCF utilizes Mr interface
based on RFC 4117 to interface to the MRFC.

62

Media Gateway Overview

A media gateway is a translation device or service that converts digital media streams between
disparate telecommunications networks. In the case of the GENBAND IPX solution the G9 is the
gateway between the IP network and the TDM network. Media streaming functions such as
echo cancellation, DTMF, and tone sender are also located in the G9.
Media gateways are often controlled by a separate Media Gateway Controller which provides the
call control and signaling functionality. In the case of the GENBAND IPX solution the C3 is the
Media Gateway Controller.

63

64

65

C3/ G9 System Frame Chassis

For turnkey GENBAND installations the standard frame is a 19 telco-style frame with an open
front. The frame has a nominal 7 height that provides 44u (77) of internal space. The frame is
designed to be bolted to the floor and to overhead frames to meet earthquake requirements.
Included in the standard GENBAND frame are:
a Frame Alarm Indicator Panel (FAIP), 1u, and a GENBAND-supplied Power Distribution Unit
(PDU), 1u, which occupy the top two positions in the frame

one or two G9 Converged Gateways

a terminal server, 1u
an optional pair of Ethernet switches for IP network connectivity
a pair of IA-RMS servers that provide the C3 functionality, which occupy the bottom of the
frame.

66

Frame Alarm Indicator Panel (FAIP)

The Frame Alarm Indicator Panel (FAIP) is mounted on the top front of the C3/G9 system and
provides a visual and audible indication of the status or fault involving the components in the
frame.
Each FAIP provides a unique frame identity contact closure that activates any time an alarm of
any level is triggered within the frame.
This signal is available to the CO alarm system for a visual indication of the alarmed frame within
the equipment lineup.
The alarm panel is wired to receive events from all frame components.
The tri-colored LED signals the severity of an event.
The visual alarms are designated as follows:
Solid Amber - Minor Alarm
Solid Red - Major Alarm
Blinking Red - Critical Alarm
Solid Green- No Alarms

Each frame also includes an audible alarm that sounds a distinctive tone for each level of alarm.
The audible alarm may be acknowledged and manually silenced at the frame.
Minor audible alarms are self-retiring.

67

Power Distribution Unit (PDU)

The Power Distribution Unit (PDU) mounts at the top of the frame below the FAIP.
A dual feed 48 VDC power source is connected to the PDU.
The circuit breakers on the panel control the connection of A and B power to the individual
components in the frame. PDU has 8 Circuit breakers and 8 GMT cricket fuses.
Provides up to 300 amps per A and B -48 VDC power source.

PDU Circuit Breaker assignments:

Each individual C3 node (Netra Server) uses two 15 amp circuit breakers. One 15 amp A circuit
breaker and one 15 amp B circuit breaker
C3 are deployed in pairs. For a total of two A and two B 15 amp breakers per pair.
Each individual G9 node uses two 65 amp circuit breakers. One 65 amp A and one 65 amp B
circuit breaker.
PDU CMT Fuse assignments:
Each individual Ethernet Switch (optional) uses two 3 amp fuse.
One 3 amp A fuse and one 3 amp B fuse.
The Terminal Server uses two 3 amp fuses.
One 3 amp A; fuse and one 3 amp B fuse.
Alarm Power Bus uses two 1 amp fuses.
One 1 amp A; fuse and one 1 amp B fuse.
68

C3 Call Session Controller

The C3 Controller consists of a set of single-shelf high-reliability multiprocessing computers
based on Kontron IA-RMS servers.
At least two C3 nodes are required for redundancy purposes. Signaling gateway (SG)
functionality is integrated into the C3 nodes.
Most C3 Controller software functions operate in 1:1 active/standby mode; but call processing as
well as SG link-level facilities are load-shared across multiple C3 Controller nodes for increased
performance, if more than two nodes are installed.
The C3 communicates with the G9 nodes via IP, typically using an Ethernet LAN. The
communication protocol between the C3 and G9 is EGCP. It is possible to locate the G9 nodes
remotely from the central site where the C3 is located.

69

70

71

C3 Server hardware platforms

The C3 application is supported on multiple hardware platform servers.
Up to the end of 2013 the deployed servers were T5220. The IA-RMS was introduced and is now
the server being shipped.

72

C3 Signaling Controller Hardware Platform

The C3 is now being shipped running on the IA-RMS and uses a dual Intel Sandy Bridge, 8 core
2.1GHz processors with 64 GB RAM @ 1600MHz.
19 rack mount, 20 depth
Pair of hot-swappable disks - 900 GB 10,000 rpm 2.5" SAS Disk Drives - GBRY44FA
Dual ATM OC-3 Network Interface cards with SFP type interfaces. LC multimode type SFPs
included with the server
Redundant 650W DC Power Entry Modules (PEMs)
GENBAND does support legacy platforms to host the C3, including GENBAND 410, 510, 512, and
514 Media Gateway Controller models, and Sun Netra 240, 440, T2000, and T5220 servers as
well at the C3 on the ATCA platform.

73

C3 Clustering
The C3 can be configured as a computing complex composed of up to 16 pairs of computing
nodes.
Most of the MGC software applications running on the C3 operate as active/standby pairs or
pooled resources.
Cluster capacity is grown by:
Adding C3 node pairs
Spreading protocol stacks and other applications across more node pairs
Adding additional instances of processing applications
Ensuring sufficient working memory is allocated to key applications
C3 cluster expansion is always implemented with C3 node pairs. Because the Call Manager is a
loadshared application, it is typically deployed on all C3 nodes in the cluster.

74

Netra T5220 Front view

With the Front Cover (Bezel) open, technical support personnel has additional access to the Hard
Drive units for replacement if required.

75

Netra 5220 Rear Connections

All connections to the Netra 240 are located in the rear on the unit. The following connections
are located in the rear:
Power Supply (PS0 and PS1)
Alarm Port
Ethernet Ports ( 0, 1, 2, and 3)

Serial Console Management port

The C3 Server can be equipped with the ADAX SS7 card for communications in the Signaling
System 7 (SS7) network. The ADAX card provides the following additional connections:
SS7 Ports (0, 1, 2, 3)

76

IA RMS Platform Front View Bezel Cover Installed

This is the front view of the Kontron CG2200 carrier grade server with the bezel cover installed,
painted black with GENBAND livery. There are no external connections on the front of the IA
RMS chassis which are used.
There are two PECs that will be supported for the IA RMS based on the power source (AC or DC).
Features of the IA RMS platform include:
CPU: Dual E5-2658, 8 cores, 95W, 2.1GHz

RAM: 64G
Disk: 2 x Seagate Savvio 900GB 2.5 10K SAS HDD
Ethernet: 4 x 1GigE RJ-45 On-board + 4 x 1GigE RJ-45 NIC
Power Supply:DC Power Supply Unit (GBRY41JA) or AC Power Supply Unit (GBRY41JD)

77

IA-RMS Front View

This is the front view of the Kontron CG2200 carrier grade server with the bezel cover removed.
Removing the bezel provides access to the hard drive carriers and SD card slots.

78

IA RMS Platform Front Panel

All front panel switches and status LEDs are located on the LED/switch board.

Item

Description

Power button

System reset button

C
C

System Status LED

D
D

Fan status LED

EE

Critical alarm (amber or red)

FF

Major alarm (amber or red)

Item

G
H
I
J
K
L

Description
Minor alarm (amber)
Power alarm (amber)
HDD activity LED
NIC activity LED
Chassis ID button
NMI button

79

IA-RMS Rear View

Eth2 & Eth3 ports go to customer L2/L3 switch/router
Each IA-RMS should be powered by (2) 15 amp fuses or circuit breakers.
The units typical power consumption is 358W with max power consumption at 506W.
Ethernet ports Eth2 & Eth3 go to customer L2/L3 switch/router.

Item

Item

Description

AA

Serial Port

DC Power Supply

BB

VGA Video Port

DC Power Supply

(DVD for software)

(USB drive for backups)

Expansion Slots

D
D

Ethernet 2 & 3 (top to bot)

JJ

Expansion Slots (x2 for OC3

Cards)

EE

Ethernet 4, 5, 6, 7 (top to
bottom)

Ethernet 0 & 1 (left to right)

FF

Ground Point)

LL

External Alarm Port

CC

80

Description

USB ports

C3 / G9 Connectivity diagram

81

Field Replaceable Units (FRUs)

Illustrated in the slide are the server components that are Field Replaceable Units (FRUs). These
FRUs can be replaced by a technical service personnel without the need to power down the unit.
Note:
Always refer to the appropriate Maintenance Documentation before carrying out maintenance
tasks.
The 630-00610-01_8.1 C3 Maintenance and Repair Guide includes maintenance and
replacement tasks for the legacy (GENBAND manufacturer discontinued) 410, 510, 512, and 514
models of the C3 Controller.
For the SUN-based T5220 and T2000 models of the C3 Controller, maintenance and repair tasks
can be found at the Sun Microsystem website.

82

http://docs.sun.com/

Note: this link now takes you to the Oracle documentation site where the documents are found.

83

G9 Media Gateway (MG)

The GENBAND G9 Converged Media Gateway is a high-density trunking media gateway
architected for both fixed and mobile service providers. The G9 Converged Media Gateway was
developed as an independent node.
The NEBS-3 compliant G9 provides the facility network access and signaling capabilities.
The G9 provides the any-to-any relationship between various traffic types and also
provides its own fault and configuration management.
G9 cards utilize 1:1, 1:N, 1+1, or N+1 redundancy, as appropriate.
Server cards can be added to grow G9 capability. Capacity increases include:
Voice Server capacity
Echo Cancellation capacity
Signaling Gateway capacity
Interface between the C3 MGC Application and the G9 is based on an enhanced proprietary
version of the MEGACO protocol standards known as Extensible Gateway Control Protocol
(EGCP). The MGC communicates only to the Master CPU (Central Processing Unit) on the Packet
and Control (PAC) card.
The G9 supports the following Media Gateway services:
Voice over ATM: AAL2 and AAL5 voice trunking
Voice Over IP: RTP voice trunking (SIP and H.323)
Media Processing, such as:
Hybrid Echo Cancellation, Tones and Announcements
84

Conference Bridges, Caller ID Frequency Shift Keying (FSK)

G9 Top-Front Alarm Panel

The G9 is equipped with the following Alarm buttons within each chassis .
Alarm Silence will silence the current occurrence of the audible alarm
The next occurrence will set the audible off again

Alarm Cutoff will permanently stop all audible alarm on the G9

Generates a minor alarm

Cutoff will generate an event message

Cutoff will be seen in EMS on the MG nodes General tab

Alarm Level LED - shows highest alarm present on the G9 (minor, major, critical)
Solid Amber Minor
Solid Red Major
Blinking Red Critical

LED Test button - Tests LEDs on circuit cards.

85

G9 Top-Rear Panel
Each G9 node in the frame will have an alarm connect to the Frame Alarm Indication Panel
(FAIP). This connection runs from the G9 Alarm Card Output.
Contains alarm card outputs.
Requires a DB-9 connector.
Connects to appropriate Alarm Connector on FAIP.

86

G9 Fans and Filters

The G9 chassis contains 12 fans to cool the chassis.
Three (3) exhaust fans are located at the upper front of the chassis. These three (3) fans exhaust cooling
air to the outside. Exhaust air blows out through the rear of the G9 chassis. The exhaust fans are
numbered as follows:
Fan numbers1-3, reading from left to right.
Nine (9) small intake fans are located at the bottom front of the chassis and are accessed from the lower
front of the chassis. They are mounted on three (3) trays with three (3) fans each. Each fan tray is
powered by ribbon cables.
These nine fans pull cooling air into the chassis from the front and sides of the unit and are numbered 412. Facing the front of the G9 chassis, they are numbered front to back and left to right as follows:
Fan #4 is at the front of the left most tray
Fan #12 is at the back of the right most tray
G9 Upper Front Exhaust Fan Assembly
The G9 upper front exhaust fan assembly can be replaced with the system operating, without presenting
an electrical hazard or damage to the system.
All 3 fans are attached to a sheet metal plate that floats (not secured with screws. The alarm panel and
air deflector shield must be removed to perform operation.

G9 Lower Front Intake Fan Assembly and Filters

The G9 lower front intake fan assembly and air filters can be replaced with the system operating, without
presenting an electrical hazard or damage to the system. The front guard panel must be removed to
perform operation. The front intake fan assemblies are attached via ribbon cables.
Fans and filters sit loosely on the tray underneath the fans and should be cleaned every 30 days.
Refer to G9 Converged Media Gateway Maintenance Guide 630-00479-01 for complete
maintenance instructions pertaining to fan assemblies and filters.

87

G9 Power Filters
There are two generations of G9 Chassis the latest being the G9e (the power filters of which are
shown in the top diagram)
In both cases the -48v input filters are located on the upper-rear of the G9 Gateway chassis and
help to eliminate noise when power inputs are not received clean.
The power feed and return cables on the back side of the filters have three (3) parallel power
connectors that connect to the top of the mid-plane.

88

Control Cards
SST Card (Switch, Service and Timing) - Provides Switching (DS0 Matrix), Service circuits (DTMF
receivers, Tone detectors, etc.) and Timing (clock distribution).
PAC Card (Packet and Control) - Contains 2 GbE switches used to switch Control plane and Bearer
plane traffic independently.
SI Card (Shelf Interface) - T1/E1 test access, BITS clock interface, PAC console interface, PAC
control interface

Server Cards
VS/ES/SG - Server Cards - Voice Server, Echo Server and/or Signaling Gateway
Network Interface Cards (NIC)
TDM Cards - T1/E1, DS3, OC-3/STM-1
Packet Interface Cards - GEI (Gigabit Ethernet) and AI (ATM Interface)

89

G9 Mid-plane
The G9 is a single-shelf design with a mid-plane chassis architecture. All cards in the G9 plug into
the Ethernet-based mid-plane. The mid-planes primary functions are to provide redundant
point-to-point connectivity, power, and physical grounds for all card slots.
The chassis mid-plane is designed and manufactured to be extremely reliable and provides two
GbE bearer paths and a GbE control path from each PAC slot (slot 7 and 8) to every other slot in
the chassis.

The chassis mid-plane also provides a point-to-point, unidirectional serial TDM DS0 highway
from each SST slot (slot 21 and 22) to and from every other slot.
The TDM connections provide up to 8000 timeslots and are allocated in 1K increments when
a slot is provisioned for a specific card type.
This allows the available TDM DS0 matrix capacity to be allocated to each slot on an asneeded basis, reducing wasted capacity due to over-allocation of TDM matrix capacity to
slots that dont require it.
The G9 mid-plane:
Supports 28 card slots, 14 front and 14 rear slots

Two half-size slots (in the rear) for Shelf Interface

These mid-plane highways are all point-to-point, fully redundant and have no single point
of failure
No direct or one-to-one relationship between front and back card slots
Additional paths are provided to enable card level redundancy schemes employed by the
90
G9.

Check your knowledge

After completing this exercise, the student will have the ability to describe and locate the G9
chassis alarm LEDS, fan unit components, and chassis external interface connectivity. The
students will also be able to perform routine maintenance on the G9 field replaceable units.
1. Which server is the newest introduction for the C3 application?
____________________

2. List the Field Replacement Units (FRUs) of the servers?

_______________________________
________________________________

________________________________
3. How many slots are there in a G9 Gateway chassis?________ rear and ________front.
4. How many fan trays are on the G9e chassis? How are they numbered and where are they
located?
a. Number of fan trays ______________
b. Fan numbers
a. ______________; location______________________________
b. ______________; location______________________________
c. ______________; location______________________________
d. ______________; location______________________________

5. Alarms can be silenced from the front alarm panel on the G9?
a. True ____________________
b. False ___________________

6. There is a one-to-one direct connection on the mid-plane, between front and rear cards on
the G9 chassis.
a. True ____________________
b. False ___________________

91

G9 Cards Card LED Indicators

The G9 chassis supports twenty-eight (28) card slots, fourteen front and fourteen rear. In
addition to the fourteen rear slots, there is are two (2) dedicated half height slots in the rear that
house the Shelf Interface (SI) Unit.
Fault and Status LEDs are in the same location for all cards, except the SI units (half slot
cards) which has no fault or status LEDs.

92

G9 Cards (Rear View)

The Network Interface (NI) cards and Switch, Service and Timing (SST) cards located in the rear
have the Fault and Status LEDs located at the top of the card above ports used for physical
terminations.
There are also additional Fault and Status LEDs for each OC3/STM1 port and for each ATM
port located in slots 19, 20, 23 and 24.
The Status LEDs will signify which port (OC3/STM1) or Port Group (AT) is currently active.

93

Shelf Interface (SI) Unit

The shelf interface unit consists of two half cards that occupy dedicated rear slots, 29A and 29B,
on the right-side of the G9 chassis. The SI units provide the following:
PAC Work - Interfaces the slot 7 PAC to the MGC (via Ethernet Switch)
PAC Protect - Interfaces the slot 8 PAC to the MGC (via Ethernet Switch)
Each PAC card has redundant 100Base-T interfaces for control connection to an MGC. On the G9
Gateway these interfaces are routed internally from the PAC card to the SI card so the
connection can be made from the rear of the chassis. Each PAC card has an MGC interface on the
top SI card and another MGC interface on the bottom SI card. T1/E1 - Provides a T1 or E1 test
point that is connected to a DSX panel allowing test equipment access
BITS - provides either a Coax (BNC) or a DB9 connection for clocking inputs
BITS connection on the UPPER SI card is the PRIMARY timing source for both SST cards.
BITS connection on the LOWER SI card is the SECONDARY timing source for both SST cards.
PAC Console - provides a CLI interface to the G9
SC Console - not currently used
LED Test Button
The LED Test button on the SI can be used to test the LEDs on all of the cards inserted in the
chassis (i.e.., same functionality as the LED Test button on the front panel of the chassis.
In addition to the LED test button on the SI unit, the PAC Ethernet Ports along with the both
Console ports have the following indicator LEDs:
Activity - Flickers Amber with packet activity between the PAC cards and the MGC.
94

Green - Link.

Packet and Control (PAC)

The Packet and Control (PAC) cards are located in slots 7 and 8, they are configured as an active/standby
(1:1) redundant pair. The standby card is kept in a hot standby state by means of continuous call state
updates from the active card
The PAC is at the top of the control hierarchy of the G9. It provides management and control of all G9
resources with the cooperation of the other processors in the G9. Other functions include:
Control Processing - The PAC card carries a 2 GB flash disk drive for storage of executables, database
backup and performance measurements. This allows for quick initial program loading and rapid
service restoration after a fault.
Call Processing - Allocates physical resources for all call types in the G9 domain. Serves as the call
processing interface from the G9 to the controlling MGC. It supports up to 255 narrowband HDLC
signaling channels used on PRI, GR303 or V5.2 links. It provides IP routing for VoIP calls with
cooperation from the IP forwarding engines on the GEI cards.
Node Management - Manages all physical resources in the gateway. It has an SNMP agent that
provides a conceptual view of the gateway resources to the controlling MGC and EMS. Monitors the
other cards in the gateway for sanity and communication capability, and will command a switchover
to a redundant card upon detecting a card failure (cards send Inserted and Keep Alives to PAC
regularly).
Ethernet Interfaces - Communicates through two external 100Base-T Ethernet (FE) interfaces on the
SI card for communication with the controlling MGC. Each external FE interface on the SI card
connects to a separate port on the control plane Layer 2 GbE switch on the PAC card.
Card Testing - Both offline monitoring and offline testing of all the other cards on the G9:

Cards utilizing TDM services PAC coordinates path monitoring on each TDM highway between the card
and associated functions on the SST card.

Cards utilizing the mid-plane GbE bearer plane the PAC verifies the function of the cards GbE bearer
capabilities using the PAC- resident GbE switching resources.

Offline Test Support - The PAC and the G9 Gateway support he capability for the craft to take a PAC
card offline and perform a comprehensive card test.

95

G9 Packet and Control Card

The interfaces are routed from the PAC to the SI so the connections can be made from the
rear of the chassis rather than the front.
Since each PAC has two control interfaces, each PAC is connected to each of the SI cards.
Thus, there are a total of four FE interfaces. Two on each of the SI cards.
The G9 chassis provides a PAC console serial port interface with the top SI card connected to
one PAC and the bottom SI card connected to the other PAC

96

Check your knowledge

After completing this exercise, the student will have the ability to determine the functions and
interfaces of the PAC cards.
1. What are the PAC slot numbers? ___________________ and redundancy
scheme?___________________
2. List five (5) functions of the PAC card.
a.
b.
c.
d.
e.

3. Shelf timing is provided by the PAC card?

a. True
b. False

4. The PAC card has two on-board __________________ whose general functions are:
a. ___________________________________________________________
b. ___________________________________________________________

5. Serial port interface communication to the PAC card is achieved through the
_______________card.
6. The PAC cards have dual connections to both SI cards.
a. True
b. false

7. Which connectors are used to communicate to the PAC from a craft

terminal?__________________________________________
8. Which connectors provide primary and secondary BITS clock inputs to the
SST?__________________________________________
9. Cards in slots 1-28 on the G9 have ________________ LED indicators.

97

Switch, Service and Timing (SST) Card

The Switch, Service and Timing (SST) card provides TDM DS0 channel switching capability for the G9 cards
via the mid-plane. There are two SST cards in a G9 chassis, configured as an active/standby (1:1)
redundant pair, which plug into two dedicated center slots in the rear (Network Interface side) of the
chassis.
The SST card also provides service circuit resources for call processing and supplies reference
clocking to the other cards in the gateway chassis.
The SST is offered in three versions and is provisioned in pairs as:
a pair of 64K SST cards or
a pair of 104K SST cards or
a pair of 104K SST with IWF cards (used in GSM and UMTS Wireless Networks)
The 104K SST card offers all the functionality of the 64K SST card but increases the capacity to 104K
timeslots. The 104K SST with IWF card has all the functionality and capacity of the 104K SST and in
addition provides an embedded Inter-Working Function (IWF).
TDM Switching Fabric or Time Slot Interchange (TSI) matrix
The 64K version of the SST card contains a 64K x 64K TDM matrix, or Time Slot Interchange (TSI) matrix.
Of the 64K (65,536) available TSI timeslots, 3K channels are reserved for overhead and service, leaving an
effective capacity of 61K (62,468) timeslots for trunk, line, and server connections
The 104K version of the SST card contains a 104K x 104K TDM matrix. Of the 104K (106,496) available
timeslots, 3K channels are reserved for overhead and service circuits and 5K channels are reserved for
internal use, leaving an effective capacity of 96K (98,304) timeslots for trunk, line, and server
connections.
The SST also provides the system clocking reference for all of the cards on the G9 Gateway Chassis that
require precise timing. Primary and secondary timing can be provided by either of two sources:
External BITS supply
Line timing source - T1/E1, SONET/SDH
The SST is equipped with an on-board Stratum 3 clock that can provide holdover timing for up to 30.

98

G9 Bearer Data Flow

Each SST provides point-to-point unidirectional serial TDM highways to and from the other slots
in the G9. The channelized interface, packet interface and server cards, in particular, require
these TDM highways

99

Server Cards
Server cards on the G9 Gateway Chassis can be installed in slots 1-6 and 9-14.
There are three (3) server card types:
Voice Server Card - VS-8B or VS-9
Echo Server Card - ES
Signaling Gateway Card - SG

100

Voice Server (VS-8 or VS-9) Card

There are two types of VS cards; the VS-8 card and the newer VS-9 card. The VS-9 card uses a
different type of digital signal processor (DSP) and offers increased channel capacity for all
supported codec types. The Voice Server cards are installed in slots 1-6 and 9-14 and utilize loadsharing protection.
The Voice Server (VS) card mediates between channelized TDM voice streams and packet based
voice streams.
The VS card has TDM interfaces to the SST and GbE interfaces to the PAC.
It uses DSP resources to interwork between those two interfaces. Converts DS0 bit streams
into IP Packets
Provides Echo Cancellation (ECAN) for TDM-to-IP Packet flow
The VS supports VoIP, UMTS and UMA / GAN and supports a variety of codecs, such as G.711,
G.726, G.729, G.723.1, T-38 and AMR.
The number of VS cards required depends on the mix of codec types needed and the
number of other cards in the G9.
The VS card also supports a wide range of both wireline and wireless protocols such as T.38, RFC
2833 for DTMF tones, and echo cancellation.
Voice Server (VS) Card Protection
The VS-8 and VS-9 cards operate with N+1 load-shared redundancy, where N can range up to 11
(cards). All packet-related traffic is shared over a pool of VS-8 cards. The number of cards is
engineered such that if the largest card in the group fails, there are still sufficient resources to
handle the engineered capacity.
101

VS Card Usable Codec Capacity

Pure mode - when no more than one compressed codec type is being used in a DSP chip Mixed
mode - when two or more compressed codec types are being used.
Total usable channels is a weighted average based upon mix of codecs used. The overall
capacity of a card is reduced by about 10%.
Additional Engineering considerations must also be considered if deployed with:
Wireless Codecs, such as AMR, GSM, EVRC and TFO
Dual Filter Echo Canceller (DFEC), support available only with the VS-9 card
Voice Quality Enhancement (VQE)
Real Time Control Protocol Extended Reports (RTCP XR)
IPv4 or IPv6
Specific engineering requirements are beyond the scope of this course. For additional
information refer to documentation: G9 Product Description:
630-00524-01

102

Echo Server (ES) Card

Echo Server cards can be installed in slots 1-6 and 9-14. Echo Server cards are only required for
TDM-to-TDM calls and TDM call legs of a TDM-to-Packet call when a bridge is used that require
Echo Cancellation (ECAN).
Each Echo Server cards supports 8K timeslots, because each call that uses the ES function
requires hair-pinning through the card, it requires two timeslots. Hence one ES card
supports up to 4,026 calls.

The maximum number of active Echo Server cards that are supported by a G9 Gateway with
the 64K SST card is four (4), therefore, four active cards support 4 x 4,026 = 16,104 calls
The maximum number of active Echo Server cards that are supported by a G9 Gateway with
the 104K SST card is five (5), therefore, five active cards support 5 x 4,026 = 20,130 calls
The Echo Server card provides Hybrid Echo Cancellation (HEC) and Transcoder Free Operation
(TFO) In-Path Equipment (IPE) functions. HEC and IPE functions are directional. The ES card
provides them in the appropriate direction for each call leg.
ES Card Protection
The ES card operates in 1:N active/standby redundancy protection, where N can be a maximum
of 4 or 5 as described above, for a potential maximum of six (six) card per G9. When a card fails
the standby card becomes active and takes over the calls from the failed card.

103

Signaling Gateway (SG) Card

With the development of VoIP, telephony switches have evolved to the softswitch architecture
(distributed Media Gateway Controller + Media Gateways), where the MGs (G9) are controlled
by the MGC (C3) using IP-based protocols such as MEGACO (H.248). Given that SS7 signaling and
ISDN Primary Rate Interface (PRI) Q.931 signaling are typically processed by the MGC, but may
actually be received by the MG (G9) over the same physical facilities as the bearer, it becomes
necessary to transport/relay the SS7/Q.931 signaling to the MGC (C3) over IP.
The IETF SIGTRAN working group has addressed this issue via the following:
The MTP3 User Adaptation Layer (M3UA) protocol, designed to reliably transport SS7
signaling over IP
The ISDN Q.921-User Adaptation Layer (IUA) protocol, designed to reliably transport Q.931User signaling over IP

104

Signaling Gateway (SG) Card

The GENBAND G9 Converged Media Gateway supports an M3UA-based and IUA-based Signaling
Gateway (SG) subsystem on the Signaling Gateway (SG) server card.
The SG Card supports:
TDM-based low-speed (56kbps or 64kbps) SS7 links (LSLs)
TDM-based high-speed (1.56Mbps or 2.04Mbps) SS7 links (HSLs)
ATM broadband-based SS7 links

PRI D-channels : SG not required when G9 is deployed with the C3 MGC.

Relaying of SS7 signaling and Q.931 signaling to MGC(s) over an IP network (SG functionality)

SG Card Protection
The SG cards operate with load-sharing protection (N+1 where N = 1-6), with up to seven cards
and a minimum of two cards.
Up to seven (maximum) Signaling Gateway cards can be installed in slots 1-6 and 9- 14.

105

M3UA Signaling Gateway Application

The M3UA-based SG function is used to backhaul SS7-based signaling from PSTN TDM-based SS7
links carry signaling traffic using an MTP3/MTP2 protocol, which can support higher-level
protocols like ISUP and TUP to the controlling MGC over a packet network. This SG function
provides interworking of SS7 signaling transport to support the following applications:
Backhaul of SS7 signaling between PSTN switches in the SS7 domain (ISDN User Part (ISUP)
and Telephone User Part (TUP) signaling) and MGCs in the IP domain

106

IUA Signaling Gateway Application

The G9 SG also supports the IETF SIGTRAN ISDN Q.921 User Adaptation (IUA) Layer interfaces
when the G9 Converged Media Gateway is deployed with a third party Media Gateway Controller
(MGC) or the GENBAND C20 Converged Softswitch.
The IUA layer transports Q.921 user signaling messages from a Signaling Gateway (SG) to one or
more Media Gateway Controllers and vice versa. IUA is used to backhaul the ISDN Q.921
signaling over an IP network using the Stream Control Transport Protocol (SCTP). IUA is used on
the G9 to support ISDN subscriber lines and ISDN PBXs.
IUA is similar to the M3UA protocol in that both reliably backhaul signaling traffic over an IP
network, but while M3UA backhauls MTP3-based SS7 signaling, IUA backhauls ISDN (Q.931)
signaling.

107

Signaling Gateway Traffic Flow

The G9 Gateway SG function connects to the SS7 network(s) via ATM or TDM links to the IP
Network via GEI cards.
SS7 and PRI Network Side:
Via OC-12c/STM-4c ATM and OC-3c/STM-1c ATM Links
MTP3b/SAAL (message routing for broadband ATM SS7)

Via E1, T1, OC-3/STM-1 TDM Links

MTP3/MTP2 (message and data link layer for narrowband and HSL SS7 links)
Q.931/Q.921 (message and data link layer for narrowband PRI links)

Communications IP network:
GEI card IP Links
M3UA/SCTP (MTP3 User Adaptation layer 3 peer protocol)/(SIGTRAN transport)
IUA/SCTP (ISDN User Adaptation layer 3 peer protocol)/ (SIGTRAN transport)

108

Channelized Interface Cards

The G9 Gateway supports the following TDM Network interface cards:
T1/E1 Channelized Interface
T3/E3 Channelized Interface
Quad OC3/STM1
Network interface cards can occupy any of twelve network interface slots on the rear of the G9
Gateway Chassis. Slot numbers are 15-20 and 23-28.

109

Universal T1/E1 Channelized Card

The Universal T1/E1 card provides TDM networks with access to the G9 system. The T1/E1 cards
reside in rear slots 15-20 and 23-28 on the G9 Gateway Chassis.
The T1/E1 card has five 51-pin connectors on the faceplate, with each connector supporting
12 T1 or E1 ports.
Each T1 card supports up to 60 T1 ports, with up to 1,440 individual DS0 channels.
Each E1 card supports up to 60 E1 ports, with up to 1,860 individual DS0 channels.
The cards have a bus connection through the mid-plane directly to the SST, which has the
responsibility of switching the information to its destination.
Universal T1/E1 Channelized Card Protection
The protection scheme for the T1/E1 interface card is 1:N unidirectional protection redundancy
where N can be from 1 to 11.

110

T1/E1 Protection
The T1/E1 card utilizes 1:N unidirectional protection scheme, where N is from 1 to 11. In this 1:N
protection scheme there is one (1) protection card for (N) working cards.
When there is a failure on a working card, traffic is switched to the protection circuit. Since
multiple working cards share the same protection card, a single failure among the set of (N)
working cards causes the one protection card to be used and the other working cards are no
longer protected. When the failed card is replaced, protection once again, is available.
T1/E1 protection supports revertive switching mode with a configurable Restore Time.

111

T1 and E1 cards - Normal Condition

If the DS1 card fails, a series of bypass relays near the interface switch the signal directly to the
mid-plane, bypassing all circuitry on the board. However, there is a facilities cable dependency
on the active card after the switchover since the facilities cables are physically connected to the
failed T1 card.
Without power to the card, the bypass relays are set to the bypass mode. This ensures the
redundant will process frames to/from the facilities cables even in the event of power failure on
a T1/E1 card.
T1 and E1 cards - Normal Condition
Active Card
Fault LED is Off
Status LED is Green

Redundant Card
Fault LED is Off
Status LED is Blinking Green (300 ms ON and 3 seconds OFF)

112

T1 and E1 Cards Failed Card Condition

Failed Card
Fault LED is Red
Status LED is OFF
Redundant Card
Fault LED is Off

Status LED is Solid Green

113

T1 / E1 Interface Cable

114

Facility Cable Connected

When a facilities cable is connected to a T1 card, a signal is sent out on pin 49. If it is received
back on pin 50, the system knows the facility cable is connected. After replacing a T1 card, after
the 5th facility cable is connected, the Revert Timer starts, which, when it times out, traffic is
reverted to the replaced card and the redundant is again the redundant.
Bypass Cable Connected
When a bypass cable is connected to a T1 facilities cable (piggy-backed), a signal is sent out by
the redundant card on pin 49. If it is received back on pin 50, the system knows the bypass cable
is connected. After connecting all 5 bypass cables, traffic from a failed T1/E1 card (that is
traveling across the backplane to the redundant T1/E1 card) is diverted across the bypass cables
to the redundant card
Process for Connecting Bypass Cable
Connect bypass cables from the redundant T1/E1 card to the failed card, by connecting
connector 1 to connector 1, connector 2 to connector 2, etc..
Secure bypass cables with built-in screws
When all bypass cables are securely fastened, and the redundant cards Status LED is solid
green,
the system automatically executes the use Front Cable command.

At this point, traffic is routed through the bypass cables to the redundant card and not through
the midplane.

115

DS3 Channelized Interface Adapter Card

The CI Adapter card can accommodate up to two DS-3 CI Super Slot cards and can reside in slots
15 through 20 and 23 through 28.
The Channelized interface (CI) Adapter card has two (2) sub-slotted locations on the card edge or
faceplate. These sub-slots are identified as Super Slots.

116

DS3 CI Super Slot Card

Each DS3 CI Super Slot card provides three DS3 interfaces with 1:1 or 1:N redundancy. There are
2,016 DS0s per Super Slot card.
The SCSI connector on each card provides three digital connectors that function as a send and
receive pair for each of the three DS3 links.
The first (top) SCSI connector on each DS3 Super Slot card carries the three (3) DS3s circuits
supported by that card.

The second (bottom) connector on each DS3 Super Slot card carries redundant traffic to the
mid-plane to be forwarded to the redundant card (during failed card scenarios).
DS3 cables connect from the digital connectors to the customers digital cross-connect by way of
a GENBAND provided BNC patch panel (see DS3 interface cables graphic on the next page).

117

DS3 Protection
The 1:1 protection scheme is provided using a Y-cable that interconnects up to three DS3
facilities on each of two DS3 Super slot cards. Up to six 1:1 protection groups can be configured.
Protection switching can be configured as revertive or nonrevertive. There is a provisionable
Restore Time.
The 1:N protection is provided by two DS3 redundancy busses in the midplane. Bus 1 - slots 1520 with slot 15 housing the protection card Bus 2 - slots 23-28 with slot 23 housing the
protection card
Protection is revertive only in a 1:N protection scheme with a provisionable Restore Time
period.
Two SCSI connectors on each Super slot card Primary connector carries the three DS3 circuits
supported by that card. The second connector carries redundant traffic to the mid-plane to be
forwarded to the redundant card.

118

DS3 Normal Condition

1:N Protection Group
The 1:N protection is provided by two DS3 redundancy busses in the midplane.
Bus 1 - slots 15-20 with slot 15 housing the protection card
Bus 2 - slots 23-28 with slot 23 housing the protection card
Protection is revertive only in a 1:N protection scheme with a provisionable Restore Time
period.
1:1 Protection Group
The 1:1 protection scheme is provided using a Y-cable that interconnects up to three DS3
facilities on each of two DS3 Super slot cards.
Up to six 1:1 protection groups can be configured.
Protection switching can be configured as revertive or nonrevertive. There is a provisionable
Restore Time.

119

DS3 Failed Super Slot Card

1:N Protection Group Failed Super Slot Card
The illustration shows the path for a 1:N protection if a failure occurred on a Super Slot Card in
slot 18.
Bus 1 - slots 15-20 with slot 15 housing the protection card
The Redundant connector would carry traffic to the adjacent cabled port, the Mid-Plane
would carry traffic to the newly Active Super Slot card.
1:1 Protection Group Failed Super Slot Card
The illustration shows the path for a 1:1 protection scheme is provided using a Y-cable that
interconnects up to three DS3 facilities on each of two DS3 Super slot cards.
The Redundant connector would carry traffic to the adjacent cabled port, which is the newly
active Super Slot card.

120

Quad OC3/STM1 Card

The Quad OC3/STM1 card has four channelized OC3/STM1 ports on a single board. The Quad
card can be installed in slots 15-20 and 23-28 on the rear G9 Gateway Chassis.
The connectors are Small-Form Pluggable (SFP) optical connectors.
The OC3 optical ports for the fiber optic cabling are 1300 nm LC duplex intermediate reach (IR)
receptacles. The single mode fiber cable must have LC connectors to plug into the OC3 CI Quad
card.
Configured as a OC3 each port supports 84 DS1s (84 * 24 = 2016 DS0s)
Up to 8,064 DS0s (2016 * 4 = 8064) are supported per Quad OC3 card

Configured as a STM1 each port supports 63 E1s (63 * 31 = 1953 DS0s)

Up to 7,812 DS0s (1953 * 4 = 7812) are supported per Quad STM1 card

Quad OC3/STM1 Protection

Quad OC-3/STM-1 cards are 1+1 protected meaning that each network interface port (facility) on
the card is protected by a redundant port on a separate card. Switch time is 50ms
In case of a failure to one port, the failed port is switched over to its associated protecting
port (on another card).
If the Quad OC-3/STM-1 card itself fails, all active ports on the card switch over to their
respective protecting ports.
This protection scheme provides both equipment and facility protection.
The cards support unidirectional and bidirectional switching modes as well as revertive and nonrevertive switching.
121
With revertive switching, a configurable Wait-To-Restore (WTR) period is used.

Quad OC3/STM1 Protection

Quad OC-3/STM-1 cards are 1+1 protected meaning that each network interface port (facility) on the
card is protected by a redundant port on a separate card. Switch time is 50ms
In case of a failure to one port, the failed port is switched over to its associated protecting port (on
another card).
If the Quad OC-3/STM-1 card itself fails, all active ports on the card switch over to their respective
protecting ports.

This protection scheme provides both equipment and facility protection.

The cards support unidirectional and bidirectional switching modes as well as revertive and non-revertive
switching. With revertive switching, a configurable Wait-To-Restore (WTR) period is used.
Unidirectional vs bidirectional
In a unidirectional operation mode, the device that detects a failure on a working channel no. 1 requests
to the remote equipment to drive the signal that specific working channel data to the protection line.
Once this request is acknowledged, Equipment E now starts to listen to the protection channel but still
drives its signal on to the working channel. This configuration option makes the actual bidirectional
voice/data path to be split into two different fibers.
When configured for bidirectional switch-over, the APS protocol will make sure that both direction of the
failed working channel is switched to the protection fiber pair.
Revertive vs non-revertive
Revertive specifies if the traffic is automatically switched back to its original channel once the failure is
cleared.
Non-revertive mode, the traffic will remain on the protection fiber until manually switched back or until a
failure is detected on the protection fiber

122

Packet Interface (PI) Cards

There are two types of Packet Interface (PI) cards that can be installed on the G9 Gateway
Chassis.
ATM Interface (AI)
Gigabit Ethernet Interface (GEI)
The ATM Interface (AI) card provides the capability to interconnect the G9 with external ATM
networks via OC3c/STM1c and/or OC12c/STM4c interfaces.
The Gigabit Ethernet Interface (GEI) card provides the capability to interconnect the G9 with
external IP networks.
Packet Interface cards can occupy four (4) slots on the rear of the G9 Gateway Chassis, slots
19, 20, 23 and 24.

123

Gigabit Ethernet Interface (GEI-2e) Card

The GEI-2e card provides the capability to interconnect the G9 Gateway with external IP
networks by means of up to two Gigabit Ethernet (GbE) interfaces.
Cards are installed in slots 19& 24 and 20 & 23. There is a maximum of four GEI cards that can be
installed with two GbE ports per card.
One of two port/connector types, copper and optical, provide the interface to the GEI card.
There are also three external Snoop/AUX/Console ports (copper only).

The on-board CPU on the card performs forwarding table management and local OAM&P
functions
While two network processors (NPUs) on the card serve as forwarding engines, supporting a persession firewall for VoIP calls.
The GEI-2e includes two GbE layer 2 switches, one for switching bearer plane packets and the
other for switching control plane packets
GEI-2e Card protection
The GEI-2e card supports load-sharing redundancy as all GEI cards can carry traffic, up to 3
remaining GEI cards to carry all traffic when one GEI card fails. The GEI card also supports 1:1
active/standby redundancy.

When used as load-sharing redundancy, the GEI cards can be inserted in slots 19, 20, 23 and
24. Currently up to 4 GEI cards per shelf, with up to 6 Gbps worth of working traffic per G9
shelf survivable from any single GEI card failure.
When used with pairs of 1:1 active/standby redundancy, the slots 19/24 and 20/23 are
paired. Currently up to 2 pairs of GEI cards per shelf, with up to 4 Gbps worth of working
traffic per G9 shelf survivable from any single GEI card failure or any single GbE link failure.
124

Check Your Knowledge

1. Voice Server Cards cards can be installed in slots 15 - 20 and 23 - 28.
a) True
b) False

2. The GEI-2e card has

a) 2 Gb Ethernet traffic ports
b) 4 Gb Ethernet traffic ports + 1 console port
c) 2 Gb Ethernet traffic ports + 1 Aux port +1 Snoop port + 1 Console Port

d) 2 Gb Ethernet traffic ports + 1 Console Port

3. Quad OC3/STM1 protection is

a) 1:1 (Active / Standby cards)
b) 1+1 (Active / Standby cards)
c) 1:1 (Active / Standby ports)
d) 1+1 (Active / Standby ports)

125

126

127

128

129

130

131

132

133

GenView EMS Architecture

The GenView EMS architecture is comprised of the following items:
Two EMS Server and two CLI Server processes running on a pair of redundant IA-RMS.
A set of EMS Graphical User Interface (GUI) client applications running on Windows or
UNIX-based workstations
A set of Command Line Interface (CLI) clients.
The two EMS Server processes run as an active/standby pair on separate hardware platforms
with the standby EMS Server maintained in a warm state through database updates and
transaction checkpoints sent from the active server. The active EMS Server process
communicates with the managed media gateway (MG) nodes.
A single EMS Server can manage up to 63 G9 Gateway nodes, which can be either co-located
with or remote from the EMS platforms. The EMS Server provides a notification service which
handles the dispatching of events and alarms to registered GUI and CLI client applications.
The GenView EMS architecture supports four external interfaces (see figure):
GenView EMS GUI Client - provides complete operational management of the G9
Gateway
CLI Client/Server - provides complete configuration management functionality
TFTP - provides file transfer services for performance measurement data
134 SNMP - provides northbound traps

Launching GenView EMS Client

The operator accesses GenView EMS through a Java-based graphical user interface
(GUI)running on a separate workstation, or via a command-line interface (CLI) on the
GenView EMS server.
The GUI accesses the same database as the CLI, ensuring that there are no synchronization
issues when data is changed through one interface or the other in real time.
The Java-based GUI client runs on both Window and Unix operating systems and will allow
multiple users to access the switch at the same time. A maximum of 100 simultaneous clients
are supported, with up to 20 clients on a single workstation.
To launch the GenView EMS GUI from your laptop:
Install Client software on your PC using the Load Windows EMS Client link located in the
documentation suite.

Locate the GenView EMS client in your program file.

Click on the GenView EMS icon to open.

NOTE: The client ensures that its software version matches the version of server's software;
if the client is out-of-date, it can pull a new client executable from the server and restart
itself immediately.
135

The GUI client connects to the C3s IP address, allowing access to the active OA&M
processor.
An operator may run multiple copies of the GUI client on a single workstation to manage
multiple systems.
The GUI allow access to all elements of OA&M (FCAPS) for both TDM and packet telephony
capabilities of the switch (the C3).
To Specify Switch:
To add a new switch to the list click the Update List... button to add or modify list of
available switches.
Select a switch (a C3 G9 EMS server) using the drop down menu.
Click the Try.. button.
Logging In
After specifying the switch you a dialogue box requests login information to log into that
switch.
An operator may run multiple copies of the GUI client on a single workstation to manage
multiple systems.
Each login is part of the 100 logins available for simultaneous clients.

136

Up to 1,000 clients can be loaded with no license requirements.

GENVIEW EMS GUI Functional Areas

Alarm Bar (aka: Dashboard)
Provides display of Performance Overview, Active Alarms and Subsystem Alarm panel.
Tool Bar
The Tool Bar allows immediate FCAPS transition between the Faults, Configuration,
Accounts, Performance, Security and Report Tools management functions
Navigation Area
Displays configuration management navigation tree
Workspace
The workspace provides data fields to provision resources and monitor system information.
Configuration and provisioning tasks are performed in the workspace.
Function Buttons
Function buttons provide GenView workspace functionality, such as adding and deleting
resources and navigation.
Status Bar
Provides a visual indication of connectivity to an active system.
Shows System Date/Time
Shows parameter definitions when certain parameters are rolled over with a mouse.137

GenView EMS Navigation

The Navigation Tree is the structured list of resource objects displayed in the Navigation Area
for management functions. The Navigation Tree is used to locate system information about a
resource by expanding nodes in the tree until the desired resource is visible.
When the user clicks the Configuration button, the navigation area displays a tiered tree with
the System node and its immediate subnodes: Nodes, Office Parameters and System
Parameters.
Blue radio buttons imply that there are underlying nodes or details.
Gray radio buttons signify that you are at the bottom level of the file tree or that no
datafill has been create at that level.
Green buttons indicate the current selected tree path.
Expanding the nodes of the Top-Level Navigation Tree exposes the sub-nodes contained
within them. Pictured are the numerous subnodes comprising a G9 CMG node object.

138

Equipment Status
Hardware and software in the G9 is hierarchical, meaning there may be slots, channels, facilities, ports, etc..
dependent on the status of the entity above them.
When selecting a particular component or node the General tab is opened by default. For most components
this will give an overview of the operational status (Unlocked / Locked or Enabled / disabled)
Administrative State - determines if traffic can pass or not

Shutting Down - Fault exist or Shutting Down manually selected

Idle channels placed out of service (Locked)

Existing calls allowed to complete before being locked.

Locked - Administrator disabled (drops all calls and puts circuit(s) OOS)

Unlocked - Puts circuit(s) back into service and able to carry traffic

Operating State - hardware status; can carry traffic provided it has been unlocked.

Unknown - Software and hardware are not committed

Disabled - Fault exist

Enabled - Ready to carry traffic

Channel Status

In-Service - Channels are in-service and ready to carry traffic

OOS Channels currently in an out-of-service state

Active Channels - Calls currently in process

139

Browser
The Browser (Query) function provides the following:
Query capabilities based on resource attributes and values
Initiated from the navigation tree on various leaf nodes
Used when number of resources to be accessed is potentially very large (i.e. subscribers,
circuits, translations, etc..)
Table display of the query results with overall and individual row views.

140

Configuration Management
The Configuration Manager offers a Java-based graphics that has an intuitive and easy to use interface
that allows complete provisioning for all system and subsystems parameters.
NOTE: Metadata and XML rules-based behavior provides context-sensitive display, operation and
data entry.
Fields are specific to the area in which you have chosen.
System notifications inform user of underlying resource changes.
Function Keys
The GenView EMS architecture is designed with a multitude of Functional keys to assist the user in
various operations.
The function keys will vary based upon which folder, which level as well as what options are valid.
The user will be presented different keys for each of the various levels within display, creation,
deletion and modification operations.
Add Key
The Add key allows the user to add a new entry of the current selected type.
Each Tab may require the user to enter information into text fields (as shown above) or make
selections from drop down lists.
Users can switch between tabs as needed as sequential progression through the tabs is not required.
Add Function
GenView EMS also supports the ability for the user to implement commands by selecting an item in
the navigational tree then depressing the right mouse button.
The supported commands will vary based upon a number of criteria such as command, mode,
141
operation, provisioning type, as well as support for a given protocol that is being managed.

Datafill Types
The following convention is used to indicate the type of input expected for provisioning
procedures:

Input - field requires a value to be typed in using the keyboard (these fields have a white
background on the screen).
Pull-down list - system provides a list of valid values that can be selected by clicking on
the down-arrow.
Checkbox - used for choices with only two possible values (e.g. on/off);
There are 4 datafill types for data entry:
Non-modifiable - data set at creation time and is not modifiable.
Dependent Modifiable - modifiable however, cannot be modified in an Administrative
State of In-Service.
Selectable - data selectable either by system supported options or prerequisite datafill.
Modifiable - data input pertaining to system values or operations.

142

Discard Changes
GenView EMS will inform the user, via a pop-up, if the user selects a new object in the
navigation item or selects cancel when changes have been made and have not been commit
to the active database.

143

Delete Key
The Delete key allows the user to delete an entry of the current selected type in the
navigational tree.

Delete Function
The user can initiate a delete operation of the item selected in the navigation tree by
depressing the right mouse button and then selecting the delete

144

Print Key
The Print key allows the user to print the details of the current selected item or save the
print as an HTML file.

Print Preview Details

The print will be formatted into sections with the details for each section following the
section heading

145

Span - Configure Key

The Configure key allows the user to define the provisioning for a previously Unassigned
span facility. Pressing the configure button will start the wizard that will step through the
configuration options (an example is covered in the subsequent pages).

146

147

148

Check your knowledge

1. The GenView EMS supports _________ simultaneous clients of which ________ can logon from a single workstation.
2. Utilizing the Tools dropdown menu on the GenView EMS Main Screen, the
______________________________________ selection allows the user to initiate an
update request to all sub-systems for posted alarm messages?
3. All G9s must be configured on the GENView Client so that it will appear in the pull
down menu to select switch.
a) True
b) False

4. When selecting a particular component or node the General tab will give an overview
of the operational status.
a) True
b) False

5. The Configure key allows

a) The user to define only the T1 span facility. OC3 Spans need to be defined using the assign
key.
b) The user to define the provisioning for a previously Unassigned span facility.
c) The user to define the provisioning for a previously Assigned span facility.
d) The user to define only the OC3/STM1 spans facility. T1/E1 Spans need to be defined using
the assign key..

149

150

151

152

G9 Diagnostics
The G9 provides a number of on board diagnostic and testing capabilities to ensure the
system operates at the highest-level availability. There are 3 categories of diagnostic
capabilities that perform a particular role in the operation and maintenance of the G9:
Power on Self Test (POST) - Can be done manually and is also performed each time a card
is powered up or inserted. It determines the operational readiness of that card and does
not affect the overall operation of the system.
Online Exerciser Routines - This category of diagnostics are designed to continually
validate the integrity of the system and its components. The diagnostics are not intrusive
to the operation of the G9. These tests ensure that all memory, busses, disks and other
system resources are functional and ready for use if application software require it.
Online Diagnostics - Online diagnostics cover in-service and out-of service components.
Diagnostics on in-service components do not affect the overall operation of the
component. Out-of-service diagnostics can be run on live systems, but the tested
component is off-line (locked).

153

Background Diagnostics - Bearer Path Tests

The system constantly performs background diagnostics including:
TDM highway loopback (single DS0 per highway)
Ethernet connection test to each server card from PAC
TDM connection test in SST (per DS0 cross connect)
TDM and ATM clock distribution monitoring
DSP sanity and/or function test
Failed Tests result in the generation of specific Events/Alarms Non-modifiable information.

154

Manual Tests - Bearer Path Tests

In addition to these background test's the user has access to various manual tests and
diagnostic results. Some examples are:

On-Demand Tone Generation

On-Demand Outpulsing Test
On-Demand Signaling Test and Remote Make Busy
The milliwatt test is a signal generated from an end office which provides a 1004 Hz tone at 0
dBm for one-way transmission measurements towards the customer's location from the
Access Service Provider end office.
The COT test for SS7 trunks can also be conducted. A COT (Continuity Test) is a loop test that
ensures a bearer path is working correctly and is required by SS7 networks before a path is
established. A COT test can be executed during call setup or performed during a system
maintenance window. The circuit can be in a locked or unlocked state when the COT test is
run. The system retests the circuit until it passes. The system runs a loop test to ensure the
bearer path is working correctly.

155

G9 Node General Information

Administrative State (right click on Node; select Admin State):
Shutting Down - Fault exists or selected manually (takes device to a Locked state but
existing calls are allowed to complete)
Locked - Administrator disabled (all calls are dropped immediately)

Unlocked - Ready to carry traffic

Operating State:
Disable - Fault exists, entity has been Locked/Shutdown manually.
Enabled - Ready to carry traffic (Card powered up, passed diagnostics, loaded its
software and passed software diagnostics).
Active Channels (Calls) - Calls currently in process.
In-Service Channels - Capable of carrying traffic.
OOS (Out-of-Service) Channels - Channels not capable of carrying traffic.
156

G9 Admin State
An entity larger than a DS1 bandwidth cannot be locked by the user if there are active
channels in use. The user will show the Locked command greyed out.

You must initiate the Shutting Down action. This will initiate action to lock channels as
they become inactive.

157

G9 Node Properties
The Node Properties tab provides various Node specific information. Not all entities are
provisional data fields.

Network Time Synchronization - NTS Server 1 and 2 IP addresses

Serial #s Mid-plane SN or MAC Address numbers.
These come from chips on the backplane - DO NOT CHANGE!

SST Span Type - Specifies the span type on the SST cards in this Node
PCM Encoding - Either MuLaw (T1) or ALaw (E1)
Echo Cancellation - Specifies if fax/modem tone detection is to be reported for calls on
this Node.
Diagnostics - Enable/Disable Highway Monitoring on VS card and Audit/Validation of the
Standby PAC card.
DSP Configuration - Mode to be used by the MG - Normal or R2 (used in Indonesia and
Brazil).

158

G9 Clock
The Primary and Secondary reference source can be set to either;
EXT-1 (Primary)/EXT-2 (Secondary) - This reference source is derived from a BITS clock
(network synchronization timing source (GPS) - could be a Stratum 1 clocking source.
If you select EXT-1 and EXT-2 you must indicate either Twist or Coax as the termination mode
(See Figure below).

ATM Interface - SONET input

CI Interface - any source that gets broken down to a T1 level. An exception to this is the
DS3. When the DS3 is unchannelized or unframed, it cannot be used as a timing source.

159

G9 Clock Switchover
The settings on this screen are for used for maintenance and/or service of the SST card. If the
user needs to switch the clock reference, the Timing Reference Switch - Active SST Card or
Standby SST Card command is initiated.

160

BITS Span Properties

Displays the provisioning for the EXT BITS to the primary or secondary clock reference source.
When the BITS Line Type is T1, the user must set the provisioning information to synch to the
incoming signal.

161

Call and Management over Ethernet

IP provisioning for call control and network management over Ethernet for communications
between the MGC and the packet and control (PAC) modules in slots 7 and 8. The IP over
Ethernet tab provides PAC Ethernet-related information.
A G9 could be run by call processing from a variety of server pairs.

162

MGC Synch Status

The MGC Synch tab indicates the general health of the PAC cards. The information provided
indicates if each PAC is ready. This tab will also show if the MGC has tried to sync with the
PAC and if it was successful.
When the PAC card is seated in the shelf, it goes through a verification and diagnostics
(power-up, hardware diagnostics, software version upload and synchronization).
There is a basic checksum that occurs during diagnostics. Once this process is completed
successfully, the database has to be sent to the PAC card - 500 ms on and off flashing Yellow
Status LED.

163

G9 Nodes Thresholds
The Threshold tab provides threshold settings to turn on and off SNMP traps for alarm and
event reporting. The settings in the above example set the threshold for CPU and memory
usage (HIGH) at 90%. It is set at 80% (Low) for clearing the alarm condition.
The Interval setting specifies the number of seconds over which to compute the average CPU
and memory utilization. In the above example the setting is 15 seconds. So every 15 seconds
the system will check the CPU and Memory usage to see if an alarm should be generated or
cleared.

164

Essential Line Service Protections

The Essential Line Service Protection tab and G9 overload control feature is used to handle
the overload situations where G9 key resources reach pre-defined high thresholds for a
period of time. The key resources include CPU usages, message buffers, and allocation of key
data structures such as call blocks and timers.
Two call zones are defined:
the essential call zone and
the normal call zone.
When the key resources reach the high water mark for a period of time, the essential call
zone is entered. This is where new call originations are denied except for those lines
marked as essential lines. When the resources are below the low water mark, the normal
zone is entered.
Line load control is a manually operated function that allows the operator to reduce the load
of new call originations (from lines) on the switch. Each is assigned a number from 0 to 15.
MG also has a global load control value.
A line is only allowed to originate a call if its load control value is equal to or greater than the
global value.
For example, if the global value is 0, all lines can make calls. If the global value is 5, only
lines with load control value equal to or greater than 5 can make a call (lines with value 0
to 4 do not get dial tone, but they can receive calls).
A user can turn on the load control by setting the global load control value to a value
other than 0. The load control is turned off when the global load control value is set to165
0.

G9 Node Card Inventory

The Inventory tab is the final tab pertaining strictly to the G9 Gateway. From this tab you will
have visibility to provisioning states and status of shelf, cards, card types, protection, etc., all
on one screen.
By clicking on column headings you can sort information in that list.
Provisioning Type - provides information as it is user provisioned in the system database.
Actual Card Type - provides the information that is available when the system queries
shelf inventory of card slots.
Operating State:
Disabled - Fault exists
Enabled - Ready to carry traffic

Unknown - Unable to read the card

166

PAC Module Operations

When a card is in Active status, you can only perform a Switchover on that card to the
Standby card. In the above example, all other functions are greyed out under the Operations
function.

167

PAC Module Operations

A locked cards cannot bear traffic.
Only Reset and POST are available.

168

PAC Software Release

SW Upgrading Used by GENBAND to indicate that software is being upgraded on this card.
This should not be checked in a normal operating switch. If it is please call customer support
to check on sanity of the PAC cards.
The upgrade flag is turned ON to indicate to the PAC to not sync database from its mate
PAC card but get the new release database from MGC server.
Regen MG S/W Ctrl File - Regenerates the Software Control File on the flash drive of the
selected PAC Card with system software from the MGC.
Pre-download MG SW Ctrl File this function will download the SW Ctrl file from the MGC.
This is an optional task, the download will occur during a card reset.
Pre-download MG DB Ctrl File this function will download the DB Ctrl file from the MGC.
This is an optional task, the download will occur during a card reset.

169

G9 Card Protection Groups and Switchovers

Protection Groups
The G9 Gateway provides protection group functionality to support redundancy for G9 cards.
As cards are added to the G9, users assign them to protection groups.
All cards within a protection group have the attributes assigned to the group, including
redundancy scheme, protection direction and the length of time the system delays in
initiating a reversion switchover.
The G9 supports only one redundant card per protection group. The exception to this is the
N+1, Load-sharing protection scheme.
Protection group numbers are default. When the G9 is turned up, all group numbers are
created at that time.

170

G9 Protection Schemes
There are 4 types of protection schemes available for cards in the G9 Gateway.
1:1 - One active card is protected by a single hot standby card. If the active card fails for any
reason, the standby card immediately begins processing from the point of failure.
1:N - Several (N) active cards are protected by a single hot standby card. If any one of the N
active cards fail for any reason, the standby card immediately begins processing from the
point of failure.
1+1 - Two active cards share the processing load (load sharing) with either card being able
to handle the entire processing load if one of the cards should fail.
N+1 - Several (N+1) identical cards share the processing load (load sharing) with N of the
cards being able to handle the entire processing load if one of the cards should fail.

A load sharing unprotected mode is also supported

Revertive and Non-Revertive Protections
The system also supports revertive and non-revertive protection schemes for the individual
resources within a protection group.
Non-revertive - In the event of a failure, the system switches over to the standby card. When
the fault is resolved, the system does not revert to its original configuration. The card that had
the fault goes to standby. Non-revertive schemes are 1+1 and 1:1.
Revertive - In the event of a failure, the system switches over to the standby card. When the
fault is resolved, the system reverts to its original configuration. The card that had the fault
goes to active. The revertive scheme supported by the system is N:1. In the revertive
protection mode, switched traffic will stay on the protecting card or circuit for at least a
minimal period (called the Restore Time) before switching back. This prevents unnecessary
switchovers in case of an intermittent problem.
Uni-directional protection, With uni-directional switch over, only the local side equipment
performs the switchover.
Bi-directional protection, switchover takes place on both the local and remote equipment.

NOTE: Bi-directional and uni-directional refer to how local and remote equipment
co-ordinate with each other during a switchover

171

Protection Mode T1 Protection Group

The G9 system supports revertive and non-revertive protection schemes for the individual
resources within a protection group.

172

Protection Mode Inhibiting Protection Group

Enabling the Inhibit field will prevent switchover from occurring for this protection group.

173

Protection Group Inventory T1 Card

In the above example, the only T1 card currently in Protection Group 16 is the T1 card in slot
number 28. If there were more than one card equipped they would be listed here.

174

QUAD OC-3/STM-1 Protection Control

The QUAD OC-3/STM-1 protection group is done at the individual port level.
QUAD OC-3/STM-1 card has four (4) Optical ports,
Requires four (4) Protection Groups (one per port)

175

Card Slot Properties

The Properties Tab shows the redundancy configuration to include:
Group - The Protection Group number this card/circuit belongs to
Protecting - Checked on the redundant card
Inhibit Switchover - Specifies whether protection switching is inhibited for this card. If
this field is checked, then protection switching is inhibited (not allowed) for this card.
Standby Inhibit Switch - Specifies whether protecting card switchover is inhibited. If this
field is checked, then the protecting card is inhibited from (not allowed) switching over.
Group Inhibit Switchover - Specifies whether protection switching is inhibited for the
protection group. If this field is checked, then switching is inhibited (not allowed).
Group Type - The type of redundancy; used for this group such as 1 to N, 1 + 1, 1 to 1

176

Card Slot Operations

Listed a list of available operations that can be performed on a card. The list updates based
on the Admin State of the card, either Locked or Unlocked.

177

178

Check your knowledge

After completing this exercise, students will determine the redundancy features of the G9
Gateway, describe the steps involved in performing a switchover and replacement of various
card in the G9 Gateway.
1. What are the 3 categories of diagnostic testing on the G9?
a. __________________________________________
b. __________________________________________
c. __________________________________________

2. What Administrative and Operating state must a span be in to be ready to carry traffic?
a. Administrative State:______________________
b. Operating State: _________________________

3. When choosing EXT-1 and EXT-2 for the timing source on a G9 Gateway, the source is
derived from ___________________. This is most commonly a Stratum ________
clocking source. You must also select either ______________ or
_____________________ in the EMS GUI as the termination mode.

4. What 3 processes do all cards have to pass in order to be put in an Enable state?
a. ______________________________________
b. ______________________________________
c. ______________________________________

5. A CPU Low threshold of 80% will turn on an SNMP trap when CPU usage is at 80%
utilization.
a. True
b. False

6. What is the function of the Inhibit Switchover on the G9?

__________________________________________________________
__________________________________________________________

179

Check your knowledge

Protection Status PAC

Using the EMS GUI determine the Protecting and Protected PAC and their status for 1 Plano
Training G9.
7. Using the EMS, determine which PAC is Active and which is in the Standby mode.
PAC Slot 7_____________; PAC Slot 8 _____________
8. Describe the different ways in which the status and the protection can be verified using
the EMS.
a. _________________________________________________________

b. _________________________________________________________
c. _________________________________________________________

Media Gateway Protection Groups

Determine the redundancy protection groups for G9 cards
9. Select the Protection Group 19 (SST cards). What is its Protection Mode and
Protection Type? ________________________________________
10. Explain how this protection scheme works?
___________________________________________________________
11. What is the Protection Group number for the SI cards? _______________
12. What is the Protection Group for the PAC cards? ____________________
13. Explain how the PAC card protection groups works.
___________________________________________________________
14. Select the Quad OC3/STM1 card. What Protection Group does it belong to?
_________________________________
180

Check your knowledge

Protection Status -SST

15. Using the EMS, determine which SST card is the Protecting card and which
the Protected card. Slot 21 SST___________; Slot 22 SST__________
16. List the ways the status and the protection can be verified using the EMS.
a. __________________________________________________________
b. __________________________________________________________
c. __________________________________________________________

Protection Status - T1 Channelized Interface

17. 1. Using EMS, determine which T1 is Protecting and which T1 s are Protected. Give
slot number(s) _______________________________
18. 2. List how status and protection of the T1 Channelized Interface cards can be verified
using the EMS.
a. _______________________________________________________
b. _______________________________________________________
c. ______________________________________________________

G9 Protection Groups
19. Using the EMS GUI determine Protection Groups for various service types in a G9.
Which protection group is utilized for:
a. Quad OC3/STM1 cards? _____________________________
b. SST cards? _____________________________

20. 2. Describe two methods of inhibiting switchover or redundancy for a specific

protected card.
a. __________________________________________________________

b. __________________________________________________________

181

182

183

184

185

186

187

188

G9 Diagnostics and Test

The GENBAND G9 Converged Media Gateway provides various on board diagnostic and testing
capabilities to ensure the system operates at the highest level availability. Each of these
capabilities performs a particular role in the operation and maintenance of the G9 system. G9
Card Facilities and Channels
Diagnostics - Network and Facility
Alarms indicate failures and cause - All alarms are events but not all events are alarms. Some
events are for informational purposes only.
Periodic performance data shows trends
Performance Thresholds highlight facilities which need attention
On-demand information shows current status
Local/Far-end loopbacks and send-codes
There are 3 types of loopbacks available; Payload, line and inward loop. Send codes
determine what code is sent to the far end
On-demand BERT test for DS1
On-demand BERT testing allows technicians to test the health of a circuit immediately to
ensure quality service is maintained with each call.
Two DS1 test access ports allow for connection of test equipment
Termination of test calls
A bridge into established calls
Milliwatt and COT Tests
Trunk tests are designed to assist the user in debugging network and/or call processing
problems. Along with tone generation, signaling and outpulse tests, the user can run milliwatt
tone and continuity (COT) test, which can be performed at the trunk group and circuit levels.
When a trunk group is provisioned, the user can specify that the milliwatt and COT are run
automatically. At the trunk group level (CAS DAL, CAS Trunk, ISUP and PRI Call Processing
groups), the tests are based on the parameters specified for the group Available test include:
Per-call ISUP COT
On-demand test call: Milliwatt or ISUP COT
Automated Trunk Routine test: milliwatt or ISUP COT

189

Card Slot OC3 facilities

Up to 4 OC3 ports may be added to the Quad OC3/STM1 card.
With Facility selected the admin state of the port can be noted. Additionally the Card Status
field shows the number of:
In Service Channels
OOS (Out of Service) Channels

Active Channels
The section Status shows LOF and LOS alarms.

190

Optical carrier-3 (OC-3) TDM Channel breakdown

When using the American National Standards Institute (ANSI) to define the optical interface
component use a Synchronous Optical Networking (SONET) Optical Carrier. Optical Carrier 3 (OC3), which is an industry standard optical carrier, includes the electrically equivalent Synchronous
Transport Signal (STS).
The optical breakdown includes:
Optical The OC-3 port(s) on the QUAD OC-3/STM-1 card. Each port will be defined with a
Facility of 1, that will be broken down to the following Payload.
The Payload includes the following:
3 SONET Paths exist for each SONET port
7 VT Groups exist for each SONET Path under the port
4 SONET VTs exist for each VT Group
Each SONET VT has a DS1 presence.
Each DS1 consists of 24 DS0s (timeslots)

191

The OC3 Structure

192

Card Slot STM1 Port facilities

Up to 4 STM1 ports may be added to the Quad OC3/STM1 card.
With Facility selected the admin state of the port can be noted. Additionally the Card Status
field shows the number of:
In Service Channels
OOS (Out of Service) Channels

Active Channels
The section Status shows LOF and LOS alarms.

193

Synchronous Transport Module -1 (STM-1) Optical Carrier TDM Channel breakdown

When using the European Telecommunications Standardization Institute (ETSI) to define the
optical interface component use a Synchronous Transport Module -1 (STM-1) Optical Carrier.
Synchronous Digital Hierarchy (SDH), which is an industry standard optical carrier, includes the
electrically equivalent Virtual Containers (VC).
The optical breakdown may be one of two options. The diagram illustrates the AU3 breakdown
which includes

STM-1 The STM-1 port(s) on the QUAD OC-3/STM-1 card. Each port will be defined with a
Facility of 1, that will be broken down to the following Payload.

The Payload includes the following:

3 AU3 Paths exist for each STM-1 port
7 TUG2 Groups exist for each STM-1 Path under the port
3 TU12s exist for each TUG2 Group
Each TU12 has a E1 presents.
Each E1 consists of 31 DS0s (timeslots)

194

Synchronous Transport Module -1 (STM-1) Optical Carrier TDM Channel breakdown

When using the European Telecommunications Standardization Institute (ETSI) to define the
optical interface component use a Synchronous Transport Module -1 (STM-1) Optical Carrier.
Synchronous Digital Hierarchy (SDH), which is an industry standard optical carrier, includes the
electrically equivalent Virtual Containers (VC).
The optical breakdown may be one of two options. The diagram illustrates the AU4 breakdown
which includes

STM-1 The STM-1 port(s) on the QUAD OC-3/STM-1 card. Each port will be defined with a
Facility of 1, that will be broken down to the following Payload.

The Payload includes the following:

3 TUG3 Paths exist for each STM-1 port
7 TUG2 Groups exist for each STM-1 Path under the port
3 TU12s exist for each TUG2 Group
Each TU12 has a E1 presents.
Each E1 consists of 31 DS0s (timeslots)

195

The STM 1 Structure

196

Span Line Status

Use to view whether or not a span is in an Alarm State.
Recv. RAI Receiving Yellow/Remote Alarm Indication from the far end. Indicates that the
upstream facility has lost its signal (LOS) or framing (LOF) from this facility
Trans. RAI - Transmitting Yellow/Remote Alarm Indication
Recv. AIS Receiving Alarm Indication Signal (all ones, Blue Alarm). Indicates that the
upstream facility has lost its signal or framing from a facility further upstream. The
transmission and transmit path from this facility to the upstream facility is good
Trans. AIS Transmitting Alarm Indication Signal (all ones, Blue Alarm). Indicates that the
facility has lost its signal or framing on the upstream side and is transmitting an AIS alarm to
a downstream facility
Recv. LOF Loss of Frame. No framing from the upstream facility. An RAI is transmitted to
that upstream facility. If this facility is cross-connected internally to another Span, an AIS is
sent to that facility
Recv. LOS Loss of Signal. No signal from the upstream facility. An RAI is transmitted to that
upstream facility. If this facility is cross-connected internally to another Span, an AIS is sent
to that facility

197

Span Properties
The Properties tab for a Span allows the user to view the provisioning.
Send Codes provide a way of testing spans. On this screen the Send Code will indicate the type of
code that is sent across the DS1 to the far end.
Send AIS Sends a AIS (Alarm Indication Signal)
Send Yellow alarm Sends a RAI (Remote Alarm Indication)

Send No Code
Send In-band Line Code
Send In-band Reset Code
Send Idle Code
Send Out-band Line Code
Send Out-band Payload Line Code
Send Out-band Reset Code

198

Span Loopback

199

Span Inventory
The Inventory tab for a span provides identification and status information on the spans
channels.

200

Channel

Indicates the channel number within the span.

Admin State

Indicates the current Administrative State of the channel.

Oper

Indicates the current Operational State of the channel.

Group

Indicates the system trunk group number the channel is a member

of. Value of 0 indicates that the channel does not belong to a trunk
group.

Circuit

Specifies the Circuit ID for ordering trunks in the trunk group.

CIC Status

Specifies the current ISUP status of the CIC assigned to this channel.
(Ie. Transient, Unequipped, incoming Busy/Active etc.)

Span Admin State

When a shutdown is performed, all idle channels automatically go to locked, and any busy
channel goes to shutting down. When the call is completed, it will automatically lock. Once
associated channels go to locked the Span will automatically lock.

201

Channel Administration State

Provides the ability to Lock, Unlock or ShutDown all channels within a specific facility.

202

Span Operations
This screen in the GenView EMS GUI allows the user and/or technician to perform a BERT test on
a span.
BERT results can be viewed at Faults/Events Tab. The event will be identified as:
Severity of INF (Informational)
Category of APP (Application)

Code of 20992
Event Name TDM_BERT_RESULTS.

203

GenView EMS Trace Tools Call Trace

GenView EMS users can trace details on a per call basis using the Call Trace option in the Tools
menu item.
Call Trace provides details on type of call, sources, destination, route information and call
progress timestamp are retrievable by utilizing the Call Trace tool.
NOTE: Call Trace will not show where call is routed to.
An active call must be up to perform the Call Trace function. If no call is in progress, the trace
output on the screen will display no info available.
See next page for an example of an active Call Trace

204

Tools Traces Call Trace Output

Details on type of call, sources, destination, route information and call progress timestamp are
retrievable by utilizing the Call Trace tool.
NOTE: Call Trace will not show where call is routed to.
An active call must be up to perform the Call Trace function. If no call is in progress, the trace
output on the screen will display no info available.

205

Tools Traces Call Translation

Call Translation verifies provisioned information but does not require a call in progress.
The switch provides the translations trace tool which allows the operator to simulate a line or
trunk call and determine how the called number is processed through the translations and
routing tables, up to the point a route index is determined.
The Call Translation tool supports the concept of assembling a complex translations table for
verification prior to actually being assigned to users or trunks.

206

Test Access Ports and Voice Connections

Voice Connections provide the user access to a query wizard that allows the definition of a query
of either DS0 or DS1 cross-connections. Prior to configuring a voice connection, the user must
configure the source and destination circuits.
The SI card also contains a T1/E1 test access port. Two twisted pair cables (one per card) with a
three-conductor bantam jack on one end and bare wires on the far end are required to make this
connection. The cable end with the bantam jack is plugged into the T1/E1 test access port. The
unterminated cable end is terminated to either a DSX-1 panel or a terminal block (via wire wrap)
furnished by the customer.
Test Access can create a cross connection from the SI to a channelized interface for testing
purposes.

207

Voice Connections Functionality

The G9 system supports Voice Connections functionality, so the system administrator can
administer nailed or dedicated connections at both the DS1 and DS0 levels.
The voice connections functionality can also supports circuit testing functionality.
The G9 supports 2048 DS0 Voice Connection cross-connects

208

Managing Voice Connections

This is a list of DS1 voice connections queried from the Voice Connections - DS1 menu item.
Users can set the Admin State by right-clicking on the connection from the list.

NOTE:
The span must be Unassigned in order to terminate it to another device.
You can only Monitor spans that are assigned.

209

Voice Connection Details General/Connection Tab

General Tab enables the user to associate a name with the Voice Connection.
Connection Tab enables the user to define the Source point and the Destination Point of the
voice connection. The connection tab creates the cross-connection.

210

Adding a DS0 Voice Connection Step 1

Step 1) Select the DS0 component, then click the Add button

211

Adding a DS0 Voice Connection Step 2

Step 2) Enter the Provider name, User name and select the Connection Type.

212

Adding a DS0 Voice Connection Step 3

Step 3) Defines the Source and Destination points.
As soon as a slot is selected, the options available will change based on the type of card
occupying the selected slot. The following example shows the fields for an Source in Slot 22,
Card 1, Facility 1, Channel 4 being connected to the Test Access port:
Test Access
Card Port 1
Facility - 1
Channel 3 a DS0 within the Test Access DS1

213

214

Check your knowledge

1. Send Codes indicate the ______________________ that is
sent across the Span to the __________________.
2. What local Loopback types can be used when conducting a loopback test on a span?
1. ______________________
2. ______________________
3. ______________________

3. When a shutdown is performed, channels that are currently in service will go into a
_________________ ______________ state until the call is completed.
4. A Call Trace works when the circuit is busy only.
1. True
2. False

5. List three Trunk tests that can be performed to ensure validity of operations?
1. ______________________________________
2. ______________________________________
3. ______________________________________

215

216

217

218

219

220

1.

Emphasis the SBC is an extremely

powerful box of which only a small
amount of functionality is used in SDIN

221

222

223

224

SBC Configuration Interfaces

There are two methods for configuring your SBC software. One way is using the Command
Line Interface (CLI) and the other is using the Graphical User Interface (GUI) from the RSM
Console.

225

SBC DB Operation
We need to bear in mind the way the different Databases at the SBC and RSM are managed
depending on the tool used for configuration.
When the configuration is done directly on the SBC via the CLI, the corresponding command
is implemented and stored in the local Postgres database, and through is autosync operation,
copied to the redundant database. But no update is sent to the RSM and its own MySQL
database, so a difference is generated between these two entities.
When the command is generated via the RSM-Console, the information is stored in the
MySQL database and the command sent to the SBC, which in turn will apply it and save it to
its own database and redundant peer.
For the SBC configuration that is not at the global level, and for some administration tasks,
you can use the SBCs CLI commands. The CLI commands will update the database tables
and lets you configure many SBC objects including Endpoints, Realms, Signaling Vnets,
Routes and Calling Plans. It will not allow you to create or modify the Media configuration
from the CLI command line, that will need to be done using the RSM Console.
NOTE:
PostgreSQL is a powerful, open source object-relational database system. It runs on all major
operating systems, including Linux, UNIX, and Windows. It is fully ACID compliant, has full support for
foreign keys, joins, views, triggers, and stored procedures (in multiple languages).

226

SBC Configuration Interfaces CLI Command

To use CLI commands, you must secure shell (SSH) into the SBC as user root.
Note: If this is the first time you log into the SBC, shipped!! is the password for root.

227

CLI View
Type cli | more at the prompt to see a complete listing of all the cli commands that are
available.

228

RSM Console
As an alternative to using the command line, you can use a the RSM Console which is a
Graphical User Interface included with the RSM server software.
To Access the RSM Console:
From the RSM, click on the RSM Console Link.
When you click on the RSM Console Link, the system will download the RSM Console
application to your desktop.

229

SBC Configuration Interfaces RSM Console

230

RSM Console View

This view gives you access to different aspects of the SBC that can be configured or
monitored.
Behaves like a desktop where you will be able to have several windows open with different
information or configuration of the SBC in each one.

The Database window is where you create the SBC endpoints.

231

RSM Console vs. CLI

From within the RSM Console, click on Utilities to access the options available for configuring
the SBCs. The Database window is where you create the SBC endpoints.

232

233

234

235

236

SBC Networking

237

The Realm

238

SBC Network
The SBC Networking connectivity is established by configuring the following:
Signaling Vnets A Signaling Virtual Network (Vnet) is the combination of a physical
interface, a gateway IP Address (router), and an optional Virtual Local Area Network (VLAN)
ID. You have to define Signaling Vnets before you can configure other network connectivity
components.

SBC Limit 1024 Signaling Vnets (512 per interface)

Media Devices If routing media, you must define the media devices configured on your SBC.
Supported device types include the Network Processor Cord installed in your system (NSF-NP,
NSF-NP2 or NSF-NP2G) and transcoders.
Media Vnets A Media Vnet is the association of a physical interface for a media device with
a gateway IP Address (router) and an optional VLAN ID.

SBC Limit 1024 Media Vnets (512 per interface)

Media Resource and Media Service Pools A Media Resource Pool is one or more
associations of an IP Address, Netmask and UDP Port Range assigned to a Media Vnet. A
Media Service Pool is a group of one or more Media Resource Pools and is assigned to the
Realm.

239

240

Basic Configuration Realms

Realms A Realm (not synonymous with a SIP Realm) is a logical service entry point for other
devices to connect to the SBC. For calls to connect successfully, you must have at least one
realm configured on your system.
SBC Limit

- 1024 Realms (Q20 / S2000 servers)

- 256 Realms (Q10 / S1000 servers)

241

Relationship Between Signaling Vnets, Media Vnets, Realms and Pools

The above slide illustrates the relationships between Vnets, Realms and Service Pools within
the SBC. As shown, two Vnets have been defined, a Signaling Vnet and a Media Vnet. The
Signaling Vnet is used for basic networking and the Media Vnet is used to route the Media
(RTP Streams).

When you define a Realm, you assign it a Realm Signaling Address (RSA) and it is associated
with a Signaling Vnet which defines the physical port the signaling traffic will use. You also
assign a Specific Media Service Pool which is responsible for routing Media traffic. The Media
Routing Pool provides the configuration details required for routing media such as a Realm
Media Address (RMA), a range of Media Ports and Media Routes.
It is important to know that a Realm can only be associated with one Media Service Pool, but
you can have multiple Realms pointed to the same Media Service Pool.

242

243

244

Basic Signaling Configuration

To configure Signaling, you must associate both physical and logical signaling parameters with
a Realm. You will specify a Realm Signaling Address (RSA) as the logical address for the
Realm. You assign additional signaling parameters to a Realm when you assign it a Signaling
Vnet. When you create a Signaling Vnet, you select the specific physical interface (Ethernet
Port) on the SBC that you want to carry signaling traffic to and from a Realm. If you have
VLANs implemented in your network environment, you can also specify a VLAN ID that
identifies the part of your network you want to associate with the Realm. You also provide
the IP Address of the default gateway (router) that you want to direct signaling traffic to and
from the Realm.
Creating Signaling Vnets
You can create Signaling Vnets using CLI Commands or using the RSM Console. When you
create Signaling Vnets on the SBC, each must have a unique name as well as a unique
physical interface / VLAN ID combination. Once created, a Signaling Vnet name cannot be
changed. Valid VLAN IDs range from 2 3999.
Note: The values 0 and 1 should not be used!!

245

Signaling Vnet CLI Commands

Command

cli vnet add <vnetname>

ipver {4|6}

cli vnet edit <vnetname>

ifname <interface name>

cli vnet edit <vnetname>

vlanid <VLAN ID>
.

Creates and names a new signaling Vnet, and specifies the IP version for
the Vnet, where: <vnetname> is the name you want to assign to the new
Vnet.
The name cannot exceed 31 characters in length.
4 indicates IP version 4
6 indicates IP version 6
If you do not specify 6 (IPv6) for this parameter when you create the Vnet,
the default value is 4 (IPv4). The IP version type cannot be changed once
the Vnet is created.
Assigns a physical interface to the Vnet, where:
<vnetname> is the name of the Vnet that you want to edit.
<interface name> is the ethernet port you want to use with
this Vnet. Valid values include eth0 through eth5, but eth2 and
eth3 are recommended for use as signaling interfaces. The other
ports are generally reserved for other uses.
Optionally assigns a VLAN ID to the Vnet, where: <vnetname> is the name
of the Vnet that you want to edit.
<VLAN ID> is the integer VLAN ID for the portion of your network using this
Vnet. Valid values are 2-4094 and none, however values above 3999 are
reserved. If you do not specify this parameter the default value is none.

cli vnet edit <vnetname>

primary-gateway
<primary gateway IP>

Identifies the primary gateway router for this Vnet, where:

<vnetname> is the name of the Vnet that you want to edit.
<primary gateway IP> is the IPv4 or IPv6 address of the primary gateway
router through which S3 accesses the network.
If you do not specify a value for this parameter, the value 0.0.0.0 is
assigned by default for an IPv4 Vnet, or :: for an IPv6 Vnet.

cli vnet edit <vnetname>

gateway-monitoring
{active|none}

Optionally controls whether a VNET is monitoring the reachability of the

primary gateway and if configured, a secondary gateway, using ICMP echo
requests.
<vnetname> is the name of the Vnet that you want to edit.
active indicates that configured gateways are being monitored using ICMP
echo requests.
none indicates that gateway monitoring is disabled and primary-gateway is
used as the default gateway (default).

cli vnet edit <vnetname>

secondary-gateway
<secondary gateway IP>

246

Description

Optionally identifies a secondary gateway router for this Vnet, where:

<vnetname> is the name of the Vnet that you want to edit.
<secondary gateway IP> is the IPv4 or IPv6 address of the secondary
gateway router through which S3 accesses the network. If you do not
specify a value for this parameter, the value 0.0.0.0 is assigned by default
for an IPv4 Vnet, or :: for an IPv6 Vnet.
If gateway-monitoring is set to none, use of a secondary gateway is
disabled and primary-gateway is used as the default gateway. A secondary
gateway is optional and only supported when the primary gateway has
been configured. The secondary gateway IP address must be different
from the primary gateway IP address.

Command

cli vnet edit <vnetname>

ping-interval <ping
interval>

cli vnet edit <vnetname>

succ-ping-count
<successful ping count>

Description
Sets the frequency at which ICMP echo requests are generated to monitor
gateways.
<vnetname> is the name of the Vnet that you want to edit.
<ping interval> is the interval at which ICMP echo requests are generated.
Default is 500 msec
Range is 50 msec to 3 sec in multiples of 50 msec
Must be greater than the round trip time the gateway router.
If gateway-monitoring is set to none, this parameter is disabled.
Sets the number of successful consecutive ICMP echo requests required to
transition a gateway from unreachable status to reachable status, where:
<vnetname> is the name of the Vnet that you want to edit.
<successful ping count> is the number of successful consecutive ICMP echo
requests required.
Default is 5
Range is 1 to 10
If gateway-monitoring is set to none, this parameter is disabled.

cli vnet edit <vnetname>

failed-ping-count
<failed ping count>

Sets the number of unsuccessful consecutive ICMP echo requests required

to transition a gateway from reachable status to unreachable status,
where:
<vnetname> is the name of the Vnet that you want to edit.
<failed ping count> is the number of unsuccessful consecutive ICMP echo
requests required.
Default is 3
Range is 1 to 10
If gateway-monitoring is set to none, this parameter is disabled.

cli vnet edit <vnetname>

monitoring-trap
{enable|disable}

Controls whether SNMP traps will be generated for gateway reachability

status transitions.
<vnetname> is the name of the Vnet that you want to edit.
enable indicates SNMP traps will be generated (default)
disable indicates SNMP traps will not be generated
If gateway-monitoring is set to none, this parameter is disabled.

cli vnet edit <vnetname>

switch-to-standby
{enable|disable}

Controls whether an S3 switchover to the standby SBC node occurs if all

monitored gateways become unreachable.
<vnetname> is the name of the Vnet that you want to edit.
enable indicates S3 switchover occurs when all monitored gateways
become unreachable
disable indicates S3 switchover will not occur (default)
If gateway-monitoring is set to none, this parameter is disabled.

cli vnet edit <vnetname>

fwzone <firewall
zone name>

Optionally assigns a different firewall zone to the Vnet, where:

<vnetname> is the name of the Vnet that you want to edit.
<firewall zone name> is the name of an existing firewall zone.
The default firewall zone, def_sig_zone, is appropriate in most installations
and is assigned by default.

cli vnet list

cli vnet lkup <vnetname>

Lists the names and configured settings for all signaling Vnets
currently defined in your system.
Lists the specified vnet name only

cli vnet delete <vnetname>

Deletes the Vnet specified by <vnetname>

247

Editing Signaling Vnets CLI

Once the Vnet is created from the CLI command, you will need to edit it to assign the
interface you want your signaling traffic to use your gateway IP Address, Partition ID, and
VLAN ID. You can apply all changes in one line or you can modify each option one by one.

248

Editing Signaling Vnets CLI

In the above slide, we are editing the demo_vnet to use interface ethernet2, VLAN ID 37 and
the gateway IP Address is 97.65.224.1.
You will receive a message Please add this interface to the interface monitor list if it is not
already present. This message indicates that if the SBC administrator uses virtual links as a
trigger for switching High Availability (HA) activity, this one should be added.
The SBC has the ability to monitor specific interfaces. In the event the interface is down on
the Active SBC, the SBC will perform a switchover to the Standby SBC. This will be covered at
length in the High Availability lesson.

249

Virtual VLAN Interfaces

The SBC supports 802.1q VLAN trunking on signaling and media interfaces. This allows us to
trunk multiple networks (each in its own VLAN) over a single interface. This, depending on
the customer's Layer 2 configuration, could eliminate the need for separate Public and
Private interfaces. This is configured on a VNET level.

VLANs and IP Subnets provide independent Layer 2 and Layer 3 constructs that map to one
another and this correspondence is useful during the network design process. Multiple VNETs
which are created using the same Ethernet interface, have to have VLANs assigned to them
to provide a one-to-one relationship between the VLAN and the IP Subnet.

250

251

About Synchronization
Occasionally, the databases between the SBC and RSM can get out of sync. Among the
reasons that this can occur are:
A user executes CLI commands to add database entries to SBC
Data successfully added into SBC but failed when added into the RSM
Data successfully added into SBC but a network-related error occurred.
The Synchronization features in the RSM allows you to perform the following tasks:
Manually synchronize database data from the SBC (MSX) to the RSM (import) and from
the RSM to the SBC (MSX) (export)
Detect an out-of-sync condition between GenView-RSM and iServer databases
NOTE:
Database synchronization and auditing is limited by the size of the database. Access to the
synchronization process is restricted to system administrators. During synchronization,
affected partition users should temporarily suspend operation!!

252

Synchronization Differences Page

The Synchronization Differences page appears listing the differences that have been detected
between the SBC listed as MSX and the RSM databases that have not been synchronized.
Each entry lists the cluster id, table name, table key values, and the cause. If the cause is
unmatched, it means the entry is missing in one of the databases. If the cause is updated it
means the entry value has been updated in one of the databases. Clicking the entry allows
you to view entry-specific details for both databases.

253

Manual Synchronization
The manual synchronization process allows you to:
Synchronize database data from the SBC to the RSM (import), allowing you to
overwrite the RSM database data with SBCs database data.
Synchronize database data from the RSM to the SBC (export), allowing you to
overwrite SBCs PostGres database data with the RSM database data.
Select an action for each table shown to identify which database should serve as the
source for synchronizing the databases:
RSM to MSX - Copies from the RSM to the SBC
MSX to RSM - Copies from the SBC to the RSM / RSM Console
No action - Does not update the table

254

Manual Database Synchronization

A progress bar shows the progress of the operation during the manual synchronization
A "stop" button can be used to interrupt the operation
When the synchronization is finished, you will see a summary of what was completed.

255

256

257

RSM Console
You can also use the RSM Console to create signaling Vnets. To access the area where you
work with signaling Vnets, select Utilities Vnet from the Database View.

258

Creating Signaling Vnets - RSM Console

259

Creating Signaling Vnets- RSM Console

Choose a Partition. When the system is first created, you will have two choices, Global or
Admin. The default Partition is Admin. However, if you have created Partitions within the
RSM, they will appear in the dropdown box for you to select and use for your signaling Vnet.
Enter a Unique name you wish to use for the Vnet and select which interface you want your
signaling traffic to use. It is recommended to use Interface Ethernet 2 or Ethernet 3, but you
can also use Ethernet 4 or Ethernet 5 for the Signaling Vnet being created.

260

Creating Signaling Vnets- RSM Console

Choose a VLAN ID if you are using the same interface for multiple Vnets or you can keep the
default, none, checked. Enter the Gateway IP Address and choose the Firewall Zone Name.
There are four zones to pick from:
def_control_zone - designed for communication traffic between SBCs in high-availability
configurations
def_int_mgt_zone not applicable
def_mgmt_zone designed for communication traffic between the SBC and other
network entities such as the RSM or an SNMP manager
def_signaling_zone (default) designed for signaling traffic from SIP or H.323 endpoints

261

Viewing Signaling Vnets - RSM Console

262

263

264

265

266

267

268

1.

Emphasis the SBC is an extremely

powerful box of which only a small
amount of functionality is used in SDIN

269

270

Basic Media Configuration

Similar to signaling, you must associate both physical and logical media routing parameters
with a Realm in order to route media traffic. When you configure media routing you specify
information such as the physical interface on your media processor card that you want to
handle media traffic, the logical media address for the Realm known as the Realm Media
Address (RMA), and a range of UDP Port numbers that are valid for voice traffic. This
information is collected in a hierarchical set of objects and is known as a Media Resource
Pool.
A Media Service Pool is used for Routing the Resource Pool to the Media Hardware defined
(HK Device). A Realm can be assigned only one Media Service Pool. Therefore, if you want a
Realm to use the components of more than one Resource Pool, you must define multiple
Resource Pools to the Service Pool.
The subordinate objects within a Media Service Pool contain the configuration details for
your media networking. You associate this media configuration with a particular Realm when
you Assign it a Media Routing Pool.

271

Basic Media Configuration

Similar to signaling, you must associate both physical and logical media routing parameters
with a Realm in order to route media traffic. When you configure media routing you specify
information such as the physical interface on your media processor card that you want to
handle media traffic, the logical media address for the Realm known as the Realm Media
Address (RMA), and a range of UDP Port numbers that are valid for voice traffic. This
information is collected in a hierarchical set of objects and is known as a Media Resource
Pool.
A Media Service Pool is used for Routing the Resource Pool to the Media Hardware defined
(HK Device). A Realm can be assigned only one Media Service Pool. Therefore, if you want a
Realm to use the components of more than one Resource Pool, you must define multiple
Resource Pools to the Service Pool.
The subordinate objects within a Media Service Pool contain the configuration details for
your media networking. You associate this media configuration with a particular Realm when
you Assign it a Media Routing Pool.

272

Basic Media Configuration

273

FCE Tab
The basic media configuration options are all accessible from the FCE (Firewall Control Entity)
Tab of the iServer Configuration dialog within the RSM Console.
Steps in Basic Media Configuration
Add a Media Routing Device (Define Media Card)
Add a Media Vnet
Add Media Routes
Create a Media Resource Pool
Create a Media Routing Pool
Note:
When you configure Media, you are adding objects (devices, pools) to the mdevices.xml file
stored in the servercfg table. Adding new objects to the mdevices.xml file does not require a
restart to the iServer process; however, changing objects already in the mdevices.xml file
requires a restart of the iServer Process. You will see a message box notifying you when a
restart of the iServer Process is required. You must restart the iServer process from the
command line (by issuing iserver all stop / iserver all start) before the changes will be
effective. It is recommended to stop and restart the Standby SBC first and once it is back
online, stop and restart the Active SBC. This will ensure there is not a major outage in the
network. In-process H.323 calls and all incomplete call setups are dropped during a restart of
the iServer process!!
274

275

Preventing Rogue RTP Packets In Media Streams

Enable the Rogue RTP detect checkbox. Check this option to enable Rogue RTP detection on
the SBC to ensure that media traffic flows only for the duration of the call so that if additional
RTP packets are received prior to the call or after the call is terminated, those packets are
blocked.

RTP injection refers to attempts by malicious users to inject extraneous IP packets with the
intention of negatively impacting network service quality, to deny service, and to overload
network resources. To prevent rogue RTP packets in media streams, the SBC assures that only
media streams with authorized packet data are accepted and routed. To accomplish this, the
media processor card determines the Source IP Address from signaling information rather
than from media packets as they arrive and are filtered.
Note: When the source of the packets is behind a NAT device, the SBC cannot ensure that
RTP injection is prevented!

276

PCMM (Packet Cable Multi-Media)

The SBC supports IMS 3GPP and PacketCable Multimedia (PCMM) architecture-defined Rx
interface to external Policy Control and Charging Rules Function (PCRF) entities.
The SBC separates the signaling flow from the media stream in accordance with IMS 3GPP
specifications, giving service providers the flexibility to impose policy-based control on the
media stream independent of the signaling flow. The standards-defined Rx interface allows
for the exchange of flow-based information between the SBC and the PCRF. Service providers
using the SBC can now exercise this DIAMETER-based Rx interface to external policy servers
or PCRFs to control each sessions Quality of Service (QoS) and network resource allocation.
Check the Enable PCMM box to enable media authorization. The configuration specified with
this command applies to all calls that originate or terminate on the SBC. The default value,
disabled, does not send requests to the policy server for media authorization for calls. If
media authorization is enabled, authorization requests are sent to the policy server.
If the SBC receives no authentication from the policy server, the SBC drops the call. When
media authorization is set as best effort, the SBC also sends a request for authorization.
However unless it receives a response from the policy server that authentication is
specifically not allowed, the SBC still processes the call, thus performing a best effort
authentication.

277

278

Media Link Connectivity Checking & Bandwidth Control

The SBC provides additional media handling capabilities that let you closely monitor the
connectivity between the SBC and Media Gateways located in your network and allows you
to manage Media Bandwidth usage.
Media Link connectivity checking protects against possible media transmission failure in
situations when network connectivity is up, but a far-end media gateway is down. Although
network connection failures are often detected immediately, far-end failures may only be
detected after using a time-out mechanism.
The SBC uses ICMP Echo requests and responses to regularly monitor the status of individual
Media Links. This allows immediate detection of such far-end failures and prevents using the
impaired link for future calls.
Media Bandwidth Management lets you manage the media bandwidth usage within a set of
logically grouped entities by assigning bandwidth limits to those entities. Implementing
Media Bandwidth policies can be helpful in managing bandwidth usage agreements and
ensuring that the appropriate amount of bandwidth is available to end users.
These capabilities require configuration of additional media-related objects beyond those
necessary for basic media configuration. These objects, Media Links and Link Groups, are
additional components of the Media Resource Pool that provide the context needed for
checking connectivity and for configuring bandwidth limits.

279

Media Links & Link Groups

A Media Link is a logical concept that describes a path between the SBC and a remote
media device, specifically between a Realm Media Address (RMA) on the SBC and a
Media IP Address on the remote device. Bandwidth limits can be applied to a link.
From the SBCs perspective, its media address is local and is therefore referred to as
the Local RMA (LRMA). The media address of the remote media device is referred to
as the Remote RMA (RRMA).
Each link describes one LRMA/RRMA pair. During configuration, each Media Link is
associated with a set of Media Ports (a port allocation) within a Media Resource Pool.
From this relationship, a link inherits additional characteristics such as Media Vnet
parameters .
A Media Link Group consists of one or more media links. A Link Group provides the
means to define another level of bandwidth limits that apply to a group of links
collectively and can apply to the same media device. Each link group is associated with
a specific Media Resource Pool.
The following diagram illustrates the concept of Media Links and Link Groups in
relation to the SBC and a remote media device. As the figure depicts, the link
relationships between an RRMA and an LRMA can be arranged in a variety of ways as
required for a particular network.
The following characteristics of links and link groups that are illustrated in the figure:

RRMAs are typically

associated with a
particular media device.
Links are always part of
a link group, even if the
group contains only one
link.
An RRMA can reside in
only one link group.
A link group can contain
links to multiple LRMAs
from a single RRMA.

280

Media Link Connectivity Checking

When Media Link connectivity checking is enabled, at a configured interval, the SBC regularly
sends out ICMP echo requests on each media link to check its status. Each media link is
configured with an interval at which echo requests are sent out to the remote device as well
as a limit on the bandwidth available for echo requests and responses from the remote
device (to prevent flooding).
The SBC considers a link to be up if it receives a response to three consecutive requests. The
SBC considers a link to be down if the remote device fails to respond to three consecutive
requests. In the event that a link is down, the SBC generates an SNMP trap and does not
attempt to use that link to set up calls until the link connectivity is restored.
Media Bandwidth Management
When Media Bandwidth Management is enabled and the SBC receives an incoming INVITE
request, it calculates the amount of media bandwidth required to complete that call. When
the SBC makes this calculation, the final determination of how the call will be routed and
what codec will be used are not yet known.
Therefore, using the SDP information from the incoming INVITE, the SBC makes its calculation
taking into account the bandwidth requirements for all the different codec possibilities and
ensures that it calculates an amount that would accommodate the codec with the highest
bandwidth consumption. Then, for both legs of the call, the SBC checks the available
bandwidth on the eligible media links (within the media pools for the ingress and egress
endpoints) and reserves the necessary bandwidth before continuing to set up the call. If the
SBC determines there are no available links with sufficient bandwidth, it rejects the call
request with a 503 Service Unavailable response.
When the SBC performs its bandwidth reservation processing it ensures that there is
adequate bandwidth in both directions. However the reservation processing for the two call
legs differs somewhat. On the ingress leg of the call, the callers RRMA is already known at
the time that the bandwidth reservation is being made. Therefore the SBC can select the
available link that currently has the most bandwidth capacity among the links in the
appropriate link group (containing the callers RRMA).

On the egress leg, the SBC does not yet know which RRMA the called party will be using.
Therefore it examines all link groups in the pool associated with the egress endpoint and
identifies the link group with the most available bandwidth. Within that group, the link with
the most available bandwidth is identified and the SBC selects the LRMA associated with that
link. The SBC then reserves bandwidth on all the links that share the selected LRMA. Once
the SBC receives a response from the called party that identifies which RRMA will be used,
the SBC releases the reservations on the links that are no longer needed.

281

RTP Timeout (in Seconds) and RTCP Timeout (in Seconds)

Configure these times to instruct the SBC to regularly monitor the transmission of RTP and
RTCP media packets. When the SBC detects that a packet has not been sent within the
configured timer threshold, it terminates the call.
This allows the SBC to promptly reclaim the resources required for the call. A minimum
timeout value of 60 seconds is recommended for the timers.
Timers can also be set at the realm and endpoint level with the most specific settings taking
precedence. If you do not want to use the media inactivity detection timers you can use the
Disable check boxes to disable either one or both of the timers.

282

Adding Media Vnets

The Media Vnet is used for media traffic by allowing you to select the physical interface on
the media processor card you want to us for your media (RTP) traffic.
The interface choices are hk0,0, hk0,1, hk0,2 and hk03.
You will also have the opportunity to associate a VLAN ID with the interface.

283

Basic Media Configuration

You can only configure media objects using the RSM Console. Media configuration
information is not configurable using the Command Line Interface (CLI Commands).

284

Add Media Vnets

In the Vlanid field, specify a VLAN ID if you want to associate one with the Vnets or if you
have multiple Vnets using the same interface. The Vnet will associate traffic on the indicated
interface with the indicated VLAN ID. Note: that you can create multiple Vnets that have the
same physical interface, but each must have its own unique VLAN ID.

Valid VLAN IDs range from 2 to 3999 inclusive. The values 0 and 1 should not be used. If you
do not want to associate the Vnet with a particular VLAN ID, check none.

285

Adding Media Routes

In association with your Media Vnet, you must create one or more Media Routes to define
where to route media packets received over this Vnet. The Media Route must supply the IP
Address of a router or gateway within your network that knows how to reach some or all of
the destinations (IP Addresses) that could be specified. Depending on how your network is
configured, you may need to create more than one media route if you use more than one
router to reach different destinations in your network.

286

Add Media Routes

The Dest IP and Mask fields are used to define an IP Address and Subnet Mask representing
the range of destinations that the Router / Gateway can reach. Note: If you are specifying a
single default Gateway (Router) to use with all destinations, use 0.0.0.0 in the Dest IP Field
and in the Subnet Mask field. Then specify the IP Address of the Router in the Gateway Field.

287

Creating Media Resource Pools

Media Resource Pools are used for sending and receiving Media. In a Media Resource Pool,
you define the logical media interface to associate with the physical interface on the media
processor card that you specified with the Media Vnet. The logical parameters you must
specify include an IP Address and Subnet Mask, and a range of ports, which determine the
valid range of UDP Ports available for transmitting media.
You can have multiple Media Resource Pools using the same or different Vnets. If you use
the same Vnet, you can assign different Realm Media IP Addresses (RMA) for each Resource
Pool, or use the same RMA Address. However if you use the same RMA Address, the port
ranges must not overlap.
Starting in Release 6.0, you can define Link Groups to the Media Resource Pool and for each
Port Allocation, you can define the Media Link. Note: You must enable the Bandwidth
Management and Media Link Check fields to configure the Link Groups and Media Links.

288

To Create a Media Resource Pool:

1. From the middle pane of the FCE tab, select the Device [hk] device in the tree
diagram, right click and select Add pool.
2. In the ID Field, enter an ID number to assign to the pool. Valid ID range is 1 to
255. The Pool ID for each Media Resource Pool must be unique.
3. In the Name Field, enter a name descriptive of the pools purpose, like Private
Network, or Public Network. The Media Resource Pool will be listed with
the name you enter, prefixed by the pool ID.

289

Creating Media Resource Pools

4. From the Vnet Pull-Down, select the Media Vnet
you want to use with this Media Resource Pool.
The Vnet specifies the physical interface you
want to associate with the logical parameters
you are creating in this dialog box.
5. In the IP Address Field, enter the IP Address you
want to use for your Realm Media Address
(RMA). This binds the IP Address to the
selected Media Vnet Interface.
6. In the Mask Field, enter a Subnet Mask used for
the Resource Pool.
Generally, customers will only need one IP Address
per Pool / Realm. Multiple IP Addresses can be
bound together here by adding them under the
same Pool. This allows for a larger number of calls
per pool and load balancing (if the Media Resource
Pools from the previous steps use a different Vnet /
Interface).

290

Creating Media Resource Pools

7. In the Low Port and High Port fields. Create a port range between 11,000 and
65,535. In the Low Port field, enter the beginning port number for the range. In
the High Port field, enter the ending port number for the range. This defines the
range of port values that can be assigned for media transmission for a leg of a
call. It is important to ensure the port range is large enough that the number of
calls on the system could never exhaust the pool, keeping in mind calls could take
up as many as FOUR ports per call one RTP and one RTCP for each of the two
legs.

291

Creating Media Resource Pools

8. You can select DTMFGEN on systems that have DTMF Generation enabled.
9. Use the BW CAC group to specify media call admission control (CAC) bandwidth
limits for the resource pool.

In Maximum Bandwidth, enter an integer value that represents the

upper limit for bandwidth for call legs utilizing this media resource pool.
The range allowed is 0 to 1000000000 kilobytes per second (kbps). The
default value is 0 which disables media bandwidth CAC for this resource
pool.

In Maximum Emergency Bandwidth, enter an integer value that

represents the additional bandwidth to allow beyond the limit defined in
Maximum Bandwidth, only for calls to designated emergency numbers.
The range allowed is 0 to 1000000000 kilobytes per second (kbps). The
default value is 0. A Maximum Bandwidth limit must also be configured
for the emergency bandwidth limit to take effect.

10. Click Set when finished.

292

Creating Media Service Pools

The Media Service Pool is created for the hk device using the Media Resource Pools you
configured in the previous procedure. A Realm can be assigned only one Media Routing Pool.
1. Right click Media Service and click Add Pool to create a Media Service
Pool.

293

Add a New Pool

2. In the ID field, enter an ID number to assign to the pool, from 1 to 255. The Pool
ID for each Media Service Pool must be unique.
3. In the Name field, enter a descriptive name for the Service Pool

294

Add a New Pool (Continued)

4. From the Sub Dev Pull-Down menu, select the device you are using (hk).
5. From the Sub Pool Pull-Down menu, select the Media Resource Pool that
includes the physical and logical components you want to include in this Media
Service Pool.
6. Click Set.

295

Add a New Pool (Continued)

7. When finished, make sure to click OK at the bottom of the screen. If you do not
click OK, all of your changes will be lost if you click Close or Refresh.

296

Add a New Pool - Finished

For the media changes to take affect, you will have to restart the iServer process. It is
recommended to do this during low call traffic and it is also recommended to start with the
Standby SBC first. Once that is completely back online, restart the Active SBC. This will cause
the Standby SBC to become the Active SBC. Any H.323 calls and any SIP calls which have not
established call setup will drop.

297

Media Configuration File - mdevices.xml

Mdevices is an XML formatted configuration file stored in the PostGres Database with a copy
exported to the /usr/local/nextone/bin directory. The mdevices.xml file is the main
configuration file for media. It defines your Media Vnets, Resource Pools and Service pools
that will be used. It is executed / used during the iServer process.

Note: The formatting is incredibly important as a simple typo or incorrectly

placed whitespace will result in the system failing to start! Wherever possible
use the GUI to create and update this configuration!

298

Media Configuration File- mdevices.xml

To view the mdevices.xml file from the PostGres database, perform a nxconfig.pl M.
A file call new-mdevices.xml will be downloaded from the PostGres database to your
current directory. You can then do a more new-mdevices.xml to see the information
configured for your media.

299

Media Configuration File- mdevices.xml

If you have to modify the medevices.xml file, make sure to update the database with the
nxconfig.pl m command. The nxconfig.pl m command will import the mdevices.xml file
into the database. A restart of the iServer process is required for the media changes to take
place. However, it is not recommended to choose Y when prompted with the question Do
you want to restart the iServer [y/n].
What is recommended is:
Type N at the prompt
Stop and Start the iServer Process on the Standby SBC
Once the Standby SBC is back online, Stop and Start the iServer Process on the Active
SBC
This is a cleaner way to restart the processes and will not cause an outage.

300

301

302

303

304

Basic Realm Configuration

After creating the basic Signaling and Media objects, you complete your basic networking
configuration by creating Realms. When you create a Realm you configure it for Signaling and
Media Routing using the objects you previously created. Once it is configured, a Realm
provides the network connectivity required for sending calls to and from the associated
endpoints.
To have network connectivity, all endpoints must be assigned an SBC Realm. This is true
whether the endpoints are statically configured on the SBC or if they dynamically register
with the SBC.
To endpoints on the outside, a Realm appears as a unique signaling interface known as a
Realm Signaling Address (RSA). No other address on the SBC or in any other Realm defined
on the SBC is directly exposed for these endpoints.

305

Creating Realms
You can create Realms using either CLI commands or using the RSM console. We will focus
on the RSM console but you should be aware of the following precautions when performing
command-line operations involving Realms:
These commands should be executed only while the iServer Process is running

If the SBC database containing new Realms is put into service by executing the
command cli db create followed by cli db switch, the realms will not be plumbed until
the iServer Process is stopped and restarted.

306

Basic Realm Configuration

307

Field

308

Description

Partition

Name of the Partition being used

Enable Signaling

When checked, enables new call setups. If unchecked, calls in progress will
not drop but new call setups are prohibited

Realm Name

Name used to identify the Realm

SIP Authentication

Use the list to specify which SIP message types will trigger authentication.

SIP Blocked
Methods

Use the list to specify which SIP message types the SBC should block.

CID Block

The prefix digit sequence a caller on this Realm can send to prevent the
Caller ID data from being sent for that call

CID Unblock

The digit sequence a caller on this Realm can pre-pend to the dialed number to
send the Caller ID data for that call

Header Policy Profile

The SBC can be configured to Pass, Insert, or Manipulate SIP Headers according
to rules you define. These rules determine how the SBC handles specific SIP
headers or specific parameters within them based on the type of SIP message in
which they appear. You can combine sets of header rules into the header policy
profiles that are applied at different levels to influence the SBCs processing

Field

Description
This option is applicable for IP PBX endpoints and determines whether the SBC includes
service-route header fields in the REGISTER response it returns to this endpoint.

Service Route

Pass -indicates that you want the SBC to include a service-route header field if one
is already present in the REGISTER response sent by the registrar. Otherwise the
SBC should not insert one.
Disable - indicates that you do not want the SBC to forward a service-route header
field in REGISTER responses.
Enable - indicates that you want the SBC to include service-route header field
information in the REGISTER response. If one is not already present, the SBC adds
one, inserting an identifier for the SBCs Realm in the header (in the form of its RSA
or the Realms Fully Qualified Domain Name (FQDN

Strict Route
Check

Check whether the routes in the Route header included in incoming requests match
those in the service-route information that the SBC previously sent to that endpoint as
part of a REGISTER response. This check applies to messages originating from endpoints
that registered through the specified Realm and are now making a non-REGISTER
request (such as an INVITE). If the comparison of the two route sets reveals a
discrepancy, the SBC responds to the request with a 400 Bad Request message.

Handle SIP Path

Header on
Ingress

PBX endpoints and determines whether the SBC adds an identifier for the SBCs Realm
to the path header information (in the form of its RSA or Realm FQDN if the Realm is
configured with an FQDN) in the REGISTER responses it returns to this endpoint.
Disable - instructs the SBC to not add an identifier for the SBCs Realm to the path
header field in the REGISTER response.
Enable instructs the SBC to add an identifier for the SBCs Realm to the path
header field in the REGISTER response.

Default Server
Reg ID

Use this option to select an endpoint Registration ID to use as the default server. These
options are available only after you select IEdge Default Server for the previous option.

Default Server
Port

Use these options to select a User Port (uport) to use as the default server. These
options are available only after you select IEdge Default Server for the previous option.

Code Map File

Number

Three-digit integer , between 001 and 999, that identifies the code map file you want to
use when the iServer process initialized.

SIP Timer T1 (in

microseconds)

Used to determine when a client transaction retransmits requests. For unreliable

transports (such as UDP), the client transaction retransmits requests at an interval that
starts after T1 seconds and doubles after every retransmission. A value for the T1
timer can be configured at the endpoint, realm, and global level. The endpoint- and
realm-level configurations are not mandatory. If a value is configured at multiple levels,
the most specific level at which the configuration is set takes precedence. A value of 0
at either the endpoint or realm level indicates that the value should be inherited from
the level above. Default is 0.

SIP Invite Max

Retransmit
Count

RFC 3261 defines Timer B as the INVITE transaction timeout timer. The SBC derives a
value for Timer B using your configured value for Timer T1 and your configured value
for the maximum INVITE retransmission count. The retransmit count parameter
controls the number of times an INVITE is retransmitted before a call setup attempt is
abandoned. The Timer B value is derived using the formula: Timer B = Timer T1 * (2^
retransmit count) The value for the maximum INVITE retransmission count can be
configured at the endpoint, realm, and global level. The configured value at the most
specific level applicable takes precedence. The default value is 0. The range allowed is 0
309
to 10.

310

SCTP Section
The SBC supports Stream Control Transmission Protocol (SCTP), an IP Transport Protocol that
offers reliable data transfer and functions. SCTP supports multi-homing, a capability that
further ensures network resilience and reliability.
Multi-homing refers to the concept of configuring a network to use an alternative
transmission path in the event that the primary path is unavailable. To support using SCTPs
multi-homing capabilities, the SBC allows you to configure a secondary (alternative) Realm
and alternative IP Addresses on endpoints.
You can configure the realm to have up to 4 secondary realms. Together, a primary Realm and
its secondary Realms are considered a Realm-Set. Secondary realms provide an alternative
network configuration (Vnet, RSA, and subnet mask) that the SBC can use as an alternative
path for traffic in the event that the primary realm network path becomes unavailable. The
Realm is thus protected against network faults through the presence of these alternative
paths.

311

Field

Description

SCTP Status

The SBC supports the following three status values for the realm:
Single-homed
Multi-homed SCTP Secondary
Multi-homed SCTP Primary

Primary SCTP Realm

Name

The name of the Primary Realm within the Realm-Set. You cannot specify a Realm
as the Primary Realm for another Realm if it is already a Secondary Realm (has a
SCTP-Primary-Realm configured on it).

Secondary SCTP
Realm Names

The name of the Realm you want to specify as a Secondary Realm within a Realmset

SCTP Ordered
Delivery

If checked, enables the SBC to use SCTP ordered delivery mode. By default, this
field is disabled.

SCTP Fallback
Transport

312

Specifies whether the SBC should attempt to make a UDP connection if it is

unable to establish an SCTP association with a peer.

Field

Description

Realm Signaling
Address (RSA)

The IP Address that Endpoints will use to send Signaling traffic to the SBC

Subnet Mask

Subnet Mask for the RSA

Domain Names
(Comma
Separated)

You can configure the SBC to replace the RSA IP Address with a Fully
Qualified Domain Name (FQDN) . You can specify up to 8 domains in a
comma-separated list.

Dynamic EP
Domain

Allows you to specify a particular FQDN on a Realm to use when an

outgoing call involves a Dynamic Endpoint registered through that Realm.

Vnet Name

The name of the Signaling Vnet assigned to this Realm. The Vnet
identifies a physical interface (port) on the SBC, an optional VLAN ID and
a default gateway for traffic from the SBC.

313

Add Realm Signaling Tab Signaling Section

Field

314

Description

SIP Port 1
SIP Port 2
SIP Port 3

Specify up to three additional ports on which the SBC should listen for SIP
messages for this Realm. These ports are in addition to the globally
configured SIP port
Note: Endpoints that are dynamically registering through this realm can
send their REGISTER message to one of these alternative ports. The SBC
keeps track of which port an endpoint uses when it registers and uses
that same port for sending subsequent messages to that endpoint.

TLS Port 1
TLS Port 2
TLS Port 3

Specify up to three additional ports on which the SBC should listen for
Transport Layer Security (TLS) connection requests for this Realm. These
ports are in addition to the globally configured TLS port

TLS Certificate
Domain

Select a certificate domain to associate with this realm When you assign a
certificate domain to a realm, this associates the x.509 certificate file
specified by the certificate domain with the realm so that the SBC uses it
as its certificate file for connections that are made to or from the realm.
The list contains the names of certificate domains currently defined on
your system

Field

Description

TLS Client
Certificate

Select an option that determines to what extent the requesting endpoint (client)
must authenticate itself.
The choices in the list are:
NOT REQUESTED - the SBC does not request a client certificate.
REQUESTED NOT ENFORCED (default)- the SBC requests a certificate and, if one is
provided, the SBC will validate it before proceeding. However if one is not provided,
the SBC will still continue to establish the TLS connection.
REQUESTED ENFORCED - the SBC requests that clients provide a valid certificate and
the SBC will validate it before proceeding. If a valid certificate is not provided, the SBC
will drop the connection

TLS Fallback

Select an option to specify what action the SBC should take when it cannot establish a
TLS connection. You can specify that it should attempt to connect using an alternative
type of transport (UDP or TCP) or to not continue to attempt to connect (NONE). The
default value is NONE.

Store Inactive
Endpoints

Check this option to enable the SBC to store configuration data for dynamic
endpoints registered through this Realm that are no longer active

Enable Port
Mapping

Check to enable SIP Port Mapping on this Realm

Port Mapping
Range

Enter values to define the range from which the SBC allocates ports to
registering endpoints. You can specify multiple port ranges by providing a
sequence of lowport:highport values delimited by commas in ascending
order. Port ranges should not overlap; they do not have to be contiguous. If you do
not specify a port range, then the SBC uses the default range of
6000:65535.

Rate Limit Policy

Select the name of the Rate Limit Profile assigned to the Realm

OBP
Registration
Scaling Factor

Use this field in conjunction with the global (Cache Timeout) timeout value or an
IEdge group timeout value (if configured). It can be used to require registering
endpoints to send their re-registration messages to the SBC at a different frequency
from which the SBC forwards the REGISTERs on to the registrar server. This effectively
"throttles" the re-registration rate.
Endpoints register at the rate prescribed by this option, but the registrar
server only receives messages at the timeout interval defined by either an IEdge
group timeout (if applicable) or the global timeout setting. The default value is 900
seconds, the same as the global timeout default.

Min-Expires

Use this field to define the minimum Expires value that the SBC will accept from a
registering endpoint. If the Expires value an endpoint offers is less than the
configured minimum, the SBC will respond to the endpoint with a 423 (Interval Too
Brief) message. If a Realm-level Min-Expires value is also configured, the Realm value
takes precedence. The default value is 0 which indicates that no minimum value is
required.

315

Add Realm Signaling Tab IPSec Tunnel Mode Section

Field

316

Description

IP Sec Mode

Select an option to enable creation of a secure IPSec tunnel between the

specified realm and an external gateway device. You have these options:
Disable - disables the secure IPSec tunnel for this Realm
EnableGateway - This option is typically used in an interconnect
deployment. In this case, the other end of the IPSec tunnel is typically
an Application Level Firewall (ALF). In this type of deployment, packets
originate from the SBC and traverse through the IPSec tunnel to the
ALF
EnableSubnet -This option is typically used in an access deployment. In
this case, the other end of the IPSec tunnel is typically a secured subnet
behind a router. In this type of deployment, packets originate from the
SBC and traverse through the IPSec tunnel to the secured subnet
behind the router.

Encryption Type

Select one of the following encryption types from the list:

AES - Advanced Encryption Standard
3DES - Triple Data Encryption Algorithm Encryption

IKE Phase 1
Lifetime

Internet Key Exchange (IKE) - Before IPSec sends authenticated or

encrypted IP data, both the sender and receiver must agree on the
protocols, encryption algorithms and keys to use. IKE authenticates IPSec
peers and negotiates IKE SAs during this phase, setting up a secure
channel for negotiating IPSec SAs in Phase 2

Field

Description

Unit for Phase 1

Lifetime

Use Phase 1 Lifetime fields to specify a number and a unit of time

(minute, second, or hour) to define a lifetime for phase 1 of the IKE
process.

IKE Phase 2
Lifetime

IKE negotiates IPSec SA parameters and sets up matching IPSec SAs and
the peers

Unit for Phase 2

Lifetime

Use Phase 2 Lifetime fields to specify a number and a unit of time

(minute, second, or hour) to define a lifetime for phase 2 of the IKE
process.

Dead Peer
Detection

The DPD value (in seconds) functions as a timeout so when there is no

traffic from the gateway over the secure tunnel within the specified
interval, the tunnel is torn down.

Authentication
Algorithm

Select either the Secure Hash Algorithm (SHA)-1 or Method Digest

(MD)5 authentication algorithm for authenticating packet data.

Authentication
Method

Select either the Pre-Shared Key (PSK) or X.509 digital certificate

method for authentication between the SBC and the external gateway
device.
If you select the pre-shared key authentication method, both the SBC
and the gateway device must be configured with your pre-shared key
value. If you select the X.509 authentication method you must obtain
and install the required X.509 certificates on the SBC and the gateway
device.

Pre-Shared Key

If you are using the pre-shared key method of authentication you must
assign a matching pre-shared key to both the SBC and the endpoint. Use
these fields to type, and then re-type, the pre-shared key.

Confirm PreShared Key

You are asked to type the key twice to ensure that you have entered it
accurately. The pre-shared key length is limited to 255 characters. There
are no restrictions on character formats.

Gateway IP
Address

Specify the IP address, in dotted-decimal format, of the external

gateway device with which the realm will communicate over a secure
IPSec tunnel

317

Add Realm Signaling Tab Mirror Proxy Section

Field

Description

Registration ID

Select the registration ID for the endpoint for which you want the SBC to
behave as a mirror proxy. The list includes endpoints you previously
configured as SIP proxies.

Port

The port number on the proxy to which traffic originating in this realm will be
sent.

Public / Private

This is optional descriptive information for the Realm.

Add Realm Signaling Tab Dynamic BlackListing Section

Field

Allow Dynamic
BlackListing

Dynamic
BlackListing Policy

318

Description
Use this option to specify whether this endpoint should be subject to
dynamic blacklisting.
Inherit from System inherit the Dynamic Blacklisting Policy from the
System
Enable Enable Dynamic Blacklisting and select one of the Dynamic
Blacklisting Policies from the Dynamic BlackListing drop-down list
Disable Disable Dynamic BlackListing from the Realm

Allows you to select policies, previously created, to protect the Realm from
potentially malicious traffic.

Field

Description

Signaling Only

Checking this box disables media routing for this Realm,

Media Pool ID

The Media Service Pool which defines the Realm Media Address (RMA)
and Subnet Mask, port range, and the physical interface (media port) for
this Realm.

Between Realm
Media Routing

When the call is between different Realms, you can specify Dont Care,
Always On, Always Off, or On.

Within Realm
Media Routing

When the call is within the same Realm, you can specify Dont Care,
Always On, Always Off, or On.

Within Same NAT

Media Routing

When a call occurs between endpoints behind the same NAT device, you
can specify Dont Care, Always On, Always Off, or On.

319

Field

320

Description

Signaling Only

Checking this box disables media routing for this Realm,

Media Pool ID

The Media Service Pool which defines the Realm Media Address (RMA)
and Subnet Mask, port range, and the physical interface (media port) for
this Realm.

Between Realm
Media Routing

When the call is between different Realms, you can specify Dont Care,
Always On, Always Off, or On.

Within Realm
Media Routing

When the call is within the same Realm, you can specify Dont Care,
Always On, Always Off, or On.

Within Same NAT

Media Routing

When a call occurs between endpoints behind the same NAT device, you
can specify Dont Care, Always On, Always Off, or On.

Media Routing settings

Field

Description

Media
Authorization

If you have configured the SBC to connect to an external policy server

to coordinate resource allocation, select the type of authorization you
want to perform on calls from this Realm.
enforced - Select to have the SBC drop the call if it does not receive
authorization from the policy server that resources are available
best effort - Select to have the SBC attempt to process the call even
if it does not receive authorization from the policy server
disabled - (default) the SBC does not request authorization from the
policy server

Transcoding

Configures the dynamic transcoding mode to use for a realm. Choices

are:
Not_defined
Proactive
React (react and recover)

Codec Profile

Specifies the codec profile the endpoint uses.

321

Add Realm Media Tab Media Inactivity Detection Section

Field

322

Description

RTP Timeout

Configure these timers to instruct the SBC to regularly monitor the

transmission of RTP and RTCP media packets for this realm. When the SBC
detects that a packet has not been sent within the configured timer
threshold, it terminates the call. This allows the SBC to promptly reclaim
the resources required for the call.

RTCP Timeout

A minimum timeout value of 60 seconds is recommended for the timers.

The timer values you specify here apply to endpoints within the realm
that are not individually configured. You can also select default which
indicates that the Realm should default to use the global media inactivity
timer settings. If you do not want to use the media inactivity detection
timers in this Realm you can use the Disable check boxes to disable either
one or both of the timers.

Add Realm Rate Limit Tab

Field

Description

Methods - Rate
Limit Column

The maximum number of requests (per second) for the chosen SIP
Method type that you want to allow for this Realm.

Methods - Burst
Column

Burst value for the chosen SIP Method which defines a temporary
increase in the number of requests of that you will permit to
accommodate occasional fluctuations in network traffic for this Realm.

Methods - EP
Default Rate
Column

Limits (per second) you want to apply to one or more of the SIP Methods
to use as a default for endpoints within this Realm that are not
configured with their own limits.

Methods - EP
Default Burst

Specify a Burst value for the SIP Method which defines a temporary
increase in the number of requests you will permit to accommodate
occasional fluctuations in network traffic for endpoints within this Realm
that are not configured with their own limits.

Rate Limit Error

Response Code

Select either Drop or Respond. Drop - the SBC will simply drop the calls
when rate limits are exceeded. Respond - the SBC will send the SIP
message you specify as the Rate Limit Error Response Code when rate
limits are exceeded.

323

Field

Description

Rate Limit
Error Code

The SIP message value to send when your configured rate limits are exceeded. The default SIP
message code is 503 (Service Unavailable).
Note: If you select a SIP response that contains a Retry- After header, you can configure the
interval that the header contains as the recommended time to wait before retrying.

Reporting
Interval

Minimum number of seconds the SBC should wait between logging reports of request rates
exceeding the Rate Limit for this Realm. Default, 0, logs all instances regardless of the frequency

UDP

Select the UDP traffic Rate Limit Bucket you want to assign to this Realm

TCP

Select the TCP traffic Rate Limit Bucket you want to assign to this Realm
Default Input Buckets.

Phone

Rate Limit Bucket used to set a default Input Rate Limit for Generic IP Endpoints within this
Realm - typically devices which are not configured with their own individual Rate Limits.

NAT

Rate Limit Bucket used to set a default Input Rate Limit for Endpoints within this realm that are
behind NAT devices and are not configured with their own individual Rate Limits.

Gateway

Rate Limit Bucket used to set a default Input Rate Limit for Gateway Endpoints within this realm
not configured with their own individual Rate Limits.

Gatekeeper

Rate Limit Bucket used to set a default Input Rate Limit for Gatekeeper Endpoints within this
realm not configured with their own individual Rate Limits.

Proxy

Rate Limit Bucket used to set a default Input Rate Limit for Proxy Endpoints within this realm
not configured with their own individual rate limits.

Subnets

Rate Limit Bucket used to set a default Input Rate Limit for subnets within this realm that are
not configured with their own individual Rate Limits.

Unknown

Rate Limit Bucket used to set a default Input Rate Limit for unknown Endpoints within this
realm that are not configured with their own individual rate limits. Note: Unknown endpoints
are those that are not yet registered with the SBC.
Default Output Buckets

Phone

Rate Limit Bucket used to set a default Output Rate Limit for Generic IP Endpoints within this
realm that are not configured with their own individual Rate Limits.

NAT

Rate Limit Bucket used to set a default Output Rate Limit for Endpoints within this realm that
are behind NAT devices and are not configured with their own individual rate limits.

Gateway

Rate Limit Bucket used to set a default Output Rate Limit for Gateway Endpoints within this
realm that are not configured with their own individual Rate Limits.

Gatekeeper

Rate Limit Bucket used to set a default Output Rate Limit for Gatekeeper Endpoints within this
realm that are not configured with their own individual Rate Limits.

Proxy

Rate Limit Bucket used to set a default Output Rate Limit for Proxy Endpoints within this Realm
that are not configured with their own individual Rate Limits.

324

Quality of Service (QoS) Tab

The values listed here will override incoming IP Packets received with Priority and
Type of Service (ToS) information specified here for Outgoing Packets.

Field

Description

Signaling 802.1p/q
Priority (1-7)

Specify a value between 1 and 7 to substitute for the received signaling 802.1q user
priority value. Or check None to use the OS default for signaling.

Media 802.1p/q
Priority (1-7)

Specify a value between 1 and 7 to substitute for the received media 802.1q user
priority value. Or check None to transparently pass the priority value.

Signaling IP Layer
ToS (0-255)

Specify a value between 0 and 255 to substitute for the received signaling ToS
value. Or check None to use the OS default for signaling.

Media IP Layer ToS

for Audio (0-255)

Specify a value between 0 and 255 to substitute for the received media ToS value
for audio. Or check None to transparently pass the received value.

Media IP Layer ToS

for Video (0-255)

Specify a value between 0 and 255 to substitute for the received media ToS value
for Video. Or check None to transparently pass the received value.

Media IP Layer ToS

for Image (0-255)

Specify a value between 0 and 255 to substitute for the received media ToS value
for Image. Or check None to transparently pass the received value.

Media IP Layer ToS

for Data (0-255)

Specify a value between 0 and 255 to substitute for the received media ToS value
for Data. Or check None to transparently pass the received value.

Media IP Layer ToS for

MSRP (0-255)

Specify a value between 0 and 255 to substitute for the received media ToS value
for MSRP. Or check None to transparently pass the received value.

325

326

327

Understanding Endpoints
Once you have established basic network connectivity you must add endpoints to your
system to be able to send and receive calls. Endpoints represent devices in your network and
must be added and configured appropriately for the type of call traffic you want to support.
The configuration settings on an endpoint help to govern how calls are processed.

Endpoints represent devices in your network and must be added and configured for the type
of call traffic you want to support. The configuration settings on an endpoint help to govern
how calls are processed.
Endpoints must be added and configured as the appropriate endpoint(s) for your network
layout and your specific installed devices.

328

Generic IP Device

A Generic IP Device is a device such as an IP Phone. When you configure a Generic IP Device
on the SBC, you can control all of the options on the device, such as enabling H.323 or SIP.
Minimum Required Fields:- A Generic IP Device endpoint requires that the following fields be
set:
Device type of Generic IP Device
Registration ID
Port number (0-255)
Extension / phone number
Realm with which the endpoint is associated

SIP or H.323 protocol support enabled

NAT detection enabled, if the endpoint is behind a NAT device
Other applicable fields are optional.
H.323 Gateway, Gatekeeper & Sgatekeeper
You should select one of the H.323 endpoint types if the device it represents will be sending
out H.323 calls. The type of device also determines whether it is a gateway or a gatekeeper.
Configuring an endpoint as an H.323 Gateway, Gatekeeper, or Sgatekeeper disables SIP
configuration options on that endpoint.

About the Sgatekeeper

While the SBC can operate as a Gatekeeper, some vendor Gatekeepers (Clarent, for example)
are not made to intercommunicate with Gatekeepers other than their own. To address this
situation in a mixed environment the SBC is configurable to appear to the other Gatekeeper
as if the SBC is a Gateway, not a Gatekeeper. To do this, you configure the other vendors
Gatekeeper on the SBC as a Super Gatekeeper, or Sgatekeeper.
Therefore, if an endpoint is a Gatekeeper (GK), it can have one of two relationships with the
SBC. It can be either a Master Gatekeeper (MGK), or Peering Gatekeeper (PGK).
If a Gatekeeper is configured as a Master GK on the SBC, the SBC registers to that MGK using
an H.323 ID assigned from the MGK. It is also necessary to configure the MGK GK ID on the
SBC as the Peer GK ID.
A Gatekeeper should be configured as a Master GK on the SBC whenever the gatekeeper
requires the SBC to register to it, or if the Gatekeeper is unable to support Gatekeeper
peering (as with the Clarent gatekeeper). When set up this way, the SBC acts as a gateway to
the MGK.
Note: For more information on EndPoints, please refer to the Session Border Controller
(SBC) Operations Guide.

329

H.323 Gateway - Minimum Required Fields

An H.323 Gateway requires the fields below:

Device type of H.323 Gateway
Registration ID
Port number (0-255)
IP Address
Realm with which the Gateway is associated
If an Egress Gateway, a Calling Plan
Other applicable fields are optional.

H.323 Gatekeeper - Minimum Required Fields

An H.323 gatekeeper, also called a Peer Gatekeeper, requires the fields below:
Device type of H.323 Gatekeeper
Registration ID
Port number (0-255)
IP Address
Realm with which the Gatekeeper is associated
If an egress gateway, a Calling Plan
Other applicable fields are optional.
H.323 Super (Master) Gatekeeper - Minimum Required Fields
An H.323 Master Gatekeeper, also called an Sgatekeeper, requires the fields below:
Device type of Master
Registration ID
Port number (0-255)
IP Address
Realm with which the Gatekeeper is associated
If an Egress Gateway, a Calling Plan
Tech Prefix, H.323 Id or Gatekeeper ID may be required for the SBC to register with this
device
Other applicable fields are optional.

330

SIP Gateway / SIP Proxy

You should select one of the SIP endpoint types if the device it represents will be sending out SIP calls.
Configuring an endpoint as a SIP gateway or SIP proxy automatically disables H.323 configuration
options on that endpoint.
SIP Gateway - Minimum Required Fields:
Device type of SIP Gateway
Registration ID
Port number (0-255)
IP Address
Realm with which the gateway is associated
If an Egress Gateway, a Calling Plan
Other applicable fields are optional.
SIP Proxy - Minimum Required Fields:
Device type of SIP Proxy
Registration ID
Port number (0-255)
IP Address
Realm with which the Proxy Server is associated
If an Egress Gateway, a Calling Plan
Other applicable fields are optional.
Softswitch Minimum Required Fields
When you configure an endpoint as a Softswitch, both H.323 and SIP configuration options are
automatically enabled on that endpoint. Calls of either type can be sent, based on the type of call
received.
Device type of Softswitch
Registration ID
Port number (0-255)
Realm with which the endpoint is associated
SIP and H.323 protocol support enabled
If an Egress Gateway, a Calling Plan
Other applicable fields are optional.
ENUM Server
An ENUM Server converts E.164 (telephone) numbers into Internet URIs, using DNS lookups. If you
are going to do ENUM queries, create an ENUM server endpoint to represent the ENUM server in
your system. The SBC can support multiple defined ENUM Server endpoints.

331

Managing Endpoints RSM Console

When you have determined the type of endpoint you need and are ready to create and
configure it, you can use the RSM Console user interface.

332

Add An Endpoint RSM Console

To Provision an Endpoint:
Make sure you are in the RSM Console, Database View.
Expand g <global> highlight v <global> Right Click Add Type of Endpoint

333

334

Adding an Endpoint RSM Console

The Provision an Endpoint dialog opens with the Phone tab shown by default. Configure the
options that are appropriate for the endpoint you are adding.
Endpoint Configuration Parameters - The following table summarizes the configuration
options available for endpoints. Depending on your network, devices, and the type of call
processing you want to support, not all of the options are applicable for a given endpoint.

Field

Description

Partition

Partition assigned to the endpoint

Device Type

The kind of endpoint being added / configured

Registration ID

Unique ID used internally by the SBC to identify an endpoint

Port Number

Virtual Port Number for the endpoint

IP Address

IP Address of the endpoint. The IP Address is not a requirement.

335

Adding an Endpoint RSM Console

Field

Description

Allow Dynamic
Registration

This option identifies the endpoint as an IP PBX that is statically

configured and registers through the SBC

Extension

The E.164 address of an endpoint. This is only available to Device Type Generic IP Device or when you specify that you are configuring an IP PBX
endpoint (by enabling the option Allow Dynamic Registration

Calling Plan

The Calling Plan used by this endpoint

Carrier ID

A logical grouping of endpoints belonging to the same supplier

336

Field

Description

Realm

The Realm assigned to this endpoint

Domain Name

Select one of the domains from the list if you want the SBC to replace the RSA IP
Address with the selected domain (FQDN) in outgoing SIP messages when this
endpoint is the destination endpoint. The list contains any domains specified in
the
configuration of the realm in which this endpoint resides

IEdge Group

The group limit to which this endpoint contributes and subscribes

Enable
Transcoding

Enables the use of Media Transcoding for the endpoint

Codec Profile

Specifies the Codec Profile the endpoint uses

337

Adding an Endpoint Advanced Tab

The SBC uses Zones
(Partitions) to group
endpoints in order to restrict
the endpoints they can call.
This restriction is applied
only when you use calling
plans to make routing
decisions.
To achieve interoperability
with different vendor's
products, the SBC may
need to
know the endpoint vendor.
Most vendor products can
be set to Generic.
The Subnet IP and
Subnet Mask define a
range of IP Addresses
that are allowed to set
up calls to the SBC
Check to have the SBC
use only the host name
portion of an ENUM
NAPTR response returned
from the ENUM server in
routing decisions.

338

Field

Description

Enum Reject String

Use this field to specify the reject string you have configured your ENUM
server to return when it is unable to look up a number. The value you specify
must be in A.B format where A and B are each strings, separated by a period.
For example, reject.com. The ENUM server must also be configured to
insert the appropriate ISDN cause code within the string, in a position
immediately following the A value and preceding the period within the
string. When the SBC receives this string from the ENUM server it extracts
the ISDN cause code embedded in the string and returns it when it is
terminating the failed call.

Enum ISDN Cause

Code

Use this field to specify a default ISDN cause code for the SBC to use when it
receives a reject string from the ENUM server, but the string does not
include an embedded ISDN cause code. The SBC sends this code when
terminating the failed call. The default value is 31.
DNS Domain Object

DNS Domain Object

Points particular DNS queries to a specific dns-resolver

IP Sec Transport Mode

Encryption Type

Select the type of encryption you want to use for IPSec connections to the
Endpoint.

IKE Phase 1
Lifetime and
Unit for Phase 1
Lifetime

Use Phase 1 Lifetime fields to specify a number and a unit of time (minute,
second, or hour) to define a lifetime for Phase 1 of the IKE Process.

IKE Phase 2
Lifetime and
Unit for Phase 2
Lifetime

Use Phase 2 Lifetime fields to specify a number and a unit of time (minute,
second, or hour) to define a lifetime for Phase 2 of the IKE Process

Dead Peer
Detection

Specify the number of seconds for the Dead Peer Detection (DPD) value.
The DPD value functions as a timeout. When there is no traffic from the
endpoint, over the secure channel within the specified interval, the channel
is torn down

Authentication
Algorithm

Select either SHA-1 or MD5 authentication algorithm for authenticating

packet data.

Authentication
Method

Select either PSK (pre-shared Key) or X.509 digital certificate method for
authentication between the SBC and the endpoint

Preshared Key

Specify the pre-shared key (password) to use between the SBC and this
endpoint.

339

DTMF
Egress DTMF

SIP DTMF

Use this list to specify whether you want the

endpoint to receive DTMF events as Out-ofband (signaling messages) or In-band (media
streams)
Select what type of SIP message you want the
endpoint to receive.
Media Inactivity

RTP Timeout / RTCP Timeout

340

Configure these timers to instruct the SBC to

regularly monitor the transmission of RTP and
RTCP media packets for this endpoint. When
the SBC detects that a packet has not been sent
within the configured timer threshold, it
terminates the call. This allows the SBC to
promptly reclaim the resources required for the
call.

Adding an Endpoint User Info Tab

Field

Description

First Name
Last Name
Email Address

Information about the customer who owns or operates this endpoint

Location
Country

Comments
Customer ID

This Customer ID is displayed in the CDR as an ID and is used to identify a

CDRs originating / destination endpoint

341

Protocol Tab
Field

Description
Gateway / Proxy

342

Gateway / Proxy

Tells the SBC that the endpoint is either a Gateway or Proxy

Priority

The SBC considers this priority setting when it searches for a destination
route
Zone
Routes Active Time-of-Day
Route Binding Priority
Destination Pattern Longest Match
Priority Setting

LNP

This enables endpoint-level Local Number Portability support. SBC

supports an endpoint performing an LNP server dip to get LNP data.
The feature is configured at two levels, the SBC, and the endpoint.
Presently, an Inoch Server is supported

Field

Description
SIP / H.323

SIP

Check this box if the endpoint supports SIP

H.323

Check this box if the endpoint supports H.323

URI (SIP/H.323)

Use to specify the Uniform Resource Identifier (URI) to use for this endpoint.
SIP / H.323 (continued)

ANI Based Auth

For use with PortaOne Billing System. Select whether you want to populate
the PortaBilling Username field with the ANI of the Calling Party to use in
Authentication and Authorization.

Enforce Privacy

Select yes to ensure that the calling party's number is not sent in egress call
requests.

Mid Call Codec

Change

You can control whether the peer endpoint participating in the call is notified
if a SIP endpoint changes its IP Address or port during a call in which the
media is being routed through the SBC

Calling Party
Number Plan

Select the type of number value to put in an egress call setup. The default
setting is Pass which causes SBC to pass through the value from the
incoming setup. For H.323 endpoints, if a value other than pass is
specified, that value is inserted as the Type of Number in the egress Calling
Party Number. For SIP endpoints a value of international causes SBC to
insert a leading plus (+) sign in the username of the egress From header. For
any value other than pass or international SBC ensures a plus sign is not
inserted.

Codemap File
Number

Enter the three-digit number for the custom codemap file you want to use to
map codes
received by this endpoint. Refer to Chapter 40 Cause Code/Response Code
Operations of the SBC Operations Guide for more information.
Cisco GTD

Enable Cisco GTD

Support

Select this check box to enable relay of Cisco GTD (Generic Transparency
Descriptor) messages to and from this endpoint. GTD is a message format
used to transmit SS7 ISUP call information between the PSTN and the VOIP
network.

343

Field

Description
Trunk Group

x-route-tag Support

When checked, the SBC will treat the x-route-tag value, rather than the tgrp
parameter value in the Contact header, as the source trunk group value in
incoming SIP call requests

Src. Trunk Group

Selects the endpoint as the ingress endpoint when the incoming call contains
a source trunk group ID that matches the string configured in this field.

Dest. Trunk Group

For destination port selection, and to insert destination trunk information

the into the egress leg.

New Source Ingress

Trunk Group

Overrides or supplies missing source trunk information from the incoming

setup.

New Source Egress

Trunk Group

Overrides or supplies missing incoming leg destination trunk group

information.

Send Dest. Trunk

Group

Controls the insertion of destination trunk information into the egress legs
setup message.
Trunk Group - Continued

x-route-tag Support

When checked, the SBC will treat the x-route-tag value, rather than the tgrp
parameter value in the Contact header, as the source trunk group value in
incoming SIP call requests

Remove Src. Trunk

Group

Removes source trunk group ID from egress leg setup requests

New Origination TG
on Egress

If this endpoint is the egress endpoint, a value in this field will replace the
origination (source) trunk group value in egress leg messages.

New Destination
TG on Egress

If this endpoint is the egress endpoint, a value in this field will replace the
destination trunk group value in egress leg messages.
Trunk Context

Support for 4904

Originating Trunk
Group

344

If this option is enabled, both trunk group ID and trunk group context can be
used to select ingress and egress endpoints. On a destination endpoint, it
specifies that trunk group and trunk group context parameters are paired in
the outgoing message, or they are removed. For destination endpoints it also
specifies that the SBC positions the originating trunk group value (tgrp) as a
user parameter in the Contact header in messages sent to that endpoint,
according to RFC 4904. If it is disabled on a destination endpoint, the SBC
positions tgrp as a URI parameter in the Contact header.

Field

Description

Source Trunk Context

Used in conjunction with the tg parameter on ingress, if the SBC

determines that an incoming call requests contains source trunk
group parameters that match
these values, it will route the call through this endpoint/port on
the ingress call leg.

Destination Trunk Context

Used in conjunction with the dtg parameter, if the SBC

determines, after processing at the ingress endpoint, that the
call request contains destination trunk group
parameters that match these values, it will route the call through
this endpoint/port on the egress call leg.

New Source Ingress Trunk

Context

If the incoming call request contains a source trunk group

context value, the value of this parameter overrides that
original source trunk group context value in the call request that
is sent to
the egress endpoint. If the incoming call request
did not contain a source trunk group context value, then this
value is inserted in the call request
before it is sent to the
egress endpoint.

New Destination Ingress

Trunk context

If the incoming call request contains a destination trunk group

context value, the value of this parameter overrides the original
destination trunk group context value in the call request that is
sent to the egress endpoint. If the incoming call request did not
contain a destination trunk group context value, then this value
is inserted in the call request before it is sent to the egress
endpoint.

New Source Egress Trunk

Context

The value of this parameter will replace the source trunk group
context value in the outgoing call messages. However, the egress
endpoint must have the option use 4904tg enabled to send
trunk group context parameters in the outgoing call.

New Destination Egress

Trunk Context

The value of this parameter will replace the destination trunk

group context value in the outgoing call messages. However, the
egress endpoint must have the option
use4904tg enabled to send trunk group context parameters in
the outgoing call.

345

SIP NAT traversal in IPv4 networks

Many IPv4 networks contain Network Address Translation (NAT) devices to extend their
addressing capabilities or for security reasons. The SBC can recognize and appropriately
handle messages from an endpoint that is behind a NAT device. Without NAT detection and
NAT traversal processing, traffic to and from the endpoint could not be routed correctly. The
SBC must be operating in OBP mode to enable NAT traversal.
Typical NAT devices change the source IP address in the SIP messages they pass along from
the endpoints behind them. With NAT detection enabled, The SBC recognizes when a SIP
request originates from behind a NAT device because the source address does not match the
address shown in the message's Via header. This mismatch triggers The SBC's NAT traversal
processing.

Endpoint using NAT (different IP for INVITE and Via)

346

Endpoint not using NAT (Via same as INVITE)

Devices with extended NAT capabilities, such as Application Layer Gateway (ALG) devices, can
change the Via header as well as the source address. In that case, no mismatch can be
detected. For those cases, the SBC also checks for the presence of an rport parameter in the
Via header. As described in RFC 3581, devices that alter source address information can help
ensure that message responses are routed back appropriately by adding an rport parameter
to the message. The rport parameter, along with the received parameter, is used to record
the IP address and port from which a message is received. Therefore, the SBC's NAT traversal
processing is also triggered when it detects an rport parameter in the Via header.

When NAT traversal processing is triggered for either reason, the SBC alters its regular
processing to ensure that it can successfully route messages back to the endpoints. The SBC
stores the source IP address and port information from which the SIP request was received.
The SBC sends responses back to this source IP address and port if the transport protocol is
UDP. If it is TCP, responses are sent back over the established TCP connection. If the SIP
request contains an rport parameter, the SBC inserts the rport parameter value in the Via
header of the responses.

347

Field

348

Description

Maximum Total
Calls

Optional limit on the Maximum Number of Concurrent calls this endpoint

can have

Maximum Ingress
Calls

An optional limit on the number of calls that may enter the network
through this endpoint/gateway. This value is independent of the
Maximum Egress Calls but limited by the Maximum Total Calls.

Maximum Egress
Calls

An optional limit on the number of calls that may be placed from the SBC
to that endpoint/gateway. This value is independent of the Maximum
Ingress Calls but limited by the Maximum Total Calls.

Enable Call
Hunting

Enable Call Hunting for this endpoint. Hunting specifies the number of
destination routes to be considered for call termination.

Inherit System
Default

If checked, this endpoint uses the system default settings for Maximum Call
Hunts configured within the Configuration > System Tab

Maximum Call
Hunts

Limits the number of Hunts allowed for a call originated by this endpoint.
Limit is 50.

Default Server
Selection

Use this option to indicate whether you want to specify a default server for
this endpoint. When configured, the SBC routes calls to this server when it
receives certain SIP response codes.

Field

Description

Never Route Media

If checked, this endpoint will not route media. If left unchecked, this
endpoint will route media.

Route Media

If checked, this endpoint will route media to/from other endpoints,

except with ones that are explicitly configured as Never Route
Media.
If left unchecked, this endpoint will route media with endpoints on
which Route Media is checked.

Max Call Duration

Use this field to specify a limit, in seconds, on how long calls or call
attempts can be in the system for this endpoint.

Enable Call Duration

Use this check box to enable setting a maximum call duration for this
endpoint.

Maximum Total Calls

Maximum Egress Calls

Use these fields to define additional call admission control (CAC)

capacity for emergency calls when normal CAC resources are
exhausted

Maximum Ingress Calls

Disable CAC Traps
Throttling

Click to check this check box if you want to disable trap throttling for
this specific endpoint. When this option is disabled all CAC threshold
traps for this endpoint are sent.

Inherit Global
Configuration / Use
Endpoint Level
Configuration

Click to select the Use Endpoint Level Configuration option if you

want to specify an individual CAC trap limit for this endpoint. This
enables the entry fields where you can define the trap limit and
interval to use for this specific endpoint. By default, the
option Inherit Global Configuration is selected which means the
endpoint is subject to the limits defined at the global level.

CAC Trap Throttling

Interval

Enter the number of seconds you want to include in the interval

during which the number of CAC threshold traps is counted.

CAC Trap Throttling Limit

Enter the maximum number of CAC traps you want sent for this
endpoint during the time interval specified in CAC Trap Throttling
Interval.

349

Adding an Endpoint Rate Limit Tab

Field

Description

Session Rate Limits

Method List

Use these fields to specify rate limits for the endpoint for one or more of the
SIP methods shown. In the Rate Limit column, specify the maximum number
of requests of that type per second that you want to allow. You can also
specify a Burst value for each type of method which defines a temporary
increase in the number of requests of that type that you will permit to
accommodate occasional fluctuations in network traffic.

Reporting Interval

Use this field to enter the minimum number of seconds that the SBC should
wait between logging reports of request rates exceeding the rate limit. The
default is 0 which means all instances are logged, regardless of the
frequency.

IP Layer Rate Limits

Group

Use these two lists to select rate limit buckets to assign for both input and
output traffic for this endpoint.

New Destination
TG on Egress

If this endpoint is the egress endpoint, a value in this field will replace the
destination trunk group value in egress leg messages.

350

351

352

353

354

1.

Emphasis the SBC is an extremely

powerful box of which only a small
amount of functionality is used in SDIN

355

356

357

358

1.

Emphasis the SBC is an extremely

powerful box of which only a small
amount of functionality is used in SDIN

359

360

tethereal / tshark
tethereal or tshark is the non-graphical command line version of wireshark.
You can capture information from your SBC to a file and then SFTP the file to your desktop.
You really need to be careful in a production environment and should never run a full blown
capture (capturing everything).

Use filters to capture the information you need and then stop the capture to ensure you
arent running out of disk space.

361

Note:
-i any : This option captures traffic of all Ethernet interfaces on the SBC (excluding hk
interfaces). Use this option to see incoming and outgoing traffic, but generates a lot of
output and should be used with caution and mostly just with the option to write it to file.

362

363

Wireshark / tethereal
Originally named Ethereal, Wireshark is the most common network analyzer on the market.
tethereal is the cli (text) version of the tool, commonly used as there is no GUI on the
servers. Ethereal writes pcap files which can be read by virtually any other network
analyzer.

tethereal can be used to check traffic flowing over specific interfaces. Checking for spanning
tree, CDP (Cisco Discovery Protocol) frames and broadcast traffic can give a basic idea of
connectivity and it can give you a quick indication of whether the interface is in the correct
VLAN / Switch Port.

364

Statserver / Statclient
The Network Processing Card has its own Linux Operating system. Command processing and
data formatting is performed by the statserver which runs on the Network Processing Card.
It receives a single command from the statclient, executes the command, and then closes the
connection.

The Statclient tool provides detail on the media interfaces by querying the operating system
on the Netowrk Processing Card. It runs on the SBC and provides an interface for the user to
query the statserver.

365

366

367

368

369

370

371

372

373

374

375

High Availability (HA)

The SBC supports 1+1 redundancy meaning that the SBCs are configured in pairs. The SBCs
in a redundant pair are considered peers to each other and are referred to individually as
nodes. If the active node goes out of service, a switchover occurs and the standby node takes
over processing responsibilities. When that happens, the former standby node becomes the
new active node until another switchover occurs.
During a failover, the standby becomes active almost immediately but in total it takes 500ms
or less for all of the processes to come up and for traffic to start flowing onto the new active
server.

376

Redundant Databases
Each node hosts a complete copy of the SBC database, with one considered the master
database and the other the slave database. The master database is the clusters source of
data for routes, calling plans, configured endpoints, and so on. Each node maintains a
consistent view of the system data through its access to the master database.

For backup purposes, the data in the master database is continually replicated to the slave
database over the control interface you configured during installation. The databases are
independent of node status (active or standby); that is, as long as a node is running, it can
host either the master or the slave database, regardless of whether that node is the active or
the standby for call processing.

377

Servicing Endpoints
When a switchover occurs, the standby node becomes active, in a seamless manner, and is
responsible for the same realm addresses. Call setup and tear-down to registered endpoints
is not lost since the realms signaling and media addresses remain available.
Endpoint registration data is also actively replicated from the active node to the standby. By
continually replicating registration data, the SBC protects the application server in your
network from receiving a flood of registration data in the event of a switchover.

378

Stateful Call Migration (SCM)

SCM prevents active calls from being dropped in the event of a system failure. Call state
information is replicated to the standby node so that active calls are maintained rather than
dropped during a switchover. Call state replication begins when the active node detects the
standby node, after the call is connected.

379

High Availability Stateful Call Migration (SCM) contd.

In addition to call state information, the following data is replicated for SCM:
Out-of-call messages (for example, NOTIFY or SUBSCRIBE messages).
Endpoint registration data.

CAC (Call Admission Control) data - The SBC provides CAC across multiple endpoint /
ports. Aggregate totals for calls in a CAC group are preserved and replicated to the
standby node so it will be able to continue appropriately limiting calls for an endpoint
group.
Session timers for active sessions are migrated to the standby node.
Call duration timers for active calls are migrated to the standby node.
Without SCM, when a switchover takes place, the node that is shutting down drops inprogress calls. The CDRs for such dropped calls are marked with shutdown in the call-error
CDR field 14.

380

Replication Status
You can use the cli scm command to display current information on the replication of callrelated data and dynamic registrations from the local node (on which the command is run)
to its peer.
The output from the command is displayed in 6 sections as described below. In each section,
Total indicates the total call states of that type on the node. The three values that follow
specify how many have been successfully replicated, how many are pending replication, and
how many failed to replicate.

381

HA Configurations- Replication Status

The first section includes information on the current state of the node (initializing, active,
standby, or impaired). It also shows the current status of replication of call states (shown as
SCM in the output) from the local node to its peer.
SCM Total States - Successfully replicated the number of calls that will survive a
switchover
SCM Pending States - This value should be zero, if it not zero, there is a problem
SCM States Successfully Sent - Running tally of states successfully replicated since the
last startup
SCM States Failed - States rejected by the beer, this value should normally be zero
Note:
Each call contributes two states (one for each leg) to the above counts.!

382

HA Configurations- Replication Status

The second section, shown as OLC (Overlap Call), provides information on out-of-dialog
messages such as SUBSCRIBE or NOTIFY requests.
The third section, shown as DRM (Dynamic Registration Memory) provides information on
the replication of dynamic registration data currently in memory.

The fourth section, shown as REG (Registration) provides internal endpoint registration states

383

HA Configurations- Replication Status

The fifth section, shown as DBQ provides information on updates to the dynamic registration
data in persistent store.
The final section indicates the number of pending media requests.

384

Cli scm examples

The above examples show the corresponding output from each server in the cluster.
Note: The cli scm command takes a snapshot.
To get an updated response, use the watch utility; watch cli scm

This will give a refreshed view every 2 seconds.

385

Monitoring the SBC

Your specific configuration and network environment determine which resources and
processes are critical to your operation. In an high-availability environment you can choose
what conditions would trigger a switchover to the standby node. Through configuration you
specify which interfaces, processes, and system resources you want to monitor.

Specifying Which Interfaces to Monitor

You can select which of the interfaces on the SBC you want to monitor. These interfaces
include the SBC Ethernet ports used for signaling (typically eth2 and eth3) and the ports on
the media processing card used for media routing (typically, hk0,0, and hk0,1). When the
SBC detects that an interface you have chosen to monitor is down, it switches over to the
standby node.

386

HA Configurations Monitoring continued

Use the following command to specify which interfaces you want to monitor:
nxconfig.pl e interface monitor-list
The SBC prompts you to select from a list of interfaces. Any interfaces you are currently
monitoring appear in the square brackets []. By default, no interfaces are monitored, so the
initial value appears as none. Enter the interfaces(s) you want to monitor by letter. The SBC
continues to prompt you for additional choices until you enter q for quit.
Note:
You should not include the interface you designated as the heartbeat interface (eth1) in the
interface monitor list. This will cause big issues if a cable is unplugged or if one of the system
reboots!!

387

Specifying Processes to Monitor

You can also monitor SBC specific processes. The processes you specify must be up and
available on the active node or else a switchover occurs. By default, the SBC monitors the
internal SBC application processes gis and rpcbind. In addition to these, you can specify that
the SBC monitor the named process (used for resolving domain names) and the snmpd
process (used only if you are running SNMP). The SBC will trigger a switchover when a
monitored process goes down.
Perform an nxconfig.pl S |grep monitored to see the processes that are being monitored
and the current values set.

388

HA Configurations Monitoring continued

Any processes you are currently monitoring appear in square brackets []. Enter any
process(es) you want to monitor, by letter. The SBC continues to prompt you for additional
choices until you type q for quit.

389

Specifying Resources to Monitor

For the resources you choose to monitor, you define usage thresholds that, when exceeded
for a period of time, will result in a switchover. The system resources available for monitoring
include Virtual Memory Usage and Swap Space Usage. The SBC regularly checks, in 5 second
intervals, the usage of the monitored resources and, if the usage over three consecutive
samples exceeds the threshold you specify, a switchover is triggered.
By default, all threshold values are set to 0 which disables the monitoring. Use the following
global commands to specify thresholds for the resources you want to monitor. The values
should be expressed as positive integers, representing the threshold percentage

390

Monitoring Virtual Memory Usage

You can specify a virtual memory threshold value and processes to monitor for exceeding
that threshold. Currently, the only process defined for this type of monitoring is gis. If you
are currently monitoring the gis process, it appears in square brackets.

391

392

393

Monitoring System Status

The SBC provides CLI commands you can use to monitor the operational status of your
cluster, including its processes and resources, as well as the replication status from the active
node to the standby node. Note: You must have root user access or have the nxadmin role
to use the CLI commands described in this section!!

394

Cluster Information
You can display information on the current status of your cluster by using the cli ha
command. The output shows the status of the node on which you ran the command, the
status of the databases on both nodes, and the resources and processes you chose to
monitor.

The status of a node can be any of the following:

Initializing the node is in the process of initializing resources. This is a transient state;
after being initialized, the node will enter either the Active or Standby state

Active all the monitored resources are in an operational state and the local node is
standing by, ready to service calls in the event of a switchover
Impaired the node is considered impaired because one or more of the monitored
resources is not available or has exceeded a threshold. This node will not be able to
service calls

395

Monitoring Database Replication

The SBC monitors the status of the database replication process (Slony) to detect when the
databases are no longer synchronized. However, such a condition does not lead to either
node being placed in an impaired state. Instead, the SBC restarts the Slony process to
attempt to correct the problem. SNMP traps are generated both when a replication problem
is detected and when it is corrected.
The status of database replication included in the output of the cli ha command as well as in
the RSM Console Cluster Information dialog.
Forcing a Switchover
If necessary, you can force a switchover by shutting down all processes (iserver all stop or
allstop) that provide the SBC services (call signaling, routing, etc.). This initiates the
switchover. After restarting the processes (iserver all start or allstart), use cli scm to review
system status. The output will indicate the state of the node on which you issued the
command and information on replication status between the nodes.

396

Cluster Monitoring RSM Console

The RSM Console also provides a GUI method for showing the Cluster Status.
To access, select iServer, Configure and access the Redundancy tab and click on Show Cluster
State to open the Cluster State window.
This window has the option of selecting the update rate via a slider.
Note:
The Cluster State window cannot be re-sized

397

Cluster Monitoring RSM Console an alternative

The two methods shown above result in the same window opening and this window can be
re-sized.

398

399

SBC Outage Report

The SBC maintains a record of instances when the nodes in a cluster change status. This data
is input to the SBC Outage report that you can generate in the RSM.
The SBC Outage report provides an historical record of outages. An outage is defined as the
state of the SBC in which the SBC cannot service calls. The SBC database stores state data as
it occurs in the iServer log. The RSM reads the SBC database to get state information and
stores this information in the RSM database. It then reports on this information in the SBC
Outage report. State information stored in the RSM includes a time stamp when the state
information is updated, SBC identification/name, current SBC state and previous SBC state.
State information stored in the RSM database is purged periodically to minimize storage
space usage. The Purge Outage Records (days) parameter on the Configuration page controls
when RSM deletes these records.
The SBC Outage report is at the cluster level. (A cluster is a pair of SBC in a high availability
configuration, where one is the active system and the other is the standby.) Also available in
the report are the states of the individual nodes inside the cluster.

400

The RSM tracks the individual state of each node, then uses this information to determine
the state of the cluster as a whole. The individual state of a node can be one of the following:
Active: the node is providing the service
Standby: the node is ready to provide service if switchover occurs
Impaired: the node cannot provide service
Clusters can have the following states, based on the states of the individual nodes within the
cluster:
If one node is Active and the other is Standby, the cluster is Up. When the cluster is up, it
is providing service.
If one node in the cluster is Active and the other is Impaired, the cluster is Up with
Impaired Node. The cluster is still providing service but switchover cannot occur.
If neither of the nodes is Active or both nodes are Active, the cluster is Down and is not
providing service. This is the Outage state.
Note:
The SBC Outage report is available only to users who are members of the Admin partition. It
is designed to be a reporting tool, not a monitoring tool!!

401

402

403

404

405

406

407

408

409

410

411

NetNumber TITAN
TITAN SRD
Transactional IP Telephony Addressing and Numbering Server
Signaling, Routing and Database
The TITAN SRD server is produced by NetNumber and is a GENBAND offered option for a CRE in a
GENBAND IPX Solution for TDM and IP-based voice services, messaging services, number-portability
services and least-cost routing services.
The TITAN provides a common infrastructure for the virtual delivery of real-time signaling control,
policy enforcement and subscriber database services.
TITAN represents a paradigm shift for building a radically simplified core network where all signaling
control services (ENUM/DNS, SIP, DIAMETER, SS7/C7 and SIGTRAN) are provided on a common
TITAN infrastructure.
TITAN SRD enables smooth inter-working with legacy signaling management services and protocols
during the transition to a next gen network.

412

Architecture Overview
Dependent on the customer requirement, typically TITAN servers would be deployed with master
and edge servers.
The master servers (active and Standby) would hold all configuration and update the edge servers.
The edge servers would perform the call routing processes.
Further Information may be found at http://netnumber.com/products/titan

413

414

415

SIP to SIP Call with common P-time and Codec

New call setup involving
Ingress S3
S3 = sbc-uk-mr-dh01
OTG = tgukukipx-tnor1111-11111

416

Egress S3
S3 = sbc-uk-bm-th02
DTG = tgukukipx-tnor222-22222

Event

Details

INVITE received at Ingress S3 to CdPN

SIP
INVITE from
CP to S3-In

Request-URI = CdPN@uk.gen.band.net;user=phone
P-Asserted-ID= CgID1@cp-name.com;user=phone
From = CgID2@cp-name.com;user=phone
SDP Offer from source

S3-In

S3 normalises CdPN and caller identities to network provider conventions

S3 inserts default identity if necessary

Ingress S3 default routes to Titan (all calls or per Endpoint)

S3-In

S3 determines OTG and Context from data provisioned against point of network
attachment

SIP
INVITE from
S3-In to
Titan

Request-URI = CdPN@titan.uk.gen.band.net
Contact = ContactID1;
tgrp=tgukukipx-tnor1111-11111;
trunk-context=map01.sig01.p10.sbc-uk-mrdh01.
uk.gen.band.net@sbc-uk-mr-dh01.uk.gen.band.net

INVITE received at Titan

Titan

Titan determines service (to handle country specific numbering plans) from OTG
Titan inspects the Call Barring attribute of the OTG profile 0 for no calls barred.
CdPN manipulated if necessary (e.g. for Number Portability)
Titan determines Destination Group from CdPN
Titan determines DTG List from Destination Group
tgukukipx-tnor2222-22222

Titan performs Trunk Group attribute matching for each OTG/DTG pair to determine
Route (including whether interworking services are required)
S3 to S3 call (NT 1 to NT 1)
P-Time match
Codec intersect
SIP to SIP
Interworking not required
Select Default Route (direct to Egress S3)
sbc-uk-bm-th02.uk.gen.band.net

Titan determines Context associated with each DTG
map01.sig01.p10.sbc-uk-bm-th02.uk.gen.band.net

417

Event

Details

300 MULTIPLE CHOICES received at Ingress S3

SIP 300
MULTIPLE
CHOICES
from TITAN
to S3

Contact = CdPN;
tgrp=tgukukipx-tnor2222-22222;
trunk-context=map01.sig01.p10.sbc-uk-bmth02.
uk.gen.band.net@ sbc-uk-bm-th02.uk.gen.band.net;
user=phone
Contact (alternate route)

S3-In

S3 matches Domain to an outgoing Endpoint and Realm

DNS query from Ingress S3 to resolve IP Address

S3-In

A specific S3 IP Address is returned and used for routing

Referenced from the sbc-uk-bm-th02.uk.gen.band.net domain DNS Resolution

INVITE sent from Ingress S3 to Egress S3

SIP
INVITE from
S3-In to S3Eg

Request-URI = CdPN;
tgrp=tgukukipx-tnor2222-22222;
trunk-context=map01.sig01.p10.sbc-uk-bmth02.
uk.gen.band.net@sbc-uk-bm-th02.uk.gen.band.net;
Contact = ContactID2;
tgrp=tgukukipx-tnor1111-11111;
trunk-context=map01.sig01.p10.sbc-uk-mrdh01.
uk.gen.band.net@sbc-uk-mr-dh01.uk.gen.band.net
SDP Offer from source with transport addresses modified by S3In

INVITE received at Egress S3

S3-Eg

S3 recognises Context and DTG as a local Trunk Group

Internal network routing information is removed from URIs
No further Titan lookup is required and the call is routed

INVITE sent from Egress S3 to CP

SIP
INVITE from
S3-Eg to CP

Request-URI = CdPN@customer.com;user=phone
Contact = ContactID3@uk.gen.band.net;user=phone
SDP Offer from source with transport addresses modified by S3Eg

418

419

CP (SIP) to CP (SIP) Media Interworking

SIP to SIP with different P-Times

New call involving:
Ingress S3

Interworking C3

Egress S3

S3 = sbc-uk-mr-dh01

C3 = mgc-uk-pool, mgc-uk-999

S3 = sbc-uk-bm-th02

OTG = tgukukipx-tnor111111111

Internal Incoming = map01.mm1

Internal Outgoing = map01.sig01.p20

DTG = tgukukipx-tnor222244444

420

Event

Details

INVITE received at Ingress S3 to CdPN

SIP
INVITE from
CP to S3-In

Request-URI = CdPN@uk.gen.band.net;user=phone
P-Asserted-ID= CgID1@cp-name.com;user=phone
From = CgID2@cp-name.com;user=phone
SDP Offer from source

S3-In

S3 normalises CdPN and caller identities to network provider conventions

S3 inserts default identity if necessary

Ingress S3 default routes to Titan (all calls or per Endpoint)

S3-In

S3 determines OTG and Context from data provisioned against point of network
attachment

SIP
INVITE from
S3-In to
Titan

Request-URI = CdPN@titan.uk.gen.band.net
Contact = ContactID1;
tgrp=tgukukipx-tnor1111-11111;
trunk-context=map01.sig01.p10.sbc-uk-mrdh01.
uk.gen.band.net@sbc-uk-mr-dh01.uk.gen.band.net

INVITE received at Titan

Titan

Titan determines service (to handle country specific numbering plans) from OTG
CdPN manipulated if necessary (e.g. for Number Portability)
Titan determines Destination Group from CdPN
Titan determines DTG List from Destination Group
tgukukipx-tnor2222-22222

Titan performs Trunk Group attribute matching for each OTG/DTG pair to determine
Route (including whether interworking services are required)
S3 to S3 call (NT 1 to NT 1)
P-Time mismatch
Codec intersect
SIP to SIP
Media Interworking required
Select Default Route (direct to Egress S3)
sbc-uk-bm-th02.uk.gen.band.net

Titan determines Context associated with each DTG
map01.sig01.p10.sbc-uk-bm-th02.uk.gen.band.net

421

Event

Details

300 MULTIPLE CHOICES received at Ingress S3

SIP
300
MULTIPLE
CHOICES
from TITAN
to S3

Contact = CdPN
tgrp=tgukukipx-tnor2222-44444;
trunk-context=map01.sig01.p20.sbc-uk-bmth02.
uk.gen.band.net@map01.mm1.mgc-ukpool.
uk.gen.band.net; user=phone
Contact (alternate route)

300
MULTIPLE
CHOICES
from TITAN
to S3

tgrp=tgukukipx-tnor2222-44444;
trunk-context=map01.sig01.p20.sbc-uk-bmth02.
uk.gen.band.net@map01.mm1.mgc-ukpool.
uk.gen.band.net; user=phone
Contact (alternate route)

S3-In

S3 matches Domain to an outgoing Endpoint and Realm

DNS query from Ingress S3 to resolve IP Address

S3-In

A specific C3 IP Address is returned and used for routing

Referenced from the map01.mm1.mgc-uk-pool.uk.gen.band.net domain
DNS resolution

INVITE sent from Ingress S3 to Interworking C3

SIP
INVITE from
S3-In to C3Iw

Request-uri = CdPN;
tgrp=tgukukipx-tnor2222-44444;
trunk-context= map01.sig01.p20.sbc-uk-bmth02.
uk.gen.band.net@map01.mm1.mgc-uk-pool.uk.gen.band.net
Contact = ContactID2;
tgrp=tgukukipx-tnor1111-11111;
trunk-context=map01.sig01.p10.sbc-uk-mrdh01.
uk.gen.band.net@sbc-uk-mr-dh01.uk.gen.band.net
SDP Offer from source with transport addresses modified by S3In

422

Event

Details

Invite received at interworking C3

C3-Iw

C3 uses layer 3 source IP Address to determine incoming Trunk Group

Internal (Type B) Trunk Group
SIP (determined from MIME header)
ITU mapping (map01)
Not Direct RTP (mm1)
C3 inspects Context in Request-URI to determine routing
Trunk-Context not itself, i.e. DTG not local
C3 launches DNS query of Context FQDN
C3 matches IP Address to a Trunk Group
Outgoing Trunk Group is internal (i.e. inter-Node)
ITU mapping (map01)
SIP (sig01)
P-Time = 20ms (p20)
C3 routes call to Egress S3
Note: Interworking is performed (or not) based on attributes set against incoming
and outgoing C3 Trunk Groups
Signalling interworking not performed
RFC / SIP (incoming TG) <> RFC / SIP (outgoing TG)
Media interworking (transrating) performed
Incoming TG is not Direct RTP, G9 inserted
SDP modified
P-Time = 20ms (outgoing TG)
Codecs = Offer All (outgoing TG)

INVITE sent from Interworking C3 to Egress S3

SIP
INVITE from
C3-Iw to
S3-Eg

Request-URI = CdPN;
tgrp=tgukukipx-tnor2222-44444;
trunk-context= map01.sig01.p20.sbc-uk-bmth02.
uk.gen.band.net@map01.sig01.p20.sbc-uk-bmth02.uk.gen.band.net
Contact = ContactID4;
tgrp=tgukukipx-tnor1111-11111;
trunk-context= map01.sig01.p10.sbc-uk-mrdh01.
uk.gen.band.net@mgc-uk-999.uk.gen.band.net
SDP Offer from source with transport addresses modified by S3In

INVITE received at Egress S3

S3-Eg

S3 recognises Context and DTG as a local Trunk Group

Internal network routing information is removed from URIs
No further Titan lookup is required and the call is routed

10

INVITE sent from Egress S3 to CP

SIP
INVITE from
S3-Eg to
CP

Request-URI = CdPN@customer.com
Contact = ContactID3@uk.gen.band.net
SDP Offer from source with transport addresses modified by S3Eg

423

G9 Bearer Data Flow

Each SST provides point-to-point unidirectional serial TDM highways to and from the other slots in
the G9. The channelized interface, packet interface and server cards, in particular, require these
TDM highways

424

425

CP (SIP) to PSTN (ISUP)

SIP to ISUP Call

New call involving:
Ingress S3

426

Egress C3

S3 = sbc-uk-mr-dh01

C3 = mgc-uk-999

OTG = tgukukipx-tnor1111-11111

DTG = tgukukpst-bm_jde00-99999

Route List = 07777

Event

Details

INVITE received at Ingress S3 to CdPN

SIP
INVITE from
CP to S3-In

Request-URI = CdPN@uk.gen.band.net;user=phone
P-Asserted-ID= CgID1@cp-name.com;user=phone
From = CgID2@cp-name.com;user=phone
SDP Offer from source

S3-In

S3 normalises CdPN and caller identities to network provider conventions

S3 inserts default identity if necessary

Ingress S3 default routes to Titan (all calls or per Endpoint)

S3-In

S3 determines OTG and Context from data provisioned against point

of network attachment

SIP
INVITE from S3-In to
Titan

Request-URI = CdPN@titan.uk.gen.band.net
Contact = ContactID1
tgrp=tgukukipx-tnor1111-11111;
trunk-context=map01.sig01.p10.sbc-uk-mrdh01.
uk.gen.band.net@sbc-uk-mr-dh01.uk.gen.band.net

INVITE received from Titan

Titan

Titan determines service (to handle country specific numbering plans)

from OTG
CdPN manipulated if necessary (e.g. for Number Portability)
Titan determines Destination Group from CdPN
Titan determines DTG List from Destination Group
tgukukpst-bm_jde00-99999

Titan performs Trunk Group attribute matching for each OTG/DTG pair
to determine Route (including whether interworking services are
required)
S3 to C3 call (NT 1 to NT 2)
Interworking applied at Egress C3
Select Signaling Interworking Route (direct to Egress C3)
map01.mm0.mgc-uk-999.uk.gen.band.net

Titan determines Context associated with each DTG

mgc-uk-999.uk.gen.band.net

427

Event

Details

300 MULTIPLE CHOICES received at Ingress S3

SIP
300
MULTIPLE
CHOICES
from TITAN
to S3

Contact = CdPN;
tgrp=tgukukpst-bm_jde00-99999;
trunk-context= mgc-uk999.uk.gen.band.net@map01.mm0.mgc-uk-999.uk.gen.band.net;
user=phone
Contact (alternate route

S3-In

S3 matches Domain to an outgoing Endpoint and Realm

DNS query from Ingress S3 to resolve IP Address

S3-In

A specific S3 IP Address is returned and used for routing

Referenced from the map01.mm0.mgc-uk-999.uk.gen.band.net domain
DNS resolution

INVITE sent from Ingress S3 to Egress C3

SIP
INVITE from
S3-In to C3Eg

Request-URI = CdPN;
tgrp=tgukukpst-bm_jde00-99999;
trunk-context= mgc-uk999.uk.gen.band.net@map01.mm0.mgc-uk-999.uk.gen.band.net
Contact = ContactID2;
tgrp=tgukukipx-tnor1111-11111;
trunk-context=map01.sig01.p10.sbc-uk-mrdh01.
uk.gen.band.net@sbc-uk-mr-dh01.uk.gen.band.net
SDP Offer from source with transport addresses modified by S3In

INVITE received at Egress C3

C3-Eg

C3 uses layer 3 source IP Address to determine incoming Trunk Group

Internal (Type B) Trunk Group
SIP (determined from MIME header)
ITU mapping (map01)
Direct RTP (mm0)
C3 inspects Context in Request-URI to determine routing
Trunk-Context itself, i.e. DTG is local
C3 matches TGRP in Request-URI to DTG
ITU mapping
ISUP
C3 routes call to local DTG
Note:
Interworking is performed (or not) based on attributes set against incoming and
outgoing C3 Trunk Groups
Signalling interworking performed
RFC / SIP (incoming TG) <> ITU / ISUP (DTG)
Media interworking performed
DTG is TDM, G9 inserted

428

Event

Details

IAM sent from Egress C3

ISUP
IAM from
C3-Eg to
CP

CdPN
CgPN

ACM received at Egress C3

C3-Eg
10

18X response from Egress C3 to Ingress S3

S3-Eg

180 RINGING if ACM = Subscriber Free Indication

SDP answer preferred common codec
183 SESSION PROGRESS otherwise
SDP answer preferred common codec
Backward speech path established at G9

11

ANM received at Egress C3

C3-Eg

200 OK sent to Ingress S3

Bi-directional speech path established at G9

429

430

431

PSTN (ISUP) to CP (SIP)

ISUP to SIP Call

New call involving:
Ingress C3

432

Egress S3

C3 = mgc-uk-888

S3 = sbc-uk-bm-th02

OTG = tgukukpst-mr_mllua-88888

DTG = tgukukipx-tnor2222-22222

Event

Details

INVITE received at Ingress C3 to CdPN

ISUP
IAM from
PSTN to
C3-In

CdPN
CgPN

C3-In

C3 processes CdPN/CgPN
CdPN matched against local numbering plan data to determine end of digits
(Overlap handling)
Note: There is a trade off in terms of how much numbering plan data is
held locally in the C3 vs. using inter-digit timers to determine end of
Digits

Ingress C3 launches query to Titan (trigger all calls)

C3-In

Note: Query launched when end of digits established

(i.e. CdPN is now En-Bloc)
C3 determines OTG TGRP from data provisioned
against incoming Trunk Group
C3 determines OTG Context from data provisioned against Node
(one Context per C3)

SIP
INVITE from
C3-In to Titan

Request-URI = CdPN@titan.uk.gen.band.net
Contact = ContactID1;
tgrp= tgukukpst-mr_mllua-88888;
trunk-context=mgc-uk-888.uk.gen.band.net@mgc-uk888.uk.gen.band.net

INVITE received at Titan

Titan

Titan determines service (to handle country specific numbering plans)

from OTG

CdPN manipulated if necessary (e.g. for Number Portability)

Titan determines Destination Group from CdPN
Titan determines DTG List from Destination Group

tgukukipx-tnor2222-22222

Titan performs Trunk Group attribute matching for each OTG/DTG pair to determine
Route (including whether interworking services are required)

C3 to S3 call (NT 2 to NT 1)

Interworking applied at Ingress C3

Select Profiled Route (direct to Egress S3)

map01.sig01.p10.sbc-uk-bm-th02.uk.gen.band.net

Titan determines Context associated with each DTG

map01.sig01.p10.sbc-uk-bm-th02.uk.gen.band.net

433

Event

Details

300 MULTIPLE CHOICES received at Ingress C3

SIP
300 MULTIPLE
CHOICES from TITAN
to C3

Contact = CdPN;
tgrp=tgukukipx-tnor2222-22222;
trunk-context=map01.sig01.p10.sbc-uk-bmth02.
uk.gen.band.net@map01.sig01.p10.sbc-uk-bmth02.
uk.gen.band.net; user=phone
Contact (alternate route)

C3-In

C3 launches DNS query of Domain FQDN

C3 matches IP Address to a Trunk Group
Outgoing Trunk Group is internal (i.e. inter-Node)
ITU mapping (map01)
SIP (sig01)
P-Time = 10ms (p10)
C3 routes call to Egress S3
Note: Interworking is performed (or not) based on attributes set against
incoming and outgoing C3 Trunk Groups
Signalling interworking performed
ITU/ISUP (OTG) <> RFC/ SIP (outgoing TG)
Media interworking performed
OTG is TDM, G9 inserted
SDP generated
P-Time = 10ms (outgoing TG)
Codecs = Offer All (outgoing TG)

INVITE sent from Ingress C3 to Egress S3

SIP
INVITE from
C3-In to C3Eg

Request-URI = CdPN;
tgrp=tgukukipx-tnor2222-22222;
trunk-context=map01.sig01.p10.sbc-uk-bmth02.
uk.gen.band.net@map01.sig01.p10.sbc-uk-bmth02.
uk.gen.band.net
Contact = ContactID2;
tgrp=tgukukpst-mr_mllua-88888;
trunk-context=mgc-uk-888.uk.gen.band.net@mgc-uk888.uk.gen.band.net
Generated SDP Offer

434

Event

Details

INVITE received at Egress S3

S3-Eg

S3 recognises Context and DTG as a local Trunk Group

Internal network routing information is removed from URIs
No further Titan lookup is required and the call is routed

INVITE sent from Egress S3 to CP

SIP
INVITE from
S3-Eg to
CP

Request-URI = CdPN@customer.com
Contact = ContactID3@uk.gen.band.net
SDP Offer from source

180 RINGING received at Ingress C3

C3-In
9

ACM sent from Ingress C3 to PSTN

C3-In

Backward ringing tone applied at G9

10

200 OK received at Ingress C3

C3-In

SDP answer preferred common codec

11

ACM sent from Ingress C3 to PSTN

C3-In

Bi-directional speech path established at G9

435

436

437

438

439

440

441

442

443

444

CDR Basics

445

CDR Types Default settings

446

CDR Types Default settings continued

447

CDR Types Optional settings

Optionally, you can configure the SBC to generate additional records for other points within the call:
At the Ingress leg start-call (Start 1)
At the Egress leg start-call (Start 2)
At the Egress leg end-call (End 2)
These records are written to the main file in addition to Leg 1 End (End 1) record.

448

CDR Types Optional settings continued

Additionally the SBC can write a record for Hunt calls.
Enabling the Hunt event instructs the SBC to write records for route-advance (or hunt) calls into the
open files.
The default is to not write route advance records into the records, but rather only one CDR, for the
last call setup attempt.
Unlike the other optional CDR events, a configuration option allows you to determine whether hunt
records are added to the default log file (containing end1 records) or the optional log file that
contains the records for the non-end1 events.
When this option is enabled and Hunt End 2 is set, all Leg 1 Start, Leg 2 Start, Leg 2 End and Hunt
records are written to a separately named open file.
If Hunt - End 1 is set, the above records are still written to the original open file.

449

CDR Types Optional settings continued

The SBC can also write Interim records.
When this option is enabled records are created after a pre-determined timer.
This is used for detecting Fraud or Hung calls.
These records are written to another separate open file.
Until the open file in which interim records accumulate is closed, all of the interim records
accumulate in an open file.

450

CDR Log File Naming

Each of the CDR file types has a unique filename suffix, and each suffix also differs depending on
whether the file is open or closed. For example, the file for traditional CDRs ends with the letters
CDR, but when it is open for writing, its suffix is CDT (think of T as meaning temporary).
For example, if you configured SBC to log CDRs daily, it does the following:
1. SBC opens a .CDT file when the first call is made.
2. It logs CDRs for each call in this file through the day.
3. It converts this files extension to .CDR at the end of the day.
4. SBC opens a new .CDT file when the first call is made the following day.
The internal format of CDR and CDT files is identical. This same suffix convention for open and
closed files applies to other types of CDR log files.
The prefix portion of the filename depends on which type of closing option is in effect. For files
being closed based on the daily, sequential, or time option, the filename prefix is the same
regardless of whether the file is open or closed. Therefore for these 3 types, the prefix of the
filename is assigned when the file opens, and remains the same when the file closes and the suffix
changes.

451

CDR format
SBC saves CDRs in a format modeled after MIND CTI1. It is a semicolon-separated ASCII flat file
format that can be imported into a billing system, or into any system that supports CSV files. The
fields appear sequentially in each CDR .
Any field listed as Not currently used appears as two adjacent semi-colons in the actual CDR file,
representing a null field.
See the SBCs Operations guide, Billing and CDR Processing, CDR Contents and Format for a full
listing of fields.
Note that in the above documentation, the CDR fields are described in the context of the default
(end1) CDR which contains end-call data for the ingress call leg.
SBC can be configured to generate additional CDRs at other points within a call. For CDRs written at
other points within the call, the contents of the fields in CDRs will reflect the parameters of the call
at that time. For example, the designation of what is source and what is destination may be
reversed and some fields may not be populated.
Note that a CDR may contain both IPv4 and IPv6 addresses. For example, if a call originates in an
IPv4 realm, and terminates in an IPv6 realm, the call-source (field 4) will be an IPv4 address, while
the call-dest (field 6) will be an IPv6 address.

452

CDR format and storage

SBC saves CDRs in a format modeled after MIND CTI1. It is a semicolon-separated ASCII flat file
format that can be imported into a billing system, or into any system that supports CSV files.
The fields appear sequentially in each CDR . Any field listed as Not currently used appears as two
adjacent semi-colons in the actual CDR file, representing a null field.
See the SBC Operations guide, Billing and CDR Processing, CDR Contents and Format for a full listing
of fields.
Note that in the above documentation, the CDR fields are described in the context of the default
(end1) CDR which contains end-call data for the ingress call leg.
SBC can be configured to generate additional CDRs at other points within a call. For CDRs written at
other points within the call, the contents of the fields in CDRs will reflect the parameters of the call
at that time. For example, the designation of what is source and what is destination may be
reversed and some fields may not be populated.
Note that a CDR may contain both IPv4 and IPv6 addresses. For example, if a call originates in an
IPv4 realm, and terminates in an IPv6 realm, the call-source (field 4) will be an IPv4 address, while
the call-dest (field 6) will be an IPv6 address.

453

Sample CDR
Billing files may be viewed using the cat or more utilities.
The above example shows 4 call records in the billing file named D20120427.CDR.
Each record starts with the date or date and time, in year-month-date-time format.
In this example the filename starts with D, which stands for Daily. As can be seen there are
numerous fields not populated shown by the adjacent semi-colons.

454

CDR Field Descriptions

The cdrdict.xml file which is located in the /usr/local/nextone/bin directory will show a description
of each of the CDR fields.
With Release 8.2, there are 189 fields.
Refer to the release notes for information on updated fields or refer to the SBC Operations Guide
for a complete listing of CDR fields.

455

CDR scripts
There are three main scripts we can use to troubleshoot CDR issues.
The cdr_decode.pl and the cdr.pl scripts are available from the GENBAND FTP server and usually
needs to be manually uploaded to your SBC.
In the training lab these scripts are located in the /var/cdrs directory.

tc - (which is an alias to tail -f /var/cdrs/*CDT): tails the current open CDR file
cdr_decode.pl - decodes the input - used with | (redirect),
cdr.pl - gives statistics on a collection of CDRs, including ASR, tallies of errors and normal calls,
etc.

456

CDR Script tc
This script is an alias of the command tail f /var/cdrs/*CDT
As new records are written to the file they will appear on the screen.
To quit the tc script, use ctrl+c

457

CDR Script cdr_decode.pl

The utility cdr_decode.pl takes the raw CDR file and displays the contents in a readable form. This
allows the administrator to breakdown the CDR to help with troubleshooting.
Note The file may contain many 1000s of call records. It may be beneficial to direct the output to
a file to be viewed later, an example of how this is done is shown below;
cdr_decode.pl D20120308.CDR > /tmp/cdr-decode-D20120308

458

CDR Script cdr.pl

The CDR Script cdr.pl gives statistics on a collection of CDRs, including ASR, tallies of errors and
normal calls, etc.
To utilise the script, navigate to the /var/cdrs directory, confirm the cdr.pl script is available in that
location, then execute the command using;
cdr.pl [filename]

459

460

461

GENView-RSM Reports Introduction

GENView-RSM Reports are available from the GENView-RSM Reports Tab.

462

Report Filter Criteria

When a Report type is selected, filter criteria will be available. The filter criteria varies depending on
the Report type chosen.
Filter criteria available includes;
Source/Destination Reg ID
example; A2-EC-T I,e; the name as defined in RSM Console Database view.

Host/SBC
example; TRN-SBC-82 I,e; SBC/MSX name as listed in Device tab.

Partition
example; Admin

Customer/Customer Service Type

Supplier/Supplier Service Type
Date/Day/Hour/Minute range See next page

463

Time and Date Filtering

To select a date and time, click on the relevant Calendar icon (Begin or End).
In the resulting window, set time value first (hours, minutes and seconds), then click on the desired
date.
The Begin Date time value will default to 00:00 on the date selected unless changed prior to
selecting a date.
The End Date will default to current date and time, but can be changed to generate a range.

464

Filter and Report saving options

The Filter Criteria can be saved using the Filters button.
In the resulting new window, click New and save with appropriate name for use at a later date.
To use a previously saved Filter, click the Filters button, select from the dropdown list, then click
set, then Show.

The Report can be saved using the Save option. Reports can be saved in in one of the following
formats: HTML, XML, CSV, TEXT.
The Report can also be emailed Select Email button and enter email address.
Note For email to work, email settings have to have been configured via the System Tab.
The output shows successful, abandoned and failed calls.
Green - Successful
Yellow - Abandoned
Red Failed

Call detail information is available for each call via the Detail link.
Each line can be further explored by clicking on the Detail link on the right.

465

GENView-RSM Reports - Selection

When launching the GENView-RSM web interface, the Report tab is displayed by default.
Within the Report tab, the Engineering ASR report is the default view.
To select any other Report Type, click the name on the left.
The Engineering Reports include:

Answer Seizure Ratio (ASR). The Answer Seizure Ratio (ASR) reports contain information on
the ratio of successful calls to the total number of outgoing calls. The reports can be grouped
by source or destination IP address, source or destination Reg ID, Region, Supplier, Customer,
Day, Hour, or Minute. The List Calls option under ASR reports lists system ASR calls for a given
day.
Network Efficiency Ratio (NER). NER reports are engineering reports based on the Network
Efficiency Ratio (NER). The NER better represents pure network performance (compared to
ASR) by eliminating user behaviour as a factor.
The reports can be grouped by source or destination IP address, source or destination Reg ID,
region, supplier, customer, day, hour, or minute.

Quality of Service (QoS). Quality of Service (QoS) reports are engineering reports that contain
data on the call quality measurements that are captured in the CDR. The reports can be
grouped by source or destination IP address, source or destination Reg ID, region, supplier,
customer, day, hour, minute, source or destination codec.
466

GENView-RSM Reports Selection continued

Other Reports available are:
Business. These reports can be filtered by origin or destination registration ID or port, or by
customer or supplier name or service type.
Route Profit. The Route Profit reports show billing related information for the time period you
select. This data can be specified based on customer or supplier.
Route Statistic. Route statistics reports show region code, period, and carrier information for
the time period you select.
Custom. GENView-RSM provides a custom reports tool that allows you to work with CDR data
derived from the Engineering report.
Fault. GENView-RSM provides the SBC Outage report that indicates the state of the SBC for the
time period you select.
Performance. Performance reports contain statistics over time that are collected from polled
attributes on the SBC.

467

GENView-RSM Reports Example - ASR Report

ASR Reports are generated based on Source/Destination IP, Source/Destination Reg ID, Region,
Supplier, Customer, Day, Hour and Minute. There is also a List Calls report.
Note The List Calls Report can only be run on a single day basis.
The results of the Report are listed below the Filter Criteria area.

Green icon denotes successful calls

Yellow icon denotes Busy or Abandoned calls
Red icon denotes Failed calls.

468

Types of ASR Reports:

ASR by Source IP

ASR by Source Reg ID

ASR by Destination IP

ASR by Destination Reg ID

ASR by Region

ASR by Supplier

ASR by Customer

ASR by Day

ASR by Hour

ASR by Minute

List Calls

GENView-RSM Reports Example - ASR Report continued

Report Data listing will vary depending on filter criteria and Report Type generated.
Each line of information can be expanded using the Detail link on right side.
Depending on Filter, Report Type and Billing settings, the Detail link may open further lists of data.
Eventually you will be presented with raw data information.

469

GENView-RSM Reports Example - ASR Report continued

CDR Call Detail window Successful Call
A successful Call Detail window will be Green.
Note:
The CDR record includes pre and post digit manipulation information.

470

GENView-RSM Reports Example - ASR Report continued

CDR Call Detail example Abandoned Call

471

GENView-RSM Reports Example - ASR Report continued

CDR Call Detail example Failed Call

472

GENView-RSM Reports Example Network Efficiency Ratio (NER)

NER reports are engineering reports based on the Network Efficiency Ratio (NER). The NER better
represents pure network performance (compared to ASR) by eliminating user behavior as a factor.
You can generate NER reports grouped by the characteristics in the following table. The report
output is initially sorted as described in the table. Subsequently you can re-sort the report data
based a different characteristic
Types of NER Reports
NER by Source IP

NER by Source Reg ID

NER by Destination IP

NER by Destination Reg ID

NER by Region

NER by Supplier

NER by Customer

NER by Day

NER by Hour

NER by Minute

473

Network Efficiency Ratio (NER)

(continued)

474

GENView-RSM Reports QoS Report (R-Factor)

Quality of Service (QoS) reports are engineering reports that contain data on the call quality
measurements that are captured in the CDR.
You can generate QoS reports grouped by the characteristics in the following table. The report
output is initially sorted as described in the table. Subsequently you can re-sort the report data
based a different characteristic
Types of QoS Reports
QoS by Source IP

QoS by Source Reg ID

QoS by Destination IP

QoS by Destination Reg ID

QoS by Region

QoS by Supplier

QoS by Customer

QoS by Day

QoS by Hour

QoS by Minute

QoS by Source Codec

QoS by Destination Codec

475

GENView-RSM Reports Example Business Reports, Revenue/Profit

You can generate business reports grouped by the characteristics listed below.
Types of Business Report

Region by Calls

Region by Minutes

Region by Revenue

Region by Profit

Supplier by Calls

Supplier by Minutes

Supplier by Revenue

Supplier by Profit

Customer by Calls

Customer by Minutes

Customer by Revenue

Customer by Profit

Customer Service Type by Calls

Customer Service Type by Minutes

Customer Service Type by Revenue

Customer Service Type by Profit

Supplier Service Type by Calls

Supplier Service Type by Minutes

Supplier Service Type by Revenue

Supplier Service Type by Profit

Orig REGID by Calls

Orig REGID by Minutes

Orig REGID by Revenue

Orig REGID by Profit

Orig IP by Calls

Orig IP by Minutes

Orig IP by Revenue

Orig IP by Profit

Term REGID by Calls

Term REGID by Minutes

Term REGID by Revenue

Term REGID by Profit

Term IP by Calls

Term IP by Minutes

Term IP by Revenue

Term IP by Profit

476

GENView-RSM Reports Example Route Statistic Report

For the region code you select, the Route Statistics report shows which carriers were used in a given
period and the cost incurred per carrier.
If you configured GENView-RSM for Percentage Based Routing (PBR), the Route Statistics report
shows the percentage of calls distributed to that carrier, by region.

477

GENView-RSM Reports Example Custom Report

The GENView-RSM system provides you with a tool for generating custom reports. The purpose of
custom reports is to provide maximum flexibility in working with CDR data. Most of the elements in
the Custom report are derived from the Engineering report. Custom reports allow you to selectively
group any elements of data. For example, you can group by IP address, ASR, and Total Calls.
See RSM documentation for more information.

478

GENView-RSM Reports Example Fault/Outage Report

The SBC Outage Report returns information on the HA state changes that have occurred in an SBC
HA cluster over a selected period of time. (A cluster is a pair of SBCs in a high-availability
configuration, where one is the active system and the other is the standby.)
Each row in the report records an instance where the state of one of the nodes changed. The SBC
database stores state data as it occurs in the SBC log.
Every five minutes, GENView-RSM reads the SBC database to get state information and stores this
information in the GENView-RSM database. It then reports on this information in the SBC Outage
report.
State information stored in GENView-RSM includes a time stamp when the state information is
updated, SBC identification/name, current SBC state and previous SBC state.
Note:
The SBC Outage report is available only to users who are members of the Admin partition.

479

GENView-RSM Reports Example Performance Report

GENView-RSM polls the SBC devices to collect performance statistics. You can view this
performance data in a report for the SBC cluster you select, over the time period you specify. (A
cluster is a pair of SBC servers in a high-availability configuration where one server is the active
system and the other is the standby.)
Note:
The Performance report is available only to users who are members of the Admin partition.

480

481

Practice
Lab Exercises
1. Generate an ASR by Day report for your allocated SBC, for a complete
working week period on the dates advised by your instructor. The period
should start at midnight on the first date, and finish at 23:59 on the last date.
2. Viewing the resulting output, identify which day had the most calls and click
the Detail link
a) How many calls were;
b) Successful____________ Abandoned___________ Error ________
Busy___________
3. Still using the above results, click on the Successful calls Detail link and then
click the Detail link for the very latest record listed.
a) a. Identify the CDR filename this record came from:
________________________________
b) Which end cleared down first? Source or
Destination?______________________________
c) c. Close Report windows to return to the RSM gui.
4.

Generate an NER by Source IP for this week, from 09:00 Monday until the
current date/time.
a) If available Select the first Error listed and click Detail If no Errors listed
change date/time to look back further until you find one.
b) In resulting list select Detail for Error again.
c) Note the Error name listed on the right, click Detail for one of them and
see where this error text is shown in the CDR.
d) Close Report windows to return to the RSM gui.

5.

Generate a QoS by Destination IP for this week.

a) From the resulting output, identify how many calls? _____ and how many
errors? _____
b) Close Report windows to return to the RSM gui.

482

CDR Detailed View of one record P1

CDR Data Block Lenght : 1392
Cdr version major/minor : 4 / 1
Cdr record type

: 1 / (1=Voice, 2=Audit, 3=AtmPvc, 4=AtmSvc)

Cdr Category type

: 0 / (0=Normal, 1=Usage Sensitive, 2=Time Change)

cdrTotalPage / cdrPage : 1 / 1
Call_ID / smInstance

: 0x4000252 / 594

Orig Incoming Signals

: SETUP, RELEASE, SIPAPM, (2000081)

Orig Outgoing Signals : CALL_PROCEEDING, ALERT, CONNECT, RELCOMP, SIPAPM, EPT_IDLE,

O_T_DISC, (c200011a)
Term Outgoing Signals

: SETUP, RELEASE, (81)

Term Incoming Signals

: CALL_PROCEEDING, ALERT, CONNECT, RELCOMP, (11a)

Orig internal Rel cause : CV_NOTPRESENT (65535)

Orig signal Rel cause/loc : CV_NORMAL_CALL_CLEARING (16) / LOC_USER (0)
Term internal Rel cause : CV_NOTPRESENT (65535)
Term signal Rel cause/loc : CV_NORMAL_CALL_CLEARING (16) / LOC_USER (0)
Time Guard Flag

: TIME_GUARD_DEFAULT (0)

Short CalledParty OffHook : SHORT_CALLED_PARTY_DEFAULT (0)

Long Duration Flag

: LONG_DURATION_DEFAULT (0)

Originate Carrier Time : Wed Oct 29 14:54:26 2014 (390 ms)

Carrier Connect Time

: Wed Oct 29 14:54:26 2014 (657 ms)*

Origination Time
Answer

Time

: Wed Oct 29 14:54:26 2014 (390 ms)

: Wed Oct 29 14:54:37 2014 (135 ms)

Disconnect Party
Orig Disc Time

: DP_ORIG (1)
: Wed Oct 29 15:02:53 2014 (892 ms)

Term Disc Time

: Wed Oct 29 15:02:53 2014 (994 ms)

Long Call Time

: NOT SET

Last Long Call Time

: NOT SET

Short on-hook duration : 0 sec 0 mSec

Ama Slp Receive Time

: NOT SET

483

Calling Party ID
: 17722857863 INTERNATIONAL NPI_ISDN PRES_RSTR_ALLOWED
SCR_NETWORK_PROVIDED
Charge Number

Dialed Number

: 2920262431

Called Party ID
: 2920262431 NATIONAL NPI_ISDN PRES_RSTR_ALLOWED
SCR_NETWORK_PROVIDED
Routing Number
: 2920262431 NATIONAL NPI_ISDN PRES_RSTR_ALLOWED
SCR_NETWORK_PROVIDED
Switch Id Routing
Digit Type

:N
: DT_NATIONAL (4)

Orig physical circuit

line-trunk type / MSF : SIP_TRUNK (1)
span / channel

: 616 / 1

TrunkGroup/CircuitID : 616 / 1
Term physical circuit
line-trunk type / MSF : ISUP (1)
span / channel

:5/6

TrunkGroup/CircuitID : 8999 / 6
Terminate Type Orig/Term : TT_ACCESS (1) / TT_ACCESS (1)
Orig Carrier Network No : 000000
Orig Routing Indicator : TANDEM (1)
Orig Carrier Type / ID : CT_FGD (1) / 0000
Term Carrier Network No : 000000
Term Routing Indicator : DIRECT (0)
Term Carrier Type / ID : CT_FGD (1) /

ANI/CPN Ind Orig / Term : AN_CPN_ONLY (2) / AN_CPN_ONLY (2)

Orig screening class

: 31

Sub Group Orig/Term

:0/0

Sub Group Type Orig/Term : NOT_DEFINED (0) / NOT_DEFINED (0)

InterSwitch Centrex Group : No
AMA test call ind

:0

Ama Translation index

:0

AMA Carrier idx Orig/Term : 1 / 0

AMA Profile idx Orig/Term : 1 / 1

484

Orig Line Info

: OLI_NOTPRESENT (255)

Term Tandem trunk group :

Free-phone number

Service Feature Code

: INVALID (0)

SCP Feature ID

:0

Usage Sensitive Feature : No

Feature State

: FEATURE_NONE (0)

Call Type (toll-free)

:0

Term Carrier Selection : NO_INDICATION (0)

Carrier Service Arrange : 0
O_LATA / T_CountryCode : 0 /
Internal Bearer Cap
UL1_NOTPRESENT

: TC_SPEECH CS_NOTPRESENT TR_NOTPRESENT ITM_NOTPRESENT

Ported Caller / Called : NEITHER (0) / NEITHER (0)

Orig LRN / LRN_source

: / NOT_APPLICABLE (0)

Term LRN / LRN_source

: / NOT_APPLICABLE (0)

LNP Query / Last_Resort : NOT_PRESENT (0) / N

Orig Codec
Organ ID/Type/Rate
Term Codec

: SANTERA / CODEC_TYPE_G_729_CS_ACELP / 2

: N/A

EC Request Status

: no EC error

Orig forward Call Ind : NOT PRESENT

Orig backward Call Ind : NOT PRESENT
Term forward Call Ind

: NI_CALL_NAT E2ENDMTH_NO_METHOD IWIND_NO_INTERWORKING

: E2EINFO_NO_INFO ISUPIND_NOT_USED IPREF_PREFERED_ATW

: ISDNACCIND_NONISDN SCCP_NO_INDICATION TCI_NUM_NOT_TRANSLATED
Term backward Call Ind : NI_CALL_NAT E2ENDMTH_NO_METHOD IWIND_NO_INTERWORKING
: E2EINFO_NO_INFO ISUPIND_NOT_USED IPREF_PREFERED_ATW
: ISDNACCIND_NONISDN SCCP_NO_INDICATION TCI_NUM_NOT_TRANSLATED

485

Outpulsed Digits

: 2920262431

Prefix Digit (NOA)

: NO_PREFIX

Calling Party Ind

: CPI_DELIVER

Orig Country Code

:0

Final Switch ID

:0

Final Trunk Member

: N/A

Complete Code
Route List

: COMCODE_NORM
:0

Called Prefix Digit

: NO_PREFIX

Answer Type

: ANS_HARDWARE

QueuedFlag

:F

Orig Carrier Selection : NO_INDICATION (0)

Final Trunk Group

:0

AccessNode Switch ID

:1

AccessNode Trunk Group : 0

ModemFaxTone Detected

: No

AccessNode Trunk Group : 0

ReOrigination Indicator : REORIG_NO
Orig Echo Canceller

:F

Term Echo Canceller

Access Type

:F
: INVALID

Account Code
Auth Code

:
:

Auth Code Prefix Len

Billing Number

:0
:

AIN Message Mapping

Pin Number

: 0x0

Universal Access Number :

NOA of GAP

486

: NOA_NOTPRESENT

Generic Address Param

Redirection Info

: No

Redirecting Number

Original Called Number :

Last Success Route List : 9001
Release Info Map

:0

Public Telecom Application : 0

Overtime Charge

: False

Meter Pulse Type

: NO_CHARGE

Number Of Pulses

:0

Pulse Interval

:0

Feature Bill Type

:0

Translation Bill Type

Original Call Id

:0
: 0x0

Original Switch Id
Call Mode

:0
: 0 / (0=Voice, 1=Fax Pass-thru, 2=Fax Relay)

T38 Fax Complete

: 0 / (0=No, 1=Yes)

Calling Party Category : 10

Call Reference / ICID

: 0x4000252 / 4194898

**********( Orig VoIP Data )**********

----------( Control Path Data )---------Local Control IP

: 10.92.184.165:5060

Remote Control Public IP

: 10.92.189.74:5060

Remote Control Private IP

: 10.92.189.74:5060

Remote User ID

: 17722857863

487

----------( VoIP RTP Session Data )---------Local RTP IP

Remote RTP IP

: 10.92.184.209:32538
: 10.92.157.149:35092

Session Start Time

: Wed Oct 29 14:54:26 2014 (65537 ms)

----------( VoIP RTP Sender Data )---------Tx RTP Packet Hi

:0

Tx RTP Packet Lo

: 25338

Tx RTP Octets Hi

:0

Tx RTP Octets Lo

: 506760

----------( VoIP RTP Receiver Data )---------Rx RTP Packet Hi

:0

Rx RTP Packet Lo

: 25268

Rx RTP Octets Hi

:0

Rx RTP Octets Lo

: 505360

Rx Packet Lost Hi

:0

Rx Packet Lost Lo

: 51

----------( VoIP QoS Metric Data )---------Remote RTCP IP

: 10.92.157.149:35093

Tx Payload Type

: 11, 0, 0, 0

Tx Packet Lost Hi

:0

Tx Packet Lost Lo

:1

Tx Jitter Max

:0

Tx Jitter Mean

:0

Rx Jitter Max

: 32

Rx Jitter Mean
Round Trip Max

: 24
: 74

Round Trip Mean

:0

IP to IP Switch Count

:0

RLM Transcoding Count

488

:0

----------( VoIP Grade Of Service Result )---------Grade of Service

:4

Tx Packet Lost Rate

: %0.00

Rx Packet Lost Rate

: %0.20

----------( End Of VoIP Data Printing )---------Orig VSM Information

VSM Circuit ID: MSF/Slot/Group/Chip/Chan: 1, 1, 1, 1, 68
Slot Id

:1

Codec Group Id / Vs Codec Type

: 1 / 11

Codec Id In Group / Codec Chan Id : 1 / 68

Sar Group Id / Sar Chan Id

: 15 / 255

EC Group Id / EC Chan Id

: 1 / 68

EC Id In Group

:1

TdmDs0 / Rtp Codec Type

CV Diag Data

: 4445 / 0
:

Two B Channel/SIP Call Transfer Information

Call Transfer Call Id

: 0x0

Call Transfer Time

: NOT SET

Presentation Number: 17722857863

Generic Number: 17722857863

489

490

491

492

493

494

495

496

497

SNMP Basics
You must first configure the SNMP agent to monitor the health of the SBC. By means
of SNMP GETS for collecting statistics and traps for collecting events, SNMP lets an
NMS (Network Management System) like the RSM monitor one or more SBC's
remotely by using SNMP-compliant or other management software to receive traps.
Traps are SNMP notifications, sent over the network to specific NMS hosts, when
events occur. The configured SNMP agent generates traps for SBC events like disk
space warnings and authentication failures. The agent also performs GENBAND
proprietary MIB notifications.
The SBC SNMP support uses SNMPv3 security for authentication and authorization.
You must configure correct authentication details (user, password, encryption
method, etc.) in both the SBC and the NMS that will receive traps from the SBC.
If SNMPv3 security is not required, you can configure the SBC SNMP agent to use the
SNMPv2c security model.
Note: Trap messages are sent through the SBC's Ethernet management interface.

498

499

500

501

502

503

504

Configuring SNMP Service: Agent Management

The agent IP address should be the same address that you assigned to the SBC
management interface.
Specify the agent IP address in one of the following three ways:
If you have already assigned the SBC management interface IP address (the
global mgmt_ip attribute in servercfg). Press <enter> to keep the current agent
IP address.
If you previously assigned an agent IP address by running nexsnmp-config, you
will receive a prompt indicating that the agent IP has already been configured,
but you can change it if necessary.
If you have not previously configured the management interface IP address in
servercfg, you will see a prompt indicating that the Agent IP is not configured.
Enter the agent IP address after the SNMP Agent IP prompt
After specifying the agent IP address, a 64-bit hexadecimal engineID is computed,
based on the local host MAC address, plus a 4-bit random number
You will need this computed engineID when creating the user account on the
remote NMS

505

Heartbeat Management
The heartbeat monitor allows you to set up how often, in seconds to monitor the
heartbeat of the SBCs. Note: The heartbeat message sent by the SNMP agent is
Heartbeat.
Threshold Management
The Threshold Management Menu allows you to monitor the Ethernet Links, Free
Disk Space, Memory Usage and Idle CPU.
Things you should know about Threshold Management:
A trap is not sent after every check, even if a link remains down. Rather, a
new trap is sent only when any of the links changes status, either up or
down
Multiple thresholds can be defined for one partition
Traps are triggered when monitoring shows that a threshold has been
exceeded since the previous check. If memory usage continues to exceed
the threshold, traps are not resent after each check. Rather, another trap is
sent when monitoring shows that memory usage falls below the threshold
and then exceeds the configured threshold again
A trap is not sent after every check, even if a link remains down. Rather, a
new trap is sent only when any of the links changes status, either up or
down

506

Login Management
Login Management monitors SSH login attempts and report when an invalid login is
attempted. The trap information will identify the address of the machine from which
the invalid login was attempted and will include whether what was entered was an
invalid username or an invalid password.

507

508

509

510

511

512

GENView-RSM Events Example

Follow the above sequence to open an Event Details window.
The fields in an Event Detail window are as describe in the table in the following page.

513

Field

Description

Event Type

The type of event: CDR, Polled Stats, log, SNMP incident, or system.

Event Sub Type

The specific type of alarm within the specified category, for example, ASR
(CDR alarm type) or Audit (Log alarm type).

Status

The severity of the event: Critical, Major, Minor, Warning, Info, Clear.

Failure Object
Type

The type of object that was responsible for generating the event

Failure Object

Identifier or name of the object that was responsible for generating the
event.

Host

Name of the cluster that was specified for the SBC.

Device IP

IPv4 or IPv6 address of the SBC that generated the event.

Category

Identifies the category to which the event belongs: GENView-RSM uses the
category to correlate events into alarms. There will be only one alarm for
multiple events for the same failure object and category.

Date and Time

The GENView-RSM server time at which the event is generated.

Message

Descriptive text message about what actually occurred.

Description

Description of the configured threshold condition.

Partition ID

The numeric identifier assigned to the partition that generated the alarm.

Device Trap OID

If applicable, the trap OID of the associated trap sent from the SBC.

514

GENView-RSM Events Filtering

To create an event filter:
1. In the Filter Name field, enter a name to identify this set of filter criteria.
2. Under Filter options, specify selection criteria.
3. Use the plus icon (+) within the filter options fields to define subsets of filter criteria. A
subset is a group of filter criteria joined by an AND operator. An event must meet the criteria
in both subsets to be selected.
4. Use the plus icon (+) outside of the filter options fields to join subsets with an OR. An event
must meet the criteria in one of the subsets to be selected. If two subsets are joined with an
AND followed by a subset joined with an OR, the event must meet the criteria in the first two
subsets or the criteria in the third subset to be selected.
5. Use the X icon inside of the filter options fields to delete a subset joined with an AND.
6. Use the X icon outside of the filter options fields to delete subsets joined with an OR.

515

7. To add sorting criteria to the filter, click the + icon in the Sorting order field. From
the drop-down list, select the column you want to sort on. Specify whether you want
to sort in Ascending or Descending order. You can specify multiple sorting criteria.
8. Click Delete to delete the selected filter.
9. Click Save to save filter criteria to the database using the name you specify.

10. Click the Set as Default checkbox to make this filter the default. Every time you
open the Events page, the default filter will be applied. The Events page will list just
those events that meet the criteria in the default filter.
11. Click Show to refresh the Events page using the criteria from the filter you select.
12. Click Reset to clear the value in the last field you edited.
13. Click Cancel to cancel the current filter configuration options and return to normal
display mode.

516

517

518

GENView-RSM Actions Configuration

The Actions screen is available from the Alarm Tab / Configuration / Actions.
Click Add to create a new Action
Select the action from the drop-down list.
The fields will change depending on the Action selected.
Select Partition

Give the Action a name This name will be seen later when configuring Alarms. It would be
beneficial if the name specifically identifies the Action.

519

GENView-RSM Actions Configuration examples

Actions available include;
Block/Unblock Endpoints
Set/Move/Restore route Priority
Execute a script
Create a Log in the Syslog or another file

Set/Change/Restore Route Percentage

Send SNMP trap to external device

520

521

522

523

524

525

526

GENView-RSM Alarm Tab example- Fields on the Alarm Page

Field

Description

Date and Time

The GENView-RSM server time at which the alarm is generated.

Type

The type of alarm: CDR, Polled Stats, log, SNMP incident, or system.

Severity

The severity level of the event: Critical, Major, Minor, Warning, and Clear.

Host

Name of the SBC cluster or the SBC which generated the event.

MSX IP

IP address of the the SBC that generated the event.

Failure Object
Type

The type of object that was responsible for generating the alarm.

Failure Object

Identifier of the object that was responsible for generating the alarm.

Message

Descriptive text message about what actually occurred.

Description

Brief description of the condition including the Alarm Message you specified in
the alarm configuration.

Clear

Indicates whether a clear event should be generated for this alarm.

Ack/Unack

Indicates whether this alarm has been acknowledged.

Owner

Indicates the user who acknowledged the alarm.

527

528

529

530

531

GENView-RSM Alarm Configuration example CDR Alarms

You can use GENView-RSMs CDR alarms to help you monitor the SBCs call traffic patterns
and call quality statistics. By analyzing the CDRs it receives from the SBC, GENView-RSM
determines the SBC call statistics such as average call duration (ACD) or average post-dial
delay (APDD).
Using CDR alarms you can define certain conditions about which you want to be alerted
when GENView-RSM detects them within the CDR statistics. In a CDR alarm you define a
triggering condition that can be detected through CDR analysis, such as detecting when
packet delay variance (PDV) is greater than some value. You then specify one or more
threshold values, in relation to the triggering condition, and associate each with an alarm
severity level (Warning, Minor, Major, Critical). You also have the option to define one or
more actions you want GENView-RSM to execute when that condition occurs. You can
specify different conditions for each severity level.

The GENView-RSM checks for the configured alarm thresholds in order from Critical
severity to Warning. When it detects that a threshold has been crossed, GENView-RSM
triggers an alarm and assigns it the severity of the highest level exceeded (most severe)
and executes the corresponding action. If no thresholds are crossed the GENView-RSM
continues to regularly check for the condition.
Once an alarm has been triggered, the GENView-RSM continues to monitor the condition,
changing the severity level of the alarm when appropriate, and executing the associated
action when changing to a new level. Once the monitored value falls within the Clear
range, the GENView-RSM clears the alarm and executes the Clear action.

532

GENView-RSM Alarm Configuration example Polled Stat Alarms

GENView-RSM can be configured to regularly poll the SBC for specific types of data. Using the
SNMP protocol, GENView-RSM can gather a wide range of health and performance-related
information on the SBC through regular polling. GENView-RSM can also monitor call volume or
vport usage through polling the SBC database. Polling must be enabled for the attributes you
want to monitor.
For attributes for which you have enabled polling, you can create a Polled Stats alarm to tell
GENView-RSM to check the polled attribute against threshold rules you define. When the polled
attribute meets the condition in a threshold rule, GENView-RSM generates a Polled Stats event
which in turn triggers the Polled Stats alarm. Within the Polled Stats alarm you also define the
severity level you want to assign to ranges of values for the polled attribute and what action
you want GENView-RSM to perform when those different severity levels are reached.
When creating Polled Stats alarms to monitor call volumes, you can select the specific
endpoints or iEdge groups you want to monitor, and you can specify thresholds for ingress,
egress, or total calls. When monitoring the level of vport or media vport usage, GENView-RSM
monitors the SBC as a whole and takes into account the vport limits allowed within the SBC
license.
In the alarms you create, call volume and vport usage threshold values can be expressed as
percentages or as actual number of calls or vports.

533

GENView-RSM Alarm Configuration example Log Alarms

The log alarms allow you to monitor the iserver.log by specifying a string that you want
GENView-RSM to search for within the log. GENView-RSM monitors the iserver.log file for the
string you specify and generates events when the designated string occurs. Log events are
correlated into alarms based on the category of the eventthat is, for all events with the same
failure object and category, one alarm is generated. Every time GENView-RSM generates a log
event, it also executes the action defined for the alarm. Log alarms can be viewed,
enabled/disabled, added, updated, and deleted using the Log menu option under Alarm >
Configuration > Incident.
NOTE: Currently, GENView-RSM supports a maximum of 200 active alarms. Having more then
this number could affect performance and eventually cause the database server to run out of
connections.

534

GENView-RSM Alarm Configuration example SNMP Alarms

The SBC sends SNMP traps to GENView-RSM. GENView-RSM processes the traps, converts them
into events, and then correlates the events into alarms.
These alarms alert the user that some incident has occurred on the SBC.
The set of SNMP traps sent from the SBC to GENView-RSM is described in the SBC and
GENView-RSM Operations Guides.
For those traps that have a severity that is other than Info (informational), you can configure
SNMP Incident alarms to specify what action or actions GENView-RSM should take when it
receives an SNMP trap from the SBC.
You specify these actions by configuring SNMP Incident alarms for the different types of SNMP
traps that the SBC can send.
You can view any already configured SNMP incident alarms and add new SNMP incident alarms
using the Configuration option on the Alarm tab.

535

Working with GENView-RSM System Alarms

You can define the following types of system alarms:
AuditAlarm based on audit trail entries.
Bad CDRAlarm based on the presence of bad CDRs.
CDR Alarm Failed to Run on TimeAlarm based on whether the CDR alarms run on time.
Threshold Alarm Failed to Run on TimeAlarm based on whether the processes that lead to
threshold monitoring (Polled Stats) alarms run on time.
CDR Disk Usage AlarmAlarm based on CDR MySQL database space usage.
Monitor CDR StreamingAlarm based on CDR streaming.
DB SYNC AlarmAlarm based on database synchronization between the SBC and GENViewRSM.
Failed Alarm ActionAlarm based on whether an alarm failed to execute its action.
Alarm Initialization FailedAlarm based on whether an alarm fails to initialize at the time
GENView-RSM starts.
Device RSM CommunicationAlarm based on whether the communication channel is up
between GENView-RSM and the devices (SBCs) configured on it.
For more information see the SBC & GENView-RSM Operations Guides.

536

Practice
Lab Exercises
1.

Log into the RSM Web GUI. Go to the Alarm Tab and select
Configuration/Action. Click Add.

2.

Add an email Action, named as your team/name number to go to your

email address, with appropriate Subject.

3.

Select Alarm Type of High Packet Loss. Give the CDR Alarm a name
based on your student/team number and select the SBC you have been
working on.

4.

Create an Alarm by going to Alarm Tab, Configuration/CDR and clicking

Add.

5.

Select the Alarm Type and Partition of your choice, use your student/team
number as a basis for the name, select the appropriate SBC.

6.

Depending on the Alarm Type, data fill the Min CDR, Duration values.

7.

Enter a value for the Severity of Critical and select your Action. Add a
description then click Submit. Confirm the CDR Alarm is listed on the
resulting screen.

537

538

539

G9 Events and Alarms

Events occur within the system as a result of milestones or threshold being reached. However,
not all events will result in a system alarm occurring. Some events are simply a result of a
successful operation occurring, (i.e. login into EMS GUI, or successful transfer of billing records).
If an event is designated to result in a system alarm then there will be a counter event that
clears the alarm.
All events result in an SNMP trap being generated. Some events are defined as critical, major,
minor or informational.
Certain events are configured as Alarms and appear on the Alarms tab.
View/alarms on-off mapping show those Events that produce Alarms and the Event that
would turn the alarm off.

540

Events Date Format Options

The user has the capability to select the format options by which the date appears in the EMS
GUI. You do this by right-clicking anywhere on the Alarm screen and then choosing the Events
Date Format Options.
An option box will appear that offers a preselected choice of date options.

541

Events
On the events screen, you can freeze the screen so that no new events will appear as you are
viewing. This is helpful when you are analyzing a particular event because as events occur they
will be updated to the screen and it is therefore constantly changing. Freezing the screen will
prevent the screen from updating as you are looking at it .
When you freeze the screen the Events tab will change to red, indicating that the screen is
frozen.

542

Request Active Alarms

GenView EMS allows the user to initiate an update request to all sub-systems for posted alarm
messages through the Request Active Alarms command.
This ability enables the user to ensure that stale alarms that are not valid are removed from the
alarm display panel. The steps to perform are:
Freeze current Alarm Display
Clear All Alarms
(Note: This will empty the alarm screen)
Request Active Alarms

543

Events/Alarm Detail Dialog

Event and Alarm details are presented by double-clicking on the desired entry. The details
screen will provide:
Throttle threshold
Description of the event/alarm
Probable Cause of the event/alarm

Corrective action to clear event/alarm

Clear type code for clearing the event/alarm
The user may acknowledge the event/alarm by clicking the Ack button located at the bottom of
the screen. The user may also add comments regarding the event/ alarm as part of the
acknowledge function. Once an alarm is acknowledged, the Alarms display changes the Ack
column to Yes.
The severity levels of alarms are:
Critical
Major

Minor
Warning
Informational

544

Event Definition
The Event Definition tab provides a complete listing of all the events that the can be generated,
along with the event severity level, category, recommended severity level default.
Event Definition Details lets a user select whether the NOC is alerted to the event.

545

Filters and Queries

A user has the ability to create filters and queries to specify the criteria for events/ alarms you
want to retrieve.
At the Filters and Query tab screen, click Add Row..

546

Applying the Alarm Filter

When the event/alarm filter is applied, you will have visibility to the events/alarms that meet the
established criteria.
After you have viewed the filtered alarms, return to the Filters and Alarms tab and Disable Alarm
Filter.

547

Query History
The user has the ability to query event/alarm history in the G9. To do this, the Current Data field
must be unchecked on the Filters and Query screen.

548

Event History Results

Results will be based upon any filters that are set

549

550

551

System Security
System Administrators (users) are configured on the G9 using the Security functions in the FCAPS
Management Access area or via the Go drop down box.
To add a user, you must add a user group or add a user to an existing user group. The user will
have the access rights and privileges that are set for the user group.

552

User Profile
The User Profile provides specific information pertaining to that unique User ID. An
Administrator that creates the User ID will define:
User ID
Group ID
Status

Password
Optionality the Administrator can define
An Inactivity Logout after a specified time of inactivity
Provide Contact Information

553

Security Log Query

The user has the ability to query for a variety of functions that occur on the G9 via the Security
Log Query.

554

Security Policy - System Parameters

Define if Passwords will expire, and the number of days.
The No Trespassing banner shown in the slide below is system wide. Every time a user logs in
they will see this banner.

555

Security Policy Security Log

Provides the amount of time to retain Security logs, also enables you to determine exactly what
information to collect in Security Logs.

556

557

Performance Management
The system administrator can query performance data from the Query tab using any
combination of the following parameters:
Resource type
Date (uncheck On Demand for access to enter dates)
ID information (MG Node, Slot Number, etc.)

The selections the user makes in the Resource Type field determines the fields that display on
the Query tab. There are two types of data that can be provided with the query
Current Data
Historical Data
The query type the user selects determines the mandatory fields for running a query. The ID
section indicates whether the ID fields are mandatory or optional.
When the system administrator selects On Demand, the date and time fields are grayed-out
and provides current data.
When the system administrator deselects On Demand as the query type, the date and time fields
are active and the ID fields become optional. This provides historical data. The Resource Type
must have Monitor Performance set to Yes before Performance Stats are available in the
Performance option/area.

558

Query Results
After a Query has been requested, the window changes to the Query Results tab that provides a
display of all the results from the query.

559

Performance Control
The system administrator uses the Control tab to specify performance data collection controls
for system resources, such as how often the system collects performance data and how long the
data is retained.

560

Performance Stats Distribution

The system administrator uses the Performance Config Parameters tab to specify the system
parameters for distributing system performance information, such as the remote directory
name, host IP address, and port.

561

562

Check your knowledge

After completing this exercise, the student will have the ability to create an Event filter to locate
specific events.
1. Select the Fault option from the Toolbar area of the EMS GUI.
2. Click on Filters and Query.
3. Look at the list of USERIDs defined :
If your USERID exists, highlight and click Modify Row and configure as shown in Step 4.
If your USERID does not exist, click Add Row and configure as shown in Step 4.

4. Create an Event filter based on the following parameters:

Under Severity, check INFO, uncheck all other values.
Under Category , check APP, uncheck all other values.
Leave the remaining entries at the default values.

5. Click Apply
6. Click OK
7. Click Apply Event Filter
8. What Event(s) has been filtered from all of the other Events?
_________________________________________________________
9. Click Disable Event Filter

563

564

565

566

567

For information about other courses offered by GENBAND, contact

your training coordinator or visit:
http://www.GENBAND.com

568