You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »



Overview


SIP – Session Initiation Protocol – is used for establishing and maintaining real-time sessions used in voice, video and messaging applications.

Protocol initiation goes through several steps, or message types.

For each message type, there is a Response code similar to HTTP, with 1xx being informational, 2xx/3xx being success, and 4xx, 5xx, 6xx indicating a failure.

VSM summarizes this data for Avaya Session Managers and Avaya Session Border Controllers.


The SIP Response Summary dashlet summarizes this data over a 24 hour period, showing a break-down across

  • 15 minute intervals
  • By message type
  • By response code


Those response codes are broken down into 4 bands:

  • Informational (blue): 1xx response codes
  • Success (green): 2xx/3xx response codes
  • Client-side failure (amber): 4xx response codes
  • Server-side or global failure (red): 5xx response codes

By default all message types are shown, but it is possible to toggle based on specific message types, for example, to assess whether there are any unusual security breaches occurring, toggle off all but Registration and review the amber for authorization errors.


From this view it is possible to identify system outages, configuration or implementation problems, or external security attacks. 



SIP Response Summary dashlet showing a system outage at 8am

Example 1: In this example, everything looks normal - the vast majority of responses are 2xx, or successful responses with only a small percentage of authorization errors, which is to be expected.  Then at 8am there is an outage, causing a rapid spike of Internal Server Errors on Invites.



Example 2: This traffic was observed on an external facing SBC - 3/4 of all Invites were met with a Authorization 401, or 403 response code, indicating heavy security attacks requiring further input from engineers

Example 3: When filtering by message type, it can be seen that a large percentage of service messages are returning a 'Bad Request' error.  This is likely caused by an internal implementation error where something is querying the SIP server for a service response, but has been misconfigured. 





Example 2



Troubleshooting



Not seeing any SIP response code data? 

  1. Check SIP Tracer is enabled within the configuration of your Session Border Controller, or Session Manager
  2. Point it to the VSM Collector IP Address, UDP port 514.  The VSM Collector IP address will be assigned the IPV4/FQDN of the machine VSM is installed on.   Further help configuring SIP Tracer is available hereNote for v8.0 of SBCs there is a known issue enabling the SIP Tracer, where clicking the checkbox does not save. 
  3. Still having issues? Contact your business partner or Virsae support.



Seeing a difference between All Source equipment and individually selected equipment?

 

When selecting 'All' from the settings, VSM collects all SIP data for that location.  However, in some cases the source IP address does not match the equipment it is configured under Manage Equipment.  This is caused by a configuration issue, contact your local system administrator for more assistance. 






  • No labels