[asterisk-dev] [Code Review]: app_voicemail: fix problem where we kill the msg_id of a message when changing its folder in odbc storage.

[jrose]

> On Nov. 29, 2012, 6:34 p.m., Alec Davis wrote:
> > This does fix the msg-id is lost problem when a message is 'moved' from inbox to old, or any other folder move.
> > 
> > I havn't followed this code path, but if you copy (note not move) a message from 1 mailbox to another (if that's possible), then we'd have 2 messages with the same msg_id.
> > 
> > Does msg_id need to be unique?
> >
> 
> Matt Jordan wrote:
>     Yes it does.  A copy should result in a new msg_id.
> 
> jrose wrote:
>     We need to come up with a new method for generating the msg_id then, because the one we have won't really cut it if uniqueness is necessary accross all mailboxes. The second half of the string is just a string hash value for a sequence of the extension, context, and the callerid used for the channel that called voicemail, so that is going to stay the same during a copy. The first half is just the epoch time (seconds). If you have a function that copies a message to twice at roughly the same time, that isn't going to work.
>     
>     So for reference, the current msg_id string is...
>     
>     (A)-hash((B)(C)(D))
>     
>     where A is a timestamp unique to each second, B is call_extension, C is call_context, and D is call_callerid.
>     
>     We could reasonably guarantee uniqueness if we simply used an atomically increasing counter (like how we handle numerous channel names currently) in addition to the epoch time, so I'm thinking the new msg_id string could be...
>     
>     (U)-(A)-hash((B)(C)(D))
>     
>     where U is the incrementing counter and everything else is the same. When doing a copy, the timestamp becomes the time at copy.
>     
>     That probably isn't enough though still. Multiple instances of Asterisk could be using the database and presumably both could do a copy at the same time to the same message. Might as well throw systemname of whichever Asterisk instance did they operation in there for good measure.
>     
>     (S)(U)-(A)-hash((B)(C)(D))
>     
>     We might need to increase the character count if we do this. systemnames usually aren't more than 20 characters or so, but adding that to the unique ID (8 hex characters), and the existing stuff (which is usually right around 20 caracters right now and could be larger under certain conditions), the current 40 that we suggest on wiki and in the contrib script would probably be inadequate. Alternatively we could just scrap the call_extension, call_context, and call_callerid hash from the message since it would no longer be necessary to provide uniqueness. We could also convert the timestamp into hex to save some characters.
> 
> jrose wrote:
>     Looks like we actually set aside 128 characters for system name.  Yuck.  Maybe I should hash that and write as hex too.
> 
> Alec Davis wrote:
>     found: http://linux.die.net/man/3/uuid_generate
>     
>     uuid_generate, uuid_generate_random, uuid_generate_time, uuid_generate_time_safe - create a new unique UUID value 
>     
>     The UUID is 16 bytes (128 bits) long, which gives approximately 3.4x10^38 unique values (there are approximately 10^80 elementary particles in the universe according to Carl Sagan's Cosmos). The new UUID can reasonably be considered unique among all UUIDs created on the local system, and among UUIDs created on other systems in the past and in the future. 
>     
>     Maybe something in this as to what it's using for randomness.
> 
> Alec Davis wrote:
>     perhaps the work has already been started/done https://reviewboard.asterisk.org/r/2217/
> 
> jrose wrote:
>     We can't use that in 1.8 unfortunately. Matt and I talked about this and its important to keep it either the same or similar to the current ID, at least as far as the appearance of the ID is concerned.
> 
> Matt Jordan wrote:
>     It wouldn't be 1.8, it'd actually be in 11.
>     
>     The reason for not making that change in release branches is to not introduce a library dependency in the middle of a version release (and, if the column length changes, potential schema modifications as well). As it turns out, that's less of a concern since pjproject depends on libuuid as well (as Russell discovered), so its possibly not as big of a show stopper - but creating a dependency on a library mid-stream feels bad.
> 
> jrose wrote:
>     > It wouldn't be 1.8, it'd actually be in 11.
>     Er, that's what I meant.
> 
> Alec Davis wrote:
>     asterisk-11 CHANGES.TXT
>     {code}
>        All messages created in old Asterisk installations will have a msg_id added to
>        them when required. This operation should be transparent as well.
>     {code}
>     
>     This isn't the case!
> 
> jrose wrote:
>     I haven't really changed anything about the circumstances behind adding msg_ids to messages from old installations, so if is false with the patch, it's false without the patch.  Can you please be a little more specific about the scenario for which this isn't true? I've tried using voice mails recorded in old installations with this patch and they seem to work and receive the msg_id when they are read and moved as what you'd generally expect to be required.
>     
>     I think transparency in this case just means the end user doesn't have to be particularly involved with the process, but if that's what you mean please enlighten me.
> 
> Alec Davis wrote:
>     CHANGES.txt was wrong before this patch, so you haven't broken anything as you say.
>     
>     Now with the opening of a voicemail, they would generally be moved old, and you patch will set a msg_id.
>     
>     The issue we're seeing is the greeting, from an old asterisk install, it didn't have a msg-id, and because it's not moved around, it will never get one.
>     Thus we always see the error "SQL Get Data error! coltitle=msg_id"
>     
>
> 
> Alec Davis wrote:
>     does the mysql msg_id column need to change size for this patch?
>     If so what to?

> does the mysql msg_id column need to change size for this patch?
> If so what to?
As of the latest version of this patch, no, so nothing.

> The issue we're seeing is the greeting, from an old asterisk install, it didn't
> have a msg-id, and because it's not moved around, it will never get one. Thus we
> always see the error "SQL Get Data error! coltitle=msg_id"