[cisco-voip] Forwarding dials wrong number

[Bob Fronk]

Yes, sorry, I should have included that.  He is dialing 9 + the 7 digit number of his cell phone.

BF


From: Jim Reed [mailto:jreed at swiftnews.com]
Sent: Wednesday, May 11, 2011 6:04 PM
To: Bob Fronk; cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Forwarding dials wrong number

Starting with the simple stuff, is the user putting a 9 - or whatever your outside dialtone code may be - in front of the 555-1234.  Depending on the calling search space that extension 1107 is configured for is where the dialtone for the outside call will be generated from.  If 1107 is in the same calling search space as 6102 then the dialtone will be generated from Site B.  Just looking at the simple stuff first.
--
Jim Reed
970-384-9141 (Direct)
775-772-7666 (Cell)



On 5/11/11 3:14 PM, "Bob Fronk" <Bob at btrfronk.com<mailto:Bob at btrfronk.com>> wrote:
CUCM 6.1.2

We are seeing an issue when an employee forwards his extension to his cell phone.

Site A is in area code 123.  User forwards extension 1107 to his cell phone at 555-1234.

Site B is in area code 456.  User in Site B is extension 6102.

User at Site B calls the user in Site A.  The forwarding number is dialed, but as a local number to Site B instead of the local number in Site A.  As it happens, these two areas have an exchange that is the same, even though they are in different States, so the number dialed is a local number, but it is the wrong area code, so this harasses some innocent person that is getting all his calls.

If callers from Site A call extension 1107, the call forwards to the user's cell phone as expected.

I am not sure how to solve this issue.

Any help or ideas appreciated.

PS - I am a novice in voice and need to try and resolve this without bringing an outside vendor.  Thanks for anyone's help.


Bob Fronk
bob at btrfronk.com<mailto:bob at btrfronk.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20110512/6c917535/attachment.html>