[asterisk-bugs] [JIRA] Created: (ASTERISK-20400) Let ODBC store multiple formats

David Laban (JIRA) noreply at issues.asterisk.org
Mon Sep 10 10:56:07 CDT 2012


Let ODBC store multiple formats
-------------------------------

                 Key: ASTERISK-20400
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20400
             Project: Asterisk
          Issue Type: Improvement
      Security Level: None
          Components: Applications/app_voicemail/ODBC
            Reporter: David Laban


http://ofps.oreilly.com/titles/9780596517342/asterisk-DB.html notes that ODBC only supports one voicemail format, but it is not noted in the example configs or anywhere else, including the code (!).

The problem that I am *actually* trying to solve is that the default wav49[*] format is not supported by android, and I am not prepared to send raw PCM over a GSM connection. The only other common codec between asterisk's app_voicemail and android (ogg vorbis) is not supported by iPhone. The ovbious solution therefore is to store multiple formats in the database. 

[*] I assume that wav49 is the default for a good reason (winxp compatibility?)

I'm in the process of speccing up my changes now, and estimating how much work it will be. I will use this bug to track my progress. If anyone has any suggestions on the storage schema, please pipe up now. The voicemail_messages table has the following schema:

Table: voicemail_messages
Create Table: CREATE TABLE `voicemail_messages` (
  `dir` char(255) NOT NULL default '',
  `msgnum` int(4) NOT NULL default '0',
  `context` char(80) default NULL,
  `macrocontext` char(80) default NULL,
  `callerid` char(80) default NULL,
  `origtime` int(11) default NULL,
  `duration` int(11) default NULL,
  `recording` blob,
  `flag` char(30) default NULL,
  `category` char(30) default NULL,
  `mailboxuser` char(30) default NULL,
  `mailboxcontext` char(30) default NULL,
  PRIMARY KEY  (`dir`,`msgnum`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

I draw your attention to: PRIMARY KEY ('dir', 'msgnum'). 'dir' is typically something like:
/var/spool/asterisk/voicemail/default/1234/INBOX
and 'msgnum' is an integer.

This gives me the choice of:
a) Insert the parallel formats as something like:

'msgnum': ogg/var/spool/asterisk/voicemail/default/1234/INBOX

b) Create a parallel table with PRIMARY KEY (`dir`, `msgnum`, `format`), but keep the existing voicemail_messages as the primary table.

c) Break backwards compatibility by removing the `recording` blob from the table and inserting a reference field that you can look up in a table that looks something like:
(
Table: voicemail_messages_data
Create Table: CREATE TABLE `voicemail_messages` (
  `format` char(10) NOT NULL default '',
  `recording_id` int(4) NOT NULL default '0',
  `data` blob,
  `refcount` int(4) default '1',
PRIMARY KEY (`recording_id`, `format`)
)

d) Give up, and try a different tactic.

Note that any changes I make will involve keeping the various formats in sync using:
#ifdef ODBC_STORAGE
static char odbc_database[80];
static char odbc_table[80];
#define RETRIEVE(a,b,c,d) retrieve_file(a,b)
#define DISPOSE(a,b) remove_file(a,b)
#define STORE(a,b,c,d,e,f,g,h,i,j) store_file(a,b,c,d)
#define EXISTS(a,b,c,d) (message_exists(a,b))
#define RENAME(a,b,c,d,e,f,g,h) (rename_file(a,b,c,d,e,f))
#define COPY(a,b,c,d,e,f,g,h) (copy_file(a,b,c,d,e,f))
#define DELETE(a,b,c,d) (delete_file(a,b))

1. Which approach is best? c) would probably be less work, because you only need to update recording_id.
1.1. How much do we care about backwards compatibility of the DB schema?

2. How much can I optimise if I make RETRIEVE etc. parse the fmt argument? 
(A naive implementation of RETREIVE would cause a pull of all formats from the server to local storage, even if app_voicemail already knows which format is best for the channel.)

Comments from someone who has experience hacking app_voicemail would be greatly appreciated.

David.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the asterisk-bugs mailing list