When using tl-stdexten for an extension, everything works OK unless the
destination extension is offline (phone unplugged, softphone shut down,
etc). In that case, it gets as far as ChanIsAvail() and drops the call:
[...]
-- Goto (macro-tl-userexten-base,s,127)
-- Executing [s@macro-tl-userexten-base:127]
Set("SIP/208.34.105.20-b7636980", "FORWARD=") in new stack
-- Executing [s@macro-tl-userexten-base:128]
GotoIf("SIP/208.34.105.20-b7636980", "1?notforwarded") in new stack
-- Goto (macro-tl-userexten-base,s,134)
-- Executing [s@macro-tl-userexten-base:134]
Set("SIP/208.34.105.20-b7636980", "FORWARD=") in new stack
-- Executing [s@macro-tl-userexten-base:135]
ChanIsAvail("SIP/208.34.105.20-b7636980", "SIP/180-hudsonltd") in new stack
== Spawn extension (macro-tl-userexten-base, s, 135) exited non-zero on
'SIP/208.34.105.20-b7636980' in macro 'tl-userexten-base'
== Spawn extension (macro-tl-userexten-base, s, 135) exited non-zero on
'SIP/208.34.105.20-b7636980' in macro 'tl-stdexten'
== Spawn extension (macro-tl-userexten-base, s, 135) exited non-zero on
'SIP/208.34.105.20-b7636980'
Looking in the dialplan, it looks like the problem is right in here:
;;; non forwarded call
;; if follow me is set and original extension not to be called
exten => s,n(notforwarded),Set(FORWARD=${DB(${THISEXT}/CFNA)})
exten => s,n,ChanIsAvail(${ARG1})
exten => s,n,GotoIf($["${AVAILCHAN}" = ""]?s-NA,1)
exten => s,n,Set(TIMEOUT=${DB(${THISEXT}/VMT0)})
A workaround we have is to use a simpler, custom tl-stdexten that just
tries to dial the phone and goes to voicemail if it doesn't work; this
is OK for temporary use, but it doesn't have the followme or anything
like that in there. I'm not sure why it's failing out like that
(perhaps something weird in Asterisk), but app_chanisavail.c hasn't
changed in Asterisk since 2006, so I don't think it's recent
brokedness. We are running Asterisk 1.4.17, Thirdlane PBX 5.0.50, and
Script Library 1.1.36.
Priorityjumping
Alex, is there anything else in Thirdlane's default macros that would require priorityjumping=yes? I have been having the same problem with calls ending if the phone isn't registered, and I just found that priorityjumping is set to yes. Changing it to no fixes the problem, but I have no idea if it breaks anything else.
Priorityjumping
As far as I can remember there is nothing that expects priorityjumping to be set to yes, at least not in our recent scripts. The current extensions.conf has it set to no, but I am afraid to patch files in the existing installations as they may have some code that does depend on it.
That is always a problem - installing new stuff and not breaking compatibility, even if Asterisk itself changes.
You may want to check that you have priorityjumping=no in general section of extensions.conf - make sure that there is nothing else that depends on priority jumping.
Best regards,
Alex