Total Pageviews

Tuesday, January 3, 2012

Cisco SIP Gateway Troubleshooting

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.
  • Check the debug ccsip 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 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).
  • View the debug ccsip 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 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: SIP Header Fields.
Table: SIP Header Fields
Header FieldDefinition
Call-IDThe 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.
ContactThe 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-LengthThe Content-Length entity-header field indicates the size of the message-body, in decimal number of octets, sent to the recipient.
Content-TypeThe Content-Type entity-header field indicates the media type of the message-body sent to the recipient.
CseqUsers 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.
DateDate 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 Note: Currently gateway uses Diversion header in initial outgoing messages.
ExpiresThe 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.
FromRequests 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-ForwardsThe 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).
RequireThe 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.
ServerThe Server response-header field contains information about the software used by the user agent server to handle the request.
TimestampThe 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.
ToThe 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-AgentThe User-Agent general-header field contains information about the client user agent originating the request.
ViaThe 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."

Troubleshooting Commands

There are several debug commands that are useful for troubleshooting problems with SIP, as follows:
  • debug ccsip all
  • debug ccsip calls
  • debug ccsip error
  • debug ccsip events
  • debug ccsip info
  • debug ccsip media
  • debug ccsip messages
  • debug ccsip preauth
  • debug ccsip states
Details about these commands can be found in the Cisco IOS Debug Command Reference.
Note Note: The output from these commands can be filtered. For more information, see the SIP Debug Output Filtering Support.
The following show and debug commands shown can be used to troubleshoot the Cisco SIP gateway:
  • 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 ccsip-Displays the different debug ccsip commands.
 router# debug ccsip ?  
  all      Enable all SIP debugging traces  
  calls    Enable CCSIP SPI calls debugging trace  
  error    Enable SIP error debugging trace  
  events   Enable SIP events debugging trace  
  messages Enable CCSIP SPI messages debugging trace  
  states   Enable CCSIP SPI states debugging trace  
The following is a sample of debug output from one side of a call:
Router1# debug ccsip all  
All SIP call tracing enabled  
Router1#  
*Mar  6 14:10:42: 0x624CFEF8 : State change from (STATE_NONE, SUBSTATE_NONE)  
  to (STATE_IDLE, SUBSTATE_NONE)  
*Mar  6 14:10:42:  Queued event from SIP SPI : SIPSPI_EV_CC_CALL_SETUP  
*Mar  6 14:10:42: CCSIP-SPI-CONTROL:  act_idle_call_setup  
*Mar  6 14:10:42:  act_idle_call_setup:Not using Voice Class Codec  
*Mar  6 14:10:42: act_idle_call_setup: preferred_codec set[0] type :g711ulaw bytes: 160   
*Mar  6 14:10:42:  Queued event from SIP SPI : SIPSPI_EV_CREATE_CONNECTION  
*Mar  6 14:10:42: 0x624CFEF8 : State change from (STATE_IDLE, SUBSTATE_NONE)
  to (STATE_IDLE, SUBSTATE_CONNECTING)  
*Mar  6 14:10:42: REQUEST CONNECTION TO IP:166.34.245.231 PORT:5060  
*Mar  6 14:10:42: 0x624CFEF8 : State change from (STATE_IDLE, SUBSTATE_CONNECTING)
  to (STATE_IDLE, SUBSTATE_CONNECTING)  
*Mar  6 14:10:42: CCSIP-SPI-CONTROL:  act_idle_connection_created  
*Mar  6 14:10:42: CCSIP-SPI-CONTROL:  act_idle_connection_created: Connid(1) 
  created to 166.34.245.231:5060, local_port 54113  
*Mar  6 14:10:42: sipSPIAddLocalContact  
*Mar  6 14:10:42:  Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE  
*Mar  6 14:10:42: CCSIP-SPI-CONTROL:  sip_stats_method  
*Mar  6 14:10:42: 0x624CFEF8 : State change from (STATE_IDLE, SUBSTATE_CONNECTING)
  to (STATE_SENT_INVITE, SUBSTATE_NONE)  
*Mar  6 14:10:42: Sent:   
INVITE sip:3660210@166.34.245.231;user=phone;phone-context=unknown SIP/2.0  
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>  
Date: Sat, 06 Mar 1993 19:10:42 GMT  
Call-ID: ABBAE7AF-823100CE-0-1CCAA69C@172.18.192.194  
Cisco-Guid: 2881152943-2184249548-0-483039712  
User-Agent: Cisco VoIP Gateway/ IOS 12.x/ SIP enabled  
CSeq: 101 INVITE  
Max-Forwards: 6  
Timestamp: 731427042  
Contact: <sip:3660110@166.34.245.230:5060;user=phone>  
Expires: 180  
Content-Type: application/sdp  
Content-Length: 137  
v=0  
o=CiscoSystemsSIP-GW-UserAgent 1212 283 IN IP4 166.34.245.230  
s=SIP Call  
t=0 0  
c=IN IP4 166.34.245.230  
m=audio 20208 RTP/AVP 0  
*Mar  6 14:10:42: Received:   
SIP/2.0 100 Trying  
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>  
Date: Mon, 08 Mar 1993 22:36:40 GMT  
Call-ID: ABBAE7AF-823100CE-0-1CCAA69C@172.18.192.194  
Timestamp: 731427042  
Server: Cisco VoIP Gateway/ IOS 12.x/ SIP enabled  
CSeq: 101 INVITE  
Content-Length: 0  
*Mar  6 14:10:42: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 166.34.245.231:5060  
*Mar  6 14:10:42: CCSIP-SPI-CONTROL:  act_sentinvite_new_message  
*Mar  6 14:10:42: CCSIP-SPI-CONTROL:  sipSPICheckResponse  
*Mar  6 14:10:42: CCSIP-SPI-CONTROL:  sip_stats_status_code  
*Mar  6 14:10:42:  Roundtrip delay 4 milliseconds for method INVITE  
*Mar  6 14:10:42: 0x624CFEF8 : State change from (STATE_SENT_INVITE, SUBSTATE_NONE)
  to (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_PROCEEDING)  
*Mar  6 14:10:42: Received:   
SIP/2.0 180 Ringing  
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>  
Date: Mon, 08 Mar 1993 22:36:40 GMT  
Call-ID: ABBAE7AF-823100CE-0-1CCAA69C@172.18.192.194  
Timestamp: 731427042  
Server: Cisco VoIP Gateway/ IOS 12.x/ SIP enabled  
CSeq: 101 INVITE  
Content-Type: application/sdp  
Content-Length: 137  
v=0  
o=CiscoSystemsSIP-GW-UserAgent 969 7889 IN IP4 166.34.245.231  
s=SIP Call  
t=0 0  
c=IN IP4 166.34.245.231  
m=audio 20038 RTP/AVP 0  
*Mar  6 14:10:42: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 166.34.245.231:5060  
*Mar  6 14:10:42: CCSIP-SPI-CONTROL:  act_recdproc_new_message  
*Mar  6 14:10:42: CCSIP-SPI-CONTROL:  sipSPICheckResponse  
*Mar  6 14:10:42: CCSIP-SPI-CONTROL:  sipSPICheckResponse : Updating session description  
*Mar  6 14:10:42: CCSIP-SPI-CONTROL:  sip_stats_status_code  
*Mar  6 14:10:42:  Roundtrip delay 8 milliseconds for method INVITE  
*Mar  6 14:10:42: HandleSIP1xxRinging: SDP MediaTypes negotiation successful!  
Negotiated Codec      : g711ulaw , bytes :160  
Inband Alerting       : 0   
*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  
Date: Mon, 08 Mar 1993 22:36:40 GMT  
Call-ID: ABBAE7AF-823100CE-0-1CCAA69C@172.18.192.194  
Timestamp: 731427042  
Server: Cisco VoIP Gateway/ IOS 12.x/ SIP enabled  
Contact: <sip:3660210@166.34.245.231:5060;user=phone>  
CSeq: 101 INVITE  
Content-Type: application/sdp  
Content-Length: 137  
v=0  
o=CiscoSystemsSIP-GW-UserAgent 969 7889 IN IP4 166.34.245.231  
s=SIP Call  
t=0 0  
c=IN IP4 166.34.245.231  
m=audio 20038 RTP/AVP 0  
*Mar  6 14:10:46: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 166.34.245.231:5060  
*Mar  6 14:10:46: CCSIP-SPI-CONTROL:  act_recdproc_new_message  
*Mar  6 14:10:46: CCSIP-SPI-CONTROL:  sipSPICheckResponse  
*Mar  6 14:10:46: CCSIP-SPI-CONTROL:  sipSPICheckResponse : Updating session description  
*Mar  6 14:10:46: CCSIP-SPI-CONTROL:  sip_stats_status_code  
*Mar  6 14:10:46:  Roundtrip delay 3536 milliseconds for method INVITE  
*Mar  6 14:10:46: CCSIP-SPI-CONTROL:  act_recdproc_new_message: 
  SDP MediaTypes negotiation successful!  
Negotiated Codec      : g711ulaw , bytes :160  
*Mar  6 14:10:46: CCSIP-SPI-CONTROL:  sipSPIReconnectConnection  
*Mar  6 14:10:46:  Queued event from SIP SPI : SIPSPI_EV_RECONNECT_CONNECTION  
*Mar  6 14:10:46: CCSIP-SPI-CONTROL:  recv_200_OK_for_invite  
*Mar  6 14:10:46:  Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE  
*Mar  6 14:10:46: CCSIP-SPI-CONTROL:  sip_stats_method  
*Mar  6 14:10:46: 0x624CFEF8 : State change from (STATE_RECD_PROCEEDING, 
 SUBSTATE_PROCEEDING_ALERTING)  to (STATE_ACTIVE, SUBSTATE_NONE)  
*Mar  6 14:10:46: The Call Setup Information is :  
       Call Control Block (CCB) : 0x624CFEF8  
       State of The Call        : STATE_ACTIVE  
       TCP Sockets Used         : NO  
       Calling Number           : 3660110  
       Called Number            : 3660210  
       Negotiated Codec         : g711ulaw  
       Source IP Address (Media): 166.34.245.230  
       Source IP Port    (Media): 20208  
       Destn  IP Address (Media): 166.34.245.231  
       Destn  IP Port    (Media): 20038  
       Destn SIP Addr (Control) : 166.34.245.231  
       Destn SIP Port (Control) : 5060  
       Destination Name         : 166.34.245.231  
*Mar  6 14:10:46: HandleUdpReconnection: Udp socket connected for fd: 1 with
  166.34.245.231:5060  
*Mar  6 14:10:46: Sent:   
ACK sip:3660210@166.34.245.231:5060;user=phone SIP/2.0  
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  
Date: Sat, 06 Mar 1993 19:10:42 GMT  
Call-ID: ABBAE7AF-823100CE-0-1CCAA69C@172.18.192.194  
Max-Forwards: 6  
Content-Type: application/sdp  
Content-Length: 137  
CSeq: 101 ACK  
v=0  
o=CiscoSystemsSIP-GW-UserAgent 1212 283 IN IP4 166.34.245.230  
s=SIP Call  
t=0 0  
c=IN IP4 166.34.245.230  
m=audio 20208 RTP/AVP 0  
*Mar  6 14:10:46: CCSIP-SPI-CONTROL:  ccsip_caps_ind  
*Mar  6 14:10:46: ccsip_caps_ind: Load DSP with codec (5) g711ulaw, Bytes=160  
*Mar  6 14:10:46: ccsip_caps_ind: set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_INBAND_VOICE  
*Mar  6 14:10:46: CCSIP-SPI-CONTROL:  ccsip_caps_ack  
*Mar  6 14:10:50: Received:   
BYE sip:3660110@166.34.245.230:5060;user=phone SIP/2.0  
Via: SIP/2.0/UDP  166.34.245.231:54835  
From: <sip:3660210@166.34.245.231;user=phone;phone-context=unknown>;tag=27D3FCA8-C7F  
To: "3660110" <sip:3660110@166.34.245.230>  
Date: Mon, 08 Mar 1993 22:36:44 GMT  
Call-ID: ABBAE7AF-823100CE-0-1CCAA69C@172.18.192.194  
User-Agent: Cisco VoIP Gateway/ IOS 12.x/ SIP enabled  
Max-Forwards: 6  
Timestamp: 731612207  
CSeq: 101 BYE  
Content-Length: 0  
*Mar  6 14:10:50: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 166.34.245.231:54835  
*Mar  6 14:10:50: CCSIP-SPI-CONTROL:  act_active_new_message  
*Mar  6 14:10:50: CCSIP-SPI-CONTROL:  sact_active_new_message_request  
*Mar  6 14:10:50: CCSIP-SPI-CONTROL:  sip_stats_method  
*Mar  6 14:10:50:  Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE  
*Mar  6 14:10:50: CCSIP-SPI-CONTROL:  sip_stats_status_code  
*Mar  6 14:10:50: CCSIP-SPI-CONTROL:  sipSPIInitiateCallDisconnect : 
  Initiate call disconnect(16) for outgoing call  
*Mar  6 14:10:50: 0x624CFEF8 : State change from (STATE_ACTIVE, SUBSTATE_NONE)
  to (STATE_DISCONNECTING, SUBSTATE_NONE)  
*Mar  6 14:10:50: Sent:   
SIP/2.0 200 OK  
Via: SIP/2.0/UDP  166.34.245.231:54835  
From: <sip:3660210@166.34.245.231;user=phone;phone-context=unknown>;tag=27D3FCA8-C7F  
To: "3660110" <sip:3660110@166.34.245.230>  
Date: Sat, 06 Mar 1993 19:10:50 GMT  
Call-ID: ABBAE7AF-823100CE-0-1CCAA69C@172.18.192.194  
Server: Cisco VoIP Gateway/ IOS 12.x/ SIP enabled  
Timestamp: 731612207  
Content-Length: 0  
CSeq: 101 BYE  
*Mar  6 14:10:50:  Queued event From SIP SPI to CCAPI/DNS : SIPSPI_EV_CC_CALL_DISCONNECT  
*Mar  6 14:10:50: CCSIP-SPI-CONTROL:  act_disconnecting_disconnect  
*Mar  6 14:10:50: CCSIP-SPI-CONTROL:  sipSPICallCleanup  
*Mar  6 14:10:50:  Queued event from SIP SPI : SIPSPI_EV_CLOSE_CONNECTION  
*Mar  6 14:10:50: CLOSE CONNECTION TO CONNID:1  
*Mar  6 14:10:50: sipSPIIcpifUpdate :CallState: 4 Playout: 1755 DiscTime:48305031 
 ConnTime 48304651  
*Mar  6 14:10:50: 0x624CFEF8 : State change from (STATE_DISCONNECTING, SUBSTATE_NONE)
 to (STATE_DEAD, SUBSTATE_NONE)  
*Mar  6 14:10:50: The Call Setup Information is :  
        Call Control Block (CCB) : 0x624CFEF8  
        State of The Call        : STATE_DEAD  
        TCP Sockets Used         : NO  
        Calling Number           : 3660110  
        Called Number            : 3660210  
        Negotiated Codec         : g711ulaw  
        Source IP Address (Media): 166.34.245.230  
        Source IP Port    (Media): 20208  
        Destn  IP Address (Media): 166.34.245.231  
        Destn  IP Port    (Media): 20038  
        Destn SIP Addr (Control) : 166.34.245.231  
        Destn SIP Port (Control) : 5060  
        Destination Name         : 166.34.245.231  
*Mar  6 14:10:50:   
       Disconnect Cause (CC)    : 16  
       Disconnect Cause (SIP)   : 200  
*Mar  6 14:10:50: udpsock_close_connect: Socket fd: 1 closed for connid 1 with remote port: 5060  
Router1#  
The debug output is as follows from the other side of the call:
3660-2# debug ccsip all  
All SIP call tracing enabled  
3660-2#  
*Mar  8 17:36:40: Received:   
INVITE sip:3660210@166.34.245.231;user=phone;phone-context=unknown SIP/2.0  
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>  
Date: Sat, 06 Mar 1993 19:10:42 GMT  
Call-ID: ABBAE7AF-823100CE-0-1CCAA69C@172.18.192.194  
Cisco-Guid: 2881152943-2184249548-0-483039712  
User-Agent: Cisco VoIP Gateway/ IOS 12.x/ SIP enabled  
CSeq: 101 INVITE  
Max-Forwards: 6  
Timestamp: 731427042  
Contact: <sip:3660110@166.34.245.230:5060;user=phone>  
Expires: 180  
Content-Type: application/sdp  
Content-Length: 137  
v=0  
o=CiscoSystemsSIP-GW-UserAgent 1212 283 IN IP4 166.34.245.230  
s=SIP Call  
t=0 0  
c=IN IP4 166.34.245.230  
m=audio 20208 RTP/AVP 0  
*Mar  8 17:36:40: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 166.34.245.230:54113  
*Mar  8 17:36:40: CCSIP-SPI-CONTROL:  sipSPISipIncomingCall  
*Mar  8 17:36:40: 0x624D8CCC : State change from (STATE_NONE, SUBSTATE_NONE)
 to (STATE_IDLE, SUBSTATE_NONE)  
*Mar  8 17:36:40: CCSIP-SPI-CONTROL:  act_idle_new_message  
*Mar  8 17:36:40: CCSIP-SPI-CONTROL:  sact_idle_new_message_invite  
*Mar  8 17:36:40: CCSIP-SPI-CONTROL:  sip_stats_method  
*Mar  8 17:36:40:  sact_idle_new_message_invite:Not Using Voice Class Codec  
*Mar  8 17:36:40: sact_idle_new_message_invite: Preferred codec[0] type: g711ulaw Bytes :160  
*Mar  8 17:36:40: sact_idle_new_message_invite: Media Negotiation successful for an
   incoming call  
*Mar  8 17:36:40: sact_idle_new_message_invite: Negotiated Codec 
    : g711ulaw, bytes :160  
Preferred Codec       : g711ulaw, bytes :160  
*Mar  8 17:36:40:  Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE  
*Mar  8 17:36:40: CCSIP-SPI-CONTROL:  sip_stats_status_code  
*Mar  8 17:36:40: Num of Contact Locations 1 3660110 166.34.245.230 5060  
*Mar  8 17:36:40: 0x624D8CCC : State change from (STATE_IDLE, SUBSTATE_NONE)
  to (STATE_RECD_INVITE, SUBSTATE_RECD_INVITE_CALL_SETUP)  
*Mar  8 17:36:40: Sent:   
SIP/2.0 100 Trying  
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>  
Date: Mon, 08 Mar 1993 22:36:40 GMT  
Call-ID: ABBAE7AF-823100CE-0-1CCAA69C@172.18.192.194  
Timestamp: 731427042  
Server: Cisco VoIP Gateway/ IOS 12.x/ SIP enabled  
CSeq: 101 INVITE  
Content-Length: 0  
*Mar  8 17:36:40:  Queued event From SIP SPI to CCAPI/DNS : SIPSPI_EV_CC_CALL_PROCEEDING  
*Mar  8 17:36:40: CCSIP-SPI-CONTROL:  act_recdinvite_proceeding  
*Mar  8 17:36:40:  Queued event From SIP SPI to CCAPI/DNS : SIPSPI_EV_CC_CALL_ALERTING  
*Mar  8 17:36:40: CCSIP-SPI-CONTROL:  ccsip_caps_ind  
*Mar  8 17:36:40: ccsip_caps_ind: codec(negotiated) = 5(Bytes 160)  
*Mar  8 17:36:40: ccsip_caps_ind: Load DSP with codec (5) g711ulaw, Bytes=160  
*Mar  8 17:36:40: ccsip_caps_ind: set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_INBAND_VOICE  
*Mar  8 17:36:40: CCSIP-SPI-CONTROL:  ccsip_caps_ack  
*Mar  8 17:36:40: CCSIP-SPI-CONTROL:  act_recdinvite_alerting  
*Mar  8 17:36:40:  180 Ringing with SDP - not likely  
*Mar  8 17:36:40:  Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE  
*Mar  8 17:36:40: CCSIP-SPI-CONTROL:  sip_stats_status_code  
*Mar  8 17:36:40: 0x624D8CCC : State change from (STATE_RECD_INVITE, 
 SUBSTATE_RECD_INVITE_CALL_SETUP)  to (STATE_SENT_ALERTING, SUBSTATE_NONE)  
*Mar  8 17:36:40: Sent:   
SIP/2.0 180 Ringing  
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>  
Date: Mon, 08 Mar 1993 22:36:40 GMT  
Call-ID: ABBAE7AF-823100CE-0-1CCAA69C@172.18.192.194  
Timestamp: 731427042  
Server: Cisco VoIP Gateway/ IOS 12.x/ SIP enabled  
CSeq: 101 INVITE  
Content-Type: application/sdp  
Content-Length: 137  
v=0  
o=CiscoSystemsSIP-GW-UserAgent 969 7889 IN IP4 166.34.245.231  
s=SIP Call  
t=0 0  
c=IN IP4 166.34.245.231  
m=audio 20038 RTP/AVP 0  
*Mar  8 17:36:44:  Queued event From SIP SPI to CCAPI/DNS : SIPSPI_EV_CC_CALL_CONNECT  
*Mar  8 17:36:44: CCSIP-SPI-CONTROL:  act_sentalert_connect  
*Mar  8 17:36:44: sipSPIAddLocalContact  
*Mar  8 17:36:44:  Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE  
*Mar  8 17:36:44: CCSIP-SPI-CONTROL:  sip_stats_status_code  
*Mar  8 17:36:44: 0x624D8CCC : State change from (STATE_SENT_ALERTING, SUBSTATE_NONE)
  to (STATE_SENT_SUCCESS, SUBSTATE_NONE)  
*Mar  8 17:36:44: Sent:   
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  
Date: Mon, 08 Mar 1993 22:36:40 GMT  
Call-ID: ABBAE7AF-823100CE-0-1CCAA69C@172.18.192.194  
Timestamp: 731427042  
Server: Cisco VoIP Gateway/ IOS 12.x/ SIP enabled  
Contact: <sip:3660210@166.34.245.231:5060;user=phone>  
CSeq: 101 INVITE  
Content-Type: application/sdp  
Content-Length: 137  
v=0  
o=CiscoSystemsSIP-GW-UserAgent 969 7889 IN IP4 166.34.245.231  
s=SIP Call  
t=0 0  
c=IN IP4 166.34.245.231  
m=audio 20038 RTP/AVP 0  
*Mar  8 17:36:44: Received:   
ACK sip:3660210@166.34.245.231:5060;user=phone SIP/2.0  
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  
Date: Sat, 06 Mar 1993 19:10:42 GMT  
Call-ID: ABBAE7AF-823100CE-0-1CCAA69C@172.18.192.194  
Max-Forwards: 6  
Content-Type: application/sdp  
Content-Length: 137  
CSeq: 101 ACK  
v=0  
o=CiscoSystemsSIP-GW-UserAgent 1212 283 IN IP4 166.34.245.230  
s=SIP Call  
t=0 0  
c=IN IP4 166.34.245.230  
m=audio 20208 RTP/AVP 0  
*Mar  8 17:36:44: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 166.34.245.230:54113  
*Mar  8 17:36:44: CCSIP-SPI-CONTROL:  act_sentsucc_new_message  
*Mar  8 17:36:44: CCSIP-SPI-CONTROL:  sip_stats_method  
*Mar  8 17:36:44: 0x624D8CCC : State change from (STATE_SENT_SUCCESS, SUBSTATE_NONE)
  to (STATE_ACTIVE, SUBSTATE_NONE)  
*Mar  8 17:36:44: The Call Setup Information is :  
        Call Control Block (CCB) : 0x624D8CCC  
        State of The Call        : STATE_ACTIVE  
        TCP Sockets Used         : NO  
        Calling Number           : 3660110  
        Called Number            : 3660210  
        Negotiated Codec         : g711ulaw  
        Source IP Address (Media): 166.34.245.231  
        Source IP Port    (Media): 20038  
        Destn  IP Address (Media): 166.34.245.230  
        Destn  IP Port    (Media): 20208  
        Destn SIP Addr (Control) : 166.34.245.230  
        Destn SIP Port (Control) : 5060  
        Destination Name         : 166.34.245.230  
*Mar  8 17:36:47:  Queued event From SIP SPI to CCAPI/DNS : SIPSPI_EV_CC_CALL_DISCONNECT  
*Mar  8 17:36:47: CCSIP-SPI-CONTROL:  act_active_disconnect  
*Mar  8 17:36:47:  Queued event from SIP SPI : SIPSPI_EV_CREATE_CONNECTION  
*Mar  8 17:36:47: 0x624D8CCC : State change from (STATE_ACTIVE, SUBSTATE_NONE)
  to (STATE_ACTIVE, SUBSTATE_CONNECTING)  
*Mar  8 17:36:47: REQUEST CONNECTION TO IP:166.34.245.230 PORT:5060  
*Mar  8 17:36:47: 0x624D8CCC : State change from (STATE_ACTIVE, SUBSTATE_CONNECTING)
  to (STATE_ACTIVE, SUBSTATE_CONNECTING)  
*Mar  8 17:36:47: CCSIP-SPI-CONTROL:  act_active_connection_created  
*Mar  8 17:36:47: CCSIP-SPI-CONTROL:  sipSPICheckSocketConnection  
*Mar  8 17:36:47: CCSIP-SPI-CONTROL:  sipSPICheckSocketConnection: Connid(1)
 created to 166.34.245.230:5060, local_port 54835  
*Mar  8 17:36:47:  Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE  
*Mar  8 17:36:47: CCSIP-SPI-CONTROL:  sip_stats_method  
*Mar  8 17:36:47: 0x624D8CCC : State change from (STATE_ACTIVE, SUBSTATE_CONNECTING)
  to (STATE_DISCONNECTING, SUBSTATE_NONE)  
*Mar  8 17:36:47: Sent:   
BYE sip:3660110@166.34.245.230:5060;user=phone SIP/2.0  
Via: SIP/2.0/UDP  166.34.245.231:54835  
From: <sip:3660210@166.34.245.231;user=phone;phone-context=unknown>;tag=27D3FCA8-C7F  
To: "3660110" <sip:3660110@166.34.245.230>  
Date: Mon, 08 Mar 1993 22:36:44 GMT  
Call-ID: ABBAE7AF-823100CE-0-1CCAA69C@172.18.192.194  
User-Agent: Cisco VoIP Gateway/ IOS 12.x/ SIP enabled  
Max-Forwards: 6  
Timestamp: 731612207  
CSeq: 101 BYE  
Content-Length: 0  
*Mar  8 17:36:47: Received:   
SIP/2.0 200 OK  
Via: SIP/2.0/UDP  166.34.245.231:54835  
From: <sip:3660210@166.34.245.231;user=phone;phone-context=unknown>;tag=27D3FCA8-C7F  
To: "3660110" <sip:3660110@166.34.245.230>  
Date: Sat, 06 Mar 1993 19:10:50 GMT  
Call-ID: ABBAE7AF-823100CE-0-1CCAA69C@172.18.192.194  
Server: Cisco VoIP Gateway/ IOS 12.x/ SIP enabled  
Timestamp: 731612207  
Content-Length: 0  
CSeq: 101 BYE  
*Mar  8 17:36:47: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 166.34.245.230:54113  
*Mar  8 17:36:47: CCSIP-SPI-CONTROL:  act_disconnecting_new_message  
*Mar  8 17:36:47: CCSIP-SPI-CONTROL:  sact_disconnecting_new_message_response  
*Mar  8 17:36:47: CCSIP-SPI-CONTROL:  sipSPICheckResponse  
*Mar  8 17:36:47: CCSIP-SPI-CONTROL:  sip_stats_status_code  
*Mar  8 17:36:47:  Roundtrip delay 4 milliseconds for method BYE  
*Mar  8 17:36:47: CCSIP-SPI-CONTROL:  sipSPICallCleanup  
*Mar  8 17:36:47:  Queued event from SIP SPI : SIPSPI_EV_CLOSE_CONNECTION  
*Mar  8 17:36:47: CLOSE CONNECTION TO CONNID:1  
*Mar  8 17:36:47: sipSPIIcpifUpdate :CallState: 4 Playout: 1265 DiscTime:66820800 
 ConnTime 66820420  
*Mar  8 17:36:47: 0x624D8CCC : State change from (STATE_DISCONNECTING, SUBSTATE_NONE)
 to (STATE_DEAD, SUBSTATE_NONE)  
*Mar  8 17:36:47: The Call Setup Information is :  
        Call Control Block (CCB) : 0x624D8CCC  
        State of The Call        : STATE_DEAD  
        TCP Sockets Used         : NO  
        Calling Number           : 3660110  
        Called Number            : 3660210  
        Negotiated Codec         : g711ulaw  
        Source IP Address (Media): 166.34.245.231  
        Source IP Port    (Media): 20038  
        Destn  IP Address (Media): 166.34.245.230  
        Destn  IP Port    (Media): 20208  
        Destn SIP Addr (Control) : 166.34.245.230  
        Destn SIP Port (Control) : 5060  
        Destination Name         : 166.34.245.230  
*Mar  8 17:36:47:   
       Disconnect Cause (CC)    : 16  
       Disconnect Cause (SIP)   : 200  
*Mar  8 17:36:47: udpsock_close_connect: Socket fd: 1 closed for connid 1 
  with remote port: 5060