sundance-communications.com/forum Forums TDM Business Telephone Systems Toshiba Telephones & Systems transfer to ext/VM being recalled intermittently

hello,

on a few occasions now one of our receptionists has tried to transfer a caller to an ext or directly to VM only to have the call recall to their phone after (not sure about the timing) 30-45 seconds. this will happen 3 or 4 times in a row (to the same call) before they just give up and take a message. the issue has happened to each of the receptionists, so i don't think it's an issue with one of the recept exts in particular.

my first thought was all the VM ports were busy, but i looked at the iES32's port log and it says there has been 0 seconds where all 4 ports were in use simultaneously (only 180s when 3 where in use, even).

so i'm looking at the CIX -- the ext being transferred to (it was the same one each time - i don't know if this is a coincidence, or if its just that she gets the most calls) is an IP phone on the local network which has a unique SCF (all options set to fwd to 8 as destination 1 - set up because the installer had it configured that the calls would bounce back to main line if the phone wasn't plugged in).

i looked at the recall timers on the receptionist's phones, but they match everyone elses and i'm pretty sure they're all defaults.

other info: the receptionists are both on a serial hunt group (0 hunts to recept1 to recept2 to VM); strangely, when either of them calls another extension, it shows the HG DN instead of the PDN of the phone. and they are both part of 2 separate MCGs (trunk to MCG on incoming lines that ring the recept phones in a certain orders depending on the day/night mode).

sorry that was so long... i'm just not sure what information is/isn't relevant to this issue, or even what triggers this.

thoughts? ideas?

thank you!!

Do you have a VM ID set for the users phone?

make sure that all voicemail ports have line access to all lines answered and transferred by this receptionist group. Any line which might be disallowed wouldn't transfer and would eventually recall the transferring extension after the transfer timer expires.

Does this happen when the target phone is busy? Is the receptionist using a dss key with the vm transfer key?

amy - yes, she has both a 1nn PDN and 5nn pilot, which the receptionists tried alternately, with the same result.

bbcfoneguy - i understood what you said, but am missing details: all 4 VM ports are in the same iES32 group (Q1); in the CIX, 6 of our 7 lines are in OLG 1, our 7th line is the end of the hunt group and is in OLG 0 - all 7 are in ILG 1; all 4 VM port PDNs appear to be set to access the same lines as the phones, but i'm not entirely sure that i haven't missed something there. **

phonemeister - its happened both B and NA. no, we just "CNF/TRN nnn". none of our phones are set up for DSS.

** i did however notice that 233-Originate OCA is set to enable, even though the tooltip for that says it should be disable for VM & auto-attendant ports. this setting was set (or more likely left default) by our installer. could this be the issue or aggravating the issue?

thank you all for the help - i keep feeling like i have the most obscure issues with our system; i don't know what i'd do without everyone here.

The test for my idea - have the receptionist tell you next time which trunk recalled without transferring - she can id the trunk by momentarily putting the caller on hold and the trunk will be displayed. Once you know the trunk, try to access that specific trunk from all 4 voicemail ports with a test set and from the extension to which she was trying to transfer the call. If you can access the trunk from all 5 stations, my theory is debunked. If one of the ports cant access the line then look into line access restriction for that port.

If the receptionist is using the cnf/trn #407 to transfer to voicemail, she might be forgetting to enter a # at the end which will cause the call to recall to her. As for the call being recalled when transferred to an extension, check the system call forward template and let us know what is checkmarked.

bbcphoneguy - i have them watching for this.

phonemeister - we've never needed to use # after the ext when transferring before. we just [CNF/TRN] 523 (hang up) for example. if i understand you correctly we should be [CNF/TRN] 523# (hang up).

the ext in question (plus the 2 other IP phones) are on a special SCF: every status/call type combination is set to destination 1: 8 (our VM), no dest 2.

originally, our installer set it to:
CO Loop Grd - B, NA, BNA - dest 1: 8
Ring Transfer - B, NA, BNA - dest 1: 8
Internal - B, NA, BNA - dest 1: 8
all other dest 1: empty
all dest 2: empty

but i found that it would bounce the caller back to the main menu if the IP phone was unplugged / not logged in.

"phonemeister - we've never needed to use # after the ext when transferring before. we just [CNF/TRN] 523 (hang up) for example. if i understand you correctly we should be [CNF/TRN] 523# (hang up)."
That's correct if you're transferring a call to the extension. But to do a voicemail transfer (CNF/TRN #407), you have to finish with a pound after entering the extension number.

"originally, our installer set it to:
CO Loop Grd - B, NA, BNA - dest 1: 8
Ring Transfer - B, NA, BNA - dest 1: 8
Internal - B, NA, BNA - dest 1: 8
all other dest 1: empty
all dest 2: empty"
You can't set B,NA, and BNA at the same time in system call forward even though it lets you. You can set only one. And why would you? Just set BNA and that'll cover it.

phonemeister - when i add the # after the extension, it jumps *straight* to the VM, like right to the beep, no "sorry i missed your call" message, and if you don't hang up in time the caller never even hears the beep, just dead line (although it is recording, which made for a couple hilarious messages when we were testing it yesterday).

is there a timing/don't skip sort of setting in the iES32?

re: SCF -- i always thought that was a might odd. i set the IP phone SCF to only BNA/DND:8.

thanks!