CUCM call sequence and flow

[Bekzod Fakhriddinov]

Hi. If there is route pattern X  and it has RL with route groups A and B , also RP  X has Local route group C . By order in route list : A is first choice, B second, X is 3rd .

How CUCM will re-route calls (will it ?) in case of when not all calls failed on trunk A, but to specific prefixes ?? 

I have this problem when calls to some international numbers dropped via primary sip trunk but didn't go trough backup PRI (different Carrier ). 

Thank you

[Bekzod Fakhriddinov]

Gregory, so that CSS under Inbound Call is CSS/partitions available for incoming calls, right?  

If yes, then what are u telling me make sense - if it will point to internal partition only it will prevent loop . 

[Gregory Brunn]

Yes this is the inbound calling search space for the trunk. It typically only need internal access. Not always the case based on each deployment. I wouldn't change this now, I would just change the other parameter we talked about for testing.

[Ayodeji Okanlawon]

What is the status of your "sh isdn status" Is the E1 link up?

Can you send the ff output

sh run

debug ccsip mess

If the CUBE is not routing the call to the E1, then its either the E1 is down or the called number doesnt match what you have configured on the E1 dial-peer

[Gregory Brunn]

Great point my assumption was the E1 was on a different gateway all together and you were looking at CUCM to control via the routelist and route groups.

[Bekzod Fakhriddinov]

yup, PRI is in diff gateway , and  I am looking at CUCM to control via the routelist and route groups.

[Bekzod Fakhriddinov]

PRI is up, channels are idle . 

sho isdn status
Global ISDN Switchtype = primary-ni
ISDN Serial0/0/0:23 interface
dsl 0, interface ISDN Switchtype = primary-ni
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
Layer 3 Status:
0 Active Layer 3 Call(s)
Active dsl 0 CCBs = 0
The Free Channel Mask: 0x807FFFFF
Number of L2 Discards = 0, L2 Session ID = 180

sho controller T1
T1 0/0/0 is up.
Applique type is Channelized T1
Cablelength is long 0db
No alarms detected.
alarm-trigger is not set
Soaking time: 3, Clearance time: 10
AIS State:Clear LOS State:Clear LOF State:Clear
Version info FPGA Rev: 08121917, FPGA Type: PRK1
Framing is ESF, Line Code is B8ZS, Clock Source is Line.
CRC Threshold is 320. Reported from firmware is 320.
Data in current interval (532 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
51 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
51 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Total Data (last 24 hours)
0 Line Code Violations, 0 Path Code Violations,
8519 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,
8519 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

[Ayodeji Okanlawon]

okay please do test call and post the output of

debug isdn q931

debug voip dialpeer inout

debug ccsip message

and your sh run

[Bekzod Fakhriddinov]

I think u missed beginning, , PRI is on different gateway B and working as backup for primary SIP trunk on different CUBE A . When some calls fails on CUBE A CUCM is not re-rotuing calls to gateway B 

[Ayodeji Okanlawon]

Oh, so Greg is right. CUCM needs to reroute the call to the backup gateway in the route group. Did you check on the second gateway to see if cucm sent the call to it?

If CUCM is not sending the call, then we need to know why. You already said the stop routing on unallocated number is set to false, so next thing is to look at cucm logs..

Please collect cucm logs and send over if you can

[Gregory Brunn]

I might have missed where stop routing on unallocated was changed from true to false.

Can you confirm that you have done this and tested yet?

[Bekzod Fakhriddinov]

I'm sorry Gregory, I was called to meeting and could not reply to you. The ISP fixed issue on SIP trunk and I can't test it right now. But I am planning to create route pattern to non-existing prefix and send it to SIP after I change that Enterprise parameter you told me , so I think then ISP 1 will send me SIP 404 then CUCM will probably send it to my backup PRI .  I also need to look more closely to that CSS inbound on sip trunk , and  test it at night before i do it in production .

Thank you , I appreciate your help

[Bekzod Fakhriddinov]

that stop routing parameter is set to true , it takes time in our production to do any changes, sometimes approvement and "paper work" takes longer than work itself :D .  Which logs from CUCM I need to send you from rtmt ?