Inbound Calls Getting Busy Signal in CUCM

[Mason Bergman]

I am not receiving inbound calls with CUCM.  I have a call flow of CUCM ->Sip > CUBE -> Sip -> PSTN.  Outbound calls are working fine.  Inbound calls appear to be not getting past the CUBE. 

I'm trying to forward a DID to one DN/phone for now to keep it simple.  I've attached the output for the debug ccsip messages command at the CUBE.  I'm using a translation pattern on the CUCM to convert the DID to the DN.  I've also added the DID number to the DN as an alternate number, but neither of these has enabled inbound calling. 

The inbound dial-peer should be fine.  Thanks for any help.

[Manish Gogna]

Hi Mason,

A couple of thing that you can check under Incoming calls settings on the CUBE added on CUCM:

1. The Calling Search Space for Incoming calls should have access to the Translation pattern or DN

2. The significant digits entry should match the number of digits on Translation pattern

If you make any changes then reset the CUBE from cucm.

Manish

[Vivek Batra]

Apart from excellent suggestions by Manish, it seems from logs that call is not hitting CUCM and rejected by CUBE itself with cause 486 Busy. Can you share 'show run' and 'debug voice ccapi inout' to verify the actual cause....

- Vivek 

[Mason Bergman]

Thanks for the response.  The CSS and partitions have been left as default system-wide.  The ccapi inout debug is attached.  Is there a tutorial somewhere about configuring translation patterns in CUCM?  I would like to be able to verify this isn't the issue.

[Suresh Hudda]

Collected logs are not complete logs, first turn on logs (debug voip ccapi inout && debug ccsip error) and then make a test call and wait for call signaling to complete fully and then turn off.

You can have look in below youtube link for TPs in CUCM.

https://www.youtube.com/watch?v=ol-iYAzNPJk

Suresh

[Vivek Batra]

Hi Mason,

Also share 'show run' to verify the config.

- Vivek

[Ayodeji Okanlawon]

Mason,

From the logs I wouldn't worry about translation patterns just yet. This is because the logs show that the gateway is not sending the call out to CUCM.

CCAPI is sending the disconnect without initiating the outbound leg of the call.

Apr 7 04:33:38.707:  feature call basic
.Apr 7 04:33:38.707: //96142/BBB7F0C9B60D/CCAPI/ccCallDisconnect:
   Cause Value=17, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)
.Apr 7 04:33:38.707: //96142/BBB7F0C9B60D/CCAPI/ccCallDisconnect:
   Cause Value=17, Call Entry(Responsed=TRUE, Cause Value=17)

Please send us your sh run as requested by Vivek.

[Mason Bergman]

Here's my running config.  Thanks for taking a look.

[Carlo Poggiarelli]

Hi Mason,

Let's start adding a dialpeer to CUCM as correctly suggested by my buddies Deji Vivek and Manish(+5 each)

dial-peer voice 200 voip

destination-pattern 855226T

session protocol sipv2

session target ipv4:x.x.x.x (ip address of your cucm)

dtmf-relay rtp-nte

no-vad

Let us know 

Regards

Carlo

[Mason Bergman]

Thanks Carlo but no difference.

[Carlo Poggiarelli]

Can you please post a debug voip ccapi inout with suggested dialpeer configured?

Thanks

Regards

Carlo

[Mason Bergman]

It's attached.  It looks like the generic inbound dialpeer 1001 (.%) was picking it up before the 200.

[Ayodeji Okanlawon]

Mason,

Please lets try this..

dial-peer voice 1001 voip

 no incoming called-number . %

incoming called-number .

Then send us the output of the following..

show dial-peer voice summ

[Amit Sharawat]

Hi Mason,

Could you please collect both "debug ccsip all" and "debug voip ccapi inout" for a test call and upload. Need to check if the ccapi or sip layer is disconnecting it first.

~Amit

[Mason Bergman]

Here it is.  Thanks for the help.