[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.

> It wouldn't be 1.8, it'd actually be in 11.
Er, that's what I meant. 


- jrose


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2220/#review7471
-----------------------------------------------------------


On Dec. 3, 2012, 11:22 a.m., jrose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2220/
> -----------------------------------------------------------
> 
> (Updated Dec. 3, 2012, 11:22 a.m.)
> 
> 
> Review request for Asterisk Developers, Mark Michelson, Matt Jordan, and kmoore.
> 
> 
> Summary
> -------
> 
> When a message is moved between folders (such as after listening to new messages, they are switched to the old messages folder), the msg_id field added in Asterisk 11 isn't copied. This patch simply adds that field to what is copied in the odbc COPY function and appears to solve the problem.
> 
> 
> This addresses bug ASTERISK-20717.
>     https://issues.asterisk.org/jira/browse/ASTERISK-20717
> 
> 
> Diffs
> -----
> 
>   /branches/11/apps/app_voicemail.c 376833 
> 
> Diff: https://reviewboard.asterisk.org/r/2220/diff
> 
> 
> Testing
> -------
> 
> Made messages in a mailbox using app_voicemail. Checked mysql to see the msg_id. Verified an ID was created.
> Listened to messages, made sure the COPY function was invoked. Checked mysql again and saw that the IDs were gone.
> 
> Applied the patch, repeated the process, the IDs remained intact.
> 
> 
> Thanks,
> 
> jrose
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20121204/85db8500/attachment-0001.htm>