Maintaining the SIP Interface

The following information is available to maintain and troubleshoot SIP trunks:

• Maintenance Commands

• Maintenance Logs

Maintenance Commands

See SIP for information on the maintenance commands available for SIP peers.

Maintenance Logs

The following logs indicate maintenance information for the SIP link:

• SIP link state information

• Busy out/return to service command against SIP link

• Authentication request failure

• Successful registration

• Malicious call trace

• Media Negotiation

SIP link state information

Busy out / return to service command against SIP link

Authentication request failure

The system maintains the authentication request failure counter on a per IP address basis, and it periodically logs the failure's relevant information (for example on every 5th failure for the IP address).

Registering and error handling

Each SIP trunk registers with its registrar and the following actions are performed:

• At startup time, it sends registration requests to its registrar with an initial expiration interval of 3600 seconds, and re-submits the registration request with its credentials (username and password) when challenged, that is, upon receiving 401 (Unauthorized) or 407 (Proxy Authentication Required) response from the registrar.

• If the registration is successful, that is, it receives 200 OK, the alarm for SIP links is re-calculated or cleared. The following maintenance log is posted:

• Note: The xxxx in the log is the expiration interval confirmed by the registrar in the 200 OK response.

• It refreshes the binding at half time of the expiration interval confirmed by the registrar.

• If its registrar is changed from ESM during runtime, removes its binding from the old registrar and re-registers with the new one.

• If the FQDN of the ICP is changed from ESM during run time, it updates its binding in the registrar.

• If the credentials are changed from ESM during run time, it uses the new credentials at next refreshing attempt when challenged. The same user name and password pair are shared between registration and SIP trunk calls. Hence the credentials for a SIP peer profile must be changed at both the service provider and the 3300 ICP before a successful call can be established if the challenge scheme is desired.

• It removes its binding from the registrar upon a graceful shutdown. Regardless of the shutdown mode, graceful or ungraceful, each SIP trunk re-registers with its service provider at startup.

The following errors are handled:

• If the trunk receives 423 (Interval Too Brief), it re-registers with the expiration interval specified in the Min-Expire header of the 423 response.

• If the trunk receives 403 (Forbidden), it will not re-try until its credentials are updated. An alarm is raised and the following maintenance log is posted:

• If the trunk receives 500 (Server Error), the system retries using the value in the Retry-after header or 90 seconds if the header is not present. An alarm is raised and the following maintenance log is posted the first time this error is received:

• If no response is received from the registrar, the system retries registration every 90 seconds until a response is received from the registrar. An alarm is raised and the following maintenance log will be posted after the failure of the first attempt:

• For the rest of the error responses, no retry is attempted. An alarm is raised and the following maintenance log will be posted after the failure of the first attempt:

• Note: The x in the log is the error response code received.

Malicious call trace

The system supports Malicious Call Trace on European ISDN interfaces only, and does not support it on the SIP interface. Malicious call SMDR records are recorded on the 3300 ICP. Call control sends a DPNSS LLM to the SIP component when a user wishes to tag a call. The 3300 ICP creates a maintenance log:

The SIPMH logs information about the Media IP address and port being used remotely:

INFO SIP – Maintenance 2005/08/08 04:56:12 Maintenance(0)

   Malicous Call Trace Id 0x12345 SendRecv

   Local IP: 10.10.10.20:9000

   Remote IP: 192.168.2.23:7892

The SSP logs information about the SIP signaling information:

INFO SIP – Maintenance 2005/08/08 04:56:12 Maintenance(0)

   Malicous Call Trace Id 0x12345

   To: 5234@10.10.10.10

   From: "Anon" anon@anonymous.invalid

   Contact: 192.168.2.23

If there are other useful headers, SSP logs them as well.

Media Negotiation

1) Incompatible packet rate capabilities

If a call requiring a non-standard packet rate is made to an endpoint that does not support variable packet rates, it will (if possible) produce the following log:

1 WARNING Media Negotiation 2008/02/02 12:00:00 MaintenanceLog(0)
Incompatible RTP packetization capabilities detected on call between SIP port xxxxxxxx and port xxxxxxxx

2) Simple Call to SIP Endpoint

When the 3300 ICP sees SDP coming from a SIP endpoint that contains either no ptime parameter, or a ptime that is not equal to the packetization rate programmed against the SIP trunk, it will produce the following log:

1 INFO Media Negotiation 2008/02/02 12:00:00 MaintenanceLog(0)

Different RTP packetization rates detected on call between SIP endpoints.

The log above is only an INFO level log as it may be generated even if the parties on the actual phone call do not detect a problem.

3) Transiting the Enterprise Cluster

It is possible, though unlikely, that a call may enter a 3300 ICP cluster via one SIP trunk, and exit the cluster through another SIP trunk to a different service provider. If the two Service Providers require different packetization rates, the result may be one-way, no-way, or garbled audio. In such scenarios, the following log will be produced:

1 WARNING Media Negotiation 2008/02/02 12:00:00 MaintenanceLog(0)
Different RTP packetization rates (xx ms detected, yy ms programmed) detected on call.

SIP To Header: xxxxxxxxxx

SIP From Header: xxxxxxxxxx

SIP Contact Header: xxxxxxxxxx

This log will be generated on both gateway nodes.

4) Calls that Require Rates Outside the Supported Range

The SIP Peer Profile form provides a range of packetization rates that calls across SIP trunks can be forced to use. If a SIP service provider requires media streams that use a packetization rate outside of this range the SIP call will likely  fail. In the event that the negotiation does not fail, the media stream will likely not be played properly by the endpoint. Nevertheless, if a call is detected that uses a non-supported rate, the following log will be generated:

1 WARNING Media Negotiation 2008/02/02 12:00:00 MaintenanceLog(0)
Unsupported RTP packetization rate of xx ms detected on call across SIP Peer xxxxxxxx.