andrewgroup

The continuing Service Flag Saga. In an attempt to build Service Flags that go set when a desired action IE. Mon-Wed-Fri 12:01-7:59 5:00p-11:59p (defines the open hours from 8:00a to 5:00pm) this flag should be set on Tues-Thurs-Sat-Sun 12:01-11:59pm (keeps the flag not set during these periods We are not getting the results we are expecting to see the flag go set on Mon-Wed-Fri during 8:00 to 5:00

I'll try 7, let me correct something, these are really long mailbox greetings, can a caller bypass these long greetings with a keystroke?

A client has long personal mailbox messages with disclaimers... We'd like to see them add this to all mailbox messages. To bypass this message press (a digit or key of our choice) to go straight to the beep.... Have we overlooked the obvious setting to allow this? Cheers.

Divide and Conquer, keep it Simple and the term "the more the merrier", simply doesn't make sense when it comes the the single most important piece of technology for a business (the telephone). Computers can burp, the internet crash, but interupt the boss on a few telephone calls, and you'll hear about it immediately. Adding more functionality would only increase the security footprint and decrease reliability. We already have a hundred choices of routers with far more functionality than we can use. Some really terrific routers with full support for NAT, SIP, VPN, PPTP, QOS, SNMP, central management, reporting, many on their umptenth OS revisions can be had for less than $200.00 Our .02 - Cheers

Attention PBXnSIP Sales; I recall seeing, reading or dreaming that PBXnSIP was moving or had moved to licensing extensions and somewhat abandoning the account limitations. Except for Recording, maybe agent groups etc the professional releases. Is this true? If so, for clients with previous license heys that would normally exchaust the accounts if we move to create this more flexible AA and Service flag based plan, how might we apply, obtain, beg borrow or buy a replacement license to increase these service accounts while not expanding our extension accounts? A post of PM is welcome.. Cheers,

Seems many of us are confused on the functionality and use of service flags. I've read almost every post, every WIKI and it seems we are all working from Scratch as we try and satisfy client needs. we plan to develop a default setup that meets a wide variety of SMB needs...and based on what I've read and the recommendations posted this should be easily accomplished. (assuming that PBXnSIP is now license by the extension count and not generic accounts that burn when you use them) A typical small business may or may not have a PC so please don't recommend making someone a domain admin, everything I outline below needs to be from a phone (and it would be nice to dial in for some features) 1. Every System needs a Manual Flag for OPEN and/or Closed By this I mean in each service flag for that might exist in an automated attendent the business owner can decide at anytime to be open, closed by having a designated extension dial a manual service flag.. I think this might mean that we would preceed any scheduled service flag with these manual flags and designated automated attendants. for example AA #70 normal Business Hours Greeting (Scheduled) AA #71 Normal After Hours Greeting (scheduled) AA #72 Closed (scheduled as in Holidays) AA #73 Closed (unscheduled Snow Storm) AA #74 Lunch Hour (Scheduled) Scheduled Service Flags SF #80 used for normal business hours SF #81 Lunch hour SF #82 Holidays SF #83 Business is closed Manual Service Flags MF #90 Open MF #91 Closed SF #92 Unscheduled Greeting Manual Flag My undertanding is if you define a time range for a scheduled service flag, then the service flag will be unset during designated hours? Right the following is the plan. SF #80 is scheduled M-F 8:00-12:00 12:30p-5:00p SF #81 is scheduled M-F 12:01p-12:29p SF #82 is scheduled 00:00-23:59 on designated holidays SF #83 is scheduled M-F 12:01-7:59 5:01p-11:59p I'm think the goal is to make every greeting a scheduled time.... This way in the service flag field we preceed the desired AA greeting with all other Service Flags, both manual and scheduled so that the business can make changes by dialing the appropriate Manual Flag and recording a greeting as needed in the unscheduled AA if needed. The Normal AA#70 greeting would watch all other service flags, and the manual flags would be listed first and the correct AA be listed in the service account...Sending all calls to the main AA would then spawn Holiday, Lunch, unscheduled closures, lunch etc.... Am I off my rocker on this, or made this way to complex? Not month goes by, that we don't get a email request telling us they are going to be open or closed later or earlier and asking us to flip the switch.... (The caller is normally not well informed or knowledgable) or could be a temp, etc... Dialing a manual service flag from a designated extension to be open later seems a whole lot easier.... there was once talk of resetting manual service flags at Midnight? Creating a proven setup to accomplish this would go a long way to answering the many posts... cheers,

And Root access was debated. - Good Call on granting it.

Removing Root access would be fine, but wait until the PBX has considerably more features to do the basics that require root access like removing old CDRs, Messages, diagnostics and more. Cheers.

The CS410 has 3 interfaces eth0, eth1, and eth2 The following is from a CS410 that has the WAN port set to 192.168.1.99 and the LAN port Disabled, NO DHCP.... My question is, why does eth0 have 192.168.192.168 ? and then look at the Route table below... via root login issue ifconfig and see this listing.....cont comcerto:~# ifconfig eth0 Link encap:Ethernet HWaddr 00:19:15:68:40:4A inet addr:192.168.192.168 Bcast:192.168.192.255 Mask:255.255.255.0 UP BROADCAST RUNNING MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 TX bytes:0 (0.0 Interrupt:22 eth1 Link encap:Ethernet HWaddr 00:1A:1B:1C:1D:1E inet addr:1.1.1.1 Bcast:1.1.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:245087 errors:0 dropped:0 overruns:0 frame:0 TX packets:29175 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:48989618 (46.7 MiB) TX bytes:6292542 (6.0 MiB) Interrupt:1 eth2 Link encap:Ethernet HWaddr 00:19:15:68:40:4B inet addr:192.168.1.99 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MTU:1500 Metric:1 RX packets:32492 errors:0 dropped:0 overruns:0 frame:0 TX packets:30379 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:6022647 (5.7 MiB) TX bytes:6845701 (6.5 MiB) Interrupt:29 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:133 errors:0 dropped:0 overruns:0 frame:0 TX packets:133 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:30111 (29.4 KiB) TX bytes:30111 (29.4 KiB) What I don't like and fully understand is the route table.... comcerto:~# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.192.0 * 255.255.255.0 U 0 0 0 eth0 192.168.1.0 * 255.255.255.0 U 0 0 0 eth2 1.1.1.0 * 255.255.255.0 U 0 0 0 eth1 default 192.168.1.1 0.0.0.0 UG 0 0 0 eth2 default 192.168.192.1 0.0.0.0 UG 0 0 0 eth0 With LAN disabled, I would have not expected that port exist..and does this route table present potential problems for broadcast packets?

This is fun. Why did two of the largest PBX developers in the World Select Linux as opposed to a RTOS? Avaya, Nortel BCM and Nortel Just announce Linux is going into the VSP9000 series equipment. Any guess as to how may installations of Asterisk/Linux are deployed around the world? I'm not suggesting that any of these are on par with the long list of superior products you have listed, but it does indicate a trend according to my understanding of statistics. The way I see it, is that PBXnSIP, Linux, and MindSpeed are fully consistent with these trends. I do hope the replacement unit addresses your problem. I do think the most common problem with most VoIP installations is a lack of understanding and poor diagnostic skills. Of course things must be configured to leave traces to indicate the problems too. this is where managed devices and monitoring systems come into play. Cheers,

A realists reply to a RANT. Crack one open and you'll find the following http://www.mindspeed.com/web/product/categ...;trail=562,1039 A Single chip (no stand-alone Realtek), designed and in use by hundreds of thousands of OEM devices around the world. This isn't a 2-bit organization building a clone on a chip, but an internationally recognized leader in voice processing. See their line-card http://www.mindspeed.com/web/download/down...jsp?docId=30526 The have an embedded release of Debian 3.x and core technology to support their integrated analog gateway and LAN interfaces. It's really a matter of PBXnSIP working with their provider to further expose capabilities to the development team without making a code that would be specific to the CS410. As the the rest of the commentary on T1's etc, OK. Cheers

The OEM technology behind the CS410 is made by http://www.mindspeed.com/web/home.html they are perhaps one of the largest manufacturers of this type of technology that serves as the basis for many different PBX platforms. Technically 10/100 BaseT L1/L2 stacks have been around for a very long time and I do not arbitrarily agree without some very strong evidence the chipset is to blame. For the most part all previous bugs or features within PBXnSIP have been addressed by the PBXnSIP development team. However, Since PBXnSIP has offered such a product onto the market they need to create clearly understood documentation and setting recommendations for use on a wide variety of Analog Lines. They are competing with traditional PBX systems that have operated on the same analog lines that continually take much of the blame in many posts. well over 1,000,000 Lucent Partner phone systems have been sold and installed throughout the world and I'll guess 75% may still be in use today and they are on the same crappy analog lines. So the challenge is to make the system tolerant of a wide range of potential issues and to know them ahead of time as to prevent problems for customers considering PBXnSIP. Cheers,

The problem and solution to this old topic http://forum.pbxnsip.com/index.php?showtopic=1194 Was the user had a DLINK or LINKSYS firewall router with PNP enabled... for some reason the Linux OS within the CS410 apparently was getting hammered by PNP traffic or something to that affect. We have a remote CS410 installation and we are seeing a LinkSys SRW business series switch having errors with PNP overload entries in the database. (Gee, if the Switch is seeing these packets, it's likely the CS410 maybe seeing these also) The LAN switch shows no layer 1/2 errors, Things I'm going to guess may be happening... A local windows PC has Internet Gateway Device Discovery and Control Client installed and it may be doing something to the system. More as I discover and analyze this problem... I'm starting with http://www.upnp-hacks.org/upnp.html Disabling PNP has been referenced in other posts and configs are going with TFTP only More on this as I progress.

I haven't tried this yet, but thought it would be worth a post until I can test this... Rather than flipping scheduled service flags send all calls to a main AA that monitorings three service flags. The first two are labeled 400 OPEN 401 CLOSED 402 SCHEDULED The AA Monitors them in this order.... 400 sends you to a normal business hours AA 800 401 would send you to a closed business hour AA 801 if neither 400 or 401 are set then 402 sends you to the normal business hours AA 800 Then by allowing an extension to flip 400 or 401 you would affectively be allowing the PBX to be either open or closed whenever you wish... Could it be this simple? Of course you burn more accounts, and does the new licensing policy (EXTENSION) apply to CS410 to get extra accounts? Will try this later...

With no direct method to flip a scheduled service flag, I keep kicking around ideas that would first check a manual flag before processing.. Perhaps inverting the logic of the service flag to show the closed hours vs the open hours... but then during normal hours a manual flag could indicate to be closed.. My head gets dizzy, as the realization from clients that then would want to control this from their home or cell phone... A 20+ year feature on common PBX's from Avaya, Panasonic, etc seems to be an insurmountable obstacle and a thorn with every installation we have to date... Any Hope for PBXnSIP every having flippable scheduled flags as discussed on numerous previous posts over the last 24 months? Cheers.

Get this post http://forum.pbxnsip.com/index.php?showtopic=1989 working for you and reference the exact OID when you set up PRTG, ARGUS, DUDE, and we also are using N-CENTRAL, and had NAGIOS working too.

when the CDR folder consumes the remaining space on a CS410, (15,000+ calls) the CS410 simply stops recording.... Using DF and DU while logged in as the root user we see the trouble and deleted the many cdr files... Have we overlooked provisions in PBXnSIP to prevent or limit the growth of these or other folders? If not I suppose I'll cron a job to get these values and mail the output to our ticket system.. (Maybe Grep for a certain value) then mail to manage the exceptions. A better solution would be adding a new SNMP variable that goes from 0 to 100 that would represent either used or available space. I'll post that on SNMP too...as a reminder.

Perhaps the built-in FXO SIP GW is the 3rd trunk

I've read the release notes for 3.3 and see no mention of anything related to service flags. Has the long standing request for the ability to flip a scheduled service flag been addressed? Cheers,

With this being a CS410 - we are adjusting the output IP to FXO from the default to +1db and re-evaluating. Obviously this will increase all outbound traffic including live calls.

Have we overlooked a common feature in voicemail systems - Volume Control when listening to vm from remote access? http://www.pbxnsip.com/download/mailbox_en_314.pdf

Today we had a client PBX with park orbits and low or easy SIP passwords get remote registrations from a Canadian IP address and the clients PBX was making outbound BANK CARD scam calls.... Caught it early but the lessons are clear and a few best practices are coming from the experience and perhaps a feature request... Lesson 1. Complex Passwords are a must - No longer can we make it easy for the users Lesson 2. Park Orbits will not enherit a default dial plan Lesson 3. enable more logging an email notifications on extensions Possible Feature requests - (optional allowable IP Address ranges on an ext Basis for phones to register from. Cheers, and learn from the experienced.

Would it be possible to make an Check BOX option on Manual Service Flags to reset at Midnight along with the other Midnight option to reset hotdesks etc? This would be selected on a SERVICE FLAG by SERVICE FLAG basis....to reset at midnight.

No - since resetting a scheduled service flag hasn't made it to production during the last year, I was brainstorming if it might be possible to make a Rube-Goldberg method to accomplish the same think using several manual service flags. The idea of putting a Manual Flag ahead of a scheduled flag would work, but it would never reset... (I'll post a feature request to allow manual flags to be reset at Midnight) I hope the development team revisits this in earnest. For several clients it's a huge issue and they have nobody on staff that could login and reliably change dates, or reset flags.

We have created a good document on this topic but cannot upload it for lack of space. PLease expand our space beyond the 500K limit and we will post this PDF docs....