Debug outbound calls and connection to pri (fast busy)

phoeneous

We had a pri circuit bounce this morning (carrier side) and now theyre saying that it is back up. However, all oubound calls are getting fast busy. Inbound calls are good. Pri interfaces on my router are up and up. I've enabled debug isdnq931 and debug voip ccapi inout. While attempting an outbound call, I get the snippet from the log below. I'm not that great with voice yet, can anyone assist with this output? Thanks.

005637: Mar  8 09:32:21.366 PST: //719/7D5225B88093/CCAPI/ccIsInfoRingback:
   Returning dpRingBack=0
005638: Mar  8 09:32:21.374 PST: //719/7D5225B88093/CCAPI/cc_api_call_connected:
   Interface=0x2AEC3C78, Data Bitmask=0x0, Progress Indication=NULL(0),
   Connection Handle=0
005639: Mar  8 09:32:21.374 PST: //719/7D5225B88093/CCAPI/cc_api_call_connected:
   Call Entry(Connected=TRUE, Responsed=TRUE, Retry Count=0)
005640: Mar  8 09:32:21.374 PST: //719/7D5225B88093/CCAPI/cc_api_set_called_ccm_detected:
   CallInfo(called ccm detected=TRUE ccmVersion 3)
005641: Mar  8 09:32:21.374 PST: //719/7D5225B88093/CCAPI/cc_api_call_notify:
   Data Bitmask=0x5, Interface=0x2AEC3C78, Call Id=719
005642: Mar  8 09:32:52.770 PST: //707/FD98F6B78090/CCAPI/cc_api_call_disconnected:
   Cause Value=16, Interface=0x2AEC3C78, Call Id=707
005643: Mar  8 09:32:52.770 PST: //707/FD98F6B78090/CCAPI/cc_api_call_disconnected:
   Call Entry(Responsed=TRUE, Cause Value=16, Retry Count=0)
005644: Mar  8 09:32:52.770 PST: //706/FD98F6B78090/CCAPI/ccConferenceDestroy:
   Conference Id=0x12E, Tag=0x0
005645: Mar  8 09:32:52.770 PST: //706/FD98F6B78090/CCAPI/cc_api_bridge_drop_done:
   Conference Id=0x12E, Source Interface=0x2B309E84, Source Call Id=706,
   Destination Call Id=707, Disposition=0x0, Tag=0x0
005646: Mar  8 09:32:52.770 PST: //707/FD98F6B78090/CCAPI/cc_api_bridge_drop_done:
   Conference Id=0x12E, Source Interface=0x2AEC3C78, Source Call Id=707,
   Destination Call Id=706, Disposition=0x0, Tag=0x0
005647: Mar  8 09:33:00.038 PST: //719/7D5225B88093/CCAPI/cc_api_call_userinfo:
   Interface=0x2AEC3C78, Signal Indication=TONES OFF(63)
005648: Mar  8 09:33:00.042 PST: //718/7D5225B88093/CCAPI/ccGenerateToneInfo:
   Stop Tone On Digit=FALSE, Tone=Null,
   Tone Direction=Network, Params=0x0, Call Id=718
005649: Mar  8 09:33:00.042 PST: //719/7D5225B88093/CCAPI/cc_api_call_userinfo:
   Interface=0x2AEC3C78, Signal Indication=TONES OFF(63)
005650: Mar  8 09:33:00.042 PST: //718/7D5225B88093/CCAPI/ccGenerateToneInfo:
   Stop Tone On Digit=FALSE, Tone=Null,
   Tone Direction=Network, Params=0x0, Call Id=718
005651: Mar  8 09:33:00.042 PST: //719/7D5225B88093/CCAPI/cc_api_set_called_ccm_detected:
   CallInfo(called ccm detected=TRUE ccmVersion 3)
005652: Mar  8 09:33:44.998 PST: //-1/805124D9C660/CCAPI/cc_api_display_ie_subfields:
006089: Mar  8 09:44:45.071 PST: ISDN Se0/0/0:23 Q931d: L3IF_rx_L2_pak: received data
006090: Mar  8 09:44:45.071 PST:        0802287C0504038090A21803A183821C
006091: Mar  8 09:44:45.071 PST:        139F8B0100A10D020101020100800547
006092: Mar  8 09:44:45.071 PST:        4549434F6C0C00803532303534363235
006093: Mar  8 09:44:45.071 PST:        353870058037353030
006094: Mar  8 09:44:45.071 PST: ISDN Se0/0/0:23 Q931d: L3_Go: source 0x020A, ces 1, event 0x0005, call id 0x0000, int id 0x0
006095: Mar  8 09:44:45.071 PST: ISDN Se0/0/0:23 Q931d: L3_Go: event 0x5  cr_len 2 cr 43132
006096: Mar  8 09:44:45.071 PST: ISDN Se0/0/0:23 Q931d: L3_Go: call_id 0x121 cr 0xA87C state 0 event 0x5 ces 1
006097: Mar  8 09:44:45.075 PST: ISDN Se0/0/0:23 Q931d: L3_ProcessEvent: callref = 0xA87C SETUP:U0_Setup(nlcb)
006098: Mar  8 09:44:45.075 PST: ISDN Se0/0/0:23 Q931d: L3_state_change: callref 0xA87C old NULL_STATE, new CALL_PRESENT
006099: Mar  8 09:44:48.059 PST: //785/39FAB6B2809F/CCAPI/ccIsInfoRingback:
   Returning dpRingBack=0
006100: Mar  8 09:44:48.063 PST: //785/39FAB6B2809F/CCAPI/cc_api_call_connected:
   Interface=0x2AEC3C78, Data Bitmask=0x0, Progress Indication=NULL(0),
   Connection Handle=0
006101: Mar  8 09:44:48.063 PST: //785/39FAB6B2809F/CCAPI/cc_api_call_connected:
   Call Entry(Connected=TRUE, Responsed=TRUE, Retry Count=0)
006102: Mar  8 09:44:48.063 PST: //785/39FAB6B2809F/CCAPI/cc_api_set_called_ccm_detected:
   CallInfo(called ccm detected=TRUE ccmVersion 3)
006103: Mar  8 09:44:48.063 PST: //785/39FAB6B2809F/CCAPI/cc_api_call_notify:
   Data Bitmask=0x5, Interface=0x2AEC3C78, Call Id=785
006104: Mar  8 09:45:27.139 PST: //-1/009B297CD460/CCAPI/cc_api_display_ie_subfields:

phoeneous

RESOLVED.

It was a bad pair on the carrier side. Call flow is good.

pitviper

Glad it’s all fixed! Sounds more like a channel lockup (maybe caused by a “bad pair”) – Which is probably the most common PRI issue outside of the physical circuit being down. In extreme cases, you can busy-out the affected b-channel(s) to restore service while the carrier works to clear the issue (or while you work to convince the carrier that it's not your equipment ):

RT2851(config)#interface Serial0/2/1:23
RT2851(config-if)#isdn service b_channel 1 state ?
  <0-2>  Valid states are 0=Inservice 1=Maint 2=Outofservice
RT2851(config-if)#isdn service b_channel 1 state 2

tokhss

Thats good info PIT..