Operating Your Telephony Controller

You can manage your telephony controller by using the telephony controller software and MML commands to stop and start the system; retrieve the status of the software, signaling, and traffic channels; and put channels in and out of service. Perform these tasks if you:

Have made certain system configuration changes, including changes to the dial plan or SNMP
Are testing the system
Have upgraded software
Are troubleshooting alarms and need to stop and start processes
Are trying to resolve a problem and have been directed to do so by the Cisco Systems Technical Assistance Center (TAC)

Table 3-1 lists the topics covered in this chapter:

Topic	Page
Before You Start	3-2
Starting and Stopping the System	3-2
Starting and Stopping the System	3-2
Figure 3-2 shows in more detail how to stop the system.	3-5
Retrieving a Process or a Process Group Status	3-6
Starting a Process or Process Group	3-8
Stopping a Process or Process Group	3-9
Managing Signal Channels and Lines	3-9
Managing Traffic Channels	3-11
Managing Failover	3-18
Where to Go Next	3-21

Table 3-1: Chapter Topics

Topic Page

Before You Start

3-2

Starting and Stopping the System

3-2

Starting and Stopping the System

3-2

Figure 3-2 shows in more detail how to stop the system.

3-5

Retrieving a Process or a Process Group Status

3-6

Starting a Process or Process Group

3-8

Stopping a Process or Process Group

3-9

Managing Signal Channels and Lines

3-9

Managing Traffic Channels

3-11

Managing Failover

3-18

Where to Go Next

3-21

3.1 Before You Start

To perform the procedures in this chapter, you must have a user ID that is part of the transpath group, and you must have the proper group privileges. To verify that your user ID is part of the transpath group and you have the necessary privileges, see the"Setting Up the Transpath Group and Users" section. For some procedures in this chapter, you must log in as root; this will be noted in the applicable sections.

The procedures in this chapter are performed using UNIX or MML commands. You should be familiar with these commands before attempting these procedures. See "UNIX System Operation," for more information about basic UNIX commands. See "MML Commands," for more information about MML commands.

3.1.1 Starting MML

To start an MML session:

Step 1 Log in to the telephony controller and change to any subdirectory under /opt/TransPath (for example, /opt/TransPath/bin).

Step 2 Enter the following command:

mml

If you receive an error message that sessions are already in use, enter the following command:

mml -s session number

Use any number from 2 to 12 and repeat until you find a vacant session. After successfully entering MML, the prompt changes to:

mml>

3.2 Starting and Stopping the System

The system defaults to automatic startup. Under normal conditions, powering up the system automatically launches the telephony controller software. For single telephony controller configurations, the process manager starts first, which in turn starts all of the system processes and process groups listed in Table 3-2. For failover configurations, the failover daemon (foverd) starts first, which controls the process manager and the other system processes.

3.2.1 Manually Starting and Stopping the System

You can disable automatic startup and manually start the system. To disable automatic startup, perform the following steps:

Step 1 Log in to the telephony controller as Root.

Step 2 Edit the startup script by entering:

chmod -x /etc/init.d/transpath

This disables the process manager (for a single telephony controller) or the failover daemon (for a failover configuration). To reverse this process and return to automatic startup:

Step 1 Log in to the telephony controller as Root.

Step 2 Edit the startup script by entering:

chmod +x /etc/init.d/transpath

To manually start the system:

Step 1 Log in to the telephony controller as Root.

Step 2 Enter sh /etc/init.d/transpath start to start the system.

To manually stop the system:

Step 1 Enter sh /etc/init.d/transpath stop;or

Step 2 Start an MML session. (See the"Starting MML" section for more information.)

Step 3 Enter the following MML commands:

STP-SOFTW:IOSG-01

STP-SOFTW:ENGG-01

STP-SOFTW:XEG-01

The system stops the channel controllers, the engine, and other processes. You can then quit MML.

When necessary, you can enter UNIX commands to identify and stop individual software processes. For example, to stop the process manager by using the kill command in UNIX, perform the following steps:

Step 1 Log in to the telephony controller as root and enter the following command:

ps -ef | grep procM

The system responds with a line containing the information about the procM process.

Step 2 Enter the following command:

kill -16 PID

PID is the Process ID number for the process you want to stop. To confirm the kill command was performed, enter the following:

ps -ef | grep procM

This command returns the status of procM.

Note If you have a failover configuration, you must stop the foverd process before stopping procM. Otherwise, foverd will restart procM. To stop the foverd process, enter the kill command as previously described and use the PID for the foverd process.

Figure 3-1 describes how to start the telephony controller software in more detail.

Figure 3-1: Starting the Telephony Controller Software

Figure 3-2 shows in more detail how to stop the system.

Figure 3-2: Stopping the System

3.3 Managing Processes

The telephony controller software contains processes and process groups that perform the software functions. These functions include managing the I/O channels; generating alarms, call detail records, and logs; and performing signal conversion. All these processes are managed by the process manager (procM) component of the software. The process manager starts applications and processes, monitors the health of managed processes, and restarts and shuts down processes. Using MML commands to control the process manager, you can start, monitor, and shut down various processes running on the telephony controller. Table 3-2 shows the system processes and process groups controlled by the process manager.

Group	Process	Executable	Description
XEG-01¹	CFM-01	../bin/cfgM	Configuration manager
XEG-01	ALM-01	../bin/almM	Alarm manager
XEG-01	MM-01	../bin/measMgr	Measurement manager
XEG-01	DMPR-01	../bin/dmpr	Dumper
ENGG-01²	ENG-01	../bin/engine	Engine
IOSG-01³	IOCM-01	../bin/ioChanMgr	I/O channel manager
IOSG-01	IOCC-01	../bin/ISDNPRI	I/O channel controller (ETSI PRI)
IOSG-01	IOCC-02	../bin/DPNSS	I/O channel controller (DPNSS)
IOSG-01	IOCC-ASP	../bin/ASP	I/O channel controller (auxiliary signaling network)
PFMG-01⁴	DSKM-01	../local/diskmonitor.sh	Disk monitor

Table 3-2: Processes

Group Process Executable Description

XEG-01¹

CFM-01

../bin/cfgM

Configuration manager

XEG-01

ALM-01

../bin/almM

Alarm manager

XEG-01

MM-01

../bin/measMgr

Measurement manager

XEG-01

DMPR-01

../bin/dmpr

Dumper

ENGG-01²

ENG-01

../bin/engine

Engine

IOSG-01³

IOCM-01

../bin/ioChanMgr

I/O channel manager

IOSG-01

IOCC-01

../bin/ISDNPRI

I/O channel controller (ETSI PRI)

IOSG-01

IOCC-02

../bin/DPNSS

I/O channel controller (DPNSS)

IOSG-01

IOCC-ASP

../bin/ASP

I/O channel controller (auxiliary signaling network)

PFMG-01⁴

DSKM-01

../local/diskmonitor.sh

Disk monitor

¹XEG-01 = Execution environment
²ENGG-01 = Engine
³IOSG = I/O Subsystem
⁴PFMG-10 = Performance monitoring

Controlled by the Process Manager

3.4 Retrieving a Process or a Process Group Status

You can retrieve the status of an individual process, a process group, or all by processes by using MML. You may want to retrieve a process status after you have stopped a process to ensure that it has stopped or to retrieve all processes to see which ones are active.

3.4.1 Retrieving the Status of All Processes

To retrieve the status of all processes, perform the following steps:

Step 1 Log in to the telephony controller and start an MML session. (See the"Starting MML" section for more information.)

Step 2 Enter the following MML command:

RTRV-SOFTW:ALL

The system returns a message similar to the following:

Transpath: SC22  VA-BLACK/TAN (SC2200) 1999-02-24 20:02:25
M  RTRV
   "CFM-01:RUNNING"
   "ALM-01:RUNNING"
   "MM-01:RUNNING"
   "DMPR-01:RUNNING"
   "DSKM-01:RUNNING"
   "ENG-01:RUNNING"
   "IOCM-01:RUNNING"
   "IOCC-ASP:RUNNING"
   "SNMP-AGT:RUNNING"
   "IOCC-01:RUNNING"
   "IOCC-PRIIP:RUNNING"
   ;

This response shows that all the system processes are running. See Table 3-2 for a list of system processes.

3.4.2 Retrieving the Status of an Individual Process

To retrieve the process status for a process, perform the following steps:

Step 1 Log in to the telephony controller and start an MML session. (See the"Starting MML" section for more information.)

Step 2 Enter the following MML command:

RTRV-SOFTW:process name

For example, to retrieve the status of the alarm manager, enter the following command:

RTRV-SOFTW:ALM-01

The system returns a message similar to the following:

TransPath: SC22  VA-BLACK/TAN (SC2200) 1999-02-24 20:11:18
M  RTRV
   "ALM-01:RUNNING"
;

3.4.3 Retrieving the Status of Processes in a Process Group

To retrieve the status of processes in a process group, perform the following steps:

Step 1 Log in to the telephony controller and start an MML session. (See the"Starting MML" section for more information.)

Step 2 Enter the following MML command:

RTRV-SOFTW:process group name

For example, to retrieve the status of processes in the execution environment, enter the following command:

RTRV-SOFTW:XEG-01

The system returns a message similar to the following:

Transpath: SC22  VA-BLACK/TAN (SC2200) 1999-02-24 20:13:44
M  RTRV
   "CFM-01:RUNNING"
   "ALM-01:RUNNING"
   "MM-01:RUNNING"
   "DMPR-01:RUNNING"
   "SNMP-AGT:RUNNING"
;

This shows the status of all processes in the process group. See Table 3-2 for a list of system processes.

3.5 Starting a Process or Process Group

You can use MML to start an individual process or a process group. You may want to do this if you have stopped individual processes and need to restart them.

3.5.1 Starting an Individual Process

To start an individual process, perform the following steps:

Step 1 Log in to the telephony controller and start an MML session. (See the"Starting MML" section for more information.)

Step 2 Enter the following MML command:

STA-SOFTW:process name

For example, to start the disk monitor process, enter the following command:

STA-SOFTW:DSKM-01

The system returns a message similar to the following:

TransPath: SC22  VA-BLACK/TAN (SC2200) 1999-02-24 20:22:25
M  COMPLD
   "DSKM-01"
;

3.5.2 Starting a Process Group

To start a process group, perform the following steps:

Step 1 Log in to the telephony controller and start an MML session. (See the"Starting MML" section for more information.)

Step 2 Enter the following MML command:

STA-SOFTW:process group name

For example, to start the engine process group, enter the following command:

STA-SOFTW:ENGG-01

The system returns a message similar to the following:

TransPath: SC22  VA-BLACK/TAN (SC2200) 1999-02-24 20:25:19
M  COMPLD
   "ENGG-01"
   ;

3.6 Stopping a Process or Process Group

You can use MML to stop an individual process or a process group, or to stop all processes at once (except the process manager and MML). You may want to do this to perform testing or maintenance.

Note If you have a failover configuration, you must stop the foverd process before stopping a process or process group, because foverd will automatically restart any stopped processes.

3.6.1 Stopping an Individual Process

To stop an individual process, perform the following steps:

Step 1 Log in to the telephony controller and start an MML session. (See the"Starting MML" section for more information.)

Step 2 Enter the following MML command:

STP-SOFTW:process name

For example, to stop the SNMP agent process, enter the following command:

STP-SOFTW:SNMP-AGT

The system returns a message similar to the following:

M  COMPLD
   SWDT
   "snmp-agt"
   /* Status, Waiting for Dependent Processes to Stop
     This is not an error, run rtrv-softw to see when
     all desired processes have stopped */
;

Perform the steps described in the "Retrieving a Process or a Process Group Status" section to ensure that the process has stopped.

3.6.2 Stopping a Process Group

To stop a process group, perform the following steps:

Step 1 Log in to the telephony controller and start an MML session. (See the"Starting MML" section for more information.)

Step 2 Enter the following MML command:

STP-SOFTW:process group name

For example, to stop the engine process group, enter the following command:

STP-SOFTW:ENGG-01

The system returns a message similar to the following:

M  COMPLD
   SWDT
   "engg-01"
   /* Status, Waiting for Dependent Processes to Stop
     This is not an error, run rtrv-softw to see when
     all desired processes have stopped */
   ;

Perform the steps described in the "Retrieving a Process or a Process Group Status" section to ensure that the process has stopped.

3.6.3 Stopping All Processes (Except procM and MML)

You can stop all processes at once, except procM and MML, by performing the following steps:

Step 1 Log in to the telephony controller and start an MML session. (See the"Starting MML" section for more information.)

Step 2 Enter the following MML command:

STP-SOFTW:ALL

The system returns a message similar to the following:

TransPath: SC22  VA-BLACK/TAN (SC2200) 1999-02-24 20:51:29
M  COMPLD
   SWDT
   "ALL"
   /* Status, Waiting for Dependent Processes to Stop
     This is not an error, run rtrv-softw to see when
     all desired processes have stopped */
   ;

Perform the steps described in the "Retrieving a Process or a Process Group Status" section to ensure that the processes have stopped.

Figure 3-3 shows how to stop an individual process or a process group.

Figure 3-3: Stopping an Individual Process or a Process Group

3.7 Managing Signal Channels and Lines

You can use the telephony controller software and MML commands to manage your signal channels and lines. You can retrieve signal channel attributes, change the states of signal channels, and change the state of signal lines.

Signal channels are transport mechanisms for call-control signaling between the telephony controller and a far-end device, such as a switch or access server. A signal channel is bidirectional and provides the expected delivery reliability for higher-layer signaling protocols.

Table 3-3 describes the basic types of signal channels.

Channel Type	Description
SS7 Message Transfer Part (MTP)	Used for reliable delivery. MTP 2 provides reliable point-to-point delivery. MTP 3 maintains multiple, load-sharing links and multiple routes between SS7 point codes.
SS7/IPSS7 MTP	Replaced with IP. Reliable delivery is provided by Reliable User Datagram (RUDP). IP and the Session Manager maintain multiple routes between SS7 point codes.
FASFacility associated signaling	Found in ISDN PRI or DPNSS over a 64 Kbps channel. Reliable delivery is provided by some form of Link Access Protocol (LAP), for example Q.921.
FAS/IPFacility associated signaling over IP	Same as FASFacility but uses IP as its transport mechanism. Reliable delivery is provided by LAP or RUDP.
Simple Gateway Control Protocol (SGCP)	Uses IP with a custom retransmission algorithm.

Table 3-3:

Channel Type Description

SS7 Message Transfer Part (MTP)

Used for reliable delivery. MTP 2 provides reliable point-to-point delivery. MTP 3 maintains multiple, load-sharing links and multiple routes between SS7 point codes.

SS7/IPSS7 MTP

Replaced with IP. Reliable delivery is provided by Reliable User Datagram (RUDP). IP and the Session Manager maintain multiple routes between SS7 point codes.

FASFacility associated signaling

Found in ISDN PRI or DPNSS over a 64 Kbps channel. Reliable delivery is provided by some form of Link Access Protocol (LAP), for example Q.921.

FAS/IPFacility associated signaling over IP

Same as FASFacility but uses IP as its transport mechanism. Reliable delivery is provided by LAP or RUDP.

Simple Gateway Control Protocol (SGCP)

Uses IP with a custom retransmission algorithm.

Signal Channel Types and Descriptions

Because all types of signal channels have basically the same functionality, they are managed similarly. Unless otherwise noted, all commands, counters, and alarms are applicable to all types of signal channels.

3.7.1 Retrieving Signal Channel Attributes

You can retrieve attributes for an individual signal channel or for all signal channels.

To retrieve attributes for all signal channels, perform the following steps:

Step 1 Log in to the telephony controller and start an MML session. (See the"Starting MML" section for more information.)

Step 2 Enter the following MML command:

RTRV-SC:ALL

The system returns a message similar to the following:

TransPath: SC22  VA-BLACK/TAN (SC2200) 1999-02-26 16:15:18
M  RTRV
   "DC-4-0:LS-4,LID=0:OOS,SUPPENT"
   /* DC-4-0: A-link to STP 1.1.4 */
   "DC-3-0:LS-3,LID=0:OOS,SUPPENT"
   /* DC-3-0: A-link to STP 1.1.3 */
   "DC-1-1:LS-1,LID=1:IS"
   /* DC-1-1: F-links to Switch */
   "DC-1-0:LS-1,LID=0:OOS"
   /* DC-1-0: F-links to Switch */
   "SC1-NAS1:SP1-IP,LID=0:IS"
   /* SC1-NAS1: Sig Channel 1 for IP Sig Path NAS1 */
   "SC1-NAS2:SP2-IP,LID=0:OOS"
   /* SC1-NAS2: Sig Channel 1 for IP Sig Path NAS2 */
   ;

This response shows the signaling links between the telephony controller and the SS7 switches, the NASes, and the service transfer points (STPs).

If you receive an install busy (INB) state, this indicates the signal channel has been created and configured, but has not been configured as In-Service or Out-of-Service. (See the "Changing the Signal Channel Service State" section for more information.)

To retrieve attributes for an individual signal channel, perform the following steps:

Step 1 Log in to the telephony controller and start an MML session. (See the"Starting MML" section for more information.) Enter the following MML command:

RTRV-SC:channel-id

For example, to retrieve attributes for the SC1-NAS1 signal channel, enter the following command:

RTRV-SC:SC1-NAS1

The system returns a message similar to the following:

TransPath: SC22  VA-BLACK/TAN (SC2200) 1999-02-26 16:21:12
M  RTRV
   "SC1-NAS1:SP1-IP,LID=0:IS"
   ;

In this response, SP1-IP is the containing signaling path, or the logical grouping of signal channels (equivalent to a linkset in SS7). LID is the line identifier, or the logical line ID of the signal channel within the signal path (equivalent to the signaling link code [SLC] in SS7). IS (In-Service) is the service state of the channel. (See the"Changing the Signal Channel Service State" section for more information about service states.)

3.7.2 Changing the Signal Channel Service State

Table 3-4 shows the available service states for signal channels.

Service state	Return Message	Effects
In-Service	IS	The telephony controller requests that the signal channel provide service. Note When an inhibited channel is placed back into service, use the UNH option. This option is the same as setting the channel for In-Service.
Out-of-Service	OOS	Requests that the signal channel stop providing service after all active calls are terminated. New calls will not be accepted. Note Until all calls are released, the signal channel's service state will appear as OOSPEND (Out-of-Service Pending).
Forced Out-of-Service	FOOS	Requests that the signal channel stop providing service immediately and release all calls.
Inhibit	INH	Requests that the signal channel be put in an inhibit state. In this state, the channel is active but it does not provide service for call processing. If the signal channel is the last one in the containing signal path, the inhibit request will be denied and an error message returned. Note This is for SS7 signal channels only and will fail on other types of signal channels.
Un-inhibit	UNH	Requests that the signal channel be removed from an inhibit state and provide service for call processing. Note This is for SS7 signal channels only and will fail on other types of signal channels.
Install busy	INB	The signal channel is created and configured, but is not yet In-Service or Out-of-Service. Note You cannot set a signal channel to INB.

Table 3-4: Signal Channel Service States

Service state Return Message Effects

In-Service

IS

The telephony controller requests that the signal channel provide service.
Note When an inhibited channel is placed back into service, use the UNH option. This option is the same as setting the channel for In-Service.

Out-of-Service

OOS

Requests that the signal channel stop providing service after all active calls are terminated. New calls will not be accepted.
Note Until all calls are released, the signal channel's service state will appear as OOSPEND (Out-of-Service Pending).

Forced Out-of-Service

FOOS

Requests that the signal channel stop providing service immediately and release all calls.

Inhibit

INH

Requests that the signal channel be put in an inhibit state. In this state, the channel is active but it does not provide service for call processing. If the signal channel is the last one in the containing signal path, the inhibit request will be denied and an error message returned.
Note This is for SS7 signal channels only and will fail on other types of signal channels.

Un-inhibit

UNH

Requests that the signal channel be removed from an inhibit state and provide service for call processing.
Note This is for SS7 signal channels only and will fail on other types of signal channels.

Install busy

INB

The signal channel is created and configured, but is not yet In-Service or Out-of-Service.
Note You cannot set a signal channel to INB.

Note Changing the state of a signal channel generates an alarm. See the "Retrieving and Clearing Alarms" section for more information on retrieving and clearing alarms.

3.7.2.1 Setting a Signal Channel In-Service

Step 1 Log in to the telephony controller and start an MML session. (See the"Starting MML" section for more information.)

Step 2 Enter the following MML command:

SET-SC-STATE:channel-id:IS

For example, to set the SC1-NAS1 signal channel to In-Service, enter the following command:

SET-SC-STATE:SC1-NAS1:IS

The system returns a message similar to the following:

TransPath: SC22  VA-BLACK/TAN (SC2200) 1999-02-26 16:35:28
M  COMPLD
   "SC1-NAS1"
   ;

Step 3 To verify that the SC1-NAS1 signal channel is In-Service, enter the following command:

RTRV-SC:SC1-NAS1

The system returns a message similar to the following:

TransPath: SC22  VA-BLACK/TAN (SC2200) 1999-02-26 16:50:20
M  RTRV
   "SC1-NAS1:SP1-IP,LID=0:IS"
   ;

The response shows the channel is In-Service.

Figure 3-4 shows in more detail how to set a signal channel In-Service.

Figure 3-4: Setting a Signal Channel In-Service

3.7.2.2 Setting a Signal Channel Out-of-Service

Step 1 Log in to the telephony controller and start an MML session. (See the "Starting MML" section for more information.)

Step 2 Enter the following MML command:

SET-SC-STATE:channel-id:OOS

For example, to set the SC1-NAS1 signal channel to Out-of-Service, enter the following command:

SET-SC-STATE:SC1-NAS1:OOS

The system returns a message similar to the following:

TransPath: SC22  VA-BLACK/TAN (SC2200) 1999-02-26 16:35:28
M  COMPLD
   "SC1-NAS1"
   ;

Step 3 To verify that the SC1-NAS1 signal channel is Out-of-Service, enter the following command:

RTRV-SC:SC1-NAS1

The system returns a message similar to the following:

TransPath: SC22  VA-BLACK/TAN (SC2200) 1999-02-26 16:40:00
M  RTRV
   "SC1-NAS1:SP1-IP,LID=0:OOS,COOS"
   ;

The response shows the channel is Out-of-Service because it was commanded to go to the Out-of-Service state and did not fail.

Figure 3-5 shows in more detail how to set a signal channel to the Out-of-Service state.

Figure 3-5: Setting a Signal Channel Out-of-Service

3.8 Managing Traffic Channels

3.8.1 Retrieving Traffic Channel States

You can retrieve the number and status of all traffic channels for a signaling channel. To retrieve traffic channel states, perform the following steps:

Step 1 Log in to the telephony controller and start an MML session. (See the"Starting MML" section for more information.)

Step 2 Enter the following MML command:

RTRV-TC:channel-id

For example, to retrieve the traffic channel states for the T-2-1 signal channel, enter the following command:

RTRV-TC:T-2-1

The system returns a message similar to the following:

CONFIG01/REL 1.1 97-08-28 18:00:32
M RTRV
"T-2-1:1=is, 2=is, 3=is, 4=is, 5=is, 6=is, 7=is, 8=is, 9=IS,10=IS,11=IS,12=OOS,13=IS,14=IS,15=OOS,16=IS,17=IS, 18=IS,19=IS,20=IS,21=IS,22=IS,23=IS,24=IS,25=IS,26=IS, 27=IS,28=IS,29=IS,30=IS,31=IS";

3.9 Managing Failover

In the failover subsystem, the primary system is paired with a backup system designed to automatically take over as the primary if failure occurs. The failover configuration provides the following:

Minimal interruption of service in the event of failure of a single machine
Maintenance of a consistent configuration on each of the primary and backup machines
Avoidance of false failover that could cause disruption of service

In a failover configuration, one server is explicitly designated as active. The active server controls failover processing as long as it remains active. Major error conditions with the active server trigger automatic failover to the current standby server and generate alarms in the signaling software's alarm manger. Failure of the standby server triggers fault reporting.

If the active server fails, the standby server takes over as the active server. When the failed server comes back online, it becomes the standby server for the server now active.

Note Depending on the number of cards in the servers, there may be a very short period (30 seconds) of service interruption when switching services from the active to standby server.

Failover is controlled by two software processes that run on the active and standby servers. These processes maintain communications between the two servers and control the failover process when failure occurs.

The active server runs the failover daemon (foverd). Foverd automatically activates upon system startup and, in turn, starts the process manager (procM). The process manager then starts the alarm manager, configuration manager, engine, I/O channel controllers, and other processes. (See the "Starting and Stopping the System" section for more information on system processes.)

The standby server runs the replication daemon (frepld). Upon failover implementation, frepld automatically copies changed configuration data from the active server. This allows either server to operate independently in case the other fails.

Failover is started automatically when the server is booted. An active or standby system can be controlled by a user who is logged in as Root.

3.9.1 Switching Active and Standby Servers

Use the following procedure to invoke a manual failover from one server to the other to ensure that the I/O cards handling MTP2 software are reset correctly after call processing has been stopped.

For best results, ensure the following:

Set the link in and out of service accordingly, so that the card firmware does not have to be reloaded.
Be sure to clear the server that was previously active before re-establishing it as the standby when invoking repeated failovers from one server to the other to avoid having to reload the card firmware.
Reset the card firmware before restarting call processing to avoid problems with link alignment.

Step 1 Starting with both the active and standby servers operating normally, identify the platform currently running as active. Log in to the first host server and enter the following command to see if the process manager is running:

ps -eaf | grep procM

If you logged in to the active server, the system returns a message similar to the following:

va-havisu% ps -eaf | grep procM
transpat  9402     1  0 11:07:23 ?        0:02 procM

If you do not see a similar message, this is the standby server. Log in to the other server and perform the same task to ensure that it is the active server.

Note The instructions in this section refers to the server you identified as active in

Step 1

Step 2 Log in to server A as root and enter the following command:

/opt/TransPath/local/cmd_failover.sh STOP

Step 3 Log in to server B and verify that server B has become active and has links in service, as expected, by performing the following steps:

(a) Log in to the telephony controller and start an MML session. See the ("Starting MML" section for more information.)

(b) Enter the following MML command:

RTRV-SOFTW:ALL

The system returns a message similar to the following:

TransPath: TP00  Havisu 1998-12-10 13:40:44
M  RTRV
"CFM-01:RUNNING"
"ALM-01:RUNNING"
"MM-01:RUNNING"
"DMPR-01:RUNNING"
"DSKM-01:RUNNING"
"ENG-01:RUNNING"
"IOCM-01:RUNNING"
"IOCC-01:RUNNING"
"IOCC-02:RUNNING"
;

RTRV-SC:ALL

The system returns a message similar to the following:

TransPath: TP00  Havisu 1998-12-10 13:40:51
M  RTRV
"SC1-NAS1:SP1-IP,LID=0:IS"
/* SC1-NAS1: Sig Channel 1 for IP Sig Path NAS1 */
"DC-1-0:LS-1,LID=0:IS"
/* DC-1-0:  ANSI SS7 */
;

Step 4 Perform any maintenance required on server A.

Step 5 To start server A operating as active, do one of the following:

(a) Reboot the server to return it to In-Service state

(b) Quit MML, change to the /opt/ITK/bin directory, and

./ixload

The system returns a message similar to the following:

ixload: Version 2.03
ixload: Device /dev/ixl,0
 
Loadfile for ix1-primary PCI 8MB V1.0-Release 08.12.1998 17:51 (#483)
Cisco Systems variant
       
Download ix1 software: ixpp.bin \|/-\|/-\|/
 
ixload: Run Firmware ... ok
 
# /etc/init.d/transpath start

Step 6 To bring up server A as active, stop server B using the same procedures described in Step 2 immediately after restarting.

3.9.2 Forcing Failover Out-of-Service

To force failover Out-of-Service, log in to the active server as root and enter the following command:

/opt/TransPath/local/cmd_failover.sh OOS

Note Entering this command takes the active server Out-of-Service and automatically triggers failover to the standby server. Be sure that the standby server is fully operational before taking the current active server Out-of-Service or there will be an interruption of service. As long as the application remains Out-of-Service, it does not respond to failure of the active server. Also, the ARU automatically sets site alarms until the server is returned to In-Service.

3.9.3 Returning an Out-of-Service Server to In-Service

To return an Out-of-Service server to In-Service, log in to the Out-of-Service machine as root and enter the following command:

/opt/TransPath/local/cmd_failover.sh IS

3.10 Where to Go Next

This chapter described how to perform common operational procedures for your telephony controller. See "Retrieving Call Detail Records and Network Measurements," for information on retrieving call detail records and other measurements. See "Maintenance Procedures," for information on performing disk space management and data backups. See "Troubleshooting Your System," for information on retrieving and clearing alarms, performing call traces, and contacting Cisco's Technical Assistance Center (TAC).

Table of Contents

Operating Your Telephony Controller