Restrict inbound calls to personal address book

Status
Not open for further replies.

orangedux

Free User
Joined
Oct 17, 2021
Messages
6
Reaction score
0
Hi,

I am looking at an implementation which requires a locked down configuration where each extension can only receive incoming calls from numbers that are in their personal address book.

1: Is this possible natively or would it require a bespoke developpement?
2: Where is the personal address book located on 3cx? Can it be accessed by a script?
This would obviously need to be dynamic and numbers added or removed to be affected as authorized/unauthorized when edited.

Many thanks.
 
Okay so technically it is doable with a CFD. You can easily configure it to receive calls, check the database and if allowed, it is sent through.

This would not use the phonebook tho, as on 3CX, it is unavailable from the admin side. Only the user can manage their own phonebook.

That's why a database might be better. Then, you need to figure out how to know who to send the call to. There's multiple ways.
 
Many thnks for you swift answer, the reason I wanted to use the user phonebook is so the list could be updated by the user, are the user contacts stored in an xml file or something?
Best regards.
 
Many thnks for you swift answer, the reason I wanted to use the user phonebook is so the list could be updated by the user, are the user contacts stored in an xml file or something?
Best regards.
No they are stored in the 3CX database which is not accessible to users.

If you want the user to be able to manage, you can simply have a small UI to update the database.
 
So basically needs a little bespoke web development with UI to update the main database entry for a given user is that correct?
Guessing I'll need to use the 3CX Exporter add-on to export to external database to use with UI instead of direct access to postgre database, is that correct? if yes, do you know where can I get the add-on?
Many thanks
 
Last edited:
So basically needs a little bespoke web development with UI to update the main database entry for a given user is that correct?
Guessing I'll need to use the 3CX Exporter add-on to export to external database to use with UI instead of direct access to postgre database, is that correct? if yes, do you know where can I get the add-on?
Many thanks
What I mean is: use a separate database. NEVER access the 3CX one.

You would need 3 things:
1. A small MySQL database on a web server.
2. A small Laravel/Symfony app with a basic UI to add/remove numbers from the lists. At this point, you can have multiple lists for each users, it's all up to you.
3. A CFD that can distinguish who's being called (either via user input or DID) and check the database for that user, see if the Caller ID is present in the DB and if so, transfer the call. Otherwise, it can be sent to whatever you want or just dropped.

Maybe @VoIPTools has a module for that exact scenario, but the Exporter wouldn't help you in any way.
 
Any web based sql admin tool, even phpmyadmin, can be used here in theory to manage the list. Or you could write a dedicated one.

Flow for Inbound would look like:
Inbound rules DID to CFD
CFD look at MySQL table for extension and permitted numbers
To user or to kill call as needed

Flow for Outbound would look like
All outbound calls start with user calling CFD (direct dialing blocked by outbound rules)
CFD prompts for number
CFD look at MySQL table for extension and permitted numbers
CFD to make call or drop depending

It's not hard to write but is some work.
 
  • Like
Reactions: Evolute IT
One way or another you are going to need someone to write some code, whether you maintain the list yourself in a separate web / database application, or use the 3CX Call Control API to query the Company directory / personal contacts.

3CX is planning to release a new REST API later this year (no ETA that I'm aware of), which "may" provide the necessary capability, or you can use our REST API to query the company directory. You could use our 3CX Exporter tool too, but in this case I think our REST API would be a better choice.
 
Status
Not open for further replies.

Forum statistics

Threads
111,975
Messages
590,085
Members
164,904
Latest member
gdstratton