92 lines
3.7 KiB
Plaintext
92 lines
3.7 KiB
Plaintext
Config Structure & Handling explained
|
|
-------------------------------------
|
|
Asterisk has a config parsing system that provides a generic interface to
|
|
config sections and paramater, this system has multiple backends like
|
|
ini, ldap, database that all present their data in a unified structure.
|
|
|
|
From chan-sccp's view all the config sections and parameters looks exactly
|
|
the same. In principal we don't have to know where the settings are coming
|
|
from, we just need to be able to handle three cases:
|
|
- requested section+paramater does not exist -> error
|
|
- requested section+parameter exists and returns a value
|
|
- requested section+parameter exists and returns NULL (ie: no field present in
|
|
ini/table or is set to NULL)
|
|
|
|
Based on this simple view of the world we built sccp_config.c and it's
|
|
primary source of information sccp_config_entries.hh. The latter contains:
|
|
- all valid config sections and parameters
|
|
- their links to the in memory entity structures (POD's)
|
|
- flags:
|
|
- their deprecated/obsolete status
|
|
- their value inheritance structure, device or lines can inherit values from
|
|
the [general] section if they are not provided (See more about inheritance
|
|
below)
|
|
- what to do when a value changes (either directly or through inheritance)
|
|
- ultimate fallback value for parameter that cannot be/work `unspecified`
|
|
- dedicated parser required to process the value, if a generic parser would
|
|
not work (for example handling codecs, deny/permit)
|
|
- help descriptions for each parameter
|
|
|
|
Config value inheritance
|
|
------------------------
|
|
sccp_config_entries.hh contains universal fallback values for parameters
|
|
that cannot work without one. Without this ultimate fallback
|
|
value, chan-sccp would crash/not work. For example chan-sccp would not know
|
|
what tcp-port to use for it's listerning connection, if not provided.
|
|
They are built-in fallback values fixed at compile time.
|
|
|
|
sccpdevices or sccplines can inherit values from the general section
|
|
in sccp.conf. The parameters in the general section are further backed by
|
|
the sccp_config_entries.hh with it's fallback value, in case they
|
|
are not provided.
|
|
|
|
So for example:
|
|
If sccpdevice:keepalive is not set, it will get it's value from
|
|
general:keepalive, which if not set, will fallback to the value provided
|
|
in sccp_config_entries.hh. The actual sccpdevice:keepalive is on evaluated
|
|
at the moment the device is connecting and registering to chan-sccp, at
|
|
which moment the value trickles down. So let's assume this situation:
|
|
|
|
sccp.conf:
|
|
```
|
|
[general]
|
|
;keepalive=120
|
|
|
|
[SEPxxxxx]
|
|
;keepalive=140
|
|
```
|
|
|
|
In this case the universal default will be provided by
|
|
sccp_config_entries.hh. When we now set general:keepalive to 120 and issue
|
|
`sccp reload`, all devices will have to be restart (RESTART_REQUIRED flag
|
|
is set for keepalive in sccp_config_entries.hh). They will start to connect
|
|
again, and the keepalive parameter is reevalueated, they will now see that
|
|
they do not have a personal keepalive parameter provided and will use the
|
|
general one, instead.
|
|
|
|
Note: inheritance is specifically specified in the sccp_config_entries.hh
|
|
file and just not automatically happen just based on the parameter name for
|
|
example.
|
|
|
|
You can think of the sccp_config_entries.hh and a universal section in the
|
|
sccp.conf that has a slew of fallback values that are there to have your
|
|
back. It will allow you to get by with a minimal config file without having
|
|
to worry about chan-sccp not working, becasue you forgot to set the port
|
|
number for example.
|
|
|
|
So mentally you can think of it like this:
|
|
```
|
|
[universal]
|
|
keepalive=60
|
|
|
|
[general]
|
|
;keepalive=120
|
|
|
|
[SEPxxxxx]
|
|
;keepalive=140
|
|
```
|
|
|
|
Note: changing sccp_config_entries.hh after the binary has been build, will
|
|
not do anything, the fallback values are backed into the final binary at
|
|
compile time.
|