CM CMM Support 5u00060k Day 01

Student Workshop Guide
This content is copyrighted and made available only to individuals enrolled in authorized Avaya Learning training.
These materials are intended for your personal use and may not be duplicated or distributed.
Page 15
2014 Avaya Inc. All Rights Reserved.
Ever since version 6.0, Communication Manager has been a Virtual Machine, whether on
System Platform with
XEN Hypervisor or vmwares ESXi, CM uses certain interfaces for its operation, this LO
highlights the differences
and particularities of each deployment and how lo look up within the boundaries of flexibility
allowed by the product
when supporting it.
In this learning object you will learn how:
CM interacts with the two platforms it is available upon in version 6.3 FP3.
Page 16
Please use this information as a resource for this learning object.

It is recommended that you save this resource document to your PC for reference as you go
though this course.
Page 17
Communication Manager has, most of the time, been an Application Server working on Linux
operating system across versions.
CM, as a flexible & well crafted application, has been transparently migrated from server to
server as they have evolved over the years
Ever since version 6.0, CM was migrated to a new very special kind of Server: a Virtual
Machine, there being a good variety of Virtualization Platforms in the market, Avaya selected a
very efficient and widely known open-source platform known as XEN-Hypervisor which is part
of certain distributions of the Open-source Linux Operating System.
Avaya developed a product called System Platform based on XEN-Hypervisor, being this, the
foundation for Communication Manager 6.0 & onwards. In System Platform, CM is installed as
a Template, a file which comprehends the Installation image and all the information that
specifies the Virtual Machine hosting CM.
However, not all customers think the same, for a good few years, VM Ware ESXi Xypervisor,
another Virtualization Platform has been successfully around, becoming a de facto standard, for
those customers, Avaya has come up, in Version six dot three Feature Pack three, with a
template to install CM over ESXi Hypervisor called Virtual Appliance or V appliance.
Both CM versions, for System Platform and the v appliance for Vmware ESXi, are virtual
machines.
Page 18
The Linux Operating System which hosts CM, allocates as many Network Interface Cards as it
finds available, the responsible for the number of interfaces allocated for CM, as well as Hard
Disk space, Memory space, number of CPUs, etcetera, is the CM template itself.
CM template books only two NICs from the whole physical server, Ethernet zero and Ethernet
one.
By default, NIC one corresponds to Ethernet zero in System Platform as well as in CMs Linux,
whereas NIC four, matches Ethernet three in System Platform but Ethernet one in CM as
displayed on the table.
Page 19
In the most complex case, CM Duplex servers, CM works as a cluster making up one logical
server out of two physical, therefor, each CM server needs a link to its Duplicated server called
Duplication Link.
By default, CM uses Ethernet zero for Administration, Control of IPSI Boards at G650s,
Processor Ethernet, and CMM in case of Simplex & Embedded servers, and Ethernet one for
Duplication Link when applicable, but this is interchangeable, as you can see on the
screenshot of CM SMI, for very particular cases.
But those ethernet zero and ethernet belong to CM, not System Platform, so you better be
careful when supporting a CM Duplex Server and bear in mind the Interface mapping shown in
the previous slide not to go wrong.
Page 20
For Vmware ESXi deployments, bare in mind that CM will ignore its a Virtual Machine and
behave exactly the same as it does over System Platform, the .ova template for ESXi defines
how many interfaces CM Virtual Machine will have available out of which, CM by default
assigns ethernet zero for Corporate Lan and ethernet one for duplication when available.
Make sure when administering ESXi that the interfaces which connect both ethernet one
duplication link interfaces are linked up by a flat, layer two network they can resolve each
others ip address at, just by broadcasting ARP messages, in simpler words, a virtual crossover cable must connect Duplication Ports on both servers.
As to the Customer Lan, that also relies on the specific ESXi configuration used for every case,
just make sure the NIC interface selected for CM ehternet zero is not shared by other virtual
machines in a way that overloads the interface causing traffic congestion and the consequent
detrimental effect in CMs performance.
Talk to your network administrator for more details.
Page 21
In this lesson, you learned how:

How the CM interacts with the two platforms it is available upon in version 6.3 FP3 including:
CM High-Level Structure
CM Interfaces for System Platform deployments
CM Interfaces for V-Appliance deployments
Page 22
Page 23
This learning object will show how Communication Manager is integrated by processes,
the Core & the Platform processes, their differences and the purpose & interaction of some
of the most relevant ones.
In this learning object you will learn:
The internal architecture of Communication Manager 6.3 SP3 by exploring some of its most
relevant processes which are frequently made reference to, in logs & other CM outputs..
Page 24
24
Communication Manager, as a Communication Server, is a complex application that consists in

multiple processes interacting with each other.
Every process performs specific functions & tasks.
CM is a mature & stable software in continuous improvement, the majority of its processes
have been carried out from previous versions.
This Learning Object is not intended to enable the audience to perform any specific actions on
the processes directly, but to help understanding some terminology and tags across the various
logs in CM.
Page 25
There are two type of processes.

Oryx Pecos Processes were inherited from the Definity, the predecessor of CM, the Oryx
Pecos name comes after the original Operating System the Definity was based on.
Platform Processes were incorporated into CM from the very beginning of the
Communication manager era, to interface Oryx Pecos processes with the Linux Operating
System.
Page 26
Dont be scared by this graphic, its easier than it looks, lets break it down in pieces to make it
more understandable.
Page 27
The call processing core of CM is the capro process.

Call processing is normally originated or terminated whether at an endpoint or a trunk, which, in
both cases hang from a circuit pack controlled by an IPSI board or a media gateway, controlled
by, wheter a CLAN board, or processor ethernet, so PCD and GIP allow communication for
control & signalling between capro and endpoints, whichever type they are.
PCD process interfaces between capro and the IPSI boards.
GIP arranges links through connection sockets between CM & external entities via CLAN or
processor ethernet gatekeeper interfaces.
PAM writes every command performed in SAT into the logfile.
Page 28
PRC_MGR or process manager creates & kills Oryx/Pecos processes as needed and orders
HMM to dispatch maintenance actions.
HMM receives inputs from various processes and eventually dispatches maintenance
processes such as initmap and fastmap.
Fastmap is responsible for IPSI interchanges when so ordered by the HMM.
Initmap watches over Oryx/Pecos processes only and start or stop them when necessary, its
always dispatched by HMM
GMM is in charge of collecting inputs from other processes and reporting alarms from CM and
the platform, all together.
Watchdog does the same as initmap but I watches over all processes including ndm, arbiter,
GMM and ndm
Page 29
Arbiter decides and orders a server interchange when CM is working in Duplex mode
Ndm handles the shadowing job which consists in synchronizing database files with the Duplex
server.
Border is the interface between Oryx/Pecos and platform processes.
Page 30
Take your time and review the core processes and their description, the CM core processes are
not listed one by one but as a whole thing, please note that CommunicaMgr encloses multiple
processes and their status.
All processes are associated with a priority, the higher the priority, the more important the
process is.
Page 31
Unlike Oryx/Pecos or core processes, the platform processes are listed individually, the most
relevant and their priorities are displayed in this table, take a thorough look at it.
Page 32

The internal architecture of Communication Manager 6.3 SP3 by exploring some of its most
relevant processes which are frequently made reference to, in logs & other CM outputs.
Page 33
Page 34
This learning object will show a high level view of Locations in CM and in which cases the
Locations feature is applicable.
CM has the ability to break down its endpoints & resources into multiple Locations to match
local conditions in large deployments.
Page 35
35

though this course.
Page 36
CM capacities along with its distributed architecture allow very large scale deployments.
Its not rare to find a CM with branch gateways & endpoints in different countries regardless of
where the CM server is located at.
There can be different dialling rules, companding laws, Tones loss-plan, analog line parameters,
etc. per country, or even within the same country.
Page 37
Its understandable that a user of a CM endpoint in Spain hanging from a CM Server in the US,
wouldnt want to hear a US typical dial tone.
Perhaps another subscriber in Germany dials out a local number that has a different length
from other regions within that country.
CM has Locations to customize service and meet specific local conditions across the globe.
Page 38
Locations can be applied to endpoints, agents or groups of endpoints, whether they are
hanging from a Media Gateway or a Cabinet in a Port Network.
Analogue & digital endpoints adopt the same Location as the Media Gateway or Port Network
they are connected to whereas IP, whether H.323 or SIP endpoints must be put in a Location
individually.
Call Processing Features can be applied to each Locations separately to customize the Call
Routing process locally.
Some Standard & Special Features can also be configured differently across Locations as you
can see on this slide.
Take your time and a quick look at these Location enabled features.
Page 39
There are three specific features for Location Management; Locations, Location Parameters &
Display Parameters, these features let the administrator add & manage Locations as long as
Multi-Locations is enabled in the License.
Only the four Applications, displayed on this page, plus Call Detail Recording are the special
features supported to be configured on a per location basis.
Page 40

CM has the ability to break down its endpoints and resources into multiple locations to match
local conditions in large deployments.
Page 41
Page 42
This learning object will show a brief Overview of the IMS Standard Architecture SIP Protocol is
based on, mapping how CM works according to IMS in the Session Manager-CM Integration.
In this learning object you will learn how to:
Interpret the IMS SIP Architecture applied to CM and the real differences between Feature
Server & Evolution Server and how to fit them in SIP Application Sequence.
Page 43
43
IMS stands for IP Multimedia Subsystem

IMS is a very wide and comprehensive architecture which defines a common control layer
which links Multimedia Applications with any know kind of Transport Network.
IMS target is the full convergence of Wired, Private and Public Wireless Networks in any kind or
form into a real cloud to make Multimedia Applications available to any user, anywhere, any
time and from any Communication Device.
At the Application layer of IMS, there is a well defined Mechanism to integrate Endpoints and
Application Servers through a SIP Soft Switch.
Session Initiation Protocol or SIP is a communication protocol which core purpose is to setup
sessions between Endpoints and/or Application Servers regardless of the content of those
sessions, that makes it flexible enough to start sessions of any kind of media, like voice, video,
text, telemetry, tele-control, etc.
Page 44
Session Manager is a SIP Application Server that, among other tasks, performs as a SoftSwitch.
Communication Manager has been developed an Internal SIP Engine which established SIP
Trunks with other entities, including Session Manager, but Communication Manager cannot
accept a registration from a SIP Phone directly.
For an Avaya SIP Phone to acquire Features from Communication Manager, is necessary to
integrate Communication Manager as an Application Server hanging from Session Manager,
then configure an Application Sequence that includes Communication Manager in it.
Page 45
A basic Phone Call has two participants, the Caller and the Callee.
A Caller can be allowed or denied to make the intended call or it can be simply diverted
somewhere else, the Feature or Application Server is responsible for that decision. This
process is known as the ORIGINATING PHASE.
A Callee can be put the call through or stopped from receiving the call or the call may be
diverted somewhere else, also the Feature or Application Server is responsible for that
decision. This process is known as the TERMINATING PHASE.
Page 46
By SIP standard, Originating & Terminating Phases can be performed in separate Application
Servers if so wished, or can also be performed by the same Application Server in two separate
transactions. This mechanism, defined in the IMS Standard is called HALF-CALL MODEL.
The majority of Telephony Platforms like Communication Manager process intrinsically both,
Originating & Terminating Phases in one single Transaction, being this modality called FULLCALL Model.
The SIP Engine in Communication Manager speaks strictly Half-Call Model towards the Outside
World entities, such as Session Manager, but it can handle whether Full or Half Call Model
towards the Communication Managers Internal Call Processing Core also known as CAPRO .
Page 47
Half Call Model, the native mechanism for SIP call processing in IMS, processes the call in two
separate phases, originating & terminating phases.
When the caller dials in, Session Manager looks up for the callers profile, if there is an
application sequence for the caller, Session Manager re-composes the SIP signalling message,
inserting all application in the sequence into the body of the new message as stops along the
route.
If Communication Manager is one or the only Application in the sequence, the signalling
message is sent to Communication Manager to apply features on it.
Communication Manager receives and recognizes it as a SIP message being consequently
passed through the SIP engine.
Communication Manager has been configured in Feature Server Mode which makes it behave
in Half Call Model mode all the way. The Communication Manager internal SIP engine analyses
the Originating part of the SIP message and ignores the Terminating part of it to be processed
further down the call setup process.
Next, the Communication Manager SIP Engine hands off the message to the CAPRO the
Communication Manager Internal Call Processing core which is only ordered to process the
Originating part of the SIP message.
CAPRO returns the SIP message to the SIP Engine which subsequently sends it back to
Session Manager.
Page 48
Session Manager which can only process in Half Call model mode, looks up it there is
some sequence of Applications to be enforced this time for the Callee, if so, the SIP
message is sent once again to Communication Manager for Terminating Phase
Processing.
The Communication Manager SIP Engine hands off the SIP message to CAPRO ,
ordering the Terminating Call Processing related only to the Callee, and ignoring the
Originating part of the SIP message.
The SIP message is returned to the SIP Engine and sent back to Session Manager
who connects or denies the call according to what Communication Manager orders to
do as far as the callee is concerned.
We can summarize this whole process by saying that, in Half-Call Model or
Communication Manager Feature Server, there are two main transactions between
Session Manager and Communication Manager and two transations between the SIP
Engine and CAPRO inside Communication Manager per call.
The call might or might not proceed according to what Communication Manager has
to say about the caller and the callee being both Communication Manager SIP
endpoints.
Page 49
The IMS field at a SIP signalling group is the only configuration in CM that toggles between
Feature Server & Evolution Server.
Page 50
Full Call Model, the typical Call Processing mechanism for Telephony Switches, processes the
whole call including both phases, originating & terminating phases in a single transaction within
Communication Manager in Evolution Server mode, in other words, when the SIP trunks in
Communication Manager have the IMS mode is disabled.
The process for Full Call Model is the same from the Session Manager Point of view.
Same as in Half Call Model, when the caller dials in, Session Manager looks up for the callers
profile, if there is an application sequence for the caller, Session Manager re-composes the SIP
signalling message, inserting all application in the sequence into the body of the new message
as stops along the route.
If Communication Manager is one or the only Application in the sequence, the signalling
message is sent to Communication Manager to apply features on it.
The differences begin from this point onwards.
Communication Manager receives and recognizes it as a SIP message being consequently
passed through the SIP engine which has been configured in Feature Server Mode or Full Call
Model. The Communication Manager internal SIP engine analyses the Originating and
Terminating parts of the SIP message and orders CAPRO to perform Call Processing for both,
the caller and the callee.
CAPRO returns the SIP message to the SIP Engine which memorizes the call ID to be ready
for bypassing the Termination Phase Message. SIP Engine and sends it back to Session
Page 51
Manager with the respective processing for both phases of the call.
Session Manager which can only process in Half Call model mode, looks up it there is
some sequence of Applications to be enforced this time for the Callee, if so, the SIP
message is sent once again to Communication Manager for Terminating Phase
Processing.
The Communication Manager SIP Engine has kept track of the call and performs a
shortcut which consists in returning the message back to Session Manager without
even bothering to send it off to CAPRO since the Terminating Phase of the call has
already been worked out during the first transation.
As a summary, in Full-Call Model or Communication Manager Evolution Server, there
are two main transactions between Session Manager and Communication Manager
but only one transation between the SIP Engine and CAPRO inside Communication
Manager per call.
Page 52
The IMS field enabled in SIP Signalling Groups turns CM into Evolution Server.
Page 53
Communication Manager Evolution Server supports all types of Avaya endpoints, it works
inside in Full Call Model.
When Communication Manager Evolution Server is included in an Application Sequence, for
the Shortcut, it must be the borderline between Originating and Terminating Phases, Last in
Originating First in Terminating.
Communication Manager Feature Server supports only Avaya SIP Endpoints, it works in Half
Call Model.
When it participates in an Application Sequence, it can be put anywhere in that sequence, as
long as there is no conflict with the other applications.
Page 54
In this lesson, you learned how to:

Interpret the IMS SIP Architecture applied to CM and the real differences between Feature
Server & Evolution Server and how to fit them in SIP Application Sequence.
Page 55
Page 56
The goal of this learning object is to provide background and prepare you for the Practice
Workshop. In the Practice Workshop you will have an opportunity to perform these tasks.
Experiment with digit treatment, call processing & call routing of incoming & outgoing calls
through CM.
Page 57

though this course.
Page 58
CM has a very flexible yet complex Call Processing Architecture based on Routing Tables,
Route Patterns, Permissions and Restrictions.
Call processing in CM can be different from Public to Private Networks, across Locations and
even at different times and days.
This topic is covered in other Knowledge Bundles but as an entry level only, the present
Learning Object intends to go though it in a deeper level for Support purposes.
Vectoring is also part of what CM can Call Process for us, however, that part wont be touched
in this Learning Object.
Page 59
The very first point a dialed digit touches is the Dial Plan Analysis table, it defines the leading
digit or digits, the minimum and maximum length for all numbers represented by the leading
digit and the type of call (extension, feature access code, enbloc extension, udp, aar or ars
number, attendant console or dial access code for trunk testing).
When a dialed string matches the leading digit defined for extensions, and the extension exists
and its active, the call is simply put through locally.
Dial Plan Parameters define how Dial Plan Analysis will behave, when UDP defines a dial
pattern which happens to also exist locally, this table allows you to establish whether local or
UDP extensions will be looked up first.
Uniform Dial Plan allows you to reach extensions from another connected CM, call routed via
the AAR table, without using a feature access code for AAR , in other words, to dial foreign
extensions transparently as if it was a single telephony switch.
Page 60
When a number is dialed, and that number is not an extension, CM has different ways to put
those digits through the Route Selection Tables called ARS and AAR .
CM is so flexible that any table can be used for either public or private trunks, however, every
table has particular features related to each specialty and the advised and supported way is to
use AAR & ARS tables for their intended purposes.
A mechanism to reach these tables for Route Selections is via a feature access code assigned
to each of them, another method consists of assigning an ARS or AAR leading digit in the
change dial plan analysis form, this last is a license file controlled feature.
The third method is assigning a local extension range for the remote extensions to be reached
through the trunk, including their leading digit in the Uniform Dial Plan and the AAR tables.
Another table which hasnt been displayed on this slide not to make it more complex, is the
Partition Routing table, common to both ARS & AAR tables, which, in combination with the time
of the day table, allows treatment of a dialed string to be sent to a different route pattern
depending the time & day of the week.
Page 61
The final outcome of ARS & AAR Tables is a Route Pattern.

Route Patterns have an associated Facility Restriction Level, which allows users to be put
through selectively by Class Of Restriction.
The same Route Pattern can allow or deny the same dialed number to different users.
A Trunk Group can be accessed by different Route Patterns.
A Route Pattern can put calls through different Trunk Groups, even in different Branch
Gateways, for higher capacity and more resiliency.
Page 62
This learning object showed you how calls are processed through CM, including:
Dial Plan, Route Selection, and Trunk Selection.
Page 63
Page 64
This learning object will show the various elements defined by the H.323 umbrella, and their
application in optimizing the Media-Traffic handling on a CM System.
In this learning object you will:
Analyze the H.323 umbrella applied to CM, Codecs, Direct & Intervening Network Regions.
Page 65
H.323 was originally created to provide a mechanism for transporting Multi-Media Applications
over a LAN , its success rapidly extended its utilization for global networks.
H.323 works transparently in combination with legacy ISDN devices, mainly because its
development was based on the ISDN Q.931 standard.
Page 66
Generically speaking, there are three main types of Endpoints in H.323.

The IP Station, Converts from Voice and or Video, forth and back, into an H.323 compatible
Media Codec.
The Media Gateway, Converts from TDM or Analogue streams, forth and back, into an H.323
compatible Media Codec.
Since Media Codecs in H.323 are transported by Unicast based Protocols, like RTP, Multi Party
Conferences must be established by an intermediate device, capable of re transmitting the
Media Streams over to the rest of the participants in a conference. This device is commonly
called the Multi Point Conferencing Unit or MCU.
Page 67
In the Avaya World, Telephony Media Gateway & MCU have been put together in one box, The
Branch Gateway.
A Branch Gateway has not only those abilities by the way, it includes within the box a powerful
vlan switch, a per vlan dhcp server, a file server, an IP router, etcetera.
Page 68
In H.323, there is only one Gatekeeper all over the Telephony System, however, CM can have
multiple Gatekeeper Interfaces, like CLAN circuit packs or the embedded Processor Ethernet in
the CM server.
Any signalling traffic across CM Gatekeeper Interfaces will be processed centrally at the CM
Server as the only Gatekeeper it is.
Page 69
The CM Server does not touch any media packets, except when CMM, the embedded
messaging system is active, but thats another story, all RTP traffic goes whether from phone to
phone or via a branch or media gateway.
RTP stands for Real Time transport Protocol. RTP is a very efficient and light weight media
transport protocol, however, it is highly time sensitive, and doesnt have an error correction
mechanism, whatever RTP packets, lost on their way, will never make it to their destination, that
makes specially important to carry out a network assessment for real time traffic conditions
before implementing Voice or any media over IP.
Page 70
On an IP network, there are two types of Layer Four and Five Services, one called TCP which
controls and guarantees the reliable delivery of the information through an acknowledge of
reception mechanism.
The other is called UDP which is faster but not as reliable as TCP, it manages the delivery of
information without confirming so.
RTP generates eight thousand packets per second, switching the handset from the left to the
right ear makes about two thousand packets being spoken into the air, and the conversation still
goes on without having to repeat anything, the human brain has the ability to reconstruct the
phrase even though a few sounds get lost on their way.
That makes perfectly possible and practical to send Audio through UDP a not so reliable service
which, being faster than TCP, guarantees a better throughput and quality for a time sensitive
application like RTP.
H.225 RAS also uses UDP transport services although it cant afford loosing a single bit along
the way, the reason why is that H.225 RAS has its own mechanism for reliable delivery implicit
in the protocol.
But why H.225 RAS was implemented over UDP services? Mainly because upon a CM restart,
all phones will try to register at the same time, which, for a CM with thousands of stations,
would have been overwhelming for the data network if TCP was used instead.
H.225 Call Signalling and H.248 dont represent that much of a work load for the network while
Page 71
they rely mainly on TCP error correction mechanism, hence their dependency on
TCP.
Audio is directly encoded into RTP as you can see.
Page 72
CODEC stands for Encoder Decoder, its a mechanism for crafting Media Packets in a format
that can be easily transportable over a Data Network.
Audio gets digitized by some circuitry which delivers a chain of bits into a Time Division
Multiplexing Bus, that TDM stream is broken down in small chunks of information and added
some header for transportation over the data network by a combination of software and Digital
Signal Processors or DSPs.
When the Codec has compression, DSPs also do the job.
Once the packets have been crafted properly, they are handed off to the network.
Page 73
These are just a few of the available Codecs in general, G.711, G.729 & G.723 have important
differences among one another.
G.711 is the straight on packetized version of PCM encoded Audio on a TDM Bus, therefore, its
quality is as good as in a TDM bus, as long as the network behaves, of course.
G.729 has a mild compression ratio which makes it still fairly good in quality with a way more
friendly bandwidth demand to narrow links.
G.723 is not that much useful any more, as technology moves forward and networks become
faster and faster, its most suitable application over Modem based dial up links is rare to find
nowadays. High compression ratio also trades off with not really good voice quality.
Page 74
The most bandwith-demanding Codec is G.711 in versions A and Mu, it consumes 64 Kbps
from the network, just for the Audio Payload, plus all the header, its total bandwidth demand
goes up to 87 Kbps.
Page 75
The slowest Ethernet LAN probably still in operation is 10BaseT, best practices in data
networks dictate not to load an Ethernet channel beyond 35% of occupancy, under that
premise, 10BaseT delivers no more than 3.5 Mbps.
3.5 Mbps is around 40 times faster than 87 Kbps, we can conclude that VoIP over a LAN
needs no compression at all.
Page 76
Setting up which Codec must be used for each pair of phones would take forever to administer,
to make things easier, a whole system can be broken down into well defined areas with similar
bandwidth conditions inside.
Those Bandwidth Areas are called IP Network Regions in the Avaya World.
Page 77
Dont get it wrong, this is not an IP Trunk, although network regions also apply to IP Trunks, this
topic refers to phones in different Bandwidth Areas within the same CM.
A call inside Network Region 1 or Network Region 2 shall use a G.711A/Mu Codec.
A call between Network Region 1 and Network Region 2 must rather use a compressed Codec
to save Bandwidth, G.729 g seven two nine> for example.
Page 78
When the inherent Bandwidth-Limit of a link is surpassed, all on-going & new calls get
degraded in quality, it would be better a congestion tone indicating that the call cannot be
completed than bad voice-quality for all subscribers using that link.
Call Admission Control can be set to a limited number of calls or amount of bandwidth, beyond
which, all calls between the two Network Regions would be denied.
Page 79
IGAR is a variation to Call Admission Control through which the calls beyond limits can be
completed using whether the Public Telephony Network or a Private Trunk for the Audio portion.
Page 80
An intervening Region is an Central Areal Traffic Wise that can be configured Call Admission
Control restrictions against all other Regions.
Any pair of Connected Regions will be constrained to the lowest limit with the Intervening
Region.
For Example, Network Region 2 and Network Region 4 can only have 4 calls between them
due to the lowest limit, in this case, defined by Region 2.
This method simplifies administration for systems with too many Network Regions.
Page 81
Page 82
Page 83
Page 84
Page 85
Page 86
In this lesson, you:

Analyzed the H.323 umbrella applied to CM, Codecs, Direct & Intervening Network Regions.
Page 87
Page 88
This learning object will show how an T1 Trunk is structured and how to configure an ISDN
Trunk over it,
by setting up, the interface, a signaling group, a trunk group and how to manage clock
synchronization with the PSTN.
CM deals with ISDN T1 Trunk Interfaces, Signaling Groups & Trunk Groups according to
Standards.
Page 89

though this course.
Page 90
Page 91
A T1 line for Telephony is broken down into 24 channels, from 1 to 24.

When Channel Associated Signaling or CAS is used, Audio is encoded in 7 bits out of the
available 8 for each channel, the remaining bit is robbed to be used for signaling.
This signaling method is limited to only send basic status messages for simple events like off
hook and on hook.
The total usable capacity of a T1 trunk with CAS or robbed bit is 24 channels.
An extra bit, is used for Synchronization with another switch or network.
Page 92
A T1 line for ISDN Telephony is broken down into 24 channels, from 1 to 24, out of which, 24 is
used for ISDN Q.931 Signaling and the rest for Audio.
The total usable capacity of a T1 trunk is 23 channels.
There is also an extra bit, counting up to 193 total bits, used for Synchronization with another
switch or network.
Page 93
CM administers the T1 channel as a DS1 board, module or circuit pack.

The D channel is implemented as a Signaling group whereas the B channel is managed as a
Trunk Group.
Page 94
Branch Gateways and Port Networks are Synchronous Machines and need a clock signal to tie
their heart beat with, that clock signal can be self-generated or take from the far end of the
trunk link.
In general, the one who generates the clock signal is known as the Master while synchronizing
remotely with the Master is called Slave.
The best practices mark to use the Service providers clock signal when connecting to the
public network, in other words, CM shall be the Slave.
Page 95
Configuring a T1 trunk from ground up involves 5 simple steps.

Having inserted the physical DS1 board in a registered Gateway, use the add ds1 board
command to configure the low level parameters for the trunk.
This is only an example, refer to the Technical documentation and the personnel from the local
carrier to make sure the applicable parameters match one to one.
Page 96
Add signaling group builds up the D channel for the ISDN signaling.
Leave the Trunk Group for Channel Selection field empty, CM will not accept a trunk number in
this field that hasnt been created yet.
Page 97
Add trunk group establishes the Audio channels for the trunk.
Add from page five onwards, as many channels as you have hired from your carrier, you can
add channels from multiple DS1 boards to the same trunk group as long as the signaling
scheme supports so, refer to documentation for more details.
Important Security note. Dial Access feature is only for testing purposes and must be de
activated as soon as the test is over.
Page 98
Remember we said to leave the Trunk Group for Channel Selection field empty? This is the
time to fill it up. Use he change signaling group command for that.
Page 99
Synchronize the TDM clock of each of your Media gateways and port networks connected with
a carrier through a digital trunk using the change synchronization media dash gateway or
change synchronization port dash network, as applicable.
Page 100
When Status signaling group and status trunk group commands mark some errors although we
have double checked all configurations, poking the trunk with a combination of busy out and
release both, trunk and signaling group, has proven to be helpful most of the times.
Should the symptom persists, revise your configuration once again, call your carrier or reach
out for a higher level of technical support.
Page 101
Page 102
Page 103
Page 104
Page 105
Page 106

CM deals with ISDN T1 Trunk Interfaces, Signaling Groups & Trunk Groups according to
Standards.
Page 107
Page 108
This learning object will show you a methodology for technical support in the form of four
phases.
You will learn how to identify the symptoms, create a hypothesis, take action and evaluate a
technical problem with CM.
Define a logical approach to troubleshooting and identify common Best Practices for
Technical Support.
Page 109
This Learning Object is not intended to teach professionals with vast experience in
troubleshooting how to perform their job or how to face Technical issues in general.
It is very well know that everyone has their own style when it comes to resolving technical
problems. However, a group of specialists, in Tech Support must show consistency by
standardizing the fine process of troubleshooting . This is done through a logical methodology,
that is easy to follow, and easy to replicate across the team.
It is not the intention of this learning object to reinvent the wheel either, by coming up with
something that has very likely been already implemented by most of the top companies and
organizations around this business.
The purpose of this Learning Object is to propose a methodology for the Lab Exercises to be
performed as part of this Knowledge Access. It might also be interesting to apply this
methodology in the field as well.
There are several steps to follow to resolve a failure or an abnormal or unexpected condition in
a system.
Lets group them together in four groups, Symptom, Hypothesis, Action and Evaluation.
Page 110
Each of the four phases break down into more specific steps, lets move forward and elaborate
on all of them.
Page 111
Notification consists of the reception of the initial report of the failure in any way it may arrive,
whether via an automatic alarm system, a 24x7 Network Operations Center monitoring, better
know as NOC , or via a human notification.
A notification of a failure is quite often a bit different from what the failure actually is. For
example, lets say that the person reporting a failure, as in the case of a human notification, and
the one receiving it, may have different levels of understanding about the system, or even
different points of view.
A customer or internal user, facing down time in a highly revenue generating system may be
under huge pressure, making the problem bigger than it is, is not rare in this business.
Convergent systems like CM interact a lot with other elements such as data networks, taking
responsibility of their respective part of a complex system is not a common habit, specially
when facing stressful conditions at work. This circumstance unleashes the blame game,
blocking any action necessary to be taken by the customer or final user.
For that reason, verification of the symptom through a series of key questions is a best practice
that avoids rework and promotes a faster resolution of the problem.
The reproduction of the failure, at an early stage of the Support Process, works along with
verification. When possible, seeing the failure for ourselves represents the best of all
verifications.
Specially in large collaboration groups of Tech Support specialists, when a failure takes longer
Page 112
to be resolved than the shift of the one looking after it, documenting the failure in a
standard and thorough way is always appreciated by those taking over the support
tasks.
Page 113
Correlation is perhaps the most critical step in troubleshooting, correlating means to figure out
how the behaviour of a given element depends on its configuration and the interaction with
other elements.
For example, The Phone is not registering, besides its correct configuration, there has to be a
network connection and a valid Gatekeeper willing to accept the request for registration.
Implication consists of brainstorming around the potential causes of the failure after the
Correlation Analysis, refer to documentation and knowledge databases if available.
For example, It could be a bad phone network & VoIP configuration, a Network breakage or
blockage, an un-configured gatekeeper interface, an inadequate Administration of the phone at
CM, Etcetera.
Action Draft establishes a plan for the tests and actions to take in order to prove, whether right
or wrong, the assumptions made during the Implication process.
For example, Ping the Phone from the Gatekeeper, ping the Gatekeeper make a trace at the
Phone and Gatekeeper to exclude a network problem, review the Gatekeeper configuration.
Page 114
Using CM Inherent or External tools helps to prove right of wrong our hypothesis rather than
going blind changing configurations randomly.
There is a long list of CM inherent tools for every occasion like the list trace or status families of
commands.
When a failure occurs beyond the CMs area of control, there are External Tools to help find out
more, like Wireshark or even a simple ping.
For example: The phone is configured ok, CM seems to have the right configuration too, list
trace ras ip-address <x.x.x.x> reports no activity, lets make two Wireshark traces, one at the
phone and one at the Processor Ethernet (Server) to find out more.
After testing, our hypothesis has been preliminary confirmed or refuted, implement your Action
Plan and see the results.
Move straight forward to the Evaluation Phase, no time gaps should exist between
Implementation and Evaluation, the customer may not pleased should something go wrong.
Page 115
Verify if the Actions youve taken resolved the problem.

If yes, verify that you have fixed the problem by rolling it back to the failure state to see if the
problem reoccurs. Its well worth it to make sure you have fixed the problem because,
sometimes, something else, completely unrelated happens at the same time we performed the
action. Do this even though the customer may be ok with the actions you have taken.
If the action taken, does not resolve the problem, roll back that action and return to work out
your Hypothesis once again, at least, youll know at that point what the problem is not about.
Once you are positive about the problem and the pertinent actions to fix it, make your resolution
permanent, Inform the customer about it and document your work for the customer, yourself
and the knowledge database for subsequent similar events to be easier to resolve.
Page 116
Try your understanding of the previous slides by following the high level steps of Support
Methodology in a graphical way using this Flowchart.
Page 117
As a conclusion, please consider the maxims presented in this Corner of wisdom.

Sense of Responsibility is a treasured asset for Tech Support specialists, but being made
accountable for the success of an operation also requires the authority to perform the
necessary actions.
One needs to be trusted to begin with, especially by one self. Trust your own common sense
when it comes to Alarms, Documentation, Higher-levels of Tech Support, Wiki-Info, Packet
Tracers, and Other Experts.
When a Support Action requires collaboration, collaborate! Trunk issues for example cannot be
resolved on a single side.
The Problem is where it is, not where I need it or want it to be, hiding the real problem always
makes it explode.
A tool can be a weapon in the wrong hands, be aware of what your tools can do for you, no
more, no less.
Understanding the layers of the OSI model helps you to understand most network failures.
Ping is a simple yet powerful tool, it tells more than a thousand alarms some times.
Alarms are not a source of wisdom whispering a solution into my ears, good knowledge on the
Product & Technology is a must to understand Alarms.
Conflict is one of the most frequent threats in Tech Support, dont forget that this is not about
Page 118
being right or wrong, its about fixing a problem.

There are a million ways to fix a problem, the first is the best.
The Support Time Paradox. The more in a hurry I work, the longer it takes to figure
out the problem. Working Fast and Working in a Rush are not the same.
Page 119

Define a logical approach to troubleshooting and identify common Best Practices for
Technical Support.
This learning object showed you a methodology for technical support in the form of four
phases.
Page 120
Page 121
This learning object will show the most common issues on CM Systems, as well as the most
useful commands to help finding and fixing those issues.
In this learning object you will:
Identify, evaluate & take actions on the most common CM issues in the field through a logical
methodology.
Page 122
CM is a solid and reliable Software working upon a solid and reliable Operating System.
Branch Gateways, Modules and Phones are proven to be solid & reliable too.
The most common issues around CM are more likely related to the following causes.
Wrong Configuration, Network Issues, Inadequate Environmental and Operational
Conditions, Incompatibility with non standard 3rd Party devices.

Lets explore the Most Common Issues in CM Systems.
Page 123
The common issues presented in these slides, may or may not be the most common ones for
everyone, depending on the specific purpose of each CM installation, administrators may face
different scenarios and events.
The most common issues relate, as said before, to bad network or wrong configuration issues
with a very few occurrences of Broken Hardware.
When an Ip phone is not registering, it may be due to various circumstances, a broken network
path, a wrong phone configuration, whether manual or automatic via dhcp server.
From the gatekeeper side, CM will not accept registration if h.323 is disabled in the gatekeeper
interface a given phone is trying to register with.
A phone will also be rejected by CM if CM has no DSP resources available in the shape of a
Branch Gateway or a Medpro or Media Resources board.
Analogue of digital phones wont work properly if the gateway the are connected to is not
registered or there are no resources to send audio out of the gateway with.
Connecting an analogue or digital phone to the wrong port, a broken port or using the wrong
port type also makes the phone inoperable.
Branch gateways wont register through a broken network path or when their MGC list points
towards the wrong Gatekeeper interface, also bad credentials, in other words, a wrong serial
number, makes impossible registering a Branch Gateway.
Page 124
When it comes to G650 gateways, the IPSI board is key to be looked after, a broken
network, bad configuration or wrong administration in CM, prevents it from registering
properly.
IPSIs are also sensitive to the carrier hardware identifier which tells the cabinet and
MC which carrier is A, B, C D or E, IPSI must be in A or A and B for high availability,
any incompliance with this rule would cause a failure.
Digital Trunks consist of a physical path based on the DS1 board, signaling group and
the set of channels called trunk group, any parameter mismatch or badly coordinated
would cause an issue.
IP trunks are very similar to digital trunks, except for the physical path with is
replaced by a network path which must be consistent with the information entered in
the node names table. Node names is nothing different from a local hosts file you
may find in most servers.
Page 125
SIP Phones dont register with CM, Session Manager takes care of that part, CM acts only as
an application server which delivers features to the Avaya SIP phone, any SIP registration
issues must rather be worked out at Session manager.
But, if the SIP phone can register but cannot get features from CM, it may be a CM problem or
at least an issue CM is involved with.
The troubleshooting for such problems, at the CM side, are very likely related to the SIP trunk
configuration or to the call routing parameters leading a call into the SIP trunk. CM features
need the SIP trunk and call routing into it, to be operational.
Another important aspect to take in consideration when it comes to CM and Session Manager
Integration, is that CM rejects any SIP & H.323 transactions if there is no DSP resources
available, even when CM is only a feature server.
When calls wouldnt make their way through a trunk, it might be due to the trunk being down in
a first place, or when the trunk has been tested trough the TAC or Trunk access code, and it
works, you may point your finger to the call routing configuration, from Dial Plan to the route
pattern, passing by Feature Access Codes, AAR/ARS Analysis tables, classes or service and
restriction, facility restriction level settings, time of the day table, digit conversion mechanisms
along th way, etcetera.
Phones may some times register but dial tone doesnt show up, that might be due to a non
supported codec defined in the Codec Set, for example, G.723 is not supported by hard phones
by default.
Page 126
Also a bad route to the device providing the H.323 phone with the dial tone can cause
this stream to get lost on the way.
Some times, there is dial tone, the call is setup ok, but Audio during the call cannot be
heard on one or both sides, this very likely obeys to a bad router configuration,
obviously when the phones are in different subnets.
Another common issue comes along with Survivable Server implementations,
possible causes for a Survivable Server not taking over the expected way could be.
Network Issues, Wrong MGC List on Branch Gateway, System ID, Module or Cluster
ID or Server ID mismatch, Wrong Network or Server Role Configuration or a bad
Survivable Server administration at the Main server.
Page 127
Some of the most useful commands in CM belong in the List, list trace, status, busy out release
families, there are way more options than those presented in this slide, and, once again, how
useful one considers each command depends on various subjective factors, including personal
troubleshooting style and taste.
List trace produce a real time output from the events being traced, therefore, GEDI console
does not support this family of commands, only the terminal emulation and ssh consoles like
Putty can be used for list trace.
Status delivers a snapshot of the current condition of a given element, hardware or software.
Busy out is a very useful command to gracefully take a certain element out of operation without
affecting other objects depending upon it.
The combination of Busy out and release in that order, can be helpful to bring out a trunk for
example from an abnormal condition, specially at the initial setup.
List shows all existing elements of a certain type, some list commands show status information
at a glance, like list media gateway, which displays the registration status of media gateways on
the last column.
At Branch gateway registration issues, it might some times be necessary to take a look at the
gateways configuration, the Media gateway Controller list must point towards a CM Gatekeeper
interface, Processor Ethernet or Clan, otherwise, the gateways would never register.
Finally, the most powerful command may very well be a simple ping, when networks are open
Page 128
to ping, its well worth to use it before displaying any alarms related to IP connected
objects.
Page 129
Support is not only a job or tasks to perform, it has a lot of personal style, common sense and
some times, a bit of art in it.
Issues and their resolution can make infinite numbers of combinations, the fastest way out of a
complex problem is a structured and organized approach to it.
Page 130
Page 131
Page 132
Page 133
Page 134
Page 135
This learning object will show the most common issues on CM Systems, as well as the most
useful commands to help finding and fixing those issues.
Page 136
Page 137
This learning object will show you how to identify the sources of alarm notification.
Differentiate hardware, operating system, and application alarms and events.
Choose the applicable interface and commands to diagnose the problem.
Consult product documentation for alarm/event explanation, causes, and repair. Resolve an
alarm or event.
The goal of this learning object is to provide background and prepare you for the Practice
Workshop.
In the Practice Workshop you will have an opportunity to perform these tasks.
Analyze and resolve abnormal or undesirable CM behavior based on alarms and events.
Page 138
An additional item that will provide you with a deeper understanding of Alarms, Events and
Errors.
It is recommended that you save these resource documents to your PC for reference as you go
though this course.
Page 139
CM alarms, errors, and events are differentiated from hardware-related alarms.

Listed for CM:
Maintenance Objects (MOs) are Communication Manager software
modules that monitor processes, connections, and hardware
Errors are Faults reported by circuit packs, media modules, and
tests used for diagnosis and recovery
Denial Events are Mistranslation or mismatched provisioning that
prevents call completion.
Listed for Hardware:
Server Alarms are Problems with:
Hard disk drives
CD/RW drives
Network interfaces (NICs)
Power supplies
Server memory
Out-of-spec environmental conditions (temperature)
Page 140
System Platform Alarms are Problems with the Hypervisor virtual layer
Page 141
This slide shows the alarm and event types as they correspond to the architecture layers.
Maintenance objects and denial events correspond with the application layer.
System platform alarms correspond with the virtual layer and appear in the SP alarm log.
Server alarms correspond with the physical layer and include problems with servers:
Hard disk drive
Memory
Processor
Network interfaces (NICs)
Power supplies, and
Environmental conditions (for example, temperature out of spec)
Page 142
There are several reports, alarm delivery methods, and visual indicators that can signal a
problem with the system.
Trouble conditions can be reported by:
SMI Current alarms
SAT Alarms Report (display alarms)
SAT Error Report (display errors)
SAT Events Report (display events)
Hardware visual indicators such as LEDs and Displays or Panels on the hardware.
SNMP traps sent to the network management software, and
Secure Access Link (SAL) gateway
Will cover these in more detail on the following slides.
Page 143
You can view the current alarms using the SMI page by selecting Current alarms on the left
hand side of the page.
It will display a summary of alarms, if present, followed by a detailed tale of explanation.
Alarms are also covered in the documentation Maintenance Alarms for Avaya Aura
Communication Manager, Media Gateways and Servers (03-300430).
Page 144
The display alarms command provides a filter (input screen) to select the alarms that you want.
Select the alarm type or types, report period, and the equipment type or types.
Press Enter for the Alarm Report output screen.
Page 145
This sample Alarm Report shows one minor, off-board alarm.

CM Maintenance Objects (MOs) have the distinctive, all-caps syntax.
Page 146
The display errors command provides a filter (input screen) to select the errors that you want.
Type the Error Type number in the Error Type field.
Make any other time-based or equipment-based choices and press Enter for the Event Report
output screen.
Page 147
This sample Error Report shows several problems with the media gateway.
CM Maintenance Objects (MOs) have the distinctive, all-caps syntax.
Page 148
Use the Event Report input screen to filter by category, time, and other details.
The Category field also has other values in addition to denial.
Look up the Event ID in Avaya Aura Communication Manager Denial Events (03602793)examples follow.
Page 149
The sample Events Report shows several entries.

Review all of the fields listed in the report:
The Event Type is the most important field to mention. When you look up the Event Type in
Avaya Aura Communication Manager Denial Events (03-602793), the book is organized by
numeric ranges of event types.
The Event Description provides a short explanation of the event.
The Event Data 1 and Event Data 2 fields provide additional information.
First Occur and Last Occur show the date and time of the first and most recent occurrence.
The Evnt Cnt (Event Count) shows the status of the error counters for this event.
Page 150
This slide shows examples of visual indicators:

TN circuit pack LEDs
Alarm (red)
The system detected a fault on this circuit pack. The alarm log should contain an on-board alarm for
this circuit pack or one of the maintenance objects that is associated with it. The red LED is also lit
briefly when a circuit pack is inserted or reset. If the circuit pack passes the initialization tests, the
LED is turned off. If a fault is detected, the LED remains lit.
Test (green)
The system is currently running tests on this circuit pack as part of background maintenance or
demand testing. This LED is also lit briefly during initialization tests when a circuit pack is inserted or
reset.
Busy (yellow)
The circuit pack is currently in use.
See the manufacturers documentation for components not produced by Avaya.
The HP DL360 has a pull-out panel that shows which component indicates trouble.
The Dell R610 (and other Avaya Common Servers) have CD/RW and hard disk drive LEDs that
indicate status and error conditions.
Although not shown, LEDs for the NICs and power supplies on the rear of the server indicate
status and error conditions on those devices.
Page 151
This sample Alarm Report shows a minor, off-board alarm.

CM maintenance objects (MOs), such as the SP-REG-M in the example, have the distinctive,
all-caps syntax.
Use Maintenance Alarms for Avaya Aura Communication Manager, Media Gateways and
Servers (03-300430) to research and repair CM maintenance objects.
Page 152
The SMI Current Alarms page also shows alarms for:

CommunicaMgr Alarms (Communication Manager alarms) found in Maintenance Alarms for
Avaya Aura Communication Manager, Media Gateways and Servers (03-300430).

The information in the display alarms and the SMI Current Alarms page is the same.
Page 153
The slide shows an example of a maintenance object (MO) in the Maintenance Alarms for
Avaya Aura Communication Manager, Media Gateways and Servers (03-300430)
documentation
IMPORTANT: This example shows that there is no Initial Command to Run, meaning that no
demand test exists to obtain further information about the alarm condition. The example DOES
indicate the possible causes of the problem.
Alarm classifications:
Major - failures that cause critical degradation of service and require immediate attention.
Minor - failures that cause some service degradation, but do not render a crucial portion of
the system inoperable. The condition requires attention, but typically a minor alarm affects
only a few trunks, stations, or a feature.
Warning - failures that cause no significant degradation of service or failures of equipment
external to the system. These alarms are not reported to the Avaya alarm-receiving system
or to the attendant console.
On-board problems originate in circuitry on the alarmed circuit pack/module.
Off-board problems originate in a process or component that is external to the circuit pack/module.
Page 154
This slide shows an example of a maintenance object (MO) in Maintenance Alarms for Avaya
Aura Communication Manager, Media Gateways and Servers (03-300430) that DOES have a
demand test (Initial Command to Run).
Test hardware only if indicated to do so.
Depending on whether the long qualifier is used in the command, the tests listed in the
Demand test description and error codes section run.
Click on the links to interpret each test result.
Page 155
Perform the repair steps listed in the alarm documentation.

Note that FAIL codes 1, 2, and 3 have the same recommended repair steps.
Page 156
Look up the event ID in Avaya Aura Communication Manager Denial Events (03-602793).
This book is organized by event ID ranges.
Begin research by looking up the Event Type.
Page 157
Look up denial events in Avaya Aura Communication Manager Denial Events (03-602793).
Event data might contain the information for:
Internal user ID (UID) of a component involved in the call (station, IP user, gatekeeper)
Product ID
Object ID
IP address
Extension
IP address involved in the call
TTI state
Numeric reason code explained in the tables in documentation
Numeric code showing the Cause Value, Cause Value Diagnostic, and Location Code for the
event. See the documentation for Cause Value meanings and interpretations.
Page 158
Event Type number ranges help define the type and source of the denial event and include
such categories as:
Call processing
Dial Plan Manager process
IP process
Data Error (corruption) process
Contact Closure process
Survivable Core Server process
Page 159
Avaya Aura Communication Manager Denial Events, 03-602793, lists the event type, the text
that appears in the Event Description field, a further Explanation of the condition, and the type
of data in the Event Data 1 and Event Data 2 fields, if present.
Page 160
Here is a list of the CM-related alarms and events documentation.

Always refer to the latest documentation at support.avaya.com.
Go to downloads and documents and enter the product name.
In this case you would enter; Communication Manager, and under filters select Document
Libraries for a list of all documentation.
You can download the CD of the documents you want.
Page 161
Page 162
Page 163
Page 164
Page 165
Page 166

Analyze and resolve abnormal or undesirable CM behavior based on alarms and events.
This learning object showed you how to identify the sources of alarm notification.
Differentiate hardware, operating system, and application alarms and events.
Choose the applicable interface and commands to diagnose the problem.
Consult product documentation for alarm/event explanation, causes, and repair.
Page 167
Logs
Page 168
This learning object explains Logs in general as well as Logs specific to the CM, and will show
how to enable Syslog Server to collect & display CM Logs.
Track down events in CM based on the most commonly used Logs.
Page 169
Please double click the document object below to open an additional item that will provide you
with a deeper understanding of logs.
though this course.
Page 170
A Log is a list of events, whether expected or unexpected, normal or abnormal, any kind of
events, reported into a text file can make a Log.
CM and its various components use Syslog, a standard Linux service that supports storing
event information in local files as well as sending events to an external Syslog server. Syslog
supports storing events in different files or logs depending on the nature of the event.
Logs in CM are produced by Servers, Branch Gateways, Operating System and Operating
Platform for Virtual Environments and even Software Applications connected to CM.
Page 171
Logs classify in 4 categories.

Operational Logs are used for Supporting Alarming and Performance Monitoring.
Security Logs are good for Discovering and Tracking Security Breaches, also enable response
to Security Threats.
Audit Trail Logs make systems compliant with Industry Regulations and specific Customer
Agreements.
Trace logs help in detailed flow tracking while Debug logs are used for testing and
troubleshooting.
Trace and Debug Logs are not available to the customer.
Page 172
A Log is not an Expert or a Wizard telling us the truth about a failure, staring at a Log for hours
wont necessarily whisper the solution into our ears
We must have a hypothesis based upon our knowledge of the product that we can prove right
or wrong by looking up for key pieces of information in Logs and other tools.
Collecting Events or to keep storing an entry for every single event, can be very demanding for
a Server. Some logs simply run in automatic whereas other logs must be activated before and
deactivated after use.
Page 173
Use the change logging-levels command at SAT terminal in CM to select which kind of actions
shall be included in CM Logs.
Page 174
Please take a moment to review the parts of the log file name. It is important that you
understand the log file name to help in your troubleshooting of the system.
Page 175
Lets take a look at the following demo to see how to deal with CM Logs.
In this demo you will see how to enable Syslog Server in CM and display Logs from it.
Page 176
The Message Sequence Tracer or MST, is a Logging and Debugging utility for tracing protocols
throughout Communication Manager, including Internal & External Protocols. It falls into the
Trace and Debug category.
Page 177
MST is a Trace and Debug Log type.

MST has powerful capabilities like Filtering the desired type of messages and specific bit strings
only or triggering the Starts and Stop of a Capture when a certain type of message or a specific
bit string occurs.
However, MST is too specific and its only for Avaya Tier 3 Personnel, Avaya officially
discourages Business Partners and Customers from using MST as you can see on this
screenshot of a support document.
Page 178
There is a good number of CM inherent and external Trace Tools that can be used instead of
MST.
Tracing just an Off Hook On Hook cycle, delivers roughly 100 lines of MST that may take years
of practice to interpret properly.
List trace is faster and more understandable at a glance for most issues inside CM.
Status station shows key information about Endpoint call control and audio.
Denial and error logs help to find out the majority of Call Processing issues.
3rd Party Protocol Analizers like Wireshark provide a very friendly and convenient to capture
and decode multi media trafic like H.323 or SIP.
Using CDR to track down how the PSTN calls get routed can help to solve so related issues.
Ping is a powerful tool, use it when possible (some security policies enforce Ping blockage)
Page 179
Page 180
Select all the error types and protocols you wish to capture from, for example, Hardware Errors,
Processing Errors, Vectors, Denial Events, IP Stations & Survivable Servers.
Note that IP Stations and Survivable Servers appear together in the same activation field, use
you troubleshooting common sense to find out why.
All of them register with CM through the RAS Registration, Admission and Status Protocol from
the H.323 standard.
Page 181
ISDN-PRI Trunks data can be filtered out by some specific Voice Channel or B channel, by
Signalling or D channel or H.323 when its an IP Trunk.
Page 182
ASAI Links can also be filtered as well as Q.931 protocol commonly found in ISDN trunks and
H.225 Endpoint Signalling.
Page 183
Vector filtering narrows down the search by Directory Number, trunk group, Vector Step and
port number.
Page 184
Traffic from or to specific IP addresses may be used for filtering, and the filter can be made
more exclusive by indicating which Clan and port we want to filer from.
Page 185
Ip Station is also a useful filter that allows to trace specific signalling and control traffic from
whether all or a station in particular.
Lets use out troubleshooting common sense once again. Why is RTP or Real Time Transport
Protocol for Voice not included in this filter?
The answer is that RTP goes directly from peer to peer, from Endpoint to Endpoint, never
through the Communication manager Server.
Page 186
Issues with Media or Branch gateways can also be track down using a filter as specific as
Gateway, module and port in both directions, up or down link.
Page 187
SIP Messages are also applicable a Filter, narrowed by signalling group, caller and callee.
Page 188
To enforce the selected changes in change mst, enable mst must be performed afterwards, but
more important perhaps is to run the disable mst command after consulting the mst logs,
nobody wants additional unnecessary stress on our Communication manager Server.
Page 189
As the rest of the Log views, MST can be displayed by a constrained time window or filtered by
a matching pattern.
Page 190
The Payload of the displayed MST Log, does not deliver useful at a glance information for
Support purposes other than CM software debugging, this trace corresponds to one single
event, an off hook on hook cycle.
The list trace station command should have helped much more than MST to find out useful
details on this event.
Page 191

Track down events in CM based on the most commonly used Logs.
You learned about Logs in general as well as Logs specific to the CM, and also how to
enable Syslog Server to collect & display CM Logs.
Page 192

CM CMM Support 5u00060k Day 01

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

CM CMM Support 5u00060k Day 01

Încărcat de

Drepturi de autor:

Formate disponibile

Student Workshop Guide

Please use this information as a resource for this learning object.

In this lesson, you learned how:

Communication Manager, as a Communication Server, is a complex application that consists in

There are two type of processes.

The call processing core of CM is the capro process.

In this lesson, you learned how:

local conditions in large deployments.

Please use this information as a resource for this learning object.

In this lesson, you learned how:

local conditions in large deployments.

IMS stands for IP Multimedia Subsystem

In this lesson, you learned how to:

Please use this information as a resource for this learning object.

The final outcome of ARS & AAR Tables is a Route Pattern.

Generically speaking, there are three main types of Endpoints in H.323.

In this lesson, you:

Please use this information as a resource for this learning object.

A T1 line for Telephony is broken down into 24 channels, from 1 to 24.

CM administers the T1 channel as a DS1 board, module or circuit pack.

Configuring a T1 trunk from ground up involves 5 simple steps.

In this lesson, you learned how:

Verify if the Actions youve taken resolved the problem.

As a conclusion, please consider the maxims presented in this Corner of wisdom.

being right or wrong, its about fixing a problem.

In this lesson, you learned how to:

Conditions, Incompatibility with non standard 3rd Party devices.

CM alarms, errors, and events are differentiated from hardware-related alarms.

Will cover these in more detail on the following slides.

This sample Alarm Report shows one minor, off-board alarm.

The sample Events Report shows several entries.

This slide shows examples of visual indicators:

The circuit pack is currently in use.

See the manufacturers documentation for components not produced by Avaya.

This sample Alarm Report shows a minor, off-board alarm.

The SMI Current Alarms page also shows alarms for:

Avaya Aura Communication Manager, Media Gateways and Servers (03-300430).

On-board problems originate in circuitry on the alarmed circuit pack/module.

Perform the repair steps listed in the alarm documentation.

Here is a list of the CM-related alarms and events documentation.

In this lesson, you learned how to:

Logs classify in 4 categories.

MST is a Trace and Debug Log type.

In this lesson, you learned how to:

enable Syslog Server to collect & display CM Logs.

S-ar putea să vă placă și