cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Walkthrough Wednesdays
859
Views
0
Helpful
4
Replies
Keith Abbott
Beginner

site getting fast-busys on outbound calls

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 Master

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.

View solution in original post

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.

 

 

Content for Community-Ad

Spotlight Awards 2021