SLA, Private Inbound, and Busy Circuits

I’m not only new to FreePBX but also to VoIP and IT entirely. I am currently at my entry level position so any harsh or condescending comments could go elsewhere. Now that I’ve stated my Noobness, I can proceed. I recently set up a small business VoIP system that is currently running through DAHDI trunks. I am running FreePBX 13.0.190.7 with Asterisk 13.12.1. We are using Sangoma S500s in the office and S300s throughout the remainder of the plant. 22 deployed phones total with 4 analog lines (phone numbers). I’m basically ready to roll and most all of my configurations are complete. I went to the CEO yesterday to speak about deployment. He asked me for “line” buttons (So-and-so you have a call on line 1), a private inbound route that only the president can use for calling in (that would never be busy), and a visual representation of when all the lines are in use so that he doesn’t attempt an outbound call and get “all circuits are busy now” message. Basically, what he wants is to know, from the phone, when the lines are all in use, a better ease of access for parking and this private route. I think the parking idea is just intimidating and I realize I’m going to receive an insane amount of backlash by switching away from the key system. Is there anything I can do to make any of this happen or should I just figure out a way to train them easily to deflect some of the curses I’m about to receive?

Not the right way to introduce yourself. You’ve just called us dicks, and that’s not getting yourself on the right foot. In spite of that, here you go:

Good. You’ve clearly come to the right place.

He wants you to put in a key system. That’s not good.

We know you’re new, but this is a tall order for a seasoned professional. The problem isn’t one of technology (it can handle all of that) but more of a problem of basis-of-reference.

The parking lot thing is actually not that challenging and there are lots of Internet resource out there that can help you with a parking lot implementation.

The problem you’ve created for yourself is you have a finite pool of resources and he effectively wants to dedicate 1/4 of that pool to his own use. You can do that, but it’s expensive and wrong-headed.

In his experience (which needs to be acknowledged), the best way to handle this is based on the idea that his phone connects to a line to the outside world. it doesn’t anymore - your FreePBX installation does - it handles all of the incoming and outgoing calls, intelligently apportioning resources to maximize utilization. Everything gets handled by FreePBX - it routes all of your calls to wherever you want - flexibility, predictability and agility are added to the system, as well as lots of new features that your old system could never do.

his experience is that managing this resource is important, so he ( as CEO) needs to keep up on this and control access to the resources. By installing FreePBX, you have the opportunity to do away with that concern. The system can monitor these things and notify someone whose job it is to fix this (read that as “you”) so that the technology people can stay on top of this and make sure that everyone in the company (not just the CEO) has the communication resources they need to get all of their jobs done and improve the business’ performance.

If it was my installation, I’d explain to him that you do one of three things:

  1. Get rid of the DAHDI lines - that’s (at least) $200 a month worth of services before you ever place a call. Replace them with a dedicated Internet Connection for the phones at (say 2MBPS up and down). That should cost you about $20 a month. Find an Internet Telephone Service Provider (ITSP) that can handle your incoming phone numbers. There are plenty of carriers out there - it depends on where you are as to which would be the best choice. Go with a reasonable rate plan (4/10 of a cent per minute with free long distance, for example). There are about 9600 minutes in a business month, but there is no limit on the number of outbound channels (within reason - you’re only doing 2M) so that’s about 8 simultaneous calls (double what you are doing now, and free LD. Assuming phone usage doesn’t change, there’s no way that he will ever get a “all circuits are busy” error again.

Allocate him his own inbound phone number and set up his phone so that it uses his personal line Caller ID. Give him a button on his phone that doesn’t use his private number too, so that his caller ID matches the company’s. The advantage now, though, is that he’s still using a shared resource (instead of allocating 1/4 of the communications resources available to him and him alone) that allows for him to have the appearance of having a private line WITHOUT THE COST OF ACTUALLY DOING THAT.

  1. Keep using the 4 POTS lines. You would then need to install one of the resource monitoring systems and set up a BLF that triggers when all of the lines are in use. Allocating 25% of the companies resources to his personal use would mean setting up two trunks - one set up to talk to the group of 3 lines that the rest of the company gets to use, and one set up to talk to the single line he wants to use.

  2. A hybrid of these. Keep his personal POTS line and get rid of the rest. He effectively becaome a second-class citizen in his own company because his line doesn’t have all of the advanced features that his janitor’s phone would have. Put the rest of the plant on a VOIP circuit. They then have the advantage of not being limited to a three lines and probably save the company a bunch of money every month.

Both. Your new system is far more flexible and intelligent than the old one. There are a few things that are different from the old way they used to work, but the advantages of the new system should make the old system’s obsolescence more and more apparent as time goes on. Things like multiple parking lots, phone queues, Do Not Disturb with flexible destinations, reduced resource exhaustion, and customizable processes are all selling points that you need to get smarter on and exploit.

As I go over the various methods that you’ve responded with, I am kind of intrigued over the resource monitoring that is available with a corresponding BLF. Is this a simple configuration or am I better off telling him that he cannot have what he wants? I actually have 5 lines by the way. I have one POTS line that does not allow long distance so I have removed it from G0 until I’ve determined what to do with it. I’m thinking that this 5th black sheep of a line would be perfect to set up for his private use. As I was saying though, this is only necessary for inbound. I do not believe he needs it for outbound at all. So I may be able to set up a trunk for this line only and allow him to dial that specific number to get into the plant without it ever being busy. The private line is really all that I am worried about as I have no problem telling him that he’s out of luck. Might you be able to direct me to a preexisting forum or website to help me through the process of configuring a monitor to operate with a BLF? Thank you very much for your response.

Once again, the point of the exercise isn’t to make it easier for him to micro-manage your telephone system. The point is to get away from the DAHDI (POTS) lines altogether.

From a management perspective, implementing a new phone system and using SIP instead of POTS for your incoming and outgoing calls, you go from a finite resource to a scalable resource.

The point is to make it so that there is no longer a reason to be concerned about the resources. As long as you insist on using 5 POTS lines to support 22 phones, you’re going to be in the position that resources can easily be exhausted.

Let me say that again another way: Get off POTS. It’s a limited, expensive technology. The last installation I did of this size I replaced 9 inbound lines going to 10 phones with a single DSL line connected to 15 phones. The customer’s phone bill went from almost $1000 a month down to $120, and that includes the prepaid cost of my time per month.

If you stop using POTS, you no longer the 1 line/1 conversation bottleneck - you can have as many calls as you want. There will never be a time when anyone calling in will get a busy signal.

Let’s try the accounting approach. There are two types of costs - Fixed and Variable. Within Fixed costs, there are two parts - initial and incremental. With POTS, the cost of adding one more line is all initial - it costs five times as much to add five lines as it does to add one. With SIP, the initial cost is the cost of establishing the first line. After that, the incremental cost is 0 (until you have to add more bandwidth). You can literally have 20 lines for the cost of a single line using SIP.

Another approach - what does the flashing “All lines are busy” light tell him? What can he do about it? When he calls the plant and all of the lines are busy, what can he do? Nothing, nothing, and nothing. By switching away from a fixed resource (his phone lines) to a scalable resource (an Internet connection dedicated to his phones), he does away with the issue. His lines can’t all be busy - he has more bandwidth than every phone can consume. he can always call in - there’s no reasonable way to exhaust the resource.

So, to recap:

  • There’s no reason to ever worry about “all lines are now busy” when you can’t fill all the lines.
  • The actual performance of the system is reviewable by IT personnel who can then make requests and plan for future expansion when needed.

Now, as far as Shared Line Appearance (unless you are talking about Service Level Agreements) - SLA is hard to do with SIP, but it’s also not particularly meaningful.

The thing is that by going to FreePBX and SIP, you do away with the whole concept of “lines”. You have instruments (which you can monitor with BLFs) and you have resources (which you’ll monitor from any one of a dozen different methodologies).

There are commercial pieces with FreePBX (@tm1000) that can help you monitor and manage your system. There are also free packages that can be added to the system that allow you do monitor the performance of the system (Nagios comes to mind).

Now, getting back to the Private Inbound thing: with an ITSP (Internet Telephony Service Provider) you can set up an unlimited number of numbers for your system. Each number will be answered by the PBX and routed based on the rules that you (as the admin) establish. For example, you can send all of the boss’ private calls directly to his phone (one of the extensions on his phone) or to his personal assistant, or to a queue where her phone rings and his doesn’t, or just about any other scenario you can think of.

The trick here is that the system is almost infinitely flexible. If you can come up with a way you want to present the calls, you can do it. Now, some of the things may not work the way you want them to, but the process for handling the calls (both on the system and within your work groups) can be very close. You can’t say “Well, the old system worked this way, so the new system has to work that way.” The old system was old, and limited, and is being replaced for a reason. The new system probably does something very similar, just not exactly the same way the old one did.

Your opening statement was “I’m new to IT.” That’s fine, but it’s also an expression that you are not experienced enough to be able to solve a problem based on what the end result needs to be. We use a paradigm called “requirements” - it’s what the system needs to do, not how it needs to do it. Your managers are giving you lists of how to do things. It’s not useful: you need to know what they want to have at the end - the goal. Once you know the goal, you can use the tools in the system to achieve that. It may not be the way the old system worked, but it should meet the need, which is really what we can help you with.

So, for example, you need a BLF that tells you when someone’s phone is off-hook. In the old system, you’d watch their line for voltage differentials. In SIP, there’s nothing like that to monitor, so you have to rely on what the phone tells the system. This means that you can also monitor when someone has set their phone to “Do Not Disturb”.

Your new phone system isn’t your old phone system. It works differently. The end states are all pretty much the same, but how we get there is probably going to be different that the old system. That’s the way it goes and is now your problem to solve.

Good luck. We’re here if you have specific questions.

I have only one response to this. It’s great information and you’ve definitely helped me along with my issues, but is it not impossible to retain my old phone number when doing such a transition as this? Besides that, I’m sure I can market this idea to my boss easily.

Hi!

There are exceptions to this and maybe that’s not doable where you are but you can usually port your old POTS (Plain Old Telephone Service, ie your DAHDI trunks) to VoIP…

Your VoIP provider can do that for you usually… They will need proof of “ownership” in the form of invoices from the losing provider and things like that… That’s called a LNP (Local Number Portability) request…

In the mean time you could still use those DAHDI trunks for inbound and have your outbound VoIP trunk caller ID set to their phone number… Not all providers let you do that, at least easily, but you won’t have problems finding one that does as there are plenty…

The last time I ported a phone number like this my provider let me do the configuration on their side and on mine before the number was ported so when it actually was ported things “just worked”… Maybe I was lucky, who knows…

Good luck, have a nice day and Season’s Greetings!

Nick

Every time I’ve ever set up a number port like this, I set up in inbound services well before the number was actually ported. Once the SIP transition happened, the SIP trunks delivered the calls to the service. From FreePBX perspective, there is no real difference between inbound calls. They all get processed through the trunks (which remember are both inbound and outbound) which then deliver the calls to the inbound routes. Whether they come in from POTS or from SIP doesn’t matter at all.

The outbound situation is the same - as long as your VOIP provider knows what your outgoing caller ID is, they should allow you to route your SIP calls through either interface.

This is one of the things I was talking about with finite versus scalable resources. Remember, one of your choices was a hybrid solution where you add SIP to expand your capacity and capabilities. You can retain as much of your POTS infrastructure (along with the 1000% price over SIP) if you or your management is not comfortable with something the phone company has been doing for 30 years.

From a generalized view, we are doing nothing more than giving you access to ATM, but are using the IP network to do it. No specialized hardware, to temperamental connections, no issues with the lines going bad every time it rains. The phone companies have been using digital connectivity for as long as I can remember (and I’ve been doing comm systems since the 1980s). We’re just exploiting the same basic technology, but without the artificially inflated cost.