Files
asterisk/contrib/ast-db-manage
George Joseph 674b18bdf0 pjsip_options: Add qualify_timeout processing and eventing
This is the second follow-on to https://reviewboard.asterisk.org/r/4572/ and the
discussion at
http://lists.digium.com/pipermail/asterisk-dev/2015-March/073921.html

The basic issues are that changes in contact status don't cause events to be
emitted for the associated endpoint.  Only dynamic contact add/delete actions
update the endpoint.  Also, the qualify timeout is fixed by pjsip at 32 seconds
which is a long time.

This patch makes use of the new transaction timeout feature in r4585 and
provides the following capabilities...

1.  A new aor/contact variable 'qualify_timeout' has been added that allows the
user to specify the maximum time in milliseconds to wait for a response to an
OPTIONS message.  The default is 3000ms.  When the timer expires, the contact is
marked unavailable.

2.  Contact status changes are now propagated up to the endpoint as follows...
When any contact is 'Available', the endpoint is marked as 'Reachable'.  When
all contacts are 'Unavailable', the endpoint is marked as 'Unreachable'.  The
existing endpoint events are generated appropriately.

ASTERISK-24863 #close

Change-Id: Id0ce0528e58014da1324856ea537e7765466044a
Tested-by: Dmitriy Serov
Tested-by: George Joseph <george.joseph@fairview5.com>
2015-04-17 15:31:14 -05:00
..

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:

  • config - Tables used for Asterisk realtime configuration
  • voicemail - Tables used for ODBC_STOARGE of voicemail messages

Alembic uses SQLAlchemy, which has support for many databases.

IMPORTANT NOTE: This is brand new and the initial migrations are still subject to change. Only use this for testing purposes for now.

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.