Pankaj Bhagchandani, Pankaj G Bhagchandani, G Pankaj Bhagchandani,, Pankaj Bhagchandani G, Pankaj Bh: Pankaj Bhagchandani Pankaj Bhagchandani, Bhagchandani Pankaj G Bhagchandani, Bhagchandani Pankaj Bhagchandani G, G Bhagchandani Pankaj Bhagchandani

Troubleshooting SIP Interfaces to the IP Network

The Cisco Session Initiation Protocol (SIP) implementation enables Cisco access platforms to signal the setup of voice and multimedia calls over IP networks.

SIP is an ASCII-based, application-layer control protocol that can be used to establish, maintain, and terminate calls between two or more endpoints. SIP is an alternative protocol developed by the Internet Engineering Task Force (IETF) for multimedia conferencing over IP. SIP features are compliant with IETF RFC 2543, SIP: Session Initiation Protocol, published in March 1999. You can view RFC 2543 at http://www.ietf.org/rfc/rfc2543.txt.

Like other Voice-over-IP protocols, SIP is designed to address the functions of signaling and session management within a packet telephony network. Signaling allows call information to be carried across network boundaries. Session management provides the ability to control the attributes of an end-to-end call.

This chapter provides procedural and reference information that you can use to determine and resolve problems with SIP interfaces to the IP network.

Note Call flows can help in troubleshooting SIP problems. SIP call flow information can be found in the Session Initiation Protocol Gateway Call Flowsdocument.

This chapter contains the following information:

•

Troubleshooting the Cisco SIP IP Phone 7960

•

Troubleshooting the Cisco SIP Gateway

•

Troubleshooting the Cisco SIP Proxy Server

•

SIP Messages and Methods

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 for troubleshooting:

•

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 or ? key twice during a call—Displays real-time transferring and receiving call statistics. This option is recommended for troubleshooting voice-quality issues.

In addition to the features listed above, the EIA/TIA-232 (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 EIA/TIA-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. You must enter the password "cisco" must be entered to enable any output to be seen via the EIA/TIA-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 EIA/TIA-232 port to a PC.

Table 48 lists the RJ-11-to-RJ-45 cable pinouts.

Table 48 RJ-11-to-RJ-45 Pinouts
RJ-11 or RJ-12	RJ-45
2	6
3	4
4	3

To connect the console port, complete the following tasks:

Step 1

Insert the RJ-11 end of the rolled cable into the EIA/TIA-232 port on the back of the phone.

Step 2

Use an RJ-45-to-DB-9 female DTE adapter (labeled TERMINAL) to connect the console port to a PC running terminal emulation software.

Step 3

Insert the RJ-45 end of the rollover cable into the DTE adapter.

Step 4

From the console terminal, start the terminal emulation program.

Step 5

Type "cisco". A prompt is displayed.

Step 6

At the prompt, you can issue the following commands to assist you in troubleshooting and debugging the phone:

•

debug error—Displays error messages that are occurring in the call flow process

•

debug sip-message—Enables you to view a text display of a call flow

Troubleshooting Tips

This section provides tips for resolving the following Cisco SIP IP phone problems:

•

Cisco SIP IP Phone Is Unprovisioned or Is Unable to Obtain an IP Address

•

Cisco SIP IP Phone Does Not Register With the SIP Proxy or SIP Registrar Server

•

Outbound Calls Cannot Be Placed from a Cisco SIP IP Phone

•

Inbound Calls Cannot Be Received on a Cisco SIP IP Phone

•

Poor Voice Quality on the Cisco SIP IP Phone

•

DTMF Digits Do Not Function Properly

•

Cisco SIP IP Phones Do Not Work When Plugged into a Line-Powered Switch

•

Call Transfer Does Not Work Correctly

•

Some SIP Messages are Retransmitted Too Often

For more information about Cisco SIP IP phones, see the Cisco IP Phone Administrator Guides for SIP.

Cisco SIP IP 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 file and the phone-specific configuration file (SIPmac.cnf where mac is the MAC address of the phone) 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, and so forth.)

•

Press the Settings button, select Status, and then Status Messages to view messages for missing files or other errors.

•

If the DHCP server has an IP subnet mask that is different from the one for 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 the Cisco website in binary format.

Cisco SIP IP Phone Does Not Register With the SIP Proxy or SIP Registrar Server

To determine why a phone does not register with a SIP proxy or SIP 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 that the Cisco SIP proxy server has been configured to require authentication. If it has, ensure that an authentication name and password have been defined in the Cisco SIP IP phone-specific configuration file (through the use of 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 (through the use of 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 reregister every 3600 seconds, but this value can be modified through the use of 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 Cisco SIP proxy server is correctly configured for routes or registrations to the remote destination.

•

Verify that the remote SIP device is available.

•

Verify that a dial plan has been defined in 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 which error tones are being received and map those tones to the messages displayed on the phone's LCD (SIP 4xx messages, and so forth.)

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, and so forth.

•

Verify that the ToS level for the media stream being used has been correctly set (through 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 i or ? button twice on the phone during the call to view realtime transferring and receiving call statistics.

•

Determine whether the problem 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 through the AVT tone method has been enabled (through 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 tones, check for packet loss in the end-to-end path.

•

Find out which codec is being used. Lower bandwidth codecs yield poorer results if AVT tones are not supported because the DTMF digits are carried in audio.

•

Verify the length of the tones being created. The tone must have 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 tasks:

•

Verify that the phone is running version 2.0 or higher 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 correctly, 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.)

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 using 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 provides tips for resolving the following Cisco SIP gateway problems:

•

Unable to Make Outbound Calls from the Cisco SIP Gateway to a SIP Endpoint

•

Unable to Make Inbound Calls to a PSTN Through a Cisco SIP Gateway

•

Calls to a PSTN via the Cisco SIP Gateway Fail with a "400 Bad Request" Response

•

Voice Quality Is Compromised on Calls Through or From the Cisco SIP Gateway

•

Some SIP Messages Are Retransmitted Too Often

•

Call Transfer Does Not Work Correctly

•

Troubleshooting Commands

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 the PSTN-side signaling protocol.

•

Verify that there is a valid VoIP dial peer configured that meets the following requirements:

–

Matches the required destination pattern

–

Is SIP-enabled (through the session protocol sipv2 command)

–

Has the correct dial peer session target defined (through the session target sip-server command

–

Has the codec correctly defined

•

Using the ping command, verify that the SIP gateway can communicate through IP with the SIP proxy or remote SIP device.

•

If the SIP proxy server is defined through the use of a FQDN, verify that the DNS server is correctly configured to resolve that address using a DNS SRV record.

•

Ensure that the time zone format configured on the SIP gateway is GMT.

•

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 and that it 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 through 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).

•

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 fails with a "400 Bad Request" response.

To determine whether the call failed because of a SIP header error, issue the debug ccsip command that displays information on the error message, or verify that the required SIP header elements exist as defined in RFC 2543. SIP header fields are shown in Table 49.

Table 49 SIP Header Fields
Header Field	Definition
Call-ID	The Call-ID general-header field uniquely identifies a specific invitation or all registrations of a specific client. Note that a single multimedia conference can give rise to several calls with different Call-IDs. For example, if a user invites a single individual several times to the same (long-running) conference.
Contact	The Contact general-header field MUST appear in INVITE and REGISTER requests and in 200 responses. It can appear in ACK, and in other 1xx, 2xx, 3xx, 485 responses. In general, it provides a URL where the user can be reached for further communications.
Content-Length	The Content-Length entity-header field indicates the size of the message-body, in decimal number of octets, sent to the recipient.
Content-Type	The Content-Type entity-header field indicates the media type of the message-body sent to the recipient.
Cseq	Users MUST add the CSeq (command sequence) general-header field to every request. A CSeq header field in a request contains the request method and a single decimal sequence number chosen by the requesting client, unique within a single value of Call-ID. The sequence number MUST be expressed as a 32-bit unsigned integer. The initial value of the sequence number is arbitrary, but MUST be less than 2**31. Consecutive requests that differ in request method, headers, or body, but have the same Call-ID MUST contain strictly monotonically increasing and contiguous sequence numbers; sequence numbers do not wrap around. Retransmissions of the same request carry the same sequence number, but an INVITE with a different message body or different header fields (a "re-invitation") acquires a new, higher sequence number. A server MUST echo the CSeq value from the request in its response. If the Method value is missing in the received CSeq header field, the server fills it in appropriately.
Date	Date is a general-header field. Its syntax is: SIP-date = rfc1123-date Note that unlike HTTP/1.1, SIP only supports the most recent RFC 1123 [29] formatting for dates.
Diversion	Note Currently gateway uses Diversion header in initial outgoing messages.
Expires	The Expires entity-header field gives the date and time after which the message content expires. This header field is currently defined only for the REGISTER and INVITE methods. For REGISTER, it is a request and response-header field. In a REGISTER request, the client indicates how long it wants the registration to be valid. In the response, the server indicates the earliest expiration time of all registrations. The server MAYchoose a shorter time interval than that requested by the client, but SHOULD NOT choose a longer one.
From	Requests and responses MUST contain a From general-header field, indicating the initiator of the request. The From field MUST contain a tag. The server copies the From header field from the request to the response. The optional "display-name" is meant to be rendered by a human-user interface. A system SHOULD use the display name "Anonymous" if the identity of the client is to remain hidden. The SIP-URL MUST NOT contain the "transport-param", "maddr-param", "ttl-param", or "headers"elements. A server that receives a SIP-URL with these elements removes them before further processing.
Max-Forwards	The Max-Forwards request-header field may be used with any SIP method to limit the number of proxies or gateways that can forward the request to the next downstream server. This can also be useful when the client is attempting to trace a request chain which appears to be failing or looping in mid chain. The Max-Forwards value is a decimal integer indicating the remaining number of times this request message is allowed to be forwarded. Each proxy or gateway recipient of a request containing a Max-Forwards header field MUST check and update its value before forwarding the request. If the received value is zero (0), the recipient MUST NOT forward the request. Instead, for the OPTIONS and REGISTER methods, it MUST respond as the final recipient. For all other methods, the server returns 483 (too many hops). If the received Max-Forwards value is greater than zero, then the forwarded message MUST contain an updated Max-Forwards field with a value decremented by one (1).
Require	The Require request-header field is used by clients to tell useragent servers about options that the client expects the server to support in order to properly process the request. If a server does not understand the option, it MUST respond by returning status code 420 (bad extension) and list those options it does not understand in the Unsupported header.
Server	The Server response-header field contains information about the software used by the user agent server to handle the request.
Timestamp	The timestamp general-header field describes when the client sent the request to the server. The value of the timestamp is of significance only to the client and it MAY use any time scale. The server MUST echo the exact same value and MAY, if it has accurate information about this, add a floating point number indicating the number of seconds that have elapsed since receiving the request. The timestamp is used by the client to compute the round-trip time to the server so that it can adjust the time out value for retransmissions.
To	The To general-header field specifies recipient of the request, with the same SIP URL syntax as the From field. Requests and responses MUST contain a To general-header field, indicating the desired recipient of the request. The optional "display-name"is meant to be rendered by a human-user interface. The UAS or redirect server service processing a request MUST always add a tag to To-header.
User-Agent	The User-Agent general-header field contains information about the client user agent originating the request.
Via	The Via field indicates the path taken by the request so far. This prevents request looping and ensures replies take the same path as the requests, which assists in firewall traversal and other unusual routing situations. When the UAC creates a request, it MUST insert a Via into that request.

Possible SDP-related errors are as follows:

•

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

Possible CheckRequest errors are as follows:

•

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, and so forth.

•

Verify that the TOS bits have been correctly set in the VoIP dial peer through the use of 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 bandwidth 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 for DSP-related issues.

•

Determine whether errors exist on the voice ports that could be causing the problems.

Some SIP Messages Are Retransmitted Too Often

The Cisco SIP gateway has SIP timers (INVITE request retries, BYE request retries) configured under the SIP UA through the use of the timers trying number, timers expires time, and retry invite number commands. In most networks, the default values work well, but 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 work correctly, 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 through the use of the SIP BYE/Also: method (as defined in Internet draft sip-cc-01.txt).

•

Use the debug voip ccapi inout command to verify that a dial peer that has application session defined is matched. The application used after the BYE request is sent should be "session" instead of "SESSION."