I've got another issue for the forums. I've thought this one through pretty well, and I'm stumped at the moment.
Netvanta 7100 & UC Server setup. Dialing rules are in place to strip off the area code for local calls. That way we can just dial seven digits when calling locally, which is what most people are used to. We also have dialing rules in place so you don't have to dial 9 to get out first. You can just pick up the phone and dial your number; anything starting with a 7 is presumed to be a local extension. All our extensions are 7### format numbers. (Primarily 7001-ish through 7099 for individual phones, and 71## series for ring groups.)
I forward my calls, after a number of rings, to my mobile phone. The beginning of my external 7 digit number is 4. Like: 4##-####
Another employee liked this setup and got a mobile phone to forward her calls to. She happened to pick a number beginning with a 7. Like: 7##-####
When I set up the exact same forwarding rule that I use for my phone (which works fine) for her, she gets a busy signal after it rings over to her mobile phone. Note, her mobile phone never actually rings; the caller just hears a busy signal after the designated number of rings.
Calling her mobile phone directly from the office also results in a busy signal, whether we include the area code prefix (which gets stripped anyway since it's a local call) or not.
My best guess is that the system is treating her 7##-#### external number as a local extension that it can't find and is doing what it otherwise does, serving up a busy signal.
So, I'm thinking it is a case of an unfortunate external number being chosen. I'm not aware of any 7##-#### numbers in the general area (although I could be wrong these days, since the first 3 of the 7 digit number aren't as relevant as they used to be with the advent of mobile phones).
Is there a dialing rule I can add somewhere that would tell the UC Server to ignore the other dialing rules (maybe not stripping the area code, or adding a 9 or something) for just her mobile number specifically? That seems like the best bet at the moment. I'll probably have to post the dialing rules in place on here when I get to work. Just curious if I'm on the right track with this.
Brian, please post a screen shot of the dialing rules you have set up. I assume the forward is being done through a service on the UC server? Thanks
Sorry for the delayed response, and thanks for yours! Here are the dial plan rules and yes, they are going through the Netvanta UC Server. I had to break them into four screen shots to get them all visible (couldn't resize the scroll area).
I also tried to play around with some dialing rules yesterday, but didn't really get anywhere. At best I get a busy signal and at worst I get a 404 error (over the phone). I've tried forwarding to another number (starting with 4##-####) and that works fine. So I figure it must be the unfortunate choice by the end user of a "7" for the beginning of the prefix.
Brian, do you have an extension on the system starting with the same first 4 numbers as the number she's trying to forward to?
I don't believe so...
It's 799-0### and I think there's a 7999 extension for...perhaps call recording or paging? (Those features aren't in use by anyone.) Let me double-check that.
Ok, "Page All" is extension 7999 and the first four (excepting area code) of her number are 799-0###. So that's ###-799-0###.
I don't believe anyone uses the page all function; I'm not sure it's fully set up in the first place.
Brian, if there's nothing overlapping the first 4 digits entirely, I wouldn't expect a match. I'd suggest opening a ticket with support. This is likely going to require live debugging and looking at some logs to track down. Thanks
Well, thanks for the info regardless! At least that lets me know I'm not overlooking something obvious or missing a dialing rule I should be able to implement.
It has to do with that unfortunate 7 in the prefix. At least I know to elevate the issue to support - which should save me some time trying to figure it out myself.
Anyway, thanks again!