Adding Large Phonebook To Swyx 2013

[ArthurDaley]

Hi guys,

 

would it be possible to import a csv-file containing 63000 client phonenumbers to an addressbook on the server? We want to achieve that when our clients call Swyx shows their names.

 

For technical reasons we can't use Tapi 2.0 coming with Swyx.

 

Thanks for any tipps on how to achieve this.

 

Arthur

[Tom Wellige]

Technically it would be possible, as there is no limitation implemented.

 

But it wouldn't be a very good thing to do (performance-wise).

 

Instead you should keep your phone numbers in your own database and use VisualContacts to resolve them on the client (and not the server, like it would happen if you place the in the SwyxWare phonebook).

[ArthurDaley]

May I ask what kind of database is required for that? We can't use our realtime client database as our datacentre keeps this under locks for proprietary applications. We need to export the data and import them into another local database to use. What kind of database would be our best option there?

 

And as for VisualContacts, does this come with SwyxWare or is it a seperate product? Have not heard of it before.

 

Thanks,

[Tom Wellige]

In fact, any database to actually is a database (MS Access it *NOT*) can be used, like e.g. MS SQL Server. Visual Contact is actually based on ESTOS Meta Directoy which is able to connect to more or less every possible data source.

 

 

Regarding Visual Contacts you should take a look here:

 

https://www.swyx.com/products/unified-communications/options.html

 

 

Of course name resolution can be done also in different ways: 

• (server sided) using the global phonebook (like you have asked for)
  
• (server sided) using an extended call routing script to resolve the name against an own database (e.g. own CRM system)
  
• (client sided) using visual contacts to connect again *any* database for name resolution (and provide contact details)
  
• (client sided) using the client api to program a small add in for name resolution against an own database
  

 

To decide which solution is best suited for you depends on amount of contacts, the performance of the server and the call load on the system.

 

Keeping work load away from the server machine is always a good idea, that's why I suggested client sided name resolution.

[ArthurDaley]

OK Thanks, that helps. I will contact our hoster for this, as we have outsourced maintenance on our Swyx Server.

[Almon Brown Strowger]

FYI - We have a Swyx phonebook that contains approx. 20000 entries. It works well in terms of the CDR picking up names and in terms of incoming user name resolution from numbers. For us this is useful for call reporting. It is slow if you click on a phonebook and try to view it though. In fact on the server it takes about 20s before displaying global phonebook in Swyxware admin. On client, it doesn't seem to display. However, for us, it implements our main purpose of reporting.

[Virikas]

Can you provide a bit more about the environment you are using such a large global phonebook in?

A list of points which influence Swyx performance:

• How many users and devices are using Swyx?
• Which Swyx Options are enabled and in use?
• How many voice and faxchannels are licensed/in use?
• How many internal groups and numbers are there?
• How many calls do you have within the system (in terms of CAPS and concurrent internal/external calls)?
• How many callrouting scripts are running?
• Is the server connected to PSTN via ISDN or SIP?
• Is it a multisite Swyx Installation?
• Is Master/Standby used?
• Which hardware setup do you use?
• Which software setup do you use (OS and Database)?
• If the server's a standalone Swyx: Is the Database running on the same host?

[Tom Wellige]

On 5/17/2016 at 6:29 PM, Almon Brown Strowger said:

However, for us, it implements our main purpose of reporting.

 

If your main purpose to have all that data in the global phone book is reporting, then it shouldn't actually be placed there. 

I would suggest to move the data into an own database (most likely you have it already there, e.g. in a CRM system), and then use call routing functionality for name resolution. You can configure one sort of global call routing (-> PreProcessing), try to resolve the caller number to a name against that database, and then set the caller name in the script. That will put the name into all displays, phone call lists and the CDR.