cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
531
Views
0
Helpful
6
Replies

No incoming calls on new CUCM

lonmc1977
Level 1
Level 1

Hey, I'm new to the call manager world but I was tasked with installing one.  I installed a new CUCM 8.6 Pub/Sub over the weekend and we can make outgoing calls fine, but incoming calls I get a fast busy signal.  This all worked before on the old CM but Im not sure what would cause it.  My gateway is a 3845 T1 GW using MGCP.  The publisher kept the old IP but the Sub did not.  I changed the MGCP call agent to the new SUB IP, but thats about it.  I dont know if it helps at all but I attached a show MGCP dump.  Any info would be appreciated.

6 Replies 6

Hi, could you please give us more details? how the GW is connected to PSTN? do the inbound calls enter into GW?

if so, please provide the debug logs from the GW with calling & called number

//Suresh Please rate all the useful posts.

Here is a debug dump, it looks like theyre getting there?

N_637_3845_T1GW#sh run | i dial-peer

dial-peer voice 99910991 pots

dial-peer voice 99911991 pots

voip dialpeer inout debugging is on

N_637_3845_T1GW#term mon

N_637_3845_T1GW#

Nov 26 14:38:50: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:

   Calling Number=, Called Number=, Voice-Interface=0x7120DF0C,

   Timeout=TRUE, Peer Encap Type=ENCAP_VOICE, Peer Search Type=PEER_TYPE_VOICE,

   Peer Info Type=DIALPEER_INFO_SPEECH

Nov 26 14:38:50: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:

   Result=Success(0) after DP_MATCH_PORT; Incoming Dial-peer=99910991

Nov 26 14:38:50: //-1/xxxxxxxxxxxx/DPM/dpMatchSafModulePlugin:

   dialstring=NULL, saf_enabled=0, saf_dndb_lookup=0, dp_result=0

N_637_3845_T1GW#

Nov 26 14:39:16: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:

   Calling Number=, Called Number=, Voice-Interface=0x7120DF0C,

   Timeout=TRUE, Peer Encap Type=ENCAP_VOICE, Peer Search Type=PEER_TYPE_VOICE,

   Peer Info Type=DIALPEER_INFO_SPEECH

Nov 26 14:39:16: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:

   Result=Success(0) after DP_MATCH_PORT; Incoming Dial-peer=99910991

Nov 26 14:39:16: //-1/xxxxxxxxxxxx/DPM/dpMatchSafModulePlugin:

   dialstring=NULL, saf_enabled=0, saf_dndb_lookup=0, dp_result=0

Nov 26 14:39:55: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:

   Calling Number=, Called Number=, Voice-Interface=0x7120DF0C,

   Timeout=TRUE, Peer Encap Type=ENCAP_VOICE, Peer Search Type=PEER_TYPE_VOICE,

   Peer Info Type=DIALPEER_INFO_SPEECH

Nov 26 14:39:55: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:

   Result=Success(0) after DP_MATCH_PORT; Incoming Dial-peer=99910991

Nov 26 14:39:55: //-1/xxxxxxxxxxxx/DPM/dpMatchSafModulePlugin:

   dialstring=NULL, saf_enabled=0, saf_dndb_lookup=0, dp_result=0

Nov 26 14:40:11: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:

   Calling Number=, Called Number=, Voice-Interface=0x7120DF0C,

   Timeout=TRUE, Peer Encap Type=ENCAP_VOICE, Peer Search Type=PEER_TYPE_VOICE,

   Peer Info Type=DIALPEER_INFO_SPEECH

Nov 26 14:40:11: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:

   Result=Success(0) after DP_MATCH_PORT; Incoming Dial-peer=99910991

Nov 26 14:40:11: //-1/xxxxxxxxxxxx/DPM/dpMatchSafModulePlugin:

   dialstring=NULL, saf_enabled=0, saf_dndb_lookup=0, dp_result=0

Could you provide debug isdn q931 & debug voice ccapi inout please?

//Suresh Please rate all the useful posts.

debug isdn wasnt an option but debug ccapi was....heres what I got there

Nov 26 14:48:36: //19838/A6FE92D9953A/CCAPI/ccCallModifyExtended:

   Nominator=0x719A7AF0, Params=0x719A6D08, Call Id=19838

Nov 26 14:48:36: //19839/A6FE92D9953A/CCAPI/ccCallModify:

   Nominator=0x800, Params=0x719A6F10, Call Id=19839

Nov 26 14:48:36: //19838/A6FE92D9953A/CCAPI/cc_api_call_modify_done:

   Result=0, Interface=0x7120DF0C, Call Id=19838

Nov 26 14:48:36: //19839/A6FE92D9953A/CCAPI/cc_api_call_modify_done:

   Result=0, Interface=0x6A287F5C, Call Id=19839

Nov 26 14:48:36: //19838/A6FE92D9953A/CCAPI/ccCallReportDigits:

   (callID=0x4D7E, digit_event=0x0, enable=FALSE, consume=FALSE)

Nov 26 14:48:36: //19838/A6FE92D9953A/CCAPI/ccCallReportDigits:

   Enabled=TRUE, Call Id=19838

Nov 26 14:48:36: //19838/A6FE92D9953A/CCAPI/cc_api_call_report_digits_done:

   (vdbPtr=0x7120DF0C, callID=0x4D7E, disp=0, digit_event=0x0, enable=FALSE, consume=FALSE)

Nov 26 14:48:36: //19838/A6FE92D9953A/CCAPI/cc_api_call_report_digits_done:

   Enabled=TRUE, Disposition=0x0, Interface=0x7120DF0C, Call Id=19838

Nov 26 14:48:36: //19838/A6FE92D9953A/CCAPI/cc_api_call_report_digits_done:

   Call Entry(Initial Digit Timeout=4000(ms), Inter Digit Timeout=4000(ms))

Nov 26 14:48:36: //19839/A6FE92D9953A/CCAPI/ccGetCallStatistics:

   Call Stats=0x6A9AFD74, Call Id=19839

Nov 26 14:48:36: //19838/A6FE92D9953A/CCAPI/ccConferenceDestroy:

   Conference Id=0x26B7, Tag=0x0

Nov 26 14:48:36: //19838/A6FE92D9953A/CCAPI/cc_api_bridge_drop_done:

   Conference Id=0x26B7, Source Interface=0x7120DF0C, Source Call Id=19838,

   Destination Call Id=19839, Disposition=0x0, Tag=0x0

Nov 26 14:48:36: //19839/A6FE92D9953A/CCAPI/cc_api_bridge_drop_done:

   Conference Id=0x26B7, Source Interface=0x6A287F5C, Source Call Id=19839,

   Destination Call Id=19838, Disposition=0x0, Tag=0x0

Nov 26 14:48:36: //19838/A6FE92D9953A/CCAPI/cc_generic_bridge_done:

   Conference Id=0x26B7, Source Interface=0x6A287F5C, Source Call Id=19839,

   Destination Call Id=19838, Disposition=0x0, Tag=0x0

Nov 26 14:48:36: //19838/A6FE92D9953A/CCAPI/ccCallDisconnect:

   Cause Value=16, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)

Nov 26 14:48:36: //19838/A6FE92D9953A/CCAPI/ccCallDisconnect:

   Cause Value=16, Call Entry(Responsed=TRUE, Cause Value=16)

Nov 26 14:48:36: //19838/A6FE92D9953A/CCAPI/cc_api_get_transfer_info:

   Transfer Number Is Null

Nov 26 14:48:36: //19839/A6FE92D9953A/CCAPI/ccCallDisconnect:

   Cause Value=16, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)

Nov 26 14:48:36: //19839/A6FE92D9953A/CCAPI/ccCallDisconnect:

   Cause Value=16, Call Entry(Responsed=TRUE, Cause Value=16)is

Nov 26 14:48:36: //19839/A6FE92D9953A/CCAPI/cc_api_call_disconnect_done:

   Disposition=0, Interface=0x6A287F5C, Tag=0x0, Call Id=19839,

   Call Entry(Disconnect Cause=16, Voice Class Cause Code=0, Retry Count=0)

Nov 26 14:48:36: //19839/A6FE92D9953A/CCAPI/cc_api_call_disconnect_done:

   Call Disconnect Event Sent

Nov 26 14:48:36: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

Nov 26 14:48:36: :cc_free_feature_vsa freeing 71986928

Nov 26 14:48:36: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

Nov 26 14:48:36:  vsacount in free is 3

Nov 26 14:48:36: //19838/A6FE92D9953A/CCAPI/cc_api_call_feature:

   Feature Type=6, Interface=0x7120DF0C, Call Id=19838

N_637_3845_T1GW#debug is

Nov 26 14:48:36: //19838/A6FE92D9953A/CCAPI/cc_api_call_feature:

   Feature Type=6, Interface=0x7120DF0C, Call Id=19838

Nov 26 14:48:36: //19838/A6FE92D9953A/CCAPI/cc_api_call_disconnect_done:

   Disposition=0, Interface=0x7120DF0C, Tag=0x0, Call Id=19838,

   Call Entry(Disconnect Cause=16, Voice Class Cause Code=0, Retry Count=0)

Nov 26 14:48:36: //19838/A6FE92D9953A/CCAPI/cc_api_call_disconnect_done:

   Call Disconnect Event Sent

Nov 26 14:48:36: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

Nov 26 14:48:36: :cc_free_feature_vsa freeing 71985EA8

Nov 26 14:48:36: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

this is not giving enough details. the cause code 16 indicates the normal call clearance.

> check how the called number entering into GW (how many digits)

> Check the Inbound CSS, Significant digits & Prefix configurations under "Call Routing Information - Inbound Calls" in the MGCP endpoint configuration of CUCM

> you may also crosscheck and compare the ISDN related configurations between Old & New CUCM

for further troubleshooting, the CCM SDI traces in detailed level along with debug isdn q931 ( if it is isdn connection) is required.

//Suresh Please rate all the useful posts.

Sorry, I wasnt that clear, we arent using ISDN to get in/out we just have a t1 connection from our IP network, into a cisco 3845 GW that turns the IP net into a t1, then it goes to a base DSO that does all the 99,98 translation stuff going outbound.  Thats really my basic understanding of how were connected.

        But ill check the other stuff you suggested, thanks.