Stumper - Call forwards to a different extension

[dudecrush]

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?

 

[gnrslash4life]

Run a route plan report to make sure that DN doesnt exist in another partition.

Certifications:
A+
Network+
CCENT
CCNA Voice
TVOICE
CAPPS

 

[dudecrush]

Nada - all of our DN's are in the Null partition.

 

[whykap]

What about the forwarding rules in Unity? Something in there? Or the transfer rules in the user voicemail configuration page?

 

[dudecrush]

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.

 

[whykap]

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.

 

[gnrslash4life]

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

 

[phrk]

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

 

[dudecrush]

Thanks phrk - good call. I'll check that and post back here with what I find.

 

[dudecrush]

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

 

[GrandmaBeth]

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