History

Michael Kuron d73f22268f res_pjsip_aoc: New module for sending advice-of-charge with chan_pjsip chan_sip supported sending AOC-D and AOC-E information in SIP INFO messages in an "AOC" header in a format that was originally defined by Snom. In the meantime, ETSI TS 124 647 introduced an XML-based AOC format that is supported by devices from multiple vendors, including Snom phones with firmware >= 8.4.2 (released in 2010). This commit adds a new res_pjsip_aoc module that inserts AOC information into outgoing messages or sends SIP INFO messages as described below. It also fixes a small issue in res_pjsip_session which didn't always call session supplements on outgoing_response. * AOC-S in the 180/183/200 responses to an INVITE request * AOC-S in SIP INFO (if a 200 response has already been sent or if the INVITE was sent by Asterisk) * AOC-D in SIP INFO * AOC-D in the 200 response to a BYE request (if the client hangs up) * AOC-D in a BYE request (if Asterisk hangs up) * AOC-E in the 200 response to a BYE request (if the client hangs up) * AOC-E in a BYE request (if Asterisk hangs up) The specification defines one more, AOC-S in an INVITE request, which is not implemented here because it is not currently possible in Asterisk to have AOC data ready at this point in call setup. Once specifying AOC-S via the dialplan or passing it through from another SIP channel's INVITE is possible, that might be added. The SIP INFO requests are sent out immediately when the AOC indication is received. The others are inserted into an appropriate outgoing message whenever that is ready to be sent. In the latter case, the XML is stored in a channel variable at the time the AOC indication is received. Depending on where the AOC indications are coming from (e.g. PRI or AMI), it may not always be possible to guarantee that the AOC-E is available in time for the BYE. Successfully tested AOC-D and both variants of AOC-E with a Snom D735 running firmware 10.1.127.10. It does not appear to properly support AOC-S however, so that could only be tested by inspecting SIP traces. ASTERISK-21502 #close Reported-by: Matt Jordan <mjordan@digium.com> Change-Id: Iebb7ad0d5f88526bc6629d3a1f9f11665434d333		2 years ago
..
cdr	Remove as much trailing whitespace as possible.	7 years ago
config	res_pjsip_aoc: New module for sending advice-of-charge with chan_pjsip	2 years ago
queue_log	queue_log: Add alembic script for generate db table for queue_log	5 years ago
voicemail	contrib: Spelling fixes	3 years ago
README.md	contrib: Spelling fixes	3 years ago
cdr.ini.sample	…
config.ini.sample	…
env.py	Remove as much trailing whitespace as possible.	7 years ago
queue_log.ini.sample	queue_log: Add alembic script for generate db table for queue_log	5 years ago
voicemail.ini.sample	…

README.md

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 records
config - Tables used for Asterisk realtime configuration
queue_log - Table used for Asterisk to store Queue Log records
voicemail - Tables used for ODBC_STORAGE 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.