Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

app_voicemail_odbc: Allow audio to be kept on disk - 18,20 #724

Open
wants to merge 1 commit into
base: 20
Choose a base branch
from

Conversation

gtjoseph
Copy link
Member

This commit adds a new voicemail.conf option 'odbc_audio_on_disk'
which when set causes the ODBC variant of app_voicemail to leave
the message and greeting audio files on disk and only store the
message metadata in the database. This option came from a concern
that the database could grow to large and cause remote access
and/or replication to become slow. In a clustering situation
with this option, all asterisk instances would share the same
database for the metadata and either use a shared filesystem
or other filesystem replication service much more suitable
for synchronizing files.

The changes to app_voicemail to implement this feature were actually
quite small but due to the complexity of the module, the actual
source code changes were greater. They fall into the following
categories:

  • Tracing. The module is so complex that it was impossible to
    figure out the path taken for various scenarios without the addition
    of many SCOPE_ENTER, SCOPE_EXIT and ast_trace statements, even in
    code that's not related to the functional change. Making this worse
    was the fact that many "if" statements in this module didn't use
    braces. Since the tracing macros add multiple statements, many "if"
    statements had to be converted to use braces.

  • Excessive use of PATH_MAX. Previous maintainers of this module
    used PATH_MAX to allocate character arrays for filesystem paths
    and SQL statements as though they cost nothing. In fact, PATH_MAX
    is defined as 4096 bytes! Some functions had (and still have)
    multiples of these. One function has 7. Given that the vast
    majority of installations use the default spool directory path
    /var/spool/asterisk/voicemail, the actual path length is usually
    less than 80 bytes. That's over 4000 bytes wasted. It was the
    same for SQL statement buffers. A 4K buffer for statement that
    only needed 60 bytes. All of these PATH_MAX allocations in the
    ODBC related code were changed to dynamically allocated buffers.
    The rest will have to be addressed separately.

  • Bug fixes. During the development of this feature, several
    pre-existing ODBC related bugs were discovered and fixed. They
    had to do with leaving orphaned files on disk, not preserving
    original message ids when moving messages between folders,
    not honoring the "formats" config parameter in certain circumstances,
    etc.

UserNote: This commit adds a new voicemail.conf option
'odbc_audio_on_disk' which when set causes the ODBC variant of
app_voicemail_odbc to leave the message and greeting audio files
on disk and only store the message metadata in the database.
Much more information can be found in the voicemail.conf.sample
file.

This commit adds a new voicemail.conf option 'odbc_audio_on_disk'
which when set causes the ODBC variant of app_voicemail to leave
the message and greeting audio files on disk and only store the
message metadata in the database.  This option came from a concern
that the database could grow to large and cause remote access
and/or replication to become slow.  In a clustering situation
with this option, all asterisk instances would share the same
database for the metadata and either use a shared filesystem
or other filesystem replication service much more suitable
for synchronizing files.

The changes to app_voicemail to implement this feature were actually
quite small but due to the complexity of the module, the actual
source code changes were greater.  They fall into the following
categories:

* Tracing.  The module is so complex that it was impossible to
figure out the path taken for various scenarios without the addition
of many SCOPE_ENTER, SCOPE_EXIT and ast_trace statements, even in
code that's not related to the functional change.  Making this worse
was the fact that many "if" statements in this module didn't use
braces.  Since the tracing macros add multiple statements, many "if"
statements had to be converted to use braces.

* Excessive use of PATH_MAX.  Previous maintainers of this module
used PATH_MAX to allocate character arrays for filesystem paths
and SQL statements as though they cost nothing.  In fact, PATH_MAX
is defined as 4096 bytes!  Some functions had (and still have)
multiples of these.  One function has 7.  Given that the vast
majority of installations use the default spool directory path
`/var/spool/asterisk/voicemail`, the actual path length is usually
less than 80 bytes.  That's over 4000 bytes wasted.  It was the
same for SQL statement buffers.  A 4K buffer for statement that
only needed 60 bytes.  All of these PATH_MAX allocations in the
ODBC related code were changed to dynamically allocated buffers.
The rest will have to be addressed separately.

* Bug fixes.  During the development of this feature, several
pre-existing ODBC related bugs were discovered and fixed.  They
had to do with leaving orphaned files on disk, not preserving
original message ids when moving messages between folders,
not honoring the "formats" config parameter in certain circumstances,
etc.

UserNote: This commit adds a new voicemail.conf option
'odbc_audio_on_disk' which when set causes the ODBC variant of
app_voicemail_odbc to leave the message and greeting audio files
on disk and only store the message metadata in the database.
Much more information can be found in the voicemail.conf.sample
file.
@gtjoseph gtjoseph changed the title app_voicemail_odbc: Allow audio to be kept on disk app_voicemail_odbc: Allow audio to be kept on disk - 18,20 Apr 29, 2024
@gtjoseph
Copy link
Member Author

cherry-pick-to: 18

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants