Tall order - phone system integration with high number of extensions with MySQL?

Maverick2002

Diamond Member
Jul 22, 2000
4,694
0
0
We're in the process of starting up a side business at my company which will involve people calling a toll free number, entering an extension, and being forwarded to another outside number.

There are going to be a LOT of extensions (eventually, around 50,000) so we'll be using a 5 digit extension system.

We're not actually answering any calls - we're basically acting as a call forwarding service.

We have a developer who has already built a MySQL database that contains a list of which extensions go where.

I'm having a hard time wrapping my head around how to integrate this with a (VoIP?) solution. Others have done similar things to what we're doing, so it's technically possible/feasible - I just need to figure out how to make it work. Here's the order of operations:

Person calls toll free # > person enters an extension > phone system references our database to see what external number this extension is associated with > phone system logs a time this call was made and adds it to a table in our database > phone system connects the person to the external number.

Now, basic call routing is pretty simple through an online VoIP provider (we're currently using RingCentral for our 'regular' phone system), but this has to plug into our database to figure out where to route and log it, with the main caveat being that there will be a TON of extensions. Also, certain groups of extensions will all reference the same external number, so there may be 100 different extensions which all go to 1 number.

My question is this: what kind of phone 'setup' should I be looking at to make this work? The 2 main points are: being able to hook into our MySQL database and being able to handle a large number of 5 digit extensions. Can a VoIP provider assist with this, or do we need our own in-house server with something like 3CX to make this work or?

Thanks for any heads up. I'm learning about VoIP as I go, but I'm a little lost on this one.
 

Leros

Lifer
Jul 11, 2004
21,867
7
81
There are going to be a LOT of extensions (eventually, around 50,000) so we'll be using a 5 digit extension system.

If you expect to support 50k extensions, you might want to go 6 digits. It's going to painful if you run out.
 

Spydermag68

Platinum Member
Apr 5, 2002
2,616
99
91
Here is a basic call outline that you might want to think about while you get the rest up and running.


Menu time out: 5 Seconds
Call dial out time: 36 seconds


Start of Call

GET DIGITS MENU
Play Message 001 - "Please Enter your five digit extension."
Recive 5 digits go to DB LOOKUP

Time out: Play Message 002 - "You did not enter enough digits."
Invalid: Play Message 003 - "You pressed an invalid digit." (In your case * and #)


DB LOOKUP
If Found goto CALL
Else
Check invalid extension counter (up to 3 times is good)
Play Message 004 - "The five digit extension you have enter is invalid."
Go to GET DIGITS MENU
if over invalid limit
Play Message 005 - "Your call cannot be completed"
Hang up on caller.
or
Play message 006 - "Please hold while your call is being connected."
Call to a default number.

CALL
Outdial to the number in the db.
If Busy - Play Message 007 - "The number is busy. Please try your call again later."
If Ring No Answer Play Message 008 - "There is no answer. Please try your call again later."



Messages:
001 - "Please Enter your five digit extension."
002 - "You did not enter enough digits."
003 - "You pressed an invalid digit."
004 - "The five digit extension you have enter is invalid."
005 - "Your call cannot be completed"
006 - "Please hold while your call is being connected."
007 - "The number is busy. Please try your call again later."
008 - "There is no answer. Please try your call again later."
 

EagleKeeper

Discussion Club Moderator<br>Elite Member
Staff member
Oct 30, 2000
42,589
5
0
As long as you have numerical indexing of the extensions; there should be no speed difference between 10K and 100K extensions. It is a direct access. It is when you need to start parsing/comparing the strings that the size kicks in.
 

ForumMaster

Diamond Member
Feb 24, 2005
7,792
1
0
As long as you have numerical indexing of the extensions; there should be no speed difference between 10K and 100K extensions. It is a direct access. It is when you need to start parsing/comparing the strings that the size kicks in.

True, but the problem might eventually be scale. If for every call, a DB lookup is made, you can only support so many callers.
Even if the numbers are indexed.

It would be much smarter to have the numbers cached (shouldn't be a big dataset) at the application tier.

If the number dialed is not found, initiate lookup in DB (and intiate cache refresh).

If number not found, "throw exception" and tell customer that it is an invalid number.

This strategy will stop the database from ever being a bottleneck.
 

Maverick2002

Diamond Member
Jul 22, 2000
4,694
0
0
Thanks for the heads up, I think we found a solution though.

We'll be using the database for information purposes and as a CSV cut & paste repository. Extensions will be imported in bulk into 3CX phone system software, and forwarding rules based on extension groups created within that software.

So it looks like we'll never need to actually hook the 3CX system directly into the database (I don't think that's even possible), just bulk add/remove extension sets in the system based on what's in the database.

The other processes will be batch runs based off downloaded phone logs. It's a bit of a duct tape solution, but it should work fine.

That said, is anyone familiar with 3CX?
 

drebo

Diamond Member
Feb 24, 2006
7,034
1
81
Oh my God, that's a terrible idea.

3CX is pretty garbage.

I would recommend Asterisk, as it can interface with MySQL natively. Utilizing an ODBC connection, you can make direct queries against your data.

Seriously, though, this is something that can be done in real time against your live dataset in Asterisk in about 45 minutes, start to finish.

If you're concerned about running the server inhouse, you could find someone who does hosted asterisk and would be willing to VPN it to you (so it can access your database). You can also find a VoIP provider. Couple of things you have to be careful of, though, is that in the telco world, if your average call duration falls below a certain level, your provider will make you start paying call setup fees. I've seen limits as high as 2 minutes and as low as 30 seconds, with fees anywhere from $0.01/call to $0.05/call.

Depending on the call volume, you may need quite a bit of bandwidth and processing power.
 

Maverick2002

Diamond Member
Jul 22, 2000
4,694
0
0
Oh my God, that's a terrible idea.

3CX is pretty garbage.

I would recommend Asterisk, as it can interface with MySQL natively. Utilizing an ODBC connection, you can make direct queries against your data.

Seriously, though, this is something that can be done in real time against your live dataset in Asterisk in about 45 minutes, start to finish.

If you're concerned about running the server inhouse, you could find someone who does hosted asterisk and would be willing to VPN it to you (so it can access your database). You can also find a VoIP provider. Couple of things you have to be careful of, though, is that in the telco world, if your average call duration falls below a certain level, your provider will make you start paying call setup fees. I've seen limits as high as 2 minutes and as low as 30 seconds, with fees anywhere from $0.01/call to $0.05/call.

Depending on the call volume, you may need quite a bit of bandwidth and processing power.

Can you elaborate on the downsides of 3CX?

Or, more specifically, the upside to using Linux/Asterisk with our MySQL database? A single data set looks good.

The 1-5 cents/call is not an issue.
 

drebo

Diamond Member
Feb 24, 2006
7,034
1
81
3CX is buggy software written for Windows. I do not believe it would work well with 50k extensions. I've seen it have problems with 5 extensions.

Also, cutting out the middleman (export and import of CSV data) will save a lot of potential for issues.

Asterisk, as stated, can directly query your data. Based on your expected calls per second/maximum simultaneous calls, this will probably be the better option.

Basically, I've never had a good experience with 3CX. While I have had some bad experiences with Asterisk, my overall experience is extremely positive.

And, like I said, the entire thing could be completed (from bare metal to functioning) in under an hour. No need to write export or import code, etc.