[Asterisk-Users] Voicemail / Dial command issue

[Alex Brett]

Hi,

I have a load of IAX extensions, which I'm trying to set up a standard 
macro to dial them, which gives unavailable or busy voicemail if there 
is no answer or the phone is in use respectively.

The macro I have at the moment is:

; std-exten macro, ${ARG1} = Device to call, ${ARG2} = voicemail box
[macro-std-exten]
; Call the user for 20 seconds
exten => s,1,Dial(${ARG1},20,tr)
exten => s,2,Goto(s-${DIALSTATUS},1)
; If unavailable, go to voicemail
exten => s-NOANSWER,1,Voicemail(u${ARG2})
exten => s-NOANSWER,2,Hangup
; If busy, go to voicemail
exten => s-BUSY,1,Voicemail(b${ARG2})
exten => s-BUSY,2,Hangup

And the bit of the dial plan that calls this is:
exten => 2002,1,Macro(std-exten,IAX2/2002,2001)

(Ignore the fact I'm using voicemail box 2001, its just as I haven't set 
2002 up yet).

Now, from what I can tell this should be fine. The noanswer bit works 
perfectly, if I call it and don't answer, I hit voicemail with the 
unavailable message, however, if the phone is in use and it gets called, 
it also hits the unavailable message rather than the busy message. I've 
done a bit of digging and as far as I can tell the Dial command seems to 
be ignoring the response from the IAX, take this for example (the 
receiving phone (2002) has dialled an extension I've set up that just 
plays hold music, and is at x.x.x.x (IPs masked for security reasons). 
The dialling phone is at y.y.y.y):

This is extension 2002 calling hold music, nothing strange here:

     -- Accepting AUTHENTICATED call from x.x.x.x:
        > requested format = ilbc,
        > requested prefs = (),
        > actual format = ilbc,
        > host prefs = (),
        > priority = mine
     -- Executing MusicOnHold("IAX2/2002 at 2002-1", "") in new stack
     -- Started music on hold, class 'default', on IAX2/2002 at 2002-1

This is the call coming in from the second phone to call 2002:

     -- Accepting AUTHENTICATED call from y.y.y.y:
        > requested format = ilbc,
        > requested prefs = (),
        > actual format = ilbc,
        > host prefs = (ilbc),
        > priority = mine
     -- Executing Macro("IAX2/asterisk at asterisk-5", 
"std-exten|IAX2/2002|2001") in new stack
     -- Executing Dial("IAX2/asterisk at asterisk-5", "IAX2/2002|20|tr") in 
new stack
     -- Called 2002

This seems to make sense, here is the IAX handler saying that the call 
was rejected by x.x.x.x as it is In call:

Mar 27 20:26:56 WARNING[25053]: chan_iax2.c:6735 socket_read: Call 
rejected by x.x.x.x: In call
     -- Hungup 'IAX2/2002-6'

This is what confuses me, as it seems the Dial application (or is it 
something else?) is saying that it is a no answer rather than a busy!

   == No one is available to answer at this time (1:0/0/0)

At this point it has obviously set the ${DIALSTATUS} to NOANSWER and 
hence the rest of the call follows this:

     -- Executing Goto("IAX2/asterisk at asterisk-5", "s-NOANSWER|1") in 
new stack
     -- Goto (macro-std-exten,s-NOANSWER,1)
     -- Executing VoiceMail("IAX2/asterisk at asterisk-5", "su2001") in new 
stack
     -- Playing '/var/spool/asterisk/voicemail/default/2001/unavail' 
(language 'en')
   == Spawn extension (macro-std-exten, s-NOANSWER, 1) exited non-zero 
on 'IAX2/asterisk at asterisk-5' in macro 'std-exten'
   == Spawn extension (internal, 2002, 1) exited non-zero on 
'IAX2/asterisk at asterisk-5'
     -- Hungup 'IAX2/asterisk at asterisk-5'

And finally I hang up extensions 2002:

     -- Stopped music on hold on IAX2/2002 at 2002-1
   == Spawn extension (internal, 500, 1) exited non-zero on 
'IAX2/2002 at 2002-1'
     -- Hungup 'IAX2/2002 at 2002-1'


In case it is needed, relevant portions of iax.conf:

[general]
bandwidth=high
allow=all
disallow=lpc10
jitterbuffer=no
notransfer=yes

[2002]
type=friend
username=2002
secret=******
host=dynamic
notransfer=yes
context=internal

If anybody could shed any light on this strange behaviour, it would be 
much appreciated, as otherwise I'm just going to have to roll with one 
voicemail message which isn't a huge problem, but slightly annoying.

Thanks in advance,
Alex Brett
alex.brett at loho.co.uk