andrewgroup Posted January 17, 2009 Report Share Posted January 17, 2009 While Emails from a PBX might Seem as useful as SNMP, I would argue that emails do not scale as well as an SNMP monitoring console. As a service provider we actively use WMI and SNMP to monitoring installed IT solutions and PBXnSIP. Expanding the use of SNMP is considerably easier than managing email alerts. An email alerting system requires 1 of 2 things A human being or an email parsing system. Needless to say the costs and complexiities of either are considerable and managing that can be a nightmare on VoIP Street. The fundemental problem with email fault notification is that we are forced to assume that all is well since no emails are arriving. "Out of Sight - Out of Mind." I can easily think of 50 things that commonly happen that would prevent those fault email alerts from arriving. But with a SNMP management consoles you easily define faults and alerts on failed SNMP queries as the first sign of a potential client trouble. As a service provider with SLA agreements with clients knowing on or before a client calls (on their cell phones) that a trouble may exist is a GREAT service. It would also be wonderful to get and provide additonal information that further solidifies the client relationship. Below is what we know about the SNMP variable and a few questions and a short wish list. these are the variables that we know of and my questions.. ;Call Objects Yes Calls (THE CALL OBJECT THAT MATTERS MOST IS TRUNK CALLS - Nobody cares about internal calls) ;Registrations Yes Registrations (WHAT ABOUT 2 PHONES REGISTERED TO SAME EXTENSION - WOULD THIS BE 2 REGISTRATIONS?) ;Messages Yes Minutes (THE MIB HAS THIS AS MESSAGES DOES THE TERM MINUTES FRO THE TEST MIB MEAN MINUTES WORTH OF MESSAGES?) ;Call Attempts No Calls (IS THIS VALUE DYNAMIC?) COULD THIS BE SET IN GLOBAL SETTINGS TO RESET EVERY 2 MINUTES? ;Successful Calls No Calls (COULD THIS BE CONTROLLED IN GLOBAL SETTINGS? ;Media CPU load Yes Value 0..100 (SELF EXPLANATORY) ;Successful Emails No Emails ;Unsuccessful Emails No Emails ;Email Alert Flag Yes Value 0..1 ;SIP Received Packets No Packets ;SIP Sent Packets No Packets Consider Adding ACTIVE TRUNK CALLS ACTIVE TRUNKS ACTIVE EXTENSIONS UPTIME Total Trunk calls, PER MINUTE, HOUR, DAY, WEEK, MONTH, YEAR (minute, hours and days would be enough, the rest is just a stretch) : - ) Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 19, 2009 Report Share Posted January 19, 2009 ACTIVE TRUNK CALLS I am not the big expert on SNMP... Is it possible to pass a string to the GET request? Then the SNMP tool could tell the PBX what trunk it is interested in. That would simplify the setup. Otherwise we would have to assign a OID to every trunk. That would not simplify the setup. Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted January 19, 2009 Author Report Share Posted January 19, 2009 I am not the big expert on SNMP... Is it possible to pass a string to the GET request? Then the SNMP tool could tell the PBX what trunk it is interested in. That would simplify the setup. Otherwise we would have to assign a OID to every trunk. That would not simplify the setup. The great majority of PBXnSIP installations that we would be installing would almost always have just 1 trunk. If they had more than 1 trunk we would still consider that trunk as making calls and knowing total out-in calls vs. total calls that might include internal calls would be best. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 19, 2009 Report Share Posted January 19, 2009 The great majority of PBXnSIP installations that we would be installing would almost always have just 1 trunk. If they had more than 1 trunk we would still consider that trunk as making calls and knowing total out-in calls vs. total calls that might include internal calls would be best. Okay, we added 13: Number calls (not call legs) and 14: Number of calls on a specific trunk. The trunk number must be the index of the trunk (to locate it see the XML file name in the trunks directory). For example, if the file name is 25.xml then the OID would be 1.3.6.1.4.1.25060.1.14.25. Check out http://pbxnsip.com/protect/pbxctrl-3.2.0.3138.exe for a build that has these two additional OID. Would be great if you can verify this. Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted January 19, 2009 Author Report Share Posted January 19, 2009 Our XML trunk file is 13, does this overide the newly added 13? Here is what we get for .13 and the following is a successful 2 call test The first get shows no call, then we made 1 and then another call and the value increased by 1 correctly 1/19/2009 11:51:30 AM (0 ms) : Start using SNMP V1 1/19/2009 11:51:30 AM (1 ms) : GET: .1.3.6.1.4.1.25060.1.13 1/19/2009 11:51:30 AM (6 ms) : ------- 1/19/2009 11:51:30 AM (7 ms) : Result: 0 1/19/2009 11:51:30 AM (9 ms) : Value: 0 1/19/2009 11:51:30 AM (10 ms) : Done 1/19/2009 11:51:37 AM (0 ms) : Start using SNMP V1 1/19/2009 11:51:37 AM (1 ms) : GET: .1.3.6.1.4.1.25060.1.13 1/19/2009 11:51:37 AM (7 ms) : ------- 1/19/2009 11:51:37 AM (9 ms) : Result: 0 1/19/2009 11:51:37 AM (11 ms) : Value: 1 1/19/2009 11:51:37 AM (13 ms) : Done 1/19/2009 11:51:55 AM (0 ms) : Start using SNMP V1 1/19/2009 11:51:55 AM (2 ms) : GET: .1.3.6.1.4.1.25060.1.13 1/19/2009 11:51:55 AM (8 ms) : ------- 1/19/2009 11:51:55 AM (10 ms) : Result: 0 1/19/2009 11:51:55 AM (13 ms) : Value: 2 1/19/2009 11:51:55 AM (16 ms) : Done Then with not TRUNK calls I placed a call from Ext to Ext and the value shows 1 call.. 1/19/2009 11:53:45 AM (0 ms) : Start using SNMP V1 1/19/2009 11:53:45 AM (6 ms) : GET: .1.3.6.1.4.1.25060.1.13 1/19/2009 11:53:45 AM (17 ms) : ------- 1/19/2009 11:53:45 AM (24 ms) : Result: 0 1/19/2009 11:53:45 AM (30 ms) : Value: 1 1/19/2009 11:53:45 AM (36 ms) : Done I would prefer not to see any EXT to EXT calls for the TRUNK OID... Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 19, 2009 Report Share Posted January 19, 2009 Our XML trunk file is 13, does this overide the newly added 13? Nono, use .14.x, where x is the trunk number. This OID has one more digit than the other OID. Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted January 19, 2009 Author Report Share Posted January 19, 2009 Nono, use .14.x, where x is the trunk number. This OID has one more digit than the other OID. This query results are; 1/19/2009 12:04:43 PM (0 ms) : Start using SNMP V1 1/19/2009 12:04:43 PM (7 ms) : GET: .1.3.6.1.4.1.25060.1.14.13 1/19/2009 12:04:43 PM (18 ms) : ------- 1/19/2009 12:04:43 PM (25 ms) : Result: -1002 1/19/2009 12:04:43 PM (31 ms) : Value: No var structure 1/19/2009 12:04:43 PM (40 ms) : Done THE LOG FILE ON PBX is [8] 2009/01/19 12:07:52: SNMP: Received unknown object identifier 060b2b0601040181c364010e0d Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted January 20, 2009 Author Report Share Posted January 20, 2009 Experiencing some Successes and now appear to be collecting - charting and alerting on the .1 thru .11 using our SNMP management tools without an an imported MIB file. .13 appears to show all active calls and .14.X is not functioning as expected... Below is a wireshark capture of failures - IP's changes to protect the innocent. No. Time Source Destination Protocol Info 352 3.403608 999.92.190.29 66.158.175.999 SNMP get-request Frame 352 (85 bytes on wire, 85 bytes captured) Ethernet II, Src: Adtran_3b:82:b6 (00:a0:c8:3b:82:b6), Dst: CameoCom_17:b3:06 (00:18:e7:17:b3:06) Internet Protocol, Src: 999.92.190.29 (999.92.190.29), Dst: 66.158.175.999 (66.158.175.999) User Datagram Protocol, Src Port: 61547 (61547), Dst Port: snmp (161) Simple Network Management Protocol version: version-1 (0) community: public data: get-request (0) get-request request-id: 0 error-status: noError (0) error-index: 0 variable-bindings: 1 item SNMPv2-SMI::enterprises.25060.1.14.13 (1.3.6.1.4.1.25060.1.14.13): <MISSING> Object Name: 1.3.6.1.4.1.25060.1.14.13 (SNMPv2-SMI::enterprises.25060.1.14.13) Value (OctetString): <MISSING> No. Time Source Destination Protocol Info 353 3.403901 66.158.175.999 999.92.190.29 SNMP get-response Frame 353 (68 bytes on wire, 68 bytes captured) Ethernet II, Src: CameoCom_17:b3:06 (00:18:e7:17:b3:06), Dst: Adtran_3b:82:b6 (00:a0:c8:3b:82:b6) Internet Protocol, Src: 66.158.175.999 (66.158.175.999), Dst: 999.92.190.29 (999.92.190.29) User Datagram Protocol, Src Port: snmp (161), Dst Port: 61547 (61547) Simple Network Management Protocol version: version-1 (0) community: public data: get-response (2) get-response request-id: 0 error-status: noError (0) error-index: 0 variable-bindings: 0 items No. Time Source Destination Protocol Info 1040 10.229458 999.92.190.29 66.158.175.999 SNMP get-request Frame 1040 (84 bytes on wire, 84 bytes captured) Ethernet II, Src: Adtran_3b:82:b6 (00:a0:c8:3b:82:b6), Dst: CameoCom_17:b3:06 (00:18:e7:17:b3:06) Internet Protocol, Src: 999.92.190.29 (999.92.190.29), Dst: 66.158.175.999 (66.158.175.999) User Datagram Protocol, Src Port: 61548 (61548), Dst Port: snmp (161) Simple Network Management Protocol version: version-1 (0) community: public data: get-request (0) get-request request-id: 0 error-status: noError (0) error-index: 0 variable-bindings: 1 item SNMPv2-SMI::enterprises.25060.1.13 (1.3.6.1.4.1.25060.1.13): <MISSING> Object Name: 1.3.6.1.4.1.25060.1.13 (SNMPv2-SMI::enterprises.25060.1.13) Value (OctetString): <MISSING> No. Time Source Destination Protocol Info 1041 10.229753 66.158.175.999 999.92.190.29 SNMP get-response Frame 1041 (85 bytes on wire, 85 bytes captured) Ethernet II, Src: CameoCom_17:b3:06 (00:18:e7:17:b3:06), Dst: Adtran_3b:82:b6 (00:a0:c8:3b:82:b6) Internet Protocol, Src: 66.158.175.999 (66.158.175.999), Dst: 999.92.190.29 (999.92.190.29) User Datagram Protocol, Src Port: snmp (161), Dst Port: 61548 (61548) Simple Network Management Protocol version: version-1 (0) community: public data: get-response (2) get-response request-id: 0 error-status: noError (0) error-index: 0 variable-bindings: 1 item SNMPv2-SMI::enterprises.25060.1.13 (1.3.6.1.4.1.25060.1.13): 1 Object Name: 1.3.6.1.4.1.25060.1.13 (SNMPv2-SMI::enterprises.25060.1.13) Value (Integer32): 1 No. Time Source Destination Protocol Info 1777 17.486801 999.92.190.29 66.158.175.999 SNMP get-request Frame 1777 (85 bytes on wire, 85 bytes captured) Ethernet II, Src: Adtran_3b:82:b6 (00:a0:c8:3b:82:b6), Dst: CameoCom_17:b3:06 (00:18:e7:17:b3:06) Internet Protocol, Src: 999.92.190.29 (999.92.190.29), Dst: 66.158.175.999 (66.158.175.999) User Datagram Protocol, Src Port: 61549 (61549), Dst Port: snmp (161) Simple Network Management Protocol version: version-1 (0) community: public data: get-request (0) get-request request-id: 0 error-status: noError (0) error-index: 0 variable-bindings: 1 item SNMPv2-SMI::enterprises.25060.1.13.13 (1.3.6.1.4.1.25060.1.13.13): <MISSING> Object Name: 1.3.6.1.4.1.25060.1.13.13 (SNMPv2-SMI::enterprises.25060.1.13.13) Value (OctetString): <MISSING> No. Time Source Destination Protocol Info 1778 17.487300 66.158.175.999 999.92.190.29 SNMP get-response Frame 1778 (68 bytes on wire, 68 bytes captured) Ethernet II, Src: CameoCom_17:b3:06 (00:18:e7:17:b3:06), Dst: Adtran_3b:82:b6 (00:a0:c8:3b:82:b6) Internet Protocol, Src: 66.158.175.999 (66.158.175.999), Dst: 999.92.190.29 (999.92.190.29) User Datagram Protocol, Src Port: snmp (161), Dst Port: 61549 (61549) Simple Network Management Protocol version: version-1 (0) community: public data: get-response (2) get-response request-id: 0 error-status: noError (0) error-index: 0 variable-bindings: 0 items No. Time Source Destination Protocol Info 2140 23.787125 203.63.95.69 66.158.175.999 SNMP get-request Frame 2140 (95 bytes on wire, 95 bytes captured) Ethernet II, Src: Adtran_3b:82:b6 (00:a0:c8:3b:82:b6), Dst: CameoCom_17:b3:06 (00:18:e7:17:b3:06) Internet Protocol, Src: 203.63.95.69 (203.63.95.69), Dst: 66.158.175.999 (66.158.175.999) User Datagram Protocol, Src Port: 4836 (4836), Dst Port: snmp (161) Simple Network Management Protocol version: version-1 (0) community: public data: get-request (0) get-request request-id: 102667661 error-status: noError (0) error-index: 0 variable-bindings: 1 item SNMPv2-SMI::enterprises.25060.1.1 (1.3.6.1.4.1.25060.1.1): Value (Null) Object Name: 1.3.6.1.4.1.25060.1.1 (SNMPv2-SMI::enterprises.25060.1.1) Value (Null) No. Time Source Destination Protocol Info 2145 26.785264 203.63.95.69 66.158.175.999 SNMP get-request Frame 2145 (95 bytes on wire, 95 bytes captured) Ethernet II, Src: Adtran_3b:82:b6 (00:a0:c8:3b:82:b6), Dst: CameoCom_17:b3:06 (00:18:e7:17:b3:06) Internet Protocol, Src: 203.63.95.69 (203.63.95.69), Dst: 66.158.175.999 (66.158.175.999) User Datagram Protocol, Src Port: 4836 (4836), Dst Port: snmp (161) Simple Network Management Protocol version: version-1 (0) community: public data: get-request (0) get-request request-id: 102667661 error-status: noError (0) error-index: 0 variable-bindings: 1 item SNMPv2-SMI::enterprises.25060.1.1 (1.3.6.1.4.1.25060.1.1): Value (Null) Object Name: 1.3.6.1.4.1.25060.1.1 (SNMPv2-SMI::enterprises.25060.1.1) Value (Null) Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted January 20, 2009 Author Report Share Posted January 20, 2009 With all our progress we see this in the PBX log file. [5] 2009/01/19 22:32:19: SNMP: Expecting GET (packet ignored) 302902010004067075626c6963a11c02020a7a0201000201003010300e060a2b0601020119030301 020500 [5] 2009/01/19 22:32:19: SNMP: Expecting GET (packet ignored) 302902010004067075626c6963a11c02020a7c0201000201003010300e060a2b0601020119020301 010500 [5] 2009/01/19 22:32:19: SNMP: Expecting GET (packet ignored) 302902010004067075626c6963a11c02020a7e0201000201003010300e060a2b0601020119020301 020500 [5] 2009/01/19 22:32:22: SNMP: Expecting GET (packet ignored) 302902010004067075626c6963a11c02020a7a0201000201003010300e060a2b0601020119030301 020500 [5] 2009/01/19 22:32:22: SNMP: Expecting GET (packet ignored) 302902010004067075626c6963a11c02020a7c0201000201003010300e060a2b0601020119020301 010500 [5] 2009/01/19 22:32:22: SNMP: Expecting GET (packet ignored) 302902010004067075626c6963a11c02020a7e0201000201003010300e060a2b0601020119020301 020500 [5] 2009/01/19 22:32:28: SNMP: Expecting SNMPv1 community public (packet ignored) Attached is a quick chart Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted January 21, 2009 Author Report Share Posted January 21, 2009 I may have updated my previous post to quickly and it wasn't obvious that we immediately tested the available release with the .13 and .14 SNMP options. Based on these new additions... Okay, we added 13: Number calls (not call legs) and 14: Number of calls on a specific trunk. The trunk number must be the index of the trunk (to locate it see the XML file name in the trunks directory). For example, if the file name is 25.xml then the OID would be 1.3.6.1.4.1.25060.1.14.25. The testing we did confirms that .13 shows all active calls regardless of trunk or station to station. Trying to add the ID of the associated XML trunk file results in no response from the PBX. We captured the actual packets for the testing of the .14.13 query. We are very interested in expanding our use of SNMP and are happy to help in any way possible - Cheers. 352 3.403608 999.92.190.29 66.158.175.999 SNMP get-request Frame 352 (85 bytes on wire, 85 bytes captured) Ethernet II, Src: Adtran_3b:82:b6 (00:a0:c8:3b:82:b6), Dst: CameoCom_17:b3:06 (00:18:e7:17:b3:06) Internet Protocol, Src: 999.92.190.29 (999.92.190.29), Dst: 66.158.175.999 (66.158.175.999) User Datagram Protocol, Src Port: 61547 (61547), Dst Port: snmp (161) Simple Network Management Protocol version: version-1 (0) community: public data: get-request (0) get-request request-id: 0 error-status: noError (0) error-index: 0 variable-bindings: 1 item SNMPv2-SMI::enterprises.25060.1.14.13 (1.3.6.1.4.1.25060.1.14.13): <MISSING> Object Name: 1.3.6.1.4.1.25060.1.14.13 (SNMPv2-SMI::enterprises.25060.1.14.13) Value (OctetString): <MISSING> No. Time Source Destination Protocol Info 353 3.403901 66.158.175.999 999.92.190.29 SNMP get-response Frame 353 (68 bytes on wire, 68 bytes captured) Ethernet II, Src: CameoCom_17:b3:06 (00:18:e7:17:b3:06), Dst: Adtran_3b:82:b6 (00:a0:c8:3b:82:b6) Internet Protocol, Src: 66.158.175.999 (66.158.175.999), Dst: 999.92.190.29 (999.92.190.29) User Datagram Protocol, Src Port: snmp (161), Dst Port: 61547 (61547) Simple Network Management Protocol version: version-1 (0) community: public data: get-response (2) get-response request-id: 0 error-status: noError (0) error-index: 0 variable-bindings: 0 items No. Time Source Destination Protocol Info Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 22, 2009 Report Share Posted January 22, 2009 Oh oh. There was a bug in OID.14.x. Please get the latest & greatest from http://pbxnsip.com/protect/pbxctrl-3.2.0.3140.exe. Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted January 22, 2009 Author Report Share Posted January 22, 2009 Oh oh. There was a bug in OID.14.x. Please get the latest & greatest from http://pbxnsip.com/protect/pbxctrl-3.2.0.3140.exe. Thank you very much for getting an update on this and we'll jump on this later in the morning. As part of our support services plan for our clients, SNMP is our first course of action followed by email notifications, but we can produce scheduled reports, graphs, and alarms far more easily with our NMS vs using email alerts. We offer SLA's and we cannot assume in the absense of an email everything is OK. How Expandable is the SNMP portion of the code? Would you consider adding? 1. UPTIME - since last restart - Minutes-hours-days (We would detect this value dropping to near zero as a indicator the system has rebooted for known or unknown reasons) Plus as a an indicator in our client reports. (A Restart email could do this too, for those not using a NMS) 2. TRUNK CALL COUNTER (RESETTING THIS VALUE during midnight processes) (We would set thresholds that would detect no changes in this value in a preset period as a possible error state) 14.13.1 could be daily call count (Add a Total Call Count with the nightly CDR email) 3. TRUNK REGISTRATION STATUS 1 = registered 0 = Not Registered (14.13) is call counts for trunk 13, (14.13.2) could be status Perhaps other values could be made available to indicate overall health of the PBX processes. Cheers. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 22, 2009 Report Share Posted January 22, 2009 1. UPTIME - since last restart - Minutes-hours-days (We would detect this value dropping to near zero as a indicator the system has rebooted for known or unknown reasons) Plus as a an indicator in our client reports. (A Restart email could do this too, for those not using a NMS) Okay, added as OID .16. 2. TRUNK CALL COUNTER (RESETTING THIS VALUE during midnight processes)(We would set thresholds that would detect no changes in this value in a preset period as a possible error state) 14.13.1 could be daily call count (Add a Total Call Count with the nightly CDR email) That is not so easy... Workaround: If you want to check if there is traffic on the trunk you can also use the trunk calls OID. 3. TRUNK REGISTRATION STATUS 1 = registered 0 = Not Registered(14.13) is call counts for trunk 13, (14.13.2) could be status Yes, added as OID .15.x. It will return the last registration status (e.g. 200 for "200 Ok"). See http://wiki.pbxnsip.com/index.php/SNMP. A build is available at http://pbxnsip.com/protect/pbxctrl-3.2.0.3141.exe. Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted January 22, 2009 Author Report Share Posted January 22, 2009 Great, and yes we can set a no call threshold within a time period as a fault indicator in our NMS... Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted January 23, 2009 Author Report Share Posted January 23, 2009 With Trunk call counting being a bit more difficult, what about resetting SIP PACKET counters? This is strictly the SIP control packets and no RTP traffic, Right? but should the idea of how to count trunk calls in the future, this would a welcome feature because the current OID cannot be used to measure call counts. Pulling active calls every minute or two would result in all calls getting counted twice or more often. Quote Link to comment Share on other sites More sharing options...
figdierve Posted December 20, 2009 Report Share Posted December 20, 2009 Q. Ive created a custom SNMP probe, but I dont want it to probe the standard SNMP MIB II variables as well as the variables specified in the probe. Should I use the nomib2="true" property in the <snmp-device-properties> section of the probe? A. The nomib2 property tells InterMapper that it should not include a request for the sysUpTime.0 variable in the custom SNMP request. If youre tracking any kind of counter, you probably want to include that because it makes computed rates more accurate. To skip the rest of the standard boilerplate SNMP queries, add the MINIMAL flag to the <header> section. <header> ... flags="MINIMAL" </header> Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.