Suggestion for new implementation

Asterisk Asterisk Support
1

Hi all, I am going to create an Asterisk gateway that it will be used at one side as REGISTRAR server for many endpoint and on the other side to a carrier.
Many users will have it’s own external number associated and others will be part of groups, and external number will be associated to that groups as well.
More or less this is what I need.
For better handle all users, DID etc, it’s better to store in AstDB DID numbers associated to internal numbers and create in dialplan an extension that reads AstDB, or is there a better way to handle this?
Maybe a sqllite db?

This is an example of what I mean:

DB:

database put inbound +495117775601 “SIP/100&SIP/101&SIP/102”
database put inbound +495117775602 “SIP/200&SIP/201&SIP/202”
database put inbound +495117775603 “SIP/300&SIP/301&SIP/302”

DIALPLAN:

[default]
exten => _+4951177756XX,1,NoOp(Chiamata in ingresso al numero ${EXTEN})
same => n,Set(INTERNALS=${DB(inbound/${EXTEN})})
same => n,GotoIf($[“${INTERNALS}”=“”]?unhandled)

same => n,Dial(${INTERNALS},30)
same => n,GotoIf($[“${DIALSTATUS}”=“NOANSWER”]?failover)
same => n,GotoIf($[“${DIALSTATUS}”=“BUSY”]?failover)
same => n,Hangup()

exten => failover,1,NoOp(Inoltro a 999)
same => n,Dial(SIP/999)
same => n,Hangup()

exten => unhandled,1,NoOp(Numero non configurato in AstDB)
same => n,Hangup()

2

Having a look on google seams better to keep all DID numbers inside extension.conf file.
Can anyone, who has experience with large asterisk implementations, give me some advice on this?

3

On Friday 07 February 2025 at 21:17:32, spady7 via Asterisk Community wrote:

Hi all, I am going to create an Asterisk gateway

If you are just starting out I strongly recommend that you use the PJSIP
channel driver instead of the deprecated and no-longer-supported chan_sip
driver.

This is an example of what I mean:

DB:

database put inbound +495117775601 “SIP/100&SIP/101&SIP/102”
database put inbound +495117775602 “SIP/200&SIP/201&SIP/202”
database put inbound +495117775603 “SIP/300&SIP/301&SIP/302”

Your use of “SIP/” there shows you are thinking about the legacy chan_sip
driver.

same => n,Dial(SIP/999)

I would be extremely wary about using this number in your dialplan, as it is
the UK emergency number (the equivalent of European 110 / 112, and the
American 911).

On Sunday 09 February 2025 at 12:51:54, spady7 via Asterisk Community wrote:

Having a look on google seams better to keep all DID numbers inside
extension.conf file.

Show us what advice you have discovered which suggests this.

Can anyone, who has experience with large asterisk implementations, give me
some advice on this?

I think you need to give a bit more detail about what “this” is.

I understand that you have a large (whatever that means to you) number of
inbound numbers.

What I don’t yet understand is:

a) what you want to happen to calls which come in to those numbers

b) how much the “things which need to happen” vary between different numbers -
you might have “DDI 1 rings device A, DDI 2 rings device B, DDI 3 rings device
C” etc, or you might be trying to set up ring groups (as suggested by your DB
example above)

c) what you want to do with outbound calls from the SIP devices to the outside
world

In my opinion, large-scale systems based on Asterisk such as Bicom PBXware and
FreePBX (as well as FusionPBX, which is not based on Asterisk, but does much
the same thing) all use an external database such as MySQL or PostgreSQL for
managing this quantity of complex data.

Have you considered whether using FreePBX might be your best starting point?

Antony.

–
BASIC is to computer languages what Roman numerals are to arithmetic.

4

Thanks for replying @Pooh .
What I wrote in my post was just an example.
I am going to use for sure PJSIP and number like 999 was just an example.
What I will have to manage is large number of endpoints (large is from my point of view) let’s say around 250.
Most of them will be called by it’s own DID. Some others will be part of hunting groups and those groups will be called by it’s own DID number.
So as you can see I will have many DID to manage and they are not on the same range (so cannot use regexp).
I thought to use something like freepbx but I would prefer to build it by my own because performance. I would say that in freepbx there are many features that I will not use.
This is my idea. Not sure I am in right direction so this is why I am asking your help :smiley:
You suggest to use database. Does astdb can be used ? Or better use external one like MySQL
Regards

5

On Sunday 09 February 2025 at 13:56:38, spady7 via Asterisk Community wrote:

What I wrote in my post was just an example.
I am going to use for sure PJSIP and number like 999 was just an example.

Please try to be more accurate / realistic with your “examples” in future :slight_smile:

What I will have to manage is large number of endpoints (large is from my
point of view) let’s say around 250.

For that number I would personally stick to extensions.conf, possibly split
into several files and combined using #include

I would consider splitting the dialplan into things like:

  • simple DDIs which map only to a single endpoint

  • DDIs which map to ring groups of several endpoints

  • DDIs which map to queues, if you use them

  • DDIs which map to IVRs, if you use them

  • etc.

However, such a structure is entirely down to you and whether you find this
division more meaningful, or more cumbersome.

You suggest to use database. Does astdb can be used ? Or better use external
one like MySQL

If you do choose to use a database, I would go for an external one, connected
via ODBC, mainly because you will then be able to use standard DB management
tools to maintain the content.

If you use the Asterisk internal DB, you are restricted to using Asterisk CLI
or AMI commands to manage the DB content (you cannot write to the DB using
external tools whilst Asterisk is using it).

Antony.

–
This space intentionally has nothing but text explaining why this space has
nothing but text explaining that this space would otherwise have been left
blank, and would otherwise have been left blank.

6

Thanks @Pooh I will.
Good advice to split dial plan in different files. It will be more readable.
I will try to create the raw configuration and will see how it will grow.
Thank you again

7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.