Table Of Contents

Maintaining the Cisco SIP Proxy Server (CSPS)

Starting and Stopping the CSPS

CSPS with All Components Installed (including Provisioning)

Starting the CSPS

Stopping the CSPS

Restarting the CSPS

Gracefully Restarting the CSPS

CSPS Installed without Provisioning

Starting the CSPS

Stopping the CSPS

Restarting the CSPS

Gracefully Restarting the CSPS

Working with Logs

Viewing and Customizing Logs

SIP Proxy Server (sipd): access_log, error_log and stats_log

Provisioning client for sipd (spa): spa_log

Provisioning Server (pserver): pserver_log

License manager (lm): licenseMgr_log

Installation script (csps_setup): csps_setup_log

Rotating Logs

Backing Up and Restoring CSPS

Backing Up Data

Restoring Backed Up Data

Maintaining the Cisco SIP Proxy Server (CSPS)

---

This chapter contains the following information:

•Starting and Stopping the CSPS

•Working with Logs

•Backing Up and Restoring CSPS

See "Product Overview", "CSPS Components" section for detail on CSPS components.

Starting and Stopping the CSPS

This section describes how to start, stop, and restart CSPS by using the sip script. If SNMP is used, CSPS can also be started, stopped, restarted, and gracefully restarted via SNMP using CIAgent. See "CIAgent".

The sip script, newly offered with CSPS 2.0, provides the functionality in the sipdctl script in previous releases. The sip script is generated from running csps_setup during installation of CSPS. If CSPS is installed without using csps_setup, a default sip script is generated. See Cisco SIP Proxy Server (CSPS) Installation Guide for installation detail.

The default sip script assumes CSPS is installed without the provisioning system. When csps_setup is used, a new sip script is created, taking into account that all the components are installed. The location of the script is <ServerRoot>/bin/sip. Scripts to start and stop each individual component exist in the same directory. It is suggested not to use the component scripts individually. The sip script should be used to invoke all the component scripts in the appropriate order and with the necessary precondition checking.

The following sections describe the procedures for starting and stopping CSPS by using the sip script. The actions and results of using this script vary depending on which components are installed on the system. Two configurations are illustrated. The first configuration has all components exist on the system (default configuration for CSPS 2.0, set up by using option 1 of csps_setup during installation). The second configuration only has CSPS server exist on the system, and the provisioning system is not used (standard configuration supported for CSPS 1.x and also CSPS 2.0).

---

Note•Before starting the CSPS, be sure to properly install CSPS and all desired components. See Cisco SIP Proxy Server (CSPS) Installation Guide for detail.

•If errors occur when the CSPS starts, stops, restarts, or gracefully restarts, the corresponding error messages are displayed in /var/log/messages (Linux) or on the screen (Solaris). Additional details can be found by viewing the log files for each process. See "Working with Logs" section.

---

CSPS with All Components Installed (including Provisioning)

Starting the CSPS

To start the CSPS, use the following steps.

---

Step 1 Execute the sip script with the start argument, as follows.

[/usr/local/sip/bin] ./sip start

The following display appears.

Starting pserver:                                          [  OK  ]

Starting license manager:                                  [  OK  ]

Starting spa:                                              [  OK  ]

Starting sipd:                                             [  OK  ]

---

Note For Linux, the default location for the script is /usr/local/sip/bin. For Solaris, the location is /opt/sip/bin.

---

If the server initializes without error, the following appears in the file /var/log/messages (for Linux) or on the screen (for Solaris).

pserverctl: /usr/local/sip/bin/pserverctl start: pserver started

sip: Starting pserver:  succeeded

lmctl: /usr/local/sip/bin/lmctl start: licenseMgr started

sip: Starting license manager:  succeeded

spactl: /usr/local/sip/bin/spactl start: spa started

spactl: /usr/local/sip/bin/spactl start: Waiting for sipd.conf from spa..

spactl: .

spactl: /usr/local/sip/bin/spactl start: sipd.conf written

sip: Starting spa:  succeeded

sipdctl: Version of CSPS        : 2.0.x.x - Experimental Version

sipdctl: Version in Config file : 2.0.x.x - Experimental Version

sipdctl: Software release version of CSPS validated successfully with your license

sipdctl: License validated successfully

sipdctl: This is Permanent license, with Infrastructure functionality

sipdctl: /usr/local/sip/bin/sipdctl start: sipd started

sip: Starting sipd:  succeeded

Step 2 To verify the CSPS is running properly, issue the following command to view all csps processes:

[/usr/local/sip/bin] ps -ef | grep "/sip/bin"

An output similar to the following appears.

csps      4040     1  0 17:38 ?        00:00:00 /usr/local/sip/bin/pserver -c /u

csps      4054     1  0 17:38 ?        00:00:00 /usr/local/sip/bin/licenseMgr /u

csps      4057  4040  0 17:38 ?        00:00:00 /usr/local/sip/bin/pserver -c /u

csps      4058  4057  0 17:38 ?        00:00:00 /usr/local/sip/bin/pserver -c /u

csps      4060  4057  0 17:38 ?        00:00:00 /usr/local/sip/bin/pserver -c /u

csps      4064  4054  0 17:38 ?        00:00:00 /usr/local/sip/bin/licenseMgr /u

csps      4065  4064  0 17:38 ?        00:00:00 /usr/local/sip/bin/licenseMgr /u

csps      4068     1  0 17:38 ?        00:00:00 /usr/local/sip/bin/spa /usr/loca

csps      4074     1  0 17:38 ?        00:00:00 /usr/local/sip/bin/Sip_Services 

csps      4080  4068  0 17:38 ?        00:00:00 /usr/local/sip/bin/spa /usr/loca

csps      4081  4080  0 17:38 ?        00:00:00 /usr/local/sip/bin/spa /usr/loca

csps      4092     1  0 17:38 pts/1    00:00:00 /usr/local/sip/bin/sipd

csps      4094  4092  0 17:38 pts/1    00:00:00 /usr/local/sip/bin/sipd

csps      4096  4092  0 17:38 pts/1    00:00:00 /usr/local/sip/bin/sipd

csps      4097  4092  0 17:38 pts/1    00:00:00 /usr/local/sip/bin/sipd

csps      4100  4092  0 17:38 pts/1    00:00:00 /usr/local/sip/bin/sipd

csps      4101  4092  0 17:38 pts/1    00:00:00 /usr/local/sip/bin/sipd

csps      4102  4092  0 17:38 pts/1    00:00:00 /usr/local/sip/bin/sipd

root      4107  1387  0 17:39 pts/1    00:00:00 grep /sip/bin

There should be 4 pserver processes, 3 licenseMgr processes, and 3 spa processes. By default, there should be 7 sipd processes. In this example, the first sipd process, with the parent process id as 1, is the parent sipd. The other sipd processes are the TCP I/O process and 5 child processes. Sip_Services is an additional process required to maintain synchronization among local and remote farm members.

---

Stopping the CSPS

To stop all CSPS processes, use the following steps.

---

Step 1 Issue the following command:

[/usr/local/sip/bin] ./sip stop

The following display appears.

Stopping sipd:                                             [  OK  ]

Stopping spa:                                              [  OK  ]

Stopping license manager:                                  [  OK  ]

Stopping pserver:                                          [  OK  ]

Output similar to the following appears in /var/log/messages (Linux) or on the screen (Solaris).

sipdctl: Waiting for process to stop.

sipdctl: .

sipdctl: /usr/local/sip/bin/sipdctl stop: sipd stopped

sipdctl: Waiting for process to stop.

sipdctl: .

sipdctl: /usr/local/sip/bin/sipdctl stop: Sip_Services stopped

sip: Stopping sipd:  succeeded

spactl: Waiting for process to stop.

spactl: .

spactl: /usr/local/sip/bin/spactl stop: spa stopped

sip: Stopping spa:  succeeded

lmctl: Waiting for process to stop.

lmctl: .

lmctl: /usr/local/sip/bin/lmctl stop: licenseMgr stopped

sip: Stopping license manager:  succeeded

pserverctl: Waiting for process to stop.

pserverctl: .

pserverctl: /usr/local/sip/bin/pserverctl stop: pserver stopped

sip: Stopping pserver:  succeeded

Step 2 At this point, all CSPS processes are stopped and the server is no longer able to process calls. This may be verified by issuing the following command:

[/usr/local/sip/bin] ps -ef | grep "/sip/bin"

csps 16421 15876 0 09:47 pts/0 00:00:00 grep sip/bin

If pserver, licenseMgr, spa, sipd processes or Sip_Services processes still exist, it is advisable to stop them manually by using the Unix command, kill.

---

Restarting the CSPS

To restart (stop and then start) all CSPS processes, use the following steps.

---

Step 1 Issue the following command:

[/usr/local/sip/bin] ./sip restart

The following display appears.

Stopping sipd:                                             [  OK  ]

Stopping spa:                                              [  OK  ]

Stopping license manager:                                  [  OK  ]

Stopping pserver:                                          [  OK  ]

Starting pserver:                                          [  OK  ]

Starting license manager:                                  [  OK  ]

Starting spa:                                              [  OK  ]

Starting sipd:                                             [  OK  ]

As shown above, this command stops all server processes, then starts them. An output similar to the following appears in /var/log/messages (Linux) or on the screen (Solaris):

sipdctl: Waiting for process to stop.

sipdctl: .

sipdctl: /usr/local/sip/bin/sipdctl stop: sipd stopped

sipdctl: Waiting for process to stop.

sipdctl: .

sipdctl: /usr/local/sip/bin/sipdctl stop: Sip_Services stopped

sip: Stopping sipd:  succeeded

spactl: Waiting for process to stop.

spactl: .

spactl: /usr/local/sip/bin/spactl stop: spa stopped

sip: Stopping spa:  succeeded

lmctl: Waiting for process to stop.

lmctl: .

lmctl: /usr/local/sip/bin/lmctl stop: licenseMgr stopped

sip: Stopping license manager:  succeeded

pserverctl: Waiting for process to stop.

pserverctl: .

pserverctl: /usr/local/sip/bin/pserverctl stop: pserver stopped

sip: Stopping pserver:  succeeded

pserverctl: /usr/local/sip/bin/pserverctl start: pserver started

sip: Starting pserver:  succeeded

lmctl: /usr/local/sip/bin/lmctl start: licenseMgr started

sip: Starting license manager:  succeeded

spactl: /usr/local/sip/bin/spactl start: spa started

spactl: /usr/local/sip/bin/spactl start: Waiting for sipd.conf from spa..

spactl: .

spactl: /usr/local/sip/bin/spactl start: sipd.conf written

sip: Starting spa:  succeeded

sipdctl: Version of CSPS        : 2.0.x.x - Experimental Version

sipdctl: Version in Config file : 2.0.x.x - Experimental Version

sipdctl: Software release version of CSPS validated successfully with your license

sipdctl: License validated successfully

sipdctl: This is Permanent license, with Infrastructure functionality

sipdctl: /usr/local/sip/bin/sipdctl start: sipd started

sip: Starting sipd:  succeeded

Step 2 To verify that CSPS is running properly, issue the following command to view all csps processes:

[/usr/local/sip/bin] ps -ef | grep "/sip/bin"

An output similar to the following appears.

[/usr/local/sip/bin]# ps -ef | grep "/sip/bin"

csps      4216     1  0 17:58 ?        00:00:00 /usr/local/sip/bin/pserver -c /u

csps      4225     1  0 17:58 ?        00:00:00 /usr/local/sip/bin/licenseMgr /u

csps      4232  4225  0 17:58 ?        00:00:00 /usr/local/sip/bin/licenseMgr /u

csps      4233  4232  0 17:58 ?        00:00:00 /usr/local/sip/bin/licenseMgr /u

csps      4235  4216  0 17:58 ?        00:00:00 /usr/local/sip/bin/pserver -c /u

csps      4236  4235  0 17:58 ?        00:00:00 /usr/local/sip/bin/pserver -c /u

csps      4240  4235  0 17:58 ?        00:00:00 /usr/local/sip/bin/pserver -c /u

csps      4241     1  0 17:58 ?        00:00:00 /usr/local/sip/bin/spa /usr/loca

csps      4245     1  0 17:58 ?        00:00:00 /usr/local/sip/bin/Sip_Services 

csps      4252  4241  0 17:58 ?        00:00:00 /usr/local/sip/bin/spa /usr/loca

csps      4253  4252  0 17:58 ?        00:00:00 /usr/local/sip/bin/spa /usr/loca

csps      4264     1  0 17:58 pts/1    00:00:00 /usr/local/sip/bin/sipd

csps      4266  4264  0 17:58 pts/1    00:00:00 /usr/local/sip/bin/sipd

csps      4268  4264  0 17:58 pts/1    00:00:00 /usr/local/sip/bin/sipd

csps      4269  4264  0 17:58 pts/1    00:00:00 /usr/local/sip/bin/sipd

csps      4270  4264  0 17:58 pts/1    00:00:00 /usr/local/sip/bin/sipd

csps      4271  4264  0 17:58 pts/1    00:00:00 /usr/local/sip/bin/sipd

csps      4276  4264  0 17:58 pts/1    00:00:00 /usr/local/sip/bin/sipd

root      4279  1387  0 18:00 pts/1    00:00:00 grep /sip/bin

---

Note All the process ids are different from those that were used before issuing the restart. During the time between the stop and start, the server cannot process any calls.

---

---

Gracefully Restarting the CSPS

Graceful restart provides a mechanism to prompt spa to write a new sipd.conf file, then the parent sipd reread the configuration file (sipd.conf), tear down the child sipd processes as they become idle, and spawn new child processes with the new configuration.

Graceful restart is usually used when a configuration change is made and the change is to be put in service. To gracefully restart the CSPS, use the following steps.

---

Step 1 Issue the following command:

[/usr/local/bin] ./sip graceful

The following display appears.

Gracefully restarting pserver:                             [  OK  ]

Gracefully restarting license manager:                     [  OK  ]

Gracefully restarting spa:                                 [  OK  ]

Gracefully restarting sipd:                                [  OK  ]

An output similar to the following appears in /var/log/messages (Linux) or on the screen (Solaris):

pserverctl: /usr/local/sip/bin/pserverctl graceful: pserver (pid 3749 3769 3770 3775) 
already running

sip: Gracefully restarting pserver:  succeeded

lmctl: /usr/local/sip/bin/lmctl graceful: licenseMgr (pid 3764 3766 3767) already running

sip: Gracefully restarting license manager:  succeeded

spactl: Waiting for process to stop.

spactl: .

spactl: /usr/local/sip/bin/spactl stop: spa stopped

spactl: Wait 3 seconds before restarting the application...

spactl: /usr/local/sip/bin/spactl start: spa started

spactl: /usr/local/sip/bin/spactl start: Waiting for sipd.conf from spa..

spactl: .

spactl: /usr/local/sip/bin/spactl start: sipd.conf written

sip: Gracefully restarting spa:  succeeded

sipdctl: /usr/local/sip/bin/sipdctl graceful: sipd gracefully restarted

sip: Gracefully restarting sipd:  succeeded

Step 2 Issue the following command to view all csps processes:

[/usr/local/sip/bin] ps -ef | grep "sip/bin"

The following process listing shows the original pserver and licenseMgr processes as they are not affected by a graceful restart. The spa processes are restarted to force the writing of a new sipd.conf file. The parent sipd process, the original Sip_Services, and the TCP I/O sipd process remain the same as from the previous start of the server. All other sipd child processes have been restarted and have new process ids.

[/usr/local/sip/bin] ps -ef | grep "sip/bin"

csps      4216     1  0 17:58 ?        00:00:00 /usr/local/sip/bin/pserver -c /u

csps      4225     1  0 17:58 ?        00:00:00 /usr/local/sip/bin/licenseMgr /u

csps      4232  4225  0 17:58 ?        00:00:00 /usr/local/sip/bin/licenseMgr /u

csps      4233  4232  0 17:58 ?        00:00:00 /usr/local/sip/bin/licenseMgr /u

csps      4235  4216  0 17:58 ?        00:00:00 /usr/local/sip/bin/pserver -c /u

csps      4236  4235  0 17:58 ?        00:00:00 /usr/local/sip/bin/pserver -c /u

csps      4240  4235  0 17:58 ?        00:00:00 /usr/local/sip/bin/pserver -c /u

csps      4264     1  0 17:58 pts/1    00:00:00 /usr/local/sip/bin/sipd

csps      4266  4264  0 17:58 pts/1    00:00:00 /usr/local/sip/bin/sipd

csps      4334     1  0 18:02 ?        00:00:00 /usr/local/sip/bin/spa /usr/loca

csps      4337     1  0 18:02 ?        00:00:00 /usr/local/sip/bin/Sip_Services 

csps      4344  4334  0 18:02 ?        00:00:00 /usr/local/sip/bin/spa /usr/loca

csps      4345  4344  0 18:02 ?        00:00:00 /usr/local/sip/bin/spa /usr/loca

csps      4357  4264  0 18:02 pts/1    00:00:00 /usr/local/sip/bin/sipd

csps      4358  4264  0 18:02 pts/1    00:00:00 /usr/local/sip/bin/sipd

csps      4359  4264  0 18:02 pts/1    00:00:00 /usr/local/sip/bin/sipd

csps      4360  4264  0 18:02 pts/1    00:00:00 /usr/local/sip/bin/sipd

csps      4361  4264  0 18:02 pts/1    00:00:00 /usr/local/sip/bin/sipd

root      4370  1387  0 18:13 pts/1    00:00:00 grep /sip/bin

---

Note When there is a server configuration change, perform a graceful restart to activate the new configuration without dropping any existing or pending calls. When the sip graceful command is used, the sipd daemon (parent process) remains alive and it kills the child processes as soon as they are not processing calls. Call processing is not interrupted as a result.

---

---

If the TCP I/O process of CSPS becomes unresponsive, the parent sipd performs its own graceful restart (up to five times) to activate the TCP I/O process. If the graceful restart fails to activate the TCP I/O process, you can perform graceful restart manually after one minute.

CSPS Installed without Provisioning

Starting the CSPS

To start the CSPS, use the following steps.

---

Step 1 Execute the sip script with the start argument, as follows:

[/usr/local/sip/bin] ./sip start

Starting sipd:                                             [  OK  ]

---

Note For Linux, the default location for the script is /usr/local/sip/bin. For Solaris, the location is /opt/sip/bin.

---

If the server initializes without error, the following appears in the file /var/log/messages (for Linux) or on the screen (for Solaris).

sipdctl: Version of CSPS        : 2.0.x.x - Experimental Version

sipdctl: Version in Config file : 2.0.x.x - Experimental Version

sipdctl: Software release version of CSPS validated successfully with your license

sipdctl: License validated successfully

sipdctl: This is Permanent license, with Infrastructure functionality

sipdctl: /usr/local/sip/bin/sipdctl start: sipd started

sip: Starting sipd:  succeeded

Step 2 To verify the CSPS is running properly, issue the following command to view all csps processes:

[/usr/local/sip/bin] ps -ef | grep "/sip/bin"

An output similar to the following appears.

csps 16394 1 4 09:40 pts/0	00:00:00 /usr/local/sip/bin/sipd

csps 16396 1 1 09:40 pts/0	00:00:00 /usr/local/sip/bin/Sip_Services 

csps 16397 16394 0 09:40 pts/0 00:00:00 /usr/local/sip/bin/sipd

csps 16399 16394 0 09:40 pts/0 00:00:00 /usr/local/sip/bin/sipd

csps 16400 16394 0 09:40 pts/0 00:00:00 /usr/local/sip/bin/sipd

csps 16401 16394 0 09:40 pts/0 00:00:00 /usr/local/sip/bin/sipd

csps 16402 16394 0 09:40 pts/0 00:00:00 /usr/local/sip/bin/sipd

csps 16408 16394 0 09:40 pts/0 00:00:00 /usr/local/sip/bin/sipd

csps 16410 15876 0 09:54 pts/0 00:00:00 grep sip/bin

By default, there should be 7 sipd processes. In this example, the first sipd process, with the parent process id as 1, is the parent sipd. The other sipd processes are the TCP I/O process and 5 child processes. Sip_Services is an additional process required to maintain synchronization among local and remote farm members.

---

Stopping the CSPS

To stop all CSPS processes, use the following steps.

---

Step 1 Issue the following command:

[/usr/local/sip/bin] ./sip stop

Stopping sipd:                                             [  OK  ]

Output similar to the following appears in /var/log/messages (Linux) or on the screen (Solaris):

sipdctl: Waiting for process to stop.

sipdctl: /usr/local/sip/bin/sipdctl stop: sipd stopped

sip: Stopping sipd:  succeeded

Step 2 At this point, all CSPS processes are stopped and the server is no longer able to process calls. This may be verified by issuing the following command:

[/usr/local/sip/bin] ps -ef | grep "/sip/bin"

csps 16421 15876 0 09:47 pts/0 00:00:00 grep sip/bin

If sipd processes or Sip_Services processes still exist, it is advisable to stop them manually by using the Unix command, kill.

---

Restarting the CSPS

To restart (stop and then start) all CSPS processes, use the following steps.

---

Step 1 Issue the following command:

[/usr/local/sip/bin] ./sip restart

Stopping sipd:                                             [  OK  ]

Starting sipd:                                             [  OK  ]

This command stops all server processes, then starts them. An output similar to the following appears in /var/log/messages (Linux) or on the screen (Solaris):

sipdctl: Waiting for process to stop.

sipdctl: /usr/local/sip/bin/sipdctl stop: sipd stopped

sip: Stopping sipd:  succeeded

sipdctl: Version of CSPS        : 2.0.x.x - Experimental Version

sipdctl: Version in Config file : 2.0.x.x - Experimental Version

sipdctl: Software release version of CSPS validated successfully with your license

sipdctl: License validated successfully

sipdctl: This is Permanent license, with Infrastructure functionality

sipdctl: /usr/local/sip/bin/sipdctl start: sipd started

sip: Starting sipd:  succeeded

Step 2 To verify that CSPS is running properly, issue the following command to view all csps processes:

[/usr/local/sip/bin] ps -ef | grep "/sip/bin"

An output similar to the following appears.

csps 16454 1 0 09:53 pts/0 00:00:00 /usr/local/sip/bin/sipd

csps 16456 1 0 09:53 pts/0 00:00:00 /usr/local/sip/bin/Sip_Services 

csps 16457 16454 0 09:53 pts/0 00:00:00 /usr/local/sip/bin/sipd

csps 16459 16454 0 09:53 pts/0 00:00:00 /usr/local/sip/bin/sipd

csps 16460 16454 0 09:53 pts/0 00:00:00 /usr/local/sip/bin/sipd

csps 16461 16454 0 09:53 pts/0 00:00:00 /usr/local/sip/bin/sipd

csps 16464 16454 0 09:53 pts/0 00:00:00 /usr/local/sip/bin/sipd

csps 16465 16454 0 09:53 pts/0 00:00:00 /usr/local/sip/bin/sipd

csps 16470 15876 0 09:54 pts/0 00:00:00 grep sip/bin

---

Note All the process ids are different from those that were used before issuing the restart. During the time between the stop and start, the server cannot process any calls.

---

---

Gracefully Restarting the CSPS

Graceful restart provides a mechanism to prompt the parent sipd process to reread the configuration file (sipd.conf), tear down the child sipd processes as they become idle, and spawn new child processes with the new configuration.

Graceful restart is usually used when a configuration change is made and the change is to be put in service. To gracefully restart the CSPS, use the following steps.

---

Step 1 Issue the following command:

[/usr/local/bin] ./sip graceful

Gracefully restarting sipd:                                [  OK  ]

An output similar to the following appears in /var/log/messages (Linux) or on the screen (Solaris):

sipdctl: /usr/local/sip/bin/sipdctl graceful: sipd gracefully restarted

sip: Gracefully restarting sipd:  succeeded

Step 2 Issue the following command to view all csps processes:

[/usr/local/sip/bin] ps -ef | grep "sip/bin"

The following process listing shows the original parent sipd process, the original Sip_Services, and TCP I/O sipd process. They are from the previous start of the server. All other sipd child processes have been restarted and have new process ids.

[/usr/local/sip/bin] ps -ef | grep "sip/bin"

csps 16454 1 0 09:53 pts/0 00:00:00 /usr/local/sip/bin/sipd

csps 16456 1 0 09:53 pts/0 00:00:00 /usr/local/sip/bin/Sip_Services

csps 16457 16454 0 09:53 pts/0 00:00:00 /usr/local/sip/bin/sipd

csps 16500 16454 0 10:01 pts/0 00:00:00 /usr/local/sip/bin/sipd

csps 16501 16454 1 10:01 pts/0 00:00:00 /usr/local/sip/bin/sipd

csps 16502 16454 0 10:01 pts/0 00:00:00 /usr/local/sip/bin/sipd

csps 16503 16454 0 10:01 pts/0 00:00:00 /usr/local/sip/bin/sipd

csps 16504 16454 0 10:01 pts/0 00:00:00 /usr/local/sip/bin/sipd

csps 16511 15876 0 10:01 pts/0 00:00:00 grep sip/bin

---

Note When there is a server configuration change, perform a graceful restart to activate the new configuration without dropping any existing or pending calls. When the sip graceful command is used, the sipd daemon (parent process) remains alive and it kills the child processes as soon as they are not processing calls. Call processing is not interrupted as a result.

---

---

If the TCP I/O process of CSPS ever becomes unresponsive, the parent sipd performs its own graceful restart (up to five times) to activate the TCP I/O process. If the graceful restart fails to activate the TCP I/O process, the user can perform graceful restart manually after one minute.

Working with Logs

During operation, each component of CSPS writes to one or more log files. The log files written by each component are as follows.

•SIP Proxy Server (sipd): access_log, error_log and stats_log

•Provisioning client for sipd (spa): spa_log

•Provisioning Server (pserver): pserver_log

•License manager (lm): licenseMgr_log

•Installation script (csps_setup): csps_setup_log

The default location for all log files is <ServerRoot>/logs.

---

Note For Linux, <ServerRoot> is /usr/local/sip/. For Solaris, <ServerRoot> is /opt/sip/

---

Viewing and Customizing Logs

All log files are text files which can be viewed with any text editor. In most cases, the content and level of detail of the log files is controlled by configuration directives. The following sections describe these log files.

SIP Proxy Server (sipd): access_log, error_log and stats_log

sipd reuses Apache existing logging facilities with enhancements to selectively enable and disable a particular module or functionality. Access logging, error logging, and statistics logging are configured and controlled by the DebugFlag configuration file directives. These can be modified by using the provisioning system GUI, or by manually editing sipd.conf if not using the GUI. By default, all internal errors are logged to <ServerRoot>/logs/error_log, access records are logged to <ServerRoot>/logs/access_log, and periodic statistics are written to <ServerRoot>/logs/stats_log.

The logs in error_log can contain the following formats, depending on the values of the DebugFlags.

Format 1

This format is printed unconditionally. Logs in this format are usually informational and contain some important error messages.

[Fri Apr 20 21:44:51 2001] [notice] A new Apache child process (27413) has started.

Format 2

This format is printed when a component DebugFlag is turned on. For instance, if the StateMachine DebugFlag directive is turned on, a call trace similar to the following example is logged to the error_log file.

[Fri Apr 13 22:29:37 2001] sip_protocol.c(4322) Received 291 bytes UDP packets from 
10.80.36.85:50117

REGISTER sip:64.102.93.77 SIP/2.0

Via:SIP/2.0/UDP 10.80.36.85:5060

From:sip:IPphone-2@64.102.93.77

To:sip:IPphone-2@64.102.93.77

Call-ID:c3943000-ee2f9c88-23f9821e-382e3031@10.80.36.85

CSeq:101 REGISTER

Contact:<sip:IPphone-2@10.80.36.85:5060>

Expires:3600

Provisioning client for sipd (spa): spa_log

spa logs to spa_log based on the value of the configuration directive DebugLevel in spa.conf. spa.conf is located in <ServerRoot>/conf/prov. To change the level of detail provided in the log file, manually edit the spa.conf file and set the DebugLevel to the desired level, in the order of decreasing verbosity: debug, info, notice, warn, error, crit, alert, emerg.

Provisioning Server (pserver): pserver_log

pserver logs to pserver_log based on the value of the configuration directive DebugLevel in ps.conf. ps.conf is located in <ServerRoot>/conf/prov. To change the level of detail provided in the log file, manually edit the ps.conf file and set the DebugLevel to the desired level, in the order of decreasing verbosity: debug, info, notice, warn, error, crit, alert, emerg.

License manager (lm): licenseMgr_log

lm logs to licenseMgr_log based on the value of the configuration directive DebugLevel in lm.conf. lm.conf is located in <ServerRoot>/conf/prov. To change the level of detail provided in the log file, manually edit the lm.conf file and set the DebugLevel to the desired level, in the order of decreasing verbosity: debug, info, notice, warn, error, crit, alert, emerg.

Installation script (csps_setup): csps_setup_log

csps_setup logs to csps_setup_log. There is no configuration directive for it. It should be consulted to verify the correctness of an installation. In the event of a failures during installation or at first startup, it may provide helpful clues to the problems.

Rotating Logs

---

Note This section applies to log files written by sipd only.

---

The size of the error_log can grow significantly if many DebugFlags are turned on. To better maintain the log file and preserve the server information, utilize the log rotation facility included in the CSPS.

•To turn on error_log rotation, enter the following command in the Custom Logs section of the provisioning system GUI. If provisioning is not used, remove the comment marker in the following line in the sipd.conf file. This instructs the CSPS to rotate the logs/error_log file every 86400 seconds (24 hours).

ErrorLog "|ServerRoot/bin/rotatelogs ServerRoot/logs/error_log 86400"

•To turn on error_log rotation, enter the following command in the Custom Logs section of the provisioning system GUI. If provisioning is not used, remove the comment marker in the following line in the sipd.conf file. This instructs the CSPS to rotate the logs/access_log file every 86400 seconds (24 hours).

TransferLog "|ServerRoot/bin/rotatelogs ServerRoot/logs/access_log 86400"

---

Note The comment markers of "CustomLog logs/access_log common" and "ErrorLog logs/error_log" should be removed if the comment markers of the above two rotatelogs lines are removed.

---

Backing Up and Restoring CSPS

In order to be able to recover quickly from catastrophic failures which render one or more servers unavailable, it is advisable to back up all important CSPS data on a regular basis.

The following sections describe the backup procedures, and how to use the backed up data to restore CSPS on a new system.

Backing Up Data

The following steps should be performed on a regular basis.

---

Note It is strongly recommended to store the backed up data on a separate system or eternal media for safeguard reasons.

---

---

Step 1 If MySQL is run for the provisioning system, or subscriber features, or both, save all the data to a flat file with the following commands.

mysqldump -u guest -p --databases sip > <outside_directory/file>

Enter password: <default password is "nobody">

---

Note If MySQL is not on the same system as CSPS, run the above commands on the system where MySQL is running.

---

Step 2 If registries exist, export them to a file by using the sysadmin_csps_regroute tool and make the following selections:

<S> Select registry (default) or routing database

<Y> use registry database

<M> return to Main menu

<X> eXport current database entries to a configuration <outside_directory/file>

Step 3 If static routes exist, export them to a file by using the sysadmin_csps_regroute tool and make the following selections:

<S> Select registry (default) or routing database

<Z> use routing database

<M> return to Main menu

<X> eXport current database entries to a configuration <outside_directory/file>

Step 4 Copy the license.conf, persistent_tcp.conf, and sipd.conf files:

a. For Solaris

cp /opt/sip/conf/license.conf <outside_directory/file>

cp /opt/sip/conf/persistent_tcp.conf <outside_directory/file>

cp /opt/sip/conf/sipd.conf <outside_directory/file>

b. For Linux

cp /usr/local/sip/conf/license.conf <outside_directory/file>

cp /usr/local/sip/conf/persistent_tcp.conf <outside_directory/file>

cp /usr/local/sip/conf/sipd.conf <outside_directory/file>

---

---

Note If provisioning is used, it is not necessary to back up sipd.conf. It will be regenerated from the information stored in MySQL.

---

Restoring Backed Up Data

Before restoring CSPS on a system, it is recommended to uninstall CSPS so the system is in a known state, if CSPS is originally installed on this system. Then install CSPS. See Cisco SIP Proxy Server (CSPS) Installation Guide for details on uninstalling and installing CSPS.

---

Note It is recommended to use csps_setup script for installation. When the license key prompt appears, reference the saved license.conf file in case the license key from the initial installation is not readily available.

---

---

Step 1 If MySQL is run for the provisioning system, for subscriber features, or for both, restore the database from the saved flat file with the following commands:

a. Delete existing sip database (if any)

mysql -u guest -p

Enter password: <default password is "nobody">

at mysql> prompt type:

drop database sip;

quit;

b. Restore previously saved sip database

mysql -u guest -p < <mysql_backup_file>

Enter password: <default password is "nobody">

c. Delete any old provisioning server connection data (required only if using provisioning)

mysql -u guest -p

Enter password: <default password is "nobody">

at mysql> prompt type:

use sip;

delete from DBSubscriberTable;

quit;

Step 2 Import saved registries, if any, to shared memory from the backup file by using the sysadmin_csps_regroute tool and make the following selections:

<S> Select registry (default) or routing database

<Y> use registry database

<M> return to Main menu

<I> Import a configuration <file> with route/registry entries <registry_backup_file>

---

Note If this is a member of a multiple member farm, import to shared memory on the first member only. If an active member already exists with a current registry database, this step may be skipped, since the farm members will synchronize the database automatically.

---

Step 3 Import saved static routes to shared memory from the backup file by using the sysadmin_csps_regroute tool and make the following selections:

<S> Select registry (default) or routing database

<Z> use routing database

<M> return to Main menu

<I> Import a configuration <file> with route/registry entries <route_backup_file>

---

Note If this is a member of a multiple member farm, import to shared memory on the first member only. If an active member already exists with a current route database, this step may be skipped, since the farm members will synchronize the database automatically.

---

Step 4 Restore the license.conf, persistent_tcp.conf, and sipd.conf files as follows.

a. For Solaris

cp <license.conf_backup file> /opt/sip/conf/license.conf

cp <persistent_tcp.conf_backup_file> /opt/sip/conf/persistent_tcp.conf

cp <sipd.conf_backup_file> /opt/sip/conf/sipd.conf

b. For Linux

cp <license.conf_backup file> /usr/local/sip/conf/license.conf

cp <persistent_tcp.conf_backup_file> /usr/local/sip/conf/persistent_tcp.conf

cp <sipd.conf_backup_file> /usr/local/sip/conf/sipd.conf

---

Note If csps_setup was used to install CSPS, it is not necessary to restore license.conf as it will be generated from the information entered while csps_setup is being run. If provisioning is used, it is not necessary to restore sipd.conf, since it will be regenerated from the information stored in MySQL at the next start, restart, or graceful restart.

---

Step 5 Gracefully restart CSPS to use the new sipd.conf

a. For Solaris

/opt/sip/bin/sip graceful

b. For Linux

/usr/local/sip/bin/sip graceful