|Summary:||ASTERISK-01352: [patch] Voicemail broadcasts|
|Reporter:||Tilghman Lesher (tilghman)||Labels:|
|Date Opened:||2004-04-06 00:30:49||Date Closed:||2004-09-25 02:09:43|
|Environment:||Attachments:||( 0) 20040502__vm_broadcasts.diff.txt|
( 1) 20040623__voicemail_broadcasts.diff.txt
|Description:||Add a flag to the last field of voicemail boxes that allows deletions:|
Also permits voicemail to be entered in the following manner, to allow multiple recipients for a single recording: Voicemail(u1001[@context][&1002[@context][...]])
|Comments:||By: capouch (capouch) 2004-04-06 04:10:50|
Could you kindly provide a bit more documentation?
E.g. Are the cc and delete entries to go into voicemail.conf?
Can you give an example of its use?
By: Tilghman Lesher (tilghman) 2004-04-06 14:00:35
1235 => 4242,Example Group,,,cc=4200;4300;*@other|delete=1
This entry creates a group mailbox at mailbox 1235, which, on receipt, is copied to mailboxes 4200, 4300, and all mailboxes in vm context other. Following the copy to these other mailboxes, the original email is deleted.
1236 => 4242,Sales Trainee,trainee@localhost,,cc=8000
This entry creates a mailbox for a trainee, whose incoming messages are to be copied to user mailbox 8000 (presumably the sales trainer).
1237 => 4242,VM via Email,firstname.lastname@example.org,,delete=1
This entry allows voicemail to be attached and sent to email@example.com and
the original voicemail subsequently deleted.
edited on: 04-06-04 12:57
By: Tilghman Lesher (tilghman) 2004-04-06 14:04:53
For reasons of a possible infinite recursion, among other problems, I have limited group CC's in such a way that groups may not contain other groups. In other words, while you may create broadcast groups of sales and tech, you may not create a group which contains the mailbox specifier for either sales or tech. (Cause: the underlying CC parameters for the included group will be ignored, although the delete parameter, if specified, will succeed).
This is not an insurmountable problem, just one I have chosen not to attack at this time.
By: cmslaght (cmslaght) 2004-04-14 23:24:07
I tested this patch with today's CVS but using MySQL for voicemail. Does not work. msg0000.txt is never written but msg0000.wav is. Mailbox says that there is no new vmail. Here is the output. I also tried to install this patch on another server that is using the "advanced5.diff" from bugnote 156 and the patch would not install successfully.
Connected to Asterisk CVS-04/14/04-22:32:30 currently running on localhost (pid = 29744)
-- Starting simple switch on 'Zap/1-1'
-- Executing VoiceMail("Zap/1-1", "1235") in new stack
-- Playing 'vm-intro' (language 'en')
-- Playing 'beep' (language 'en')
-- x=0, open writing: /var/spool/asterisk/voicemail//1235/INBOX/msg0000 format: wav49, 0x80dcb10
-- x=1, open writing: /var/spool/asterisk/voicemail//1235/INBOX/msg0000 format: gsm, 0x80e3f90
-- x=2, open writing: /var/spool/asterisk/voicemail//1235/INBOX/msg0000 format: wav, 0x8117b38
-- User hung up
== Parsing '/var/spool/asterisk/voicemail//1235/INBOX/msg0000.txt': == Parsing '/var/spool/asterisk/voicemail//1235/INBOX/msg0000.txt': Found
== Parsing '/var/spool/asterisk/voicemail/default/1234/INBOX/msg0000.txt': == Parsing '/var/spool/asterisk/voicemail/default/1234/INBOX/msg0000.txt': Not found (No such file or directory)
By: cmslaght (cmslaght) 2004-04-15 00:07:05
Recompiled with todays CVS using a "normal" config (ie: no MySQL) and the message gets delivered into my mailbox w/o the msg000*.txt file. The wav file plays correctly though just does not have any timestampt of CID info.
Another feature of this patch may be to add the "recorded name" of the group extension when playing back the message so you know where the vmail came from.
edited on: 04-14-04 23:04
By: Tilghman Lesher (tilghman) 2004-04-15 00:11:22
Okay, part of the fix is to install bug ASTERISK-1274, but that won't solve the entire problem. I can probably update the patch by Monday to fix the rest of the problem.
By: twisted (twisted) 2004-04-20 07:32:46
Corydon76: Is this at all similar to the voicemail groups being done in ASTERISK-153 ?
By: Tilghman Lesher (tilghman) 2004-04-20 11:00:36
twisted: I don't see voicemail groups being discussed at all in ASTERISK-153. If it is there, then it isn't either in the description or bugnotes. And I don't have time to look through all umpteen patches for that bug.
By: cmslaght (cmslaght) 2004-04-20 17:43:47
I applied the most Current CVS, applied the patches in bugnote 0001282 (successfully) but get the follow hunk failed when applying the latest vm_broadcast.diff:
Hunk #4 succeeded at 1027 (offset 1 line).
Hunk ASTERISK-1 succeeded at 1240 (offset 3 lines).
Hunk ASTERISK-2 succeeded at 1393 with fuzz 1 (offset 15 lines).
Hunk ASTERISK-3 succeeded at 1538 (offset 2 lines).
Hunk ASTERISK-4 FAILED at 1591.
Hunk ASTERISK-5 succeeded at 1612 (offset 14 lines).
Hunk ASTERISK-6 FAILED at 1621.
Hunk ASTERISK-7 succeeded at 2256 (offset -6 lines).
Hunk ASTERISK-8 FAILED at 2456.
Hunk ASTERISK-9 FAILED at 3119.
Hunk ASTERISK-10 FAILED at 3429.
5 out of 14 hunks FAILED -- saving rejects to file apps/app_voicemail.c.rej
By: cmslaght (cmslaght) 2004-04-20 17:46:25
By the way.. the patch in bugnote 0000156 does have a broadcast feature but it has to be in a [group] section. I like the way that this patch works but it would be great if these two patches could be integrated together. It also appears that if you use MySQL suppport for voicemail that this patch gets ignored.
By: Tilghman Lesher (tilghman) 2004-04-20 17:56:40
New patch uploaded, due to changes in app_voicemail.c.
By: cmslaght (cmslaght) 2004-04-20 18:08:44
Still a couple left:
patching file apps/app_voicemail.c
Hunk #4 succeeded at 1027 (offset 1 line).
Hunk ASTERISK-1 succeeded at 1240 (offset 3 lines).
Hunk ASTERISK-2 succeeded at 1381 (offset 3 lines).
Hunk ASTERISK-3 succeeded at 1451 (offset 3 lines).
Hunk ASTERISK-4 succeeded at 1550 (offset 2 lines).
Hunk ASTERISK-5 FAILED at 1603.
Hunk ASTERISK-6 succeeded at 1612 (offset 2 lines).
Hunk ASTERISK-7 succeeded at 1621 (offset 2 lines).
Hunk ASTERISK-8 succeeded at 2277 (offset 3 lines).
Hunk ASTERISK-9 succeeded at 2468 (offset 2 lines).
Hunk ASTERISK-10 succeeded at 3128 (offset 4 lines).
1 out of 14 hunks FAILED -- saving rejects to file apps/app_voicemail.c.rej
By: Tilghman Lesher (tilghman) 2004-04-23 13:16:42
Fix for ASTERISK-1274 has been incorporated into this patch. Also, the hard links, which were removed in a previous patchset under this bug are now back in the current patchset.
By: cmslaght (cmslaght) 2004-04-26 09:40:01
Tried to patch this after applying patch from bugnote 1483 (advanced9 voicemail features) but failed at Hunk's 1,2,12,20 and 29. Is there any chance that this patch can be made to work if applied after advanced9.diff? I saw that they don't want it incorporated into the advanced features patch.
By: philipp2 (philipp2) 2004-04-26 16:15:56
Just a check: Will this cause trouble if I soft linke mailbox 1234 to 7000 and include both in the broadcast although this is physically the same box?
By: Tilghman Lesher (tilghman) 2004-04-26 16:42:08
Well, in that case, you're going to get a duplicate message. I'm not sure how I could code around that (in a portable way).
By: cmslaght (cmslaght) 2004-04-28 15:29:13
Bugnote 0001483 has been committed to CVS. Can you revise this patch to work with the current CVS head?
By: twisted (twisted) 2004-04-28 17:30:44
I'd like to make a suggestion on a way to handle this:
How about something like this:
1000 => 1234,Group 1,,,broadcast=yes|delete=yes
1234 => 4321,Joe Schmoe,firstname.lastname@example.org,,group=1000
1235 => 5321,Jill Schmoe,email@example.com,,group=1000
kind of so we dont' have to have a vastly LARGE options line for larger groups. Take care of it by having a seperate group box, with each other box subscribing to it. This would make it a lot easier to configure voicemail for LARGE configurations, and make it a lot easier to add/remove one person from the broadcast.
By: Tilghman Lesher (tilghman) 2004-04-28 18:18:24
While that makes the administration of current groups easier, it also makes it more difficult to create new groups (because you have to edit every single record for people you want to admit to that group). Whereas in the current patchset, if you attempt to copy to a mailbox that doesn't exist, it simply ignores that mailbox (which makes deleting mailboxes as easy as it is in your method).
By: cmslaght (cmslaght) 2004-04-28 22:14:14
After applying todays CVS and vm_broadcast I get the follow errors.
Apr 28 21:51:40 WARNING: file.c:471 ast_openstream: File ISS-mainmenu does not exist in any format
Apr 28 21:51:40 WARNING: file.c:759 ast_streamfile: Unable to open ISS-mainmenu (format GSM): No such file or directory.
Special Note: I use MySQL for voicemail but I don't think that has anything to do with it. I am going to try it on a non-mysql box later tonight.
By: Tilghman Lesher (tilghman) 2004-04-29 10:56:15
I think you either typoed something or you've got that file in your dialplan. When I do a 'grep -R ISS-mainmenu /usr/src/asterisk', I come up with a big fat nothing. That's with current CVS.
By: cmslaght (cmslaght) 2004-04-29 11:10:50
The error message (listed above) is generated when our "Mainmenu" is played using the app_background. All I did to fix this problem was recompile without using your broadcast patch. Something that you patch changes in file.c was breaking app_background or some component of it.
By: Tilghman Lesher (tilghman) 2004-04-29 11:46:49
Ah, whoops. New patch fixes that.
By: cmslaght (cmslaght) 2004-04-30 09:28:12
Works as advertised. Saw one wierd thing though. The first time I left a message in the group mailbox, I had two messages in my personal mailbox but when asterisk saved the broadcast message in my mailbox, it said it was msg00000.txt. I listened to my messages and never got the broadcast. I cleaned out my vmailbox and then sent two more broadcasts and got both of them although on the console screen it still is saying msg00000.txt.
By: Tilghman Lesher (tilghman) 2004-04-30 13:22:18
Well, if you have a broadcast box whose messages are immediately deleted, then all messages to come in will be msg0000.txt (because all prior messages were previously deleted). When copied to recipient mailboxes, however, the message number sequencing will come into play at that time.
By: Mark Spencer (markster) 2004-05-02 13:41:40
One option to consider would be to just allow the "Voicemail" program to leave messages for more than one entity, along the lines of:
That would work for a lot of situations (e.g. making an announcement to everyone) but then there are other situations where having a *shared* inbox makes more sense where when one person acknowledges the message, it's disappears from other poeple's boxes too (e.g. tech support)
By: Tilghman Lesher (tilghman) 2004-05-02 22:19:21
It would work a lot of situations, but the examples above, I think, show there's a few more situations where the functionality contained in this patch would be desirable.
In terms of the shared mailbox, I think the approach has to be different, in that a separate mailbox exists that can be referenced as if it were a part of a user's mailbox. There's all sorts of interesting locking problems in this (i.e. two users check their messages at the same time, with both getting totals including the shared mailbox, then one deletes the message before the other can listen to it.) This patchset does not attempt to solve that problem, and I think it's best put off for a later date.
By: Mark Spencer (markster) 2004-05-02 23:42:35
How, what does this patch provide that the ability to do them with "&" does not?
By: Tilghman Lesher (tilghman) 2004-05-03 00:55:14
The delete flag, when used alone, provides functionality that allows a user to receive their voicemail via email alone (i.e. the voicemail is deleted from the server after sending the message). This has been requested before on the mailing list.
By: Mark Spencer (markster) 2004-05-03 00:57:53
Okay, so how about Voicemail(du6275) for example? My only gripe is having it in the user's voicemail definition. That's the part i'm not very excited about.
By: Tilghman Lesher (tilghman) 2004-05-03 01:20:47
Okay, but what happens when you call Voicemail() with no arguments? The user enters the mailbox number, the voicemail is saved, the email is sent... how does Voicemail know whether to delete from the mailbox or not? If you don't, and the user never checks their voicemail, their Voicemailbox is going to fill up (and consume disk space). And if you do, well, that's also a bad thing if they do check their messages via VoicemailMain.
It's simply not a consistent experience for the user.
By: dennis (dennis) 2004-05-05 00:21:37
I'm a big fan of Mark's suggestion:
That would save us from creating mailboxes that are used solely to distribute messages to other mailboxes. Using Voicemail(du6236&6124) to delete the message after sending email notifications would also be great.
Corydon76 has a very valid point in regards to calling Voicemail() with no arguments. I personally never call Voicemail() without arguments, but this may not be the case for everyone. Any chance Mark's method could be implemented, yet still include support for "delete=1" in voicemail.conf as a option for those rare exceptions? Just a suggestion.
By: Mark Spencer (markster) 2004-05-05 00:36:12
Obviously you could just call it as Voicemail(d) to select the deletion mode.
By: Tilghman Lesher (tilghman) 2004-05-05 07:59:39
But that still doesn't make any sense, Mark. Deleting voicemail after sending email is a PER MAILBOX option. Why are you insisting on treating it like a GLOBAL option?
By: Mark Spencer (markster) 2004-05-05 09:56:01
Okay, you can make a "delete" override then in the mailbox which overrides the default behavior but that's the ONLY option that goes in the mailbox definition, and I still think it's a stupid, contrived example, but whatever.
By: Tilghman Lesher (tilghman) 2004-05-05 11:25:18
It may seem like a contrived example to you, but I have REAL users on both sides of the fence: those who want their voicemail ONLY via email and those who check voicemail only via VoiceMailMain.
By: Mark Spencer (markster) 2004-05-05 11:30:46
Okay just give the patch.
By: cmslaght (cmslaght) 2004-05-05 23:26:09
In the example "Voicemail(u6236&6124&4242)", what greating for voicemail does it play or is u6236 the group mailbox and the rest of the mailboxes listed are extra people?
By: Mark Spencer (markster) 2004-05-05 23:39:58
It would give the greeting for the first.
Of course you can do a custom greeting too if you wanted to.
By: cmslaght (cmslaght) 2004-05-06 09:35:51
My only issue with this is that I am trying to make my extensions.conf as marco'd and variabled as possible. I am using MySQL for voicemail so that I can edit it through a web interface. Using the voicemail broadcast the way you are talking would not work in this configuration (Voicemail(u6236&6124&4242)).
By: Mark Spencer (markster) 2004-05-06 09:38:12
What behavior are you trying to get? You can always do playback first, and then omit the "u" if you want a custom greeting.
By: Tilghman Lesher (tilghman) 2004-05-21 18:59:23
New implementation, per Mark's note.
By: Mark Spencer (markster) 2004-05-25 01:41:36
hard links are a bad idea since that means that changes on one side will automagically be reflected on the other side.
By: Tilghman Lesher (tilghman) 2004-05-25 10:55:29
Okay, I took the hard link out of file.c. However, I scoured the code in app_voicemail.c and there's no place where there are changes that can be made to a hard linked file, so I left that hard link in.
By: cmslaght (cmslaght) 2004-06-09 09:24:28
Anything being finalized on this one. I did notice that when I was using this that I would get an email with the attached message but the attachment was from a previous message. If I looked in the email that we setup for the broadcast mailbox, it would playback the correct message. Very wierd.
By: Tilghman Lesher (tilghman) 2004-06-09 10:26:31
Are you using the latest patchset?
By: cmslaght (cmslaght) 2004-06-10 09:23:39
I will test the latest and greatest tonight. Any word on if this is going get included into CVS?
By: Tilghman Lesher (tilghman) 2004-06-22 16:00:59
Patch updated, since there were major changes to app_voicemail.c. No word yet on when this will go in.
By: Mark Spencer (markster) 2004-06-22 17:53:20
It's closer but there are still some outstanding issues:
1) All the hard link stuff should go away. Copy the files -- under no circumstances should they be linked. If you *really* want the ability to do the hard links, you can make it a compile-time or global runtime option that defaults to OFF.
2) The code for re-opening the text file is important, because it prevents the leakage of a file descriptor in certain cases. Please don't change it.
3) Am I missing something or are the text files never deleted?
4) The notify_new_message() function opens the mif file only in order to report the duration, correct? Why not just pass it as an argument to both the notify_new_message and copy_message functions, that way the file doesn't ever have to be read at all?
That's all that bugs me about it right now.
By: Tilghman Lesher (tilghman) 2004-06-22 21:04:21
Point 2 actually causes another problem: text files which, in certain circumstances, only contain a single line, with "duration=<num>". If we have a file descriptor leak, we should fix that, not cause additional problems by reopening the file.
I'll look at points 1, 3, & 4, and have a new patch in the morning.
By: Mark Spencer (markster) 2004-06-22 21:05:53
Actually, no, point 2 does not create empty files because it's opened with O_WRITE and O_APPEND and *not* with O_CREAT which means it will not create the file if it doesn't exist, hence why we open and then fdopen.
By: Tilghman Lesher (tilghman) 2004-06-23 11:44:38
OK, all 4 points have been addressed in the latest patch. Patch has been tested when sending to 1, 2, or 3 mailboxes at once.
By: Mark Spencer (markster) 2004-06-23 14:15:05
Added to CVS. Nicely done.
By: frank (frank) 2004-07-17 17:18:52
Reminder sent to frank
By: modesittc (modesittc) 2004-08-23 02:40:23
Reminder sent to Corydon76
Corydon76, I appologize if there is a more appropriate way to report this but it is related to bug ASTERISK-1352.
When you perform a Voicemail Broadcast using
exten => 1234,1,VoiceMail(u2001&201&202&203)
If you specify more than 65 mailboxes it failes to copy the message to the 66th. Was this intended or a possible bug?