mattia
9da9d57d5e
Add rtp_port_start and rtp_port_end options to PJSIP endpoint configuration, allowing each endpoint to use a dedicated RTP port range instead of the global rtp.conf setting. This is useful for scenarios where different endpoints need isolated port ranges, such as firewall rules per trunk, multi-tenant systems, or network QoS policies tied to port ranges. The implementation adds ast_rtp_instance_new_with_port_range() to the RTP engine API, which sets the port range on the instance before the engine allocates the transport. The default RTP engine (res_rtp_asterisk) checks for per-instance overrides in rtp_allocate_transport() and falls back to the global range when none is set. Both options must be set together, with values >= 1024 and rtp_port_end > rtp_port_start. Setting both to 0 (the default) preserves existing behavior. Resolves: https://github.com/asterisk/asterisk-feature-requests/issues/71 UserNote: PJSIP endpoints now support rtp_port_start and rtp_port_end options to configure a dedicated RTP port range per endpoint, overriding the global rtp.conf setting. UpgradeNote: An alembic database migration has been added to add the rtp_port_start and rtp_port_end columns to the ps_endpoints table. Run "alembic upgrade head" to apply the schema change. DeveloperNote: New public API: ast_rtp_instance_new_with_port_range() creates an RTP instance with a per-instance port range. ast_rtp_instance_get_port_start() and ast_rtp_instance_get_port_end() allow RTP engines to query the override. Third-party RTP engines can use these getters to support per-instance port ranges.
Asterisk Database Manager
Asterisk includes optional database integration for a variety of features. The purpose of this effort is to assist in managing the database schema for Asterisk database integration.
This is implemented as a set of repositories that contain database schema migrations, using Alembic. The existing repositories include:
cdr- Table used for Asterisk to store CDR recordsconfig- Tables used for Asterisk realtime configurationqueue_log- Table used for Asterisk to store Queue Log recordsvoicemail- Tables used forODBC_STORAGEof voicemail messages
Alembic uses SQLAlchemy, which has support for many databases.
Example Usage
First, create an ini file that contains database connection details. For help with connection string details, see the SQLAlchemy docs.
$ cp config.ini.sample config.ini
... edit config.ini and change sqlalchemy.url ...
Next, bring the database up to date with the current schema.
$ alembic -c config.ini upgrade head
In the future, as additional database migrations are added, you can run alembic again to migrate the existing tables to the latest schema.
$ alembic -c config.ini upgrade head
The migrations support both upgrading and downgrading. You could go all the way back to where you started with no tables by downgrading back to the base revision.
$ alembic -c config.ini downgrade base
base and head are special revisions. You can refer to specific revisions
to upgrade or downgrade to, as well.
$ alembic -c config.ini upgrade 4da0c5f79a9c
Offline Mode
If you would like to just generate the SQL statements that would have been executed, you can use alembic's offline mode.
$ alembic -c config.ini upgrade head --sql
Adding Database Migrations
The best way to learn about how to add additional database migrations is to refer to the Alembic documentation.
Notes
- For boolean columns, always use the AST_BOOL_VALUES type.
Example:
from alembic import op
import sqlalchemy as sa
# This works for MySQL/MariaDB and others as well
from sqlalchemy.dialects.postgresql import ENUM
AST_BOOL_NAME = 'ast_bool_values'
AST_BOOL_VALUES = [ '0', '1',
'off', 'on',
'false', 'true',
'no', 'yes' ]
def upgrade():
# ast_bool_values have already been created, so use postgres enum object type
# to get around "already created" issue - works okay with MySQL/MariaDB and others.
ast_bool_values = ENUM(*AST_BOOL_VALUES, name=AST_BOOL_NAME, create_type=False)
op.add_column('ps_endpoints', sa.Column('suppress_moh_on_sendonly', ast_bool_values))
def downgrade():
if op.get_context().bind.dialect.name == 'mssql':
op.drop_constraint('ck_ps_endpoints_suppress_moh_on_sendonly_ast_bool_values', 'ps_endpoints')
op.drop_column('ps_endpoints', 'suppress_moh_on_sendonly')
Older scripts used YESNO_VALUES but that is no longer supported.