Call getting redirected

[ziqex]

Hi,

I encountered weird issue in call manager environment.

When I call the number 3962, the call is redirected to extension 3943. 

There is no forwarding set on the line. I used dialled number analyzer but it is showing that calls goes to 3962.

There is also no translation done on the voice getaway. Issue is present for internal and external call for this specific extension.

No issues with extension 3963 or 3961 which share the same configuration.

Any ideas?  

System version: 12.5.1.14900-63 Unrestricted

Thank you.

Regards.

Daniel

[Maren Mahoney]

Go to the Route Plan Report and do a Find for all patterns that "Contain" 3962. It looks to me like a translation pattern might be in the mix.

If that doesn't show anything, take another look in your DNA output under "Alternate Matches" (or is it 'Additional Matches'?) to see if CUCM is seeing anything else.

If you still don't see anything, would it be possible for you to capture a trace file for the CallManager service that contains this call and post that?

Maren

[ziqex]

Route plan report for 3962 displays one entry directory number 3962.

DNA shows:

• Alternate Matches
• Note: Information Not Available

 Is the trace that you are referring to collected via RTMT?

Thank you.

[Nithin Eluvathingal]

As @Maren Mahoney  mentioned, Check if any alternative match on DNA. And also Have a look on dial plan report. 

[ziqex]

I've collected the traces and after opening could see the below entries:

|3962|3943|SME-CLS-TRUNK|

|3962|3943|

Thank you

[Roger Kallberg]

Apart from any one with insight into your specific system that information would not mean anything.

[Maren Mahoney]

That looks like a line from the call log rather than the trace file. I'd need to see the sdl file (you can send it to me privately rather than post it here if you prefer), along with the originating device MAC address and DN and the original dialed number. From there I can figure out what's going on.

Maren

[ziqex]

I've open sdl trace and could see the below:

57385215.001 |17:35:30.857 |AppInfo |Forwarding - processingCFA_SsCallInfoRes - callKey= 0x1277
57385215.002 |17:35:30.857 |AppInfo |Forwarding - saveCallInfo, callKey= 0x1277
57385215.003 |17:35:30.857 |AppInfo |Forwarding - saveCallInfo: mServedUserDn set to cdpn
57385215.004 |17:35:30.858 |AppInfo |Forwarding - getMaskedDn - maskedDn=[3943] dn=[3962] mask=[3943] URI=[false]

Assume the output should not contain the 3943 

Thank you

Regards,

Daniel

[Maren Mahoney]

From that small bit of SDL it looks like whomever is at 3962 set Call Forward All to go to 3943. You can turn that off on the DN configuration page or at the phone.

That's all I can tell from what you have shared. If the Call Forward All is not the culprit, then you'll need to look elsewhere for the cause. (If you'd like my assistance, I'll need the full trace file which, again, you can post to me privately via a private message.)

Maren

[ziqex]

We had a go at directly querying the db – still cant find this. There was no redirection present. 

We decided to raise with TAC and waiting for their advice. I will share the solution once the issue is resolved.

It looks almost like a ghost entry which does not make much sense. 

[ziqex · Accepted solution]

It looks like the issue is now resolved.

TAC suggestion after long investigation was to restart Cisco CallManager service on all nodes.