call 456 and see if it the VM answer. for debugging there are two tools, first is system status. go to the active call then call 456 and watch the call path. if you are not able to see the problem then start call monitor software under the IP office tab. clear screen than call 456 and post the log.
This is how the system works and it makes sense, if it followed forwards and went to the mailbox it happened to be ringing at, at the time, then messages could be left for the completely wrong people. And if multiple users forward to the same place who was it actually for? It would end up a total mess so they kept it simple and it always goes to the original targets mailbox....as it should
Riddle - no work around? employee leaves and customer wants all calls dialed to that ext sent to new ext that will handle the call... if they don't answer - its RNA.....so now they must check 2 Mailboxes?
Either way it can be made to do what he wants, just embedded requires using shortcodes and forwarding to those shortcodes etc, problem being (with either vm type) if the user being forwarded to also wants to retain the use of their own mailbox, this can be sorted with pro but not embedded
I have it working on several of my customer. in fact I have that if 456 doesn't answer it will call the cell if the cell doesn't answer the VM for 456 pulls the call back and answers the call.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.