Shared Voicemail

Status
Not open for further replies.
johnny

johnny

New Member
Apr 10, 2020
18
5
3
39
Hi @tfernandez I just pulled the latest git commit to our fusionpbx install and it works Great!! however the programmed button does not connect to the voicemail box, only the light emits when voicemail is present. Is this something you may implement in the future?
I really appreciate your hard work, thanks again. ;)
 
johnny

johnny

New Member
Apr 10, 2020
18
5
3
39
@tfernandez

Thanks for the update on Github

This is the message @tfernandez gave if anyone needs it for reference

hi @johnnyq thanks!


That feature should already be there. It requires the dialplan to be updated. You can either execute App Defaults or modify it manually.


To modify it manually, go to Dialplan > Dialplan Manager


Search for vmain


The second section will have a condition with a destination number of: ^(vmain$|^\*4000$|^\*98)(\d{2,12})$


Change that to: ^(vmain$|^\*4000$|^\*98|voicemail\+)(\d{2,12})$


Keep in mind the manual method will require you to add that on every domain


Dialplan - FusionPBX
 
I

Incubugs

Member
Apr 7, 2018
175
10
18
49
This is why i get the feeling that there is now that many people contributing to fusionpbx that they are just messing with stuff for the sake of it. One thing gets "improved" then 4 others break. I have given up trying to keep up with the 30 commits a day from various sources, just find a version that works for you then stick to it, and if you wanna add stuff fork it and do it yourself, its safer, unless your a member if you do have issues they will not talk to you at all.
 
T

tfernandez

Member
Oct 31, 2019
37
11
8
31
@KNERD That might make sense since I don't believe the updater will update the LUA scripts that I wrote.

Try going to my PR Files changed which will show you all the files that I made modifications to. Make sure that your system has those files.
 
V

viiiwonder

Member
Sep 24, 2022
49
2
8
41
So, in general... this is all working for me (on a Yealink T53W), EXCEPT that after a reboot or re-register, no BLFs that I believe to be provided by BLF_Subscribe.lua are available. They come up as 'blank' (not lit). This applies to BLFs for both 'voicemail+[ext]' and 'flow+[ext]'. In either case, if I change the 'state' of either (by leaving or checking a voicemail, or toggling the flow respectively), they both then get updated to the current state (no voicemail, or current state of the Call Flow) indicated by a red or green LED.

I'm very concerned about this as if a customer's phone were to reboot they might not realize they have a voicemail in the 'shared' BLF based voicemail, or realize that the Flow is currently in 'night mode'.

(Sorry to tack on the 'flow' concept to this thread, but I can't help but think that this is related to some people's reports that this isn't working.)

For the record, upon following your guidance on github to uncomment log.debug(event:serialize()) in blf_subscribe.lua, I have very little blf or subscribe entries in my log at all (assuming the web based Status>Log Viewer is the appropriate place to check). This is all I really found:

2022-09-29 01:43:32.985708 65.27% [NOTICE] switch_cpp.cpp:1465 [voicemail] 2022-09-29 01:43:32.985708 65.27% [DEBUG] switch_cpp.cpp:1465 [presence] turn_lamp: voicemail+198@test.[pbxurl].com - true(boolean)

I'm not sure how to check the status/state of blf_subscribe script.

Is the expected behavior only to update subscriptions when the state changes? The subscriptions can't get the state of the object when the phone registers?
 
Last edited:
V

viiiwonder

Member
Sep 24, 2022
49
2
8
41
So, for the record: the reason that this wasn't working for us was because of two things:
1: [scripts_dir]/run/ did not exist. As such, many of the startup scripts were actually failing to run. I know that some scripts actually create this if it doesn't exist. I'm assuming that whichever script was 'first' was failing to create it. I manually created it on our filesystem and suddenly all sorts of new behaviors started (as results of the now running startup scripts).
2: the changes implemented by the PR/feature listed in this thread ('voicemail+[ext]') BLF configuration was not working for us. After much debugging, we determined that the SQL query listed in blf_subscribe.lua for the purposes of determining if there was an unread VM was wrong/not pulling the desired result. We looked to see what happens when you dial the voicemail box main_menu.lua uses a completely different WHERE statement in its SQL. We modified blf_subscribe.lua to emulate it.

As such, I signed the contributor agreement and have posted this PR: https://github.com/fusionpbx/fusionpbx/pull/6482

A spot to store/call common queries seems like a logical method of fixing this for future possible regressions if ever the schema or other changes are made... but this isn't a development forum, so I'll keep that short.
 
Status
Not open for further replies.
Top Bottom