In the dashlet settings, the Source Equipment is limited to a maximum of 5. After five are selected the remaining equipment will be greyed out and cannot be selected.
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 Session Managers and 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.
When the dashet is set to Huge size then the view includes anomaly detction by Response.
Example 1 - System Outage: 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 - Security issue: 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 - Configuration issue: 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.
Anomoly Detection on Huge size
SIP Response Summary (Huge) with anomaly detection
Troubleshooting
Not seeing any SIP response code data?
- Check SIP Tracing is enabled within the configuration of your Session Manager or Session Border Controller.
- Further help configuring SIP Tracer is available here.
- Note for v8.0 of Avaya SBCs there is a known issue enabling the SIP Tracer, where clicking the checkbox on the SBC does not save.
- Ensure any firewalls or network security allows the SIP Traces to route to the VSM Collector IP address on UDP port 514.
- 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. In some cases, the IP address that SIP Data has been received from may not match the equipment IP address configured under Manage Equipment.
If you have this issue please contact your Business Partner or Virsae Support to get assistance to correct the configuration.