I have some remote users who have VoIP phones in their offices and use Zulu Desktop or WebRTC when they’re traveling. They have a somewhat unreliable ISP; so their hardware phones occasionally lose connection to the server. I’ve discovered that when I call their extensions, FreePBX only checks for their primary client. If their primary client is offline the call is routed to voicemail; regardless of whether they are available on Zulu or WebRTC. Anyone have an idea of how to work around this limitation? I’m currently using Extension mode – perhaps it will work differently under Device & User mode?
This doesn’t actually surprise me. The specifics of how the other clients (Zulu or WebRTC) connect to the extension you are calling would be important, but it sounds like the timeout for the local voicemail is grabbing the call and disabling your attempts to continue the call.
The logs for a call that fails would probably help, since the routing of the call through to voicemail or another extension should be documented in there.
Looking at the logs a little closer, I think there might be some configuration files with errors. Here’s a section of the log of a call from 8300 to 8399 (I removed some of the detail from the log line to keep them shorter):
[14:14:18] pbx.c: Executing [dstring@macro-dial-one:2] Set("PJSIP/8300-00000035", "DEVICES=998399&908399&8399") in new stack
[14:14:18] pbx.c: Executing [dstring@macro-dial-one:3] ExecIf("PJSIP/8300-00000035", "0?Return()") in new stack
[14:14:18] pbx.c: Executing [dstring@macro-dial-one:4] ExecIf("PJSIP/8300-00000035", "0?Set(DEVICES=98399&908399&8399)") in new stack
[14:14:18] pbx.c: Executing [dstring@macro-dial-one:5] Set("PJSIP/8300-00000035", "LOOPCNT=3") in new stack
[14:14:18] pbx.c: Executing [dstring@macro-dial-one:6] Set("PJSIP/8300-00000035", "ITER=1") in new stack
[14:14:18] pbx.c: Executing [dstring@macro-dial-one:7] Set("PJSIP/8300-00000035", "THISDIAL=") in new stack
[14:14:18] pbx.c: Executing [dstring@macro-dial-one:8] GosubIf("PJSIP/8300-00000035", "1?zap2dahdi,1()") in new stack
[14:14:18] pbx.c: Executing [zap2dahdi@macro-dial-one:1] ExecIf("PJSIP/8300-00000035", "1?Return()") in new stack
[14:14:18] pbx.c: Executing [dstring@macro-dial-one:9] GotoIf("PJSIP/8300-00000035", "1?docheck") in new stack
[14:14:18] pbx_builtins.c: Goto (macro-dial-one,dstring,14)
[14:14:18] pbx.c: Executing [dstring@macro-dial-one:14] GotoIf("PJSIP/8300-00000035", "1?skipset") in new stack
[14:14:18] pbx_builtins.c: Goto (macro-dial-one,dstring,16)
[14:14:18] pbx.c: Executing [dstring@macro-dial-one:16] Set("PJSIP/8300-00000035", "ITER=2") in new stack
[14:14:18] pbx.c: Executing [dstring@macro-dial-one:17] GotoIf("PJSIP/8300-00000035", "1?begin") in new stack
[14:14:18] pbx_builtins.c: Goto (macro-dial-one,dstring,7)
[14:14:18] pbx.c: Executing [dstring@macro-dial-one:7] Set("PJSIP/8300-00000035", "THISDIAL=") in new stack
[14:14:18] pbx.c: Executing [dstring@macro-dial-one:8] GosubIf("PJSIP/8300-00000035", "1?zap2dahdi,1()") in new stack
[14:14:18] pbx.c: Executing [zap2dahdi@macro-dial-one:1] ExecIf("PJSIP/8300-00000035", "1?Return()") in new stack
[14:14:18] pbx.c: Executing [dstring@macro-dial-one:9] GotoIf("PJSIP/8300-00000035", "1?docheck") in new stack
[14:14:18] pbx_builtins.c: Goto (macro-dial-one,dstring,14)
[14:14:18] pbx.c: Executing [dstring@macro-dial-one:14] GotoIf("PJSIP/8300-00000035", "1?skipset") in new stack
[14:14:18] pbx_builtins.c: Goto (macro-dial-one,dstring,16)
[14:14:18] pbx.c: Executing [dstring@macro-dial-one:16] Set("PJSIP/8300-00000035", "ITER=3") in new stack
[14:14:18] pbx.c: Executing [dstring@macro-dial-one:17] GotoIf("PJSIP/8300-00000035", "1?begin") in new stack
[14:14:18] pbx_builtins.c: Goto (macro-dial-one,dstring,7)
[14:14:18] pbx.c: Executing [dstring@macro-dial-one:7] Set("PJSIP/8300-00000035", "THISDIAL=PJSIP/8399") in new stack
[14:14:18] pbx.c: Executing [dstring@macro-dial-one:8] GosubIf("PJSIP/8300-00000035", "1?zap2dahdi,1()") in new stack
I see now that out of the three iterations only one has a channel ( THISDIAL=PJSIP/8399 ) it looks like WebRTC and Zulu channels aren’t getting set properly. I’ll try taking away Zulu and WebRTC and putting them back in to see if updates the config.
Yep. Not sure what happened, but when I disabled Zulu for one user and then re-enabled it, suddenly all of the Zulu extensions started working.
– spoke too soon. They worked for a short while and then stopped.
Making progress… it appears that most of the Zulu extensions aren’t showing up in the hints (Subscriptions) for their extension. The few that do work correctly.
I decided to do all the system updates and reboot before I looked deeper at the problem. Not sure what caused the problem; but now that everything’s up to date and fresh it’s fine.
P.S. – Things started going wonky with the FreePBX 13 to 14 upgrade.