Call Handler Not Reachable From Outside Call

[chrisbuchner]

Hi Experts,

I am sitting with an unique issue where my Auto Attendant works perfectly from inside the office, however it is not reachable from external calls.

Connection ISP > SIP > CUBE > SIP > CUCM

What I am seeing is as soon as I direct the call to CUC either via voicemail forward or CTI RP then when the external call comes in it gets directed back out to ISP and fails.

I have tried a dial-peer pointing the exact Directory Number to CUCM in order to force the selection but it immediately gets sent back out.

I get error 481 call leg/transaction does not exist and then obviously from the ISP side 404 not found.

If I remove the forward the number is reached as normal but as soon as it needs to be forwarded to CUC it fails

[b.winter]

Don't you think, that logs would help troubleshooting call routing issues?

[chrisbuchner]

My Apologies, Here is an output with debug ccsip all and debug voice ccapi all.

This is the flow of the call. 

Thanks for taking the time to assist.

[chrisbuchner]

10.170.117.5 - Cube

10.52.100.5 - CUCM

192.168.10.2 - ISP SBC

[b.winter]

Please also provide the corresponding CUCM trace of this call.
In my opinion, the debug output doesn't contain all the relevant SIP messages. The beginning of the call is not visible at all.
And pleeeease, don't mask any numbers or IP-address. It makes troubleshooting and correlating numbers / calls very difficult / impossible. E.g. how should you know, if any number translations really worked, if there is no info about the original number?

[chrisbuchner]

Hey b.winter, the numbers are masked because its real numbers and for a business. I do not translate any of the numbers from the cube only from the CUCM and the only translation happening is from 0 to E164 format. I have even tried without transformation letting the original number from ISP be reached as is and it still fails. I will try to get a CUCM trace as well!

[b.winter]

Do you really think, masking numbers in logs for this forum will prevent fraud calls to this company?
You are trying to "protect" information, which is publicly available on every company webpage ...

[chrisbuchner]

That is true, I was hoping there is an obvious "something" that I have missed or am missing with this since it works from internal.

I will get a fresh log with all of the call legs in it and keep the numbers open if that will help.

[Sajid Pasha Muhammad]

Hi @chrisbuchner 

Can you please share cube config?

I see you are sending 33XXXXXXX. To the sip gate. Is this what they are expecting? And the called number is 03XXXXXXX

Do you have translation pattern configured to convert the called number ?

Is there any called party transform mask for the incoming translation pattern? 

[chrisbuchner]

Hi Sajid,

See attached the cube configuration the configuration is a mess as I have been trying various things to get it to work the only dial peer that has to stay is the incoming dial peer 200 from ISP using URI without it calls can not be reached internally unless there is a better way to do it.

Thanks for checking.

[Maren Mahoney]

In your screengrab of TranslatorX, it shows the CUCM involved in this hairpinning call. If the call is reaching CUCM and is then redirected out to the PSTN, I'd look to CUCM first to figure out why an inbound call is being sent back out.

Have you tried the Dialed Number Analyzer, selecting "Trunk" and entering the calling and called parties as presented by the CUBE? What does it show?

Maren

[chrisbuchner]

Hi Maren,

Thank you for your response, From what I can see from the DNA is the following:

The number is registered on my CIMC and forwarded to Voicemail where it should be picked up by the Auto Attendant.

It also obviously matches the outbound patterns as well. The CSS also has the voicemail partition inside to reach CUC.

[Maren Mahoney]

If you take the CFWDALL off on the CIPC device and call the number, does the CIPC ring?

Do you have the ability to post a trace file (and you can send it in a private message to me) that includes this inbound call?

Maren

[chrisbuchner]

Correct if you remove the forward all the number rings and you can pick up the call no problem if you add the forward to another directory number it also works and calls are received.

You are on the right track I am almost able to figure this out this is the ladder:

I also see TERMINATION CAUSE CODE = 47 which indicates a possible MTP or Xcode resource needed on the Cube I am guessing?

[Maren Mahoney]

Okay. So for sure the problem is in CUCM/CUC and not the CUBE. That is good news.

First, if you have CFWDALL off but have the checkboxes for CFNA Internal and External checked so they go to VM, does rolling to VM work when calling the DN? Can you provide a screenshot of the Call Forwarding portion of the DN?

For CFWDALL: Do you have the checkbox for Voicemail checked or do you have specific information in the CFWDALL area?

Also, what is the pair of CSSes that are configured in your system for CFWDALL? 

Maren