cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 
cancel
1447
Views
0
Helpful
4
Replies

site getting fast-busys on outbound calls

Keith Abbott
Level 1
Level 1

Hi,

 

We are running UCM 11.5. We have a remote site that recently started getting fast busys on their outbound calls. Inbound is operating normally.

 We are unaware of any changes at the site. 

Looking at the gateway, I do not see any controllers reporting down interfaces.

I had someone at the site do a test call, then captured the CDR information for that call.

It indicated the call had been terminated by the destination device and the device name it gave was for a SIP trunk back to our central UCM. The destCause_value was 1459617833. Some checking indicates that translates to 'CCM_SIP_503_SERVICE_UNAVAILABLE'. 

I checked the trunk on cucm and it indicated it was fully up and had been for 5 days. I performed a reset of the trunk and had the test user try again but with the same results. 

Can anyone suggest where I need to look next?

thanks for your help

1 Accepted Solution

Accepted Solutions

How is the FXO port controlled? Is it MGCP, H323 or SIP on CUCM side? Because if it's SIP then and it's on the same physical gateway as your PRIs you would see the call hitting the same SIP trunk and dial-peers would control where it goes.

View solution in original post

4 Replies 4

Chris Deren
Hall of Fame
Hall of Fame

Please post "show run", "show controller T1/ or E1", and "debug isdn q931" for one of the calls.

Hi Chris - finally found the problem late yesterday. I'm pretty cisco green and complete newbie with cisco CDR so this wound up being a case of putting too much faith in what I was seeing on the CDR record and not interpreting it correctly (I guess) and not having a familiarity with the site in question. (We support a lot of sites and dont have a lot of information about them).

After digging deeper from a different angle (starting with the calledPartyPattern instead of the terminating device) I found the outbound calls were actually routing out of POTS lines on an FXO card. And as it turned out, the first preferred pots was quietly down so the system dumped the call to the port, where it died. We have the carrier checking it today. I busied that port out and calls were flowing again!

Can you explain why the destination CMR would show the deviceName of the SIP trunk between the remote site and the central site when the terminating device was actually an fxo port?

Is the approach I ultimately took - starting with the directing pattern, the best approach to use when tracing something like this?

Thanks for your response.

How is the FXO port controlled? Is it MGCP, H323 or SIP on CUCM side? Because if it's SIP then and it's on the same physical gateway as your PRIs you would see the call hitting the same SIP trunk and dial-peers would control where it goes.

Hi Chris

Thanks for the response -thats it! SIP trunk and same gateway. Guess I just need more experience reading the CDRs and better over-all understanding of the guts.

 

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: