{"id":2336,"date":"2017-02-14T13:09:20","date_gmt":"2017-02-14T13:09:20","guid":{"rendered":"http:\/\/emtunc.org\/blog\/?p=2336"},"modified":"2017-02-14T13:09:20","modified_gmt":"2017-02-14T13:09:20","slug":"cucm-snmp-active-call-stats","status":"publish","type":"post","link":"https:\/\/emtunc.org\/blog\/02\/2017\/cucm-snmp-active-call-stats\/","title":{"rendered":"CUCM SNMP Active Call Stats"},"content":{"rendered":"

So the title is a bit misleading but I figured it’s what most people will search if they want to get active call stats from their Cisco Unified Communications infrastructure – it’s certainly what I searched when I wanted to achieve the same thing. Turns out you can only get active call stats via SNMP from the Cisco Unified Border Element (CUBE).<\/p>\n

I will show you how you can get the active\u00a0incoming\/outgoing and total external<\/span>\u00a0calls and how you can use these in PRTG to get a nice graph going of Active Calls Vs Bandwidth<\/em>.<\/p>\n

What you\u00a0won’t<\/span> see is the number of\u00a0internal<\/span> calls as we are only monitoring the CUBE. Internal calls don’t touch the CUBE and as far as my research went, the CUCM server doesn’t keep track of active calls… at least not without some manipulation of OIDs.<\/p>\n

<\/p>\n

    \n
  1. First we need to SSH to the CUBE and enable SNMP\n
    configure terminal\r\nsnmp-server community <your-community-string>\r\nsnmp-server location <location of CUBE>\r\nsnmp-server contact <contact e-mail><\/pre>\n<\/li>\n
  2. Next we need the dial-peer voice numbers\/tags for the inbound and outbound calls. Do a\u00a0show running-config<\/strong> on the CUBE and look for the sections labelled\u00a0dial-peer voice <number>
    \n<\/strong>
    \nYou need to figure out which of your dial-peers’ match up to inbound and outbound calls. In my set-up it looks like this:<\/p>\n
    dial-peer voice 10 voip\r\ndescription Outbound Dial-peer to SIP Provider\r\ntranslation-profile outgoing Outbound\r\npreference 1\r\n[...]\r\n\r\ndial-peer voice 20 voip\r\ndescription Inbound Dial-peer to CUCM\r\ntranslation-profile outgoing Inbound\r\npreference 1\r\n[...]<\/pre>\n
    So dial-peer 10 is outbound calls and dial-peer 20 for inbound calls.<\/p>\n
    To confirm you have the right dial-peer numbers, you can do a SNMP walk against the following OID\u00a01.3.6.1.4.1.9.9.63.1.3.8.4.1.2 – you should see only a handful of sub-OID’s – start doing a few test outbound\/inbound calls and you should see the values change.<\/li>\n
  3. In PRTG add a SNMP Custom<\/strong> sensor. We’ll create two of these – one for outbound calls and another for inbound.In the OID put the following:\n
    1.3.6.1.4.1.9.9.63.1.3.8.4.1.2.<dial-plan><\/p>\n
    It should look something like this:<\/p>\n
    \"\"<\/a><\/p>\n
    Now do the same for outbound calls.<\/li>\n
  4. Now add a Sensor Factory<\/strong> sensor in PRTG.Follow the screenshot below but note that the sensor ID’s\u00a0will<\/strong> be different in your PRTG instance.\n
    #1:Calls: Total [Calls] – all this does is label the axis
    \nchannel(5469,0) + channel(5468,0) – these are the sensor ID’s for inbound and outbound calls. You can find the sensor ID’s in the URL of the sensor.
    \n#2:CUBE: Total Bandwidth Utilisation – the other axis for bandwidth
    \nChannel(5448,1) – This grabs the bandwidth sensor from the CUBE and uses channel 1 which equates to traffic out.<\/p>\n
    So basically: Channel<sensorID>,<channelID><\/p>\n
    \"\"<\/a><\/li>\n<\/ol>\n
    That’s all there is to it. I’ve only demonstrated how to do Total Calls Vs Bandwidth but you could easily to Inbound Vs Outbound, etc by playing around with the\u00a0Sensor Factory<\/em> in PRTG.<\/p>\n
    \"\"<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
    So the title is a bit misleading but I figured it’s what most people will search if they want to get active call stats from their Cisco Unified Communications infrastructure – it’s certainly what I searched when I wanted to achieve the same thing. Turns out you can only get active call stats via SNMP […]<\/p>\n","protected":false},"author":32,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"footnotes":""},"categories":[1],"tags":[256,255,245],"class_list":["post-2336","post","type-post","status-publish","format-standard","hentry","category-tech","tag-cube","tag-cucm","tag-snmp"],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p1trTO-BG","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/posts\/2336","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/comments?post=2336"}],"version-history":[{"count":3,"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/posts\/2336\/revisions"}],"predecessor-version":[{"id":2425,"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/posts\/2336\/revisions\/2425"}],"wp:attachment":[{"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/media?parent=2336"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/categories?post=2336"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/tags?post=2336"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}