Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Stumper - Call forwards to a different extension

Status
Not open for further replies.

dudecrush

IS-IT--Management
Apr 2, 2007
468
US
DN 031-6841 will forwarded to the voice-mail of 021-7601 if the line for 031-6841 is busy. However, there is no forward in either:
a) The Line settings of DN 031-6841
b) Alternate extension on voice-mail for 031-6841
c) No CTI route point
d) No translation pattern

Can't think of what else is causing this. The end-user swears that there is no call forward on the phone. Any ideas?
 
Run a route plan report to make sure that DN doesnt exist in another partition.

Certifications:
A+
Network+
CCENT
CCNA Voice
TVOICE
CAPPS
 
Nada - all of our DN's are in the Null partition.
 
What about the forwarding rules in Unity? Something in there? Or the transfer rules in the user voicemail configuration page?
 
I checked all that stuff yesterday. I Didn't see a thing.

031-6841 is on 6 phones. The best I can think of is that there is a manual forward on one of these phones to 021-7601. I would've thought, though, that it would've shown on the line settings.
 
yes it will show in the admin page forwarding settings. But it would ring the forwarded phone first, then go to the originating voice mail by default.
 
Best thing to do is to replicate it, and then pull CM and Unity logs. You should see what is happening then.

Certifications:
A+
Network+
CCENT
CCNA Voice
TVOICE
CAPPS
 
That is a good one. You may want to check if DBreplication looks ok in RTMT, CUCM reports, or CLI. I had a similar situation where calls were forwarding even though I had removed it in CUCM Admin and it looked like it was no longer configured. The CUCM Subscriber to which the phone was registered wasn't running the same config as I could see in CUCM admin. Restoring dbreplication fixed the issue. If that isn't it, did you try to review CM logs in RTMT as gnrslash4life suggested to see what it thought was going on? THX
 
Thanks phrk - good call. I'll check that and post back here with what I find.
 
Well - db replication seems to be OK

Cluster Replication State: Replication status command started at: 2016-03-16-15-34
Replication status command COMPLETED [highlight #FCE94F]603 tables checked out of 603[/highlight]
No Errors or Mismatches found.

Use 'file view activelog cm/trace/dbl/sdi/ReplicationStatus.2016_03_16_15_34_13.out' to see the details

DB Version: ccm9_1_2_12900_11
Repltimeout set to: 300s
PROCESS option set to: 1

Cluster Detailed View from ablcucmpub01 (3 Servers):

PING CDR Server REPL. DBver& REPL. REPLICATION SETUP
SERVER-NAME IP ADDRESS (msec) RPC? (ID) & STATUS QUEUE TABLES LOOP? (RTMT) & details
----------- ------------ ------ ---- -------------- ----- ------- ----- -----------------
ablcucmsub01 172.17.5.9 0.429 Yes (3) Connected 0 match Yes (2) Setup Completed
ablcucmpub01 172.17.5.25 0.064 Yes (2) Connected 0 match Yes (2) PUB Setup Completed
ablcucmsub02 172.19.5.9 2.031 Yes (4) Connected 0 match Yes (2) Setup Completed
 
Have you tried the Dialed Number Analyzer in the Cisco Serviceability? That tool has proven to be priceless to me when troubleshooting call flow and patterns. -Beth
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top