[asterisk-users] Multiple dial macros at the same time

Graham Mainwaring graham at mhn.org
Sun Oct 29 18:38:34 MST 2006


I am setting up an after-hours on-call system. Someone calls in and 
requests service, and while they listen to music on hold, we dial out to 
several people's cell phones and home phones. We don't know if they will 
be answered by the employee, or by voicemail or a 
spouse/relative/child/pet. So we play a message that says "press 1 to 
accept the call" and ask employees to train their 
spouse/relative/child/pets not to press 1.

The following extract from my dialplan shows how I have this feature set 
up. This is with Asterisk 1.2.13.

  [macro-screen]
  exten => s,1,Set(MACRO_RESULT=CONTINUE)
  exten => s,2,Read(ACCEPT|press-1-to-accept|1|skip|3|1)
  exten => s,3,GotoIf($[${ACCEPT}=1]?5:4)
  exten => s,4,MacroExit
  exten => s,5,Set(MACRO_RESULT=)
  exten => s,6,Playback(please-say-hello)

  [menu]
  exten => _FOLS1NXXNXXXXXX,1,Dial(SIP/${EXTEN:4}@pstn,20,oM(screen))
  exten => s,1,Playback(welcome)
  exten => s,2,Dial(LOCAL/FOLS19195551000&LOCAL/FOLS19195552000,,tm)
  exten => s,3,Voicemail(u301)
  exten => s,4,Hangup

In order for this to work, I needed the ability to restore MACRO_RESULT 
back to an unset state. For now I just hacked the Set application so 
that after removing the variable from the context, it only re-creates it 
if the value provided is greater than zero length. In the future I will 
probably write an UnSet application to handle this more gracefully, 
unless someone knows a better way to unset a variable.

This all works fine, with one small problem that is driving me batty. I 
would appreciate any insight or ideas on how to solve this. Here's the 
scenario:

  1. Caller dials the number and hears the welcome message,
     then music on hold.
  2. Simultaneous calls are made to Employee A at 555-1000
     and Employee B at 555-2000 (per above).
  3. Both of them answer the phone.
  4. Employee A presses one and hears "you will now be connected,
     please say hello to the caller."
  5. Employee A is bridged to the caller, says hello, and begins
     working with them.
  6. A few seconds later, the Employee B also presses 1. He also
     hears "you will now be connected."
  7. Employee B fails to bridge, and is hung up on.

The problem is, these are pretty urgent calls and employees are highly 
motivated to make sure they get answered. Employee B doesn't know 
whether the call dropped because someone else got it, or because of a 
phone system problem of some sort. He is now obligated to figure out 
what's up with the call and make sure someone got it. What I want 
instead is for Employee B to hear an alternate message that says 
"someone else got the call." This gives positive confirmation that it's 
not his problem, so he can roll over and go back to sleep.

I can see two ways of doing this.

1. Write a function called BridgedChannel that takes a channel ID and 
returns its bridge peer channel ID, if any. This would allow me to set a 
variable __PARENTCHANNEL with the channel ID of the incoming call, 
before the Dial command executes. The macro, at priority 6, can then 
check BridgedChannel(${__PARENTCHANNEL}). If it has a value then the 
call is already bridged and we can tell the employee not to worry.

2. Have a MySQL database with a single table with two fields, varchar 
channel-ID and boolean answered. When the call starts do update table 
set answered=false where channel-ID=${__PARENTCHANNEL}. When an employee 
dials 1, retrieve the value of answered for __PARENTCHANNEL and also set 
it to true in a single transaction. If the returned value was false, 
tell them to answer the call and bridge; if the returned value was true, 
tell them to go back to sleep and hang up.

Solution #1 requires me to write a whole new function, and solution #2 
requires a MySQL database, which is pretty big dependency for such a 
simple function.

Does anyone see a simpler way of doing this, or have any ideas for other 
avenues to pursue?

Thanks in advance,

-Graham


More information about the asterisk-users mailing list