I have a CCR path that is programmed as an external transfer. The vm responds with "The line or pool you have chosen is invalid" when you make that selection via AA. I tried many things to troubleshoot this including rebuilding the path, resetting the system, changing pools, setting it to line, adding dialtone detect, pausing after ctx9, changing the dial string, checking vm port line access. I clipped on the line with a butt-set/digi-grabber, and it IS going off-hook and dialing the correct digits. But just as soon as it finishes dialing, it hangs up. Strangely enough, the *Talk version is 2.0.10.0 and the KSU is R1T1. Their versions are worlds apart, but it has been working fine for months. Once a month they change the external number in this path, but this time it just won't work. I have placed a digital set on the vm port, and can dial out without issue. It's a 4 port unit, and I've treated both extensions the same. The only thing I can come up with now is that the voice mail is damaged.
These are centrex lines, so two nines are required (one for pool) and one of those is in the dial string. I tried every combination, with and without External Code, no 9, one 9, two nines. Then I decided to choose pool 9; since it was letting me enter 4 digits for a pool number and you can have a four digit Line Pool Access Code...sure why not. The error message changed to "The line or pool you have chosen is busy." So I added a line to pool I, and tried again, this time getting the 'invalid' message again. That gave me the idea to put a test-set on that line. That's when I found that it was outdialing the correct digits. As soon as the last digit went out, it hung up and gave the error message (cell in one ear, test set w/digigrabber in the other). So I tried adding dialtone detect 'D' and pauses to the string. No difference. Writing this, I realize that I didn't try adding a pause to the end. I rebooted both units; no change.
With R1T1, I don't think I can call forward off-premise. I would prefer to send this CCR path to an internal extension that is forwarded off-premise. It would be much easier for the customer to change the forwarding number. I tried using line redirect, but it wouldn't work.
These are centrex lines, so two nines are required (one for pool) and one of those is in the dial string. I tried every combination, with and without External Code, no 9, one 9, two nines. Then I decided to choose pool 9; since it was letting me enter 4 digits for a pool number and you can have a four digit Line Pool Access Code...sure why not. The error message changed to "The line or pool you have chosen is busy." So I added a line to pool I, and tried again, this time getting the 'invalid' message again. That gave me the idea to put a test-set on that line. That's when I found that it was outdialing the correct digits. As soon as the last digit went out, it hung up and gave the error message (cell in one ear, test set w/digigrabber in the other). So I tried adding dialtone detect 'D' and pauses to the string. No difference. Writing this, I realize that I didn't try adding a pause to the end. I rebooted both units; no change.
With R1T1, I don't think I can call forward off-premise. I would prefer to send this CCR path to an internal extension that is forwarded off-premise. It would be much easier for the customer to change the forwarding number. I tried using line redirect, but it wouldn't work.
