Im trying to xfer calls to vm by dialing *<ext>. I can xfer the call to voicemail if I release before the voicemail pilot picks up. But if the voicemail pilot answers, you cannot transfer the call (it rings you back).
The easiest way I find if you do not have a lot of extensions is to program hunt groups that equal *+ext and then reroute always to voicemail using the CALL REROUTE ASSIGNMENT form. The embedded voicemail does not recognize the * or # so it only recognizes the 0-9 digits that equal the mailbox. Greeting for that mailbox will start immediately, so release or hangup your phone quickly!
Also how is *<ext> programmed
- Speedial?
- Phantom DN Forwarded to VM?
- Phantom DN forwarded to speedial?
- Any of 100 other scenarios?
Just guessing here, but your symptom reminds me of an issue with an SX200 with a phantom DN forwarded to a speeddial that terminates to an inband integrated voicemail.
*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
yea that part is the issue. I have some how would you put it....."high turnover rate employees" which basically means quickly is not in their vocab. Do you know why it rings back so quickly. or whats happening to make it ring back?
I have it setup where a user ext is programmed on a phontom pkm with a * before the ext. The call rerouting always for this extension goes to my voicemail pilot number.
After calling support, they recommended creating a hunt group in the same fashion (with a * before). Then create a new COS for the HG that has a Call FOrward no answer of 2 seconds. We will also Call reroute always this to the VM pilot. THis will give the employee time to hang up without having to turn into Flash Gordon.
On a 3300 with embedded mail this should work fine.
I suspect that some COS option is enabled on the VM that is preventing this from working.
What happens if a user just dials the code (no transfer)?
You might want to check your COS options enabled on the voicemail against the "defaults applied to the 3300 ICP by the config wizard" Help File search term "Configuration Wizard"
*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
Check the interconnect restriction (IR) and COR of the VM ports. When you are ring the VM Pilot it is the hunt group IR and COR that is checked when the transfer occurs. After the VM port has answered it is the VM port's IR and COR that is checked and if it fails it will cause the recall to ring the transferring party back.
Ok I found it. I imagine there was some kind of interconnect issue. I just changed the COS options called
Override Interconnect Restriction on Transfer. After this it worked fine.
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.