CUBE dial-peer busyout warning

[CUCM55120]

Hi,

We have two CUBEs that are at separate sites but linked on our WAN and are providing SIP-PSTN access for our single CUCM cluster. From what I can tell the CUBEs are basically mirrored config of each other aside from IP addressing and dial peer preferences so they are set to prefer routing calls to the CM nodes that are on the same site/building as that particular CUBE first with the nodes at other sites as back up.

On Solarwinds one of the dial peers on one of the CUBEs is constantly reporting as being in a warning state. When looking at the dial peer summary on the CUBEs two of the CUCM node dial peers are in busyout state (one of them being the one causing the warning on Solarwinds). When looking at the stats for these dial peers they have never routed any calls. The CUCM nodes these dial peers are pointing to are up and CM is enabled on them. On the other CUBE the dial peer summary reports the same CM nodes as active so not sure why it is like this on one CUBE only? I didn't really have much involvement when our SIP provider set up the CUBEs so trying to understand the reason these are like this and how I can get to the bottom of it?

Thanks.

[R0g22]

Are your dial-peers configured with OPTIONS keepalive ? Do you have any buffered syslog warnings when you do a "show logg" ?

[CUCM55120]

HI Nipun,

Yes keepalive is configured on all dial peers:

 'voice-class sip options-keepalive'

From show dial-peer voice XXXXX

'voice class sip options-keepalive up-interval 60 down-interval 30 retry 5'

The dial-peers that are coming back as busyout on one CUBE are configured on the other CUBE in the exact same way (apart from preference is changed around) and are reporting back as active.

Thanks.

[R0g22]

Interesting. Are both the CUBE's running the same IOS ? On the problematic CUBE, can you do a "show logg" and attach it here please ?
We might need to take a SIP debug to see why is the dial-peer not being brought into active state. If the CUBE is getting a response from the destination specified on the dial-peer, it should be brought back into service by CUBE aka ACTIVE state.

[Rob Garcia]

Hello, I know this is an old post but were you able to get this resolved?

We are having the exact same issue with our vCUBEs. We have the same IOS on both routers and same configuration. 

[Justinwong19918]

Hi Guys 

Is it the issue resolved ? i have the same issue. 

DC-RT-SIP-TEMP#show dial-peer v summary
dial-peer hunt 0
AD PRE PASS SESS-SER-GRP\ OUT
TAG TYPE MIN OPER PREFIX DEST-PATTERN FER THRU SESS-TARGET STAT PORT KEEPALIVE VRF
301 voip up up 1234 1 syst  ipv4:xx.xxx.xxx.xx2                                                          busyout NA
302 voip up up 1234 2 syst ipv4:xx.xxx.xxx.xx2                                                          busyout NA

[Roger Kallberg]

Hi Justin

Please share your running config and also the output for debug ccsip message. Also if you could share a screenshot of the SIP trunk and SIP Profile configuration in CM that would be of help.

[JustinWang777]

dial-peer hunt 0

             AD                                    PRE PASS SESS-SER-GRP\  OUT

TAG    TYPE  MIN  OPER PREFIX    DEST-PATTERN      FER THRU SESS-TARGET    STAT PORT    KEEPALIVE    VRF

301    voip  up   up             1234               1  syst ipv4:10.222.1.10              busyout    NA                 

302    voip  up   up             1234               2  syst ipv4:10.223.1.10              busyout    NA                 

250    voip  up   up             4321               0  syst dns:iptel.net           active     NA                 

251    voip  up   up             4321               0  syst dns:iptel.net           active     NA                 

101    voip  up   up                                     0  syst sip-server                            active     NA                 

100    voip  up   up                                     0  syst sip-server                                            NA                 

99     voip  up   up                                       0  syst sip-server                                            NA           

[JustinWang777]

#Call Flow: ITSP à CUBE à CUCM à IP Phone

We enabled the debugs, made a test call and collected the logs and we found the following:

Outgoing Dial-peer selected is 301:

010800: May 27 09:57:39.902: //10635/C063CC29ABF4/CCAPI/ccIFCallSetupRequestPrivate:

   Interface=0x3F63BBA4, Interface Type=3, Destination=, Mode=0x0,

   Call Params(Calling Number=0046623423,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),

   Called Number=+61863111111(TON=Unknown, NPI=Unknown), Calling Translated=FALSE,

   Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE, Outgoing Dial-peer=301, Call Count On=FALSE,

   Source Trkgrp Route Label=, Target Trkgrp Route Label=, tg_label_flag=0, Application Call Id=)

#No response as the dial-peer was in BUSYOUT state:

010827: May 27 09:57:39.902: //10636/C063CC29ABF4/CCAPI/ccCallDisconnect:

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

010828: May 27 09:57:39.902: //10636/C063CC29ABF4/CCAPI/ccCallDisconnect:

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

[Roger Kallberg]

Please provide the asked for information in full. FYI there is no need to do any call to see the SIP option ping in the debug asked for. This will be sent periodically by both CM and GW if enabled.

[joe_sinclair]

I doubt you still need help with this after 18 months Justin but future viewers of this thread might be interested to read that you were (possibly) hitting a known bug:

https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/217860-troubleshooting-busyout-dial-peers-on-cu.html