andrewgroup

Not important. What you need to know is how to easily manage these puppies.... Begin by first logging into the box using an SSH client. The most popular is PUTTY.EXE The login name is ROOT and the default password is listed on a sheet of paper or send an email to support for the default. Many people will not change this and why spread the love. Visit www.debian.org and download their quick reference cards.... http://www.debian.org/doc is a good place to start.... Download the following TOOLS WINSCP This will give you an easy way to access files and folders on the CS410 in a Windows Explorer interface with Drag n Drop from local disk to the CS410 DISK.. You should be able to find a small ISO download of Linux Debian with a few googles... I suggest installing the freeVMWARE stuff or other Virtual tools and install the Debian onto your desktop to learn a bit more...

What - Me Worry! Will this require a restart? [8] 2008/01/01 10:57:19: SMTP: Received 220 2.0.0 Ready to start TLS [8] 2008/01/01 10:57:20: SMTP: Received [8] 2008/01/01 10:57:20: Last message repeated 2 times [5] 2008/01/01 10:57:20: SMTP: Connection refused on 70.25.63.17:25 Is there a URL that will display the contents of the entire global XML file or the keys within?

Is this a member of a domain? if so, not so good as group policies refreshes 90 minutes or so, consum cpu cycles and LAN activity.

Can one modifiy the colors from the aqua green? Does PBXnSIP pull from the executable and build a virtual htm and img folder in RAM? Aside from RegStatus, remotecall, what other url based options are available to control the PBX?

My problem is the CS410 was upgraded from a 2.x to 3.x and the http://localhost/reg_status.htm?save=save&...p_starttls=TRUE line is not within the global file. The crafted url to set this to FALSE or TRUE simply doesn't add this non-existent line to the file. I've read the following links cover to cover and have not gotten the expected results. http://forum.pbxnsip.com/index.php?showtop...7&hl=global http://wiki.pbxnsip.com/index.php/Global_Configuration_File Is their a something we are missing?

We really thought this option was previously addressed. We simply have yet to see a way for clients to call the scheduled service flag and flip the status. This means clients cannot close early, leave late, etc. This prevents us from duplicating the NIGHT BUTTON so common on every PBX created to date. What gives? or are we missing the obvious? Cheers

V 1.5 to V2.0 and above is a purchased product. contact a reseller - See display ads or contact PBXnSIP for a referral.

WOW - Finding some really old posts to comment on heh? We've adding a few more SwitchVox shutdowns to the mix as we continue to focus on solutions. Our small 6 extension CS410 solution installs for about $6,200 and requires a additional a $1,200 first year warranty, 24x7 remote monitoring - 5 x 8 business hour alert program. First year margin is roughtly 70%. Yes, there are many PBX firms that will beat that price everyday. We don't sell price.

Will be attacking this tommorrow, can today's date be inserted into the name? "file:$d-cdr.tct" to prevent overwriting of historical CDR files?

I see the global settings for mysql cdr writing, and during a recent call about a pending installation I thought I heard the idea existing to create a daily CDR file that would mirror the Simple CDR settings. We plan to move all XML CDR, recordings daily, we plan to outpulse via TCP/IP the simple CDR output to a SMDR reporting system, and the creation of a daily CSV file that mirrors simple CDR output would be the Holy Grail. I must have been dreaming - We do that often.

I must have dreamed this, but does 3.2.x support a daily output of CSV file? If so, how?

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.

Great, and yes we can set a no call threshold within a time period as a fault indicator in our NMS...

What's wrong with this statement to alter TLS email sending on a CS410 with this version 3.0.0.2993 (Linux) We thought 3.x supported this option or must we update? localhost/reg_status.htm?save=save&smtp_starttls=TRUE or localhost/reg_status.htm?save=save&smtp_starttls=FALSE The symptom we see is the browser goes to a unknown page.

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.

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

http://forum.pbxnsip.com/index.php?showtopic=967 We are now at 3.2.0.3138 (Win32) and we are simply missing something. Create a Day Night Service Flag, We assume grant an extension permissions, set the times accordingly and then call the service flag from the designated Extension. We are expecting the Service Flag to flip from it's current State . Is this the way it is known to work based on the post mentioned above? Logging Service Flag States would a nice option. Cheers

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

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)

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

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...

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.

Version: 3.2.0.3130 (Win32) Can the once a day graph be scheduled to run every 1, 5 ,10 or more minutes? (testing purposes only) to provide a smaller performance window.

CAN THIS STATUS report be forced to happen. I.E. (during a test period, schedule this to generate and send every 10 minutes.)

Cannot import this into N-Central from N-ABLE. We'd surely contribute $$ to a finished version that imports correctly.