Managing and Troubleshooting the Cisco VoIP Infrastructure Solution for SIP
This chapter describes tools that you can use to manage and troubleshoot the Cisco VoIP Infrastructure Solution for SIP. It also includes tips for problem isolation and suggested actions for resolution. It includes the following sections:
Using CVM 2.0 to Manage the Cisco VoIP Infrastructure Solution for SIP
Ciscoworks2000 Voice Manager (CVM) is a client-server, web-based voice management solution used by network administrators to configure and manage voice ports and create and modify dial plans on voice-enabled Cisco routers. Using CVM, network administrators can:
Manage the configuration of FXO, FXS, E&M, and ISDN voice interfaces on voice-enabled routers
Create and manage local (POTS) dial plans on voice-enabled routers
Generate detailed reports using Telemate.net Quickview
Note CVM is not a device configuration tool. Devices supported by CVM must first be configured through
the CLI and have Simple Network Management Protocol (SNMP) enabled before they can be
managed by CVM. You can then use CVM to modify the configuration of voice ports and create and
manage local and network dial plans.
Note For complete information about using CVM to manage your SIP VoIP infrastructure, see the
CiscoWorks2000 Voice Manager 2.0 documentation.
Prerequisites
The CVM Server requires the following:
Note System requirements for the server are based on software requirements and a call volume of
96,000 calls per hour. The call volume is based on an estimated 20 calls per DS0 channel, 3
minutes holding time, and 60 busy minutes.
256 MB of memory
CPU running at 450 MHz
8 GB of available hard disk space
Windows NT 4.0 with Service Pack 5
CiscoWorks2000 CD One
The CVM Client requires the following:
64 MB of memory
CPU running at 300 MHz
One of the following:
Windows 95 running Netscape 4.04 or Internet Explorer 4.01 and 64 MB of virtual memory
Windows NT running Netscape 4.04 or Internet Explorer 4.01 and 64 MB of virtual memory
Solaris running Netscape 4.04 with Telnet and Java enabled and 64 MB of virtual memory
Display settings of:
1024 x 768 resolution
16-bit color palette
Before you can use CVM to manage your voice network, for each router that you are going to add to CVM:
You must have network access to the router.
You must know the IP address of the router.
You must know all the passwords for the router.
You must know the SNMP read community string for the router.
Telnet must be enabled on the router. Because Telnet is used by CVM to communicate with a router, session timeout should be configured to a non-zero value for all tty lines.
SNMP must be enabled on the router.
Note For detailed information about using CVM to manage your SIP VoIP infrastructure, see the
CiscoWorks2000 Voice Manager 2.0 documentation.
Troubleshooting the Cisco VoIP Infrastructure Solution for SIP
This section provides procedural and reference information that you can use to determine and resolve problems you might experience while using the SIP components of the Cisco VoIP Infrastructure Solution for SIP.
Note For troubleshooting information on the other components of the Cisco VoIP Infrastructure Solution
for SIP (Cisco uOne Messaging System, Cisco Secure PIX Firewall, and the SS7 Interconnect for
VoIP Gateways Solution, see the documentation for those products.
Troubleshooting the Cisco SIP IP Phone 7960
This section describes troubleshooting features and tips for the Cisco SIP IP phone 7960.
Troubleshooting Features
The following is a list of features on the Cisco SIP IP phone that you can use to troubleshoot phone:
Settings button to Network Configuration soft key—Use to view or modify the network configuration of the phone.
Settings button to SIP Configuration soft key—Use to view or modify a phone's SIP settings.
Settings button to Status—Display configuration or initialization errors.
Call Messages on LED screen—Display basic SIP message flows.
Pressing "i" key twice during a call—Displays real-time transferring and receiving call statistics. This option is recommended for trouble-shooting voice-quality issues.
In addition to the features listed above, the RS-232 port located on the back of the Cisco SIP IP phone 7960 is a console port and can be used to gather debug information.
The RS-232 port is password-protected and requires a custom RJ-11-to-RJ-45 cable.
Note For a PC connection, the RJ-45 connection needs a DB-9 female DTE adapter or an RJ-45 crossover
cable for an octal async connection. The password "cisco" must be entered to enable any output to
be seen via the RS-232 port. The connection baud rate, parity, start bits, and stop bits are 9600, N, 8,
and 1.
To use the console port, use a RJ-11-to-RJ-45 custom cable to connect the RS-232 port to a PC.
Phone is Unprovisioned or is Unable to Obtain an IP Address
To determine why a phone is unprovisioned or unable to obtain an IP address, perform the following tasks as necessary:
If using TFTP to download configuration files, verify that the SIPDefault.cnf and the phone-specific configuration (SIPmac.cnf where mac is the MAC address of the phone) files exist and are configured correctly.
Verify that the TFTP server is working properly.
Verify that the Cisco SIP IP phone Network Configuration parameters are properly configured and the phone is obtaining the proper IP addressing information (IP address, subnet mask, default gateway, TFTP server, etc.).
Press the settings button, select Status, and then Status Messages to view messages for missing files or other errors.
If the DHCP server is on a different IP subnet mask than the Cisco SIP IP phone, verify that "ip helper-address" address is enabled on the local router.
Verify that the Cisco SIP IP phone software image (P0S3xxyy.bin where xx is the version number and yy is the subversion number) was downloaded from CCO using binary format.
Cisco SIP IP Phone will not Register with the SIP Proxy/Registrar Server
To determine why a phone will not register with a SIP proxy/registrar server, perform the following tasks as necessary:
Note The character "x" displayed to the right of a line icon indicates that registration has failed.
Verify that phone registration with a proxy server is enabled (via the proxy_register parameter in the configuration files). By default, registration during initialization is disabled.
Verify that the IP address (proxy1_address parameter) of the primary SIP proxy server to be used by the phones is valid.
If a Fully Qualified Domain Name (FQDN) is specified in the proxy1_address parameter, verify that the DNS server is configured to resolve the FQDN as a DNS A-record type.
Verify whether the Cisco SIP Proxy Server has been configured to require authentication. If so, ensure that an authentication name and password has been defined in the Cisco SIP IP phone phone-specific configuration file (via the linex_authname and linex_password parameters).
The Cisco SIP IP phone currently supports the HTTP Digest authentication method. Verify that the authentication method required by the Cisco SIP Proxy Server (via the AuthScheme directive in the sipd.conf file) is HTTP Digest.
Verify that a registration request hasn't expired. By default, Cisco SIP IP phones will re-register every 3600 sections but this value can be modified via the time_reqister_expires parameter.
Outbound Calls Cannot be Placed from a Cisco SIP IP Phone
If a call cannot be placed from a Cisco SIP IP phone, perform the following tasks as necessary:
Verify that the Cisco SIP IP phone Network Configuration IP address parameters have been correctly entered or received from a DHCP server.
Verify that the Cisco SIP Proxy Server used by the phone is working properly.
Verify that the remote SIP device is available.
Verify that a dial plan has been defined via the dialplan.xml file and if so, that the configuration is correct. This file should have been downloaded from CCO to the root directory of your TFTP server.
Determine the error tones that are being received and map those tones to the messages displayed on the phone's LCD (SIP 4xx messages, etc.)
Verify that the Cisco SIP Proxy Server is correctly configured for routes or registrations to the remote destination.
Inbound Calls Cannot be Received on a Cisco SIP IP Phone
If inbound calls cannot be received on a Cisco SIP IP phone, perform the following tasks as necessary:
Verify that the line (user portion) was defined in the Request-URI or the SIP INVITE request. The Cisco SIP IP phone requires this information to determine the proper line to ring.
Verify that the Request-URI is sent to port 5060 of the phone's IP address. The phone listens on UDP port 5060.
Verify that the Cisco SIP IP phone is registered with the local proxy server.
Poor Voice Quality on the Cisco SIP IP Phone
If a call's voice quality is compromised on the Cisco SIP IP phone, perform the following tasks as necessary:
Check the network path for errors, packet drops, loss, loops, etc.
Verify that the ToS level for the media stream being used have been correctly set (via the tos_media parameter in the configuration file).
Verify that the Cisco SIP IP phone is plugged into a switch rather than a hub to avoid excessive collisions and packet loss.
Ensure that there is enough bandwidth on the network for the selected codec (especially for calls over a WAN).
Press the blue "i" button twice on the phone during the call to view realtime transferring and receiving call statistics
Determine whether the problem just occurs with the handset, headset, or speaker phone, or with all of them.
DTMF Digits Do Not Function Properly
If DTMF digits are not functioning properly, perform the following tasks as necessary:
If out-of-bound signaling via the AVT tone method has been enabled (via the dtmf_outofband configuration file parameter), verify that the remote device supports AVT tones (as defined in RFC 2833). If AVT tones have been enabled and the remote device does not support AVT tone, check for packet loss in the end-to-end path.
Verify which codec is being used. Lower bandwidth codecs yield poorer result if AVT tones are not support because the DTMF digits are carried via audio.
Verify the length of the tones being created. The tone must be a minimum signal duration of 40 ms with signaling velocity (tone and pause) of no less than 93 ms (as defined in RFC 2833).
Cisco SIP IP Phones do not Work When Plugged into a Line-Powered Switch
If the Cisco SIP IP phones do not work when plugged into a line-powered switch, perform the following task:
Verify that the phone is running Version 2.0 of the Cisco SIP IP Phone software. (Line-powered support was not available in Version 1.0).
Verify that the network media type Network Settings parameter is set to auto-negotiation (auto).
Call Transfer Does Not Work Correctly
If call transfer does not work, verify the remote SIP device that is sending the call is using the SIP BYE/Also: method (as defined in Internet draft sip-cc-01.txt.
Some SIP Messages are Retransmitted Too Often
The Cisco SIP IP phone has several timers (INVITE request retries, BYE request retries, etc.) that can be configured via the sip_invite_retx and sip_retx configuration file parameters. In most networks, the default values work fine, however, conditions such as network delay, slower-processing proxy servers, and packet loss might require that the timers be adjusted. If some SIP messages appear to be retransmitted too often, adjust these parameters.
Troubleshooting the Cisco SIP Gateway
This section describes troubleshooting features and tips for Cisco SIP Gateways running Cisco IOS Release 12 1(5)XM.
Troubleshooting Features
The following commands can be used to troubleshoot the Cisco SIP Gateway:
show sip ?—Displays the different show sip commands.
router#show sip ?
retry Display SIP Protocol Retry Counts
statistics Display SIP UA Statistics
status Display SIP UA Listener Status
timers Display SIP Protocol Timers
show sip status—Displays the SIP user agent listener status.
sip-2600a#show sip status
SIP User Agent Status
SIP User Agent for UDP : ENABLED
SIP User Agent for TCP : ENABLED
SIP max-forwards : 6
show sip statistics—Displays SIP user agent statistics
router#show sip statistics
SIP Response Statistics (Inbound/Outbound)
Informational:
Trying 3/0, Ringing 3/0,
Forwarded 0/0, Queued 0/0,
SessionProgress 0/0
Success:
OkInvite 3/0, OkBye 2/0,
OkCancel 0/0, OkOptions 0/0
Redirection (Inbound only):
MultipleChoice 0, MovedPermanently 0,
MovedTemporarily 0, SeeOther 0,
UseProxy 0, AlternateService 0
Client Error:
BadRequest 0/3, Unauthorized 0/0,
PaymentRequired 0/0, Forbidden 0/0,
NotFound 0/0, MethodNotAllowed 0/0,
NotAcceptable 0/0, ProxyAuthReqd 0/0,
ReqTimeout 0/0, Conflict 0/0, Gone 0/0,
LengthRequired 0/0, ReqEntityTooLarge 0/0,
ReqURITooLarge 0/0, UnsupportedMediaType 0/0,
BadExtension 0/0, TempNotAvailable 0/0,
CallLegNonExistent 0/0, LoopDetected 0/0,
TooManyHops 0/0, AddrIncomplete 0/0,
Ambiguous 0/0, BusyHere 0/0
Server Error:
InternalError 0/0, NotImplemented 0/0,
BadGateway 0/0, ServiceUnavail 0/0,
GatewayTimeout 0/0, BadSipVer 0/0
Global Failure:
BusyEverywhere 0/0, Decline 0/0,
NotExistAnywhere 0/0, NotAcceptable 0/0
SIP Total Traffic Statistics (Inbound/Outbound)
Invite 3/7, Ack 2/1, Bye 0/2,
Cancel 0/0, Options 0/0
Retry Statistics
Invite 2, Bye 0, Cancel 0, Response 1
debug sip ?—Displays the different debug ccsip commands.
*Mar 6 14:10:42: 0x624CFEF8 : State change from (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_PROCEEDING) to (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_ALERTING)
*Mar 6 14:10:46: Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 166.34.245.230:54113
From: "3660110" <sip:3660110@166.34.245.230>
To: <sip:3660210@166.34.245.231;user=phone;phone-context=unknown>;tag=27D3FCA8-C7F
Unable to Make Outbound Calls from the Cisco SIP Gateway to a SIP Endpoint
If a call cannot be placed from the Cisco SIP gateway, perform the following tasks as necessary:
Verify that the voice ports are properly configured and enabled for PSTN-side signaling protocol.
Verify that there is a valid VoIP dial peer configured which meets the following requirements:
Matches the required destination pattern
Is SIP-enabled (via the session protocol sipv2 command)
Has the correct dial peer session target defined (via the session target sip-server command
Has the codec correctly defined
Using the ping command, verify that the SIP gateway can communicate via IP with the SIP proxy or remote SIP device.
If the SIP proxy server is defined using a FQDN, verify that the DNS server is correctly configured to resolve that address using a DNS SRV record.
Ensure that the timezone format configured on the SIP gateway is GMT.
View the debugccsip all | calls | error | events | messages | states command output for protocol errors.
Unable to Make Inbound Calls to a PSTN Through a Cisco SIP Gateway
If inbound calls to a PSTN cannot be made through the Cisco SIP gateway, perform the following tasks as necessary to determine the cause:
Verify that the voice ports are correctly configured and enabled for the PSTN-side signaling protocol.
Verify that a valid POTS dial peer is configured which matches the required destination pattern.
Using the ping command, verify that the Cisco SIP gateway can communicate with the SIP proxy server or remote SIP device via IP.
If the inbound call has any hostnames defined as a FQDN, ensure that the proper DNS configuration is enabled on the Cisco SIP gateway (to resolve the hosts).
View the debugccsip all | calls | error | events | messages | states command output for protocol errors.
Calls to a PSTN via the Cisco SIP Gateway Fail with a "400 Bad Request" Response
If the Cisco SIP gateway does not like part of a SIP message (header or SDP), the call attempt will fail with a "400 Bad Request" response.
To determine whether the call failed because of a SIP header errors, issue the debugccsip all | calls | error | events | messages | states command that displays information on the error message or verify the required SIP header elements exist as defined in RFC 2543. Also, the "Cisco SIP Compliance Reference Information" in the Session Initiation Protocol Gateway Call Flows (http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121rel/sipcfs/index.htm) document lists the currently supported SIP headers.
Table 5-2 lists possible SDP-related errors and their related error codes. Table 5-3 lists the possible CheckRequest errors.
Table 5-2 SDP Errors and Related Error Codes
SIP SDP Parser Error Codes
SDP_ERR_INFO_UNAVAIL
SDP_ERR_VERSINFO_INVALID
SDP_ERR_CONNINFO_IN
SDP_ERR_CONNINFO_IP
SDP_ERR_CONNINFO_NULL
SDP_ERR_CONNINFO_INVALID
SDP_ERR_MEDIAINFO_TYPE
SDP_ERR_MEDIAINFO_INVALID
SDP_ERR_MEDIAINFO_NULL
SDP_ERR_OWNERINFO_NULL
SDP_ERR_OWNERINFO_SESSID_NULL
SDP_ERR_OWNERINFO_SESSID_INVALID
SDP_ERR_OWNERINFO_VERSID_NULL
SDP_ERR_OWNERINFO_VERSID_INVALID
SDP_ERR_OWNERINFO_IN
SDP_ERR_OWNERINFO_IP
SDP_ERR_TIMEINFO_ST_NULL
SDP_ERR_TIMEINFO_ET_NULL
SDP_ERR_TIMEINFO_ST_INVALID
SDP_ERR_TIMEINFO_ET_INVALID
SDP_ERR_ATTRINFO_INVALID
SDP_ERR_ATTRINFO_NULL
SDP_ERR_AUDIO_MEDIA_UNAVAIL
SDP_ERR_MEDIAINFO_PORT_INVALID
SDP_ERR_MEDIAINFO_MALLOC_FAIL
SDP_ERR_ATTRINFO_MALLOC_FAIL
Table 5-3 Possible CheckRequest Errors
CheckRequest Errors
CHK_REQ_FAIL_MISMATCH_CSEQ
CHK_REQ_FAIL_INVALID_CSEQ
CHK_REQ_FAIL_FROM_TO
CHK_REQ_FAIL_VERSION
CHK_REQ_FAIL_METHOD_UNKNOWN
CHK_REQ_FAIL_REQUIRE_UNSUPPORTED
CHK_REQ_FAIL_CONTACT_MISSING
CHK_REQ_FAIL_MISMATCH_CALLID
CHK_REQ_FAIL_MALFORMED_CONTACT
CHK_REQ_FAIL_MALFORMED_RECORD_ROUTE
Voice Quality is Compromised on Calls Through or From the Cisco SIP Gateway
If the voice quality on calls through or from the Cisco SIP gateway is compromised, perform the following tasks as necessary to determine the cause:
Check the network path for errors, packet drops, loss, loops, etc.
Verify that the TOS bits have been correctly set in the VoIP dial peer using the ip precedence command.
To minimize excessive collisions and packet loss, connect the Cisco SIP gateway to a switch rather than a hub.
Verify that enough bandwidths exists on the network for the configured codec (especially for calls over a WAN).
View the output of the show interface command for packet drops. View the output of the show voice dsp command or DSP-related issues.
Verify whether errors exists on the voice-ports that could be causing the echo, etc.
Some SIP Messages are Retransmitted Too Often
The Cisco SIP gateway has SIP timers (INVITE request retries, BYE request retries, etc) configured under the SIP UA via the timers trying number, timers expires time, and retry invite number commands. In most networks, the default values work fine, however, conditions such as network delay, slower-processing proxy servers, and packet loss might require that the timers be adjusted. If some SIP messages appear to be retransmitted too often, adjust these parameters.
Call Transfer Does Not Work Correctly
If call transfer does not function properly, perform the following tasks to determine the cause:
Verify that the "application session" is defined on the VoIP and POTS dial peers.
Verify that the remote SIP device that is sending the call is using the SIP BYE/Also: method (as defined in Internet draft sip-cc-01.txt.
Verify that a dial peer that has "application session" defined is matched using the debug voip ccapi inout command. The application used after the BYE request is sent should be "session" instead of "SESSION."
Troubleshooting the Cisco SIP Proxy Server
This section describes troubleshooting features and tips for the Cisco SIP Proxy Server, Version 1.0.
Troubleshooting Features
When trying to troubleshoot problems with the Cisco SIP Proxy Server, remember the following:
Each module with the Cisco SIP Proxy Server has debugging capabilities that can be set via a debug flag in the sipd.conf file. When these debug flags are set to On, and the server is running in multi-process mode, the debug output is written to the ./logs/error_log file. When the flags are set to On and single-process mode is enabled, the debug output is written to standard output.
Changes to the sipd.conf file do not automatically take effect. To have any changes take effect, issue a graceful restart by issuing the following command:
./sipdctl graceful
Troubleshooting Tips
This section provides tips for resolving the following Cisco SIP Proxy Server problems:
If the Cisco SIP Proxy Server does not start, perform the following tasks as necessary to determine the cause:
Verify that the /usr/local/sip directory (on Linux) or the opt/local/sip/ directory (on Solaris) has the read and write permissions set that allow the user to start the Cisco SIP Proxy Server.
Verify that the LD_LIBRARY_PATH environment variable has been enabled as defined in the Cisco SIP Proxy Server Administrator Guide.
If using the Linux RPM version of the Cisco SIP Proxy Server, verify that the software has been correctly installed.
Verify that an older version of the Cisco SIP Proxy Server is not still running by issuing the following command:
ps -ef | grep -i sip
If another version is running, disable these processes by issuing the following command:
./sipdctl stop
Verify that the Cisco SIP Proxy Server can resolve its hostname via DNS.
The Cisco SIP Proxy Server Does Not Allow Devices to Register
If the Cisco SIP Proxy Server does not allow devices to register, perform the following tasks as necessary to determine the cause:
Verify that registration services are enabled via the mod_sip_registry module in the sipd.conf file.
If authentication is required, ensure that the SIP UA and password is defined in the MySQL database subscriber table and that the Cisco SIP Proxy Server can connect to the MySQL database.
Verify the type the SIP UAs are using the HTTP Digest authentication method.
The Cisco SIP Proxy Server Does Not Route Calls Properly
If the Cisco SIP Proxy Server does not properly route calls, perform the following tasks as necessary to determine the cause:
Verify that numbering plans statements are configured correctly in the mod_sip_numexpand module in the sipd.conf file.
Verify that the translation modules (mod_sip_registry, mod_sip_enum, and mod_sip_gktmp are correctly configured and have the correct entries populated.
Verify that the correct routes exist in the static routing table of the sipd.conf file.
Verify that the DNS server is configured for DNS SRV and DNS A records of the devices to be routed.
View the error_log file for error messages (bad SIP messages, process errors, etc.).
The Cisco SIP Proxy Server Reports that SIP Messages are Bad
If the Cisco SIP Proxy Server reports SIP messages as bad, enable the StateMachine debug flag in the sipd.conf file and view the SIP message in the error_log file. The error_log file should contain SIP messages that are received in ASCII format. Verify the SIP headers of those messages against the headers defined in RFC 2543 or verify the SDP information against the information defined in RFC 2327.
Cisco SIP Proxy Server Farming Does Not Work Correctly
If Cisco SIP Proxy Server farming does not work correctly, perform the following tasks as necessary to determine the cause:
Verify that all members of the far have the same sipd.conf file configuration
Verify that all members of the farm have an entry for the other farm members defined in the Cisco_Registry_Farm_Members directive in their sipd.conf file.
Verify that all members of the farm are running the same version of the Cisco SIP Proxy Server.
Verify that all members of the farm are sychronized to the same clock source via Network Time Protocol (NTP).
Voice Quality Problems
SIP using RTP to transmit media between two endpoints. The Cisco SIP Proxy server is only involved with the SIP signaling and not the media. Therefore, voice-quality issues should be determined in the endpoint devices not the Cisco SIP proxy server because the media does not pass through it.
