SIP gateway monitoring. SIP Trunk. CUBE.

Aurus Blog

This blog is to share our expertise in Cisco UCM, UCCX/UCCE and Cisco Meeting Server

  • Archive

    «   April 2024   »
    M T W T F S S
    1 2 3 4 5 6 7
    8 9 10 11 12 13 14
    15 16 17 18 19 20 21
    22 23 24 25 26 27 28
    29 30          

SIP gateway monitoring. SIP Trunk. CUBE.

This article is about practical monitoring that helps answering such questions as call activity, the calls passing through a trunk, etc.

Call activity on CUBE

  • Active calls:
        show call active voice compact
  • The active calls summary by the number of call legs:
        show call active voice summary
  • Recent calls:
        show call history voice compact

Call activity on CUBE from the point of view of CUCM

You can view the CUBE load in CAR:
https://cucm_ip:8443/car
Proceed to: Device Reports -> Trunk -> Utilization
Find your trunk and specify the report.
This report can only give you the notion about the trunk load in general, without any details.

Monitoring CUBE activity through SNMP

This is a very useful feature that allows you to perform online monitoring without any commands and reports. You can monitor the calls and connections through SNMP and view this information in PRTG. The most useful MIB is:
CISCO-VOICE-DIAL-CONTROL-MIB
We are interested in the following OIDs here:

  • CISCO-VOICE-DIAL-CONTROL-MIB/cv call volume/cv call vol conn total active connections
  • CISCO-VOICE-DIAL-CONTROL-MIB/cv call vol if: Loopback0/cv call vol media incoming calls
  • CISCO-VOICE-DIAL-CONTROL-MIB/cv call vol if: Loopback0/cv call vol media outgoing calls

Loopback0 is an inside interface on which all internal dial peers are bound, for example, like this:

dial-peer voice 500124 voip
description internal to CUCM
preference 3
destination-pattern [1-4]...
session protocol sipv2
session target ipv4:10.190.65.12
voice-class codec 1
voice-class sip bind control source-interface Loopback0
voice-class sip bind media source-interface Loopback0
dtmf-relay rtp-nte
ip qos dscp cs3 signaling
no vad

Directory numbers in trunk calls

Suppose that after PRTG monitoring a call activity surge aroused our interest. There are two ways to know what subscribers took part in it:

  • RTMT
    Proceed to: Call Manager -> Call Process -> Session Trace
    Here we can specify the time period and determine the gateway we are interested in using Called Named Device field.
    Session Trace is useful for obtaining up-to-date information on all the calls in cluster nearly in real time.
  • CDR
    And, of course, we always can get the information on the calls from a CDR file.
    - Log in to Cisco Unified CallManager CAR interface: https://:8443/car/
    - CDR > Export CDR/CMR
    - Select the time period and click Export to file.
    - On the next screen you can download the file.
    - Then open the file in MS Excel to analyze it.
    For your convenience you should do the following:
    - Select the first line (legend), then in MS Excel menu click Data -> Filter -> AutoFilter, and then Format -> Column -> AutoFit.

The fields of interest are:
origDeviceName
destDeviceName
You can also find the trunk by its name.

You can find the field descriptions here: Cisco Call Detail Records Field Descriptions

Notice the date and time format in dateTimeOrigination field. This is the number of seconds beginning from the midnight (00:00:00) of January 1, 1970. To make this readable, you can insert a column, format it as Date and use the following formula: =((E2 + 14400) / 86400) + 25569.