[Asterisk-Users] Multiple announcements in a queue ??

[A.J. Paxson]

On 5/16/06 12:23 AM, "Richard Lyman"  wisely said:

> A.J. Paxson wrote:
> 
>> On 5/15/06 10:55 PM, "Richard Lyman"  wisely said:
>> 
>>  
>> 
>>> A.J. Paxson wrote:
>>> 
>>>    
>>> 
>>>> Hi All!
>>>> 
>>>> I've really been struggling trying to get around this.  Instead of the same
>>>> announcement being played over and over again, I want to be able to play
>>>> more than 1 announcement in a queue.
>>>> 
>>>> Does anyone have any brainstorming ideas on how I can try this?
>>>> 
>>>> Once a caller is in a queue, I no longer have any control inside that
>>>> queue.
>>>> I can have that queue timeout, play a different announcement, and place
>>>> them
>>>> back in the queue, but then the caller loses it's place.
>>>> 
>>>> Any ideas?
>>>> 
>>>> ~~Aaron
>>>> 
>>>> 
>>>> 
>>>>      
>>>> 
>>> i'd suggest not using 'announcements' and use moh.
>>> you can setup any number of subdirs and assign that as moh for a queue,
>>> it just randomly plays the files within the dir. remove -z  for fifo (iirc)
>>> 
>>> <>op => mp3:/var/lib/asterisk/mohmp3/op,-z      ; randomly play all
>>> files in op directory
>>> vr => mp3:/var/lib/asterisk/mohmp3/vr,-z        ; randomly play all
>>> files in vr directory
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> --Bandwidth and Colocation provided by Easynews.com --
>>> 
>>> Asterisk-Users mailing list
>>> To UNSUBSCRIBE or update options visit:
>>> http://lists.digium.com/mailman/listinfo/asterisk-users
>>> 
>>>    
>>> 
>> That's a good idea.  However, that sounds like a lot of work, as I would
>> have to split my music on hold songs into 60 or 90 second increments, just
>> to get my announcements in.
>> 
>> And it wouldn't seem like a smooth transition if, after my announcement, I
>> go on to a completely different moh song.
>> 
>> 1).  Music On Hold for 60 seconds (/var/lib/asterisk/mohmp3/queue1/moh1.mp3)
>> 2).  Announcement 1 (/var/lib/asterisk/mohmp3/queue1/moh2.mp3)
>> 3).  Go back to Music where we left off, for another 60 seconds
>> (/var/lib/asterisk/mohmp3/queue1/moh3.mp3).
>> 4).  Announcement 2....
>> 
>> Etc.
>> 
>> Unless I failed to understand the point you were making.....
>> 
>> Thanks for the discussion, Richard!
>> 
>> ~~Aaron
>>  
>> 
> actually it would mean removing the -z and naming your files as
> 001.yadda 002.yadda regardless of length,
> meaning if you decide to use a 10 minute file as your 'inbetween music'
> then that is the time it takes..
> so as you stated, if you want to 'stucture' the way moh is played, then
> yes you would have to make them x long.
> 
> i guess i misunstood your question.  because currently, announcements do
> not work that way (unless its in the 'test tree').
> so i offered a non-announcement way.  if what you really meant to ask
> was if anyone has written a mod that allows
> multiple announcement files... i feel i have just wasted your time. <G>
> 
> 
> 
> 
> 
You certainly have not wasted my time.  I knew it wasn't available
"out-of-the-box" and was asking for ideas "outside the box".

This is something I can work with, albeit, cumbersome.

I like the idea that I can just pick up the phone, dial an extension, record
an announcement, and be sure that announcement will play during extended
hold times.

Thanks for the ideas, Richard!

It just came to me, about using timeouts on the queues, play an announcment,
update the caller's priority, and then putting them back in the queue.
Maybe?

Pseudo-code.  Syntax and structure maybe incorrect.

Exten => 1111,1,Queue(techsupport||||120)
Exten => 1111,n, Play(announcment-1)
Exten => 1111,n, setVar(QUEUE_PRIO+1)
Exten => 1111,n,Queue(techsupport||||120)
.........

Basically, the priority was increased by one, so when I placed them back in
the queue, even though the caller lost their place, their priority should be
high enough to still receive the call.

The only problem with that is, if my announcement-1 is 30 seconds long,
another caller could have been answered while this caller was listening to
the playback.

Sigh....nothing is ever easy.  ((grin))

Thanks for the discussion and replies, Richard!