Archive for the ‘TROUBLESHOOTING’ Category

Is there out anybody who doesn’t like playing with ‘BREAK-FIX” ?

I have ran into this issue before but, it was a few year ago! I forgot what I did (I should have boggled it out) and it took me solid 5 hours to troubleshoot one this real world break fix!

SCENARIO:

PSTN—H323GW—CUCM—PHONESInbound call works perfectly
Outbound Call (phone to PSTN)

THE PROBLEM:

=> Production CUCM Cluster
=> Nothing changed in CUCM, everything seems to be correct -i.e. RP/GW/GK perfectly fine.
=>Any outbound call doesn’t seem to be appearing in H323 GW
=> Dial Analyser tool shows everything as expected. No doubt in CUCM config!
=> The following tools | Commands  became useless! WHY?

debug voip ccapi inout – useless
debug isdn q931/q921 – useless
No infrastructure related issue or Teleco issue.CUCM and GW are in the same subnet – i..e the same layer2 domain.
Dial analyser results revels everything is 100% correct.

DEBUGS:

debug voip ccapi inout spat out the following;
May 21 04:57:32.006: //19/46CBDD9B8007/CCAPI/cc_api_call_media_reset_ind:
Interface=0x0, Call Id=19
May 21 04:57:32.014: //19/46CBDD9B8007/CCAPI/cc_api_set_called_ccm_detected:
CallInfo(called ccm detected=TRUE ccmVersion 3)
May 21 04:57:32.014: //19/46CBDD9B8007/CCAPI/cc_api_call_notify:
Data Bitmask=0x1, Interface=0x473254D8, Call Id=19
May 21 04:57:32.014: //19/46CBDD9B8007/CCAPI/cc_api_get_ssCTreRoutingNotSupporte
d:
CallInfo(ssCTreRoutingNotSupported=FALSE)
May 21 04:57:32.014: //19/46CBDD9B8007/CCAPI/cc_api_get_ccm_detected:
CallInfo(ccm detected=TRUE)
May 21 04:57:32.014: //18/46CBDD9B8007/CCAPI/ccCallNotify:
Data Bitmask=0x1, Call Id=18
May 21 04:57:32.034: //19/46CBDD9B8007/CCAPI/cc_api_caps_ind:
Destination Interface=0x481D9D0C, Destination Call Id=18, Source Call Id=19,
Caps(Codec=0x1, Fax Rate=0x80, Vad=0x1,
Modem=0x2, Codec Bytes=160, Signal Type=2)
May 21 04:57:32.034: //19/46CBDD9B8007/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
May 21 04:57:32.034: //19/46CBDD9B8007/CCAPI/cc_api_caps_ack:
Destination Interface=0x481D9D0C, Destination Call Id=18, Source Call Id=19,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_14400(0x80), Vad=OFF(0x1),
Modem=ON(0x2), Codec Bytes=160, Signal Type=2, Seq Num Start=4977)
May 21 04:57:32.034: //18/46CBDD9B8007/CCAPI/cc_api_caps_ack:
Destination Interface=0x473254D8, Destination Call Id=19, Source Call Id=18,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_14400(0x80), Vad=OFF(0x1),
Modem=ON(0x2), Codec Bytes=160, Signal Type=2, Seq Num Start=4977)
May 21 04:57:32.034: //18/46CBDD9B8007/CCAPI/cc_api_voice_mode_event:
Call Id=18
May 21 04:57:32.034: //18/46CBDD9B8007/CCAPI/cc_a

SOLUTION:

Easier than you would ever think.
*Check H323 Voice GW configuration – most likely ISDN port is not associated with VOIP dialplan.

EXAMPLE:

Dial-peer voice 10 voip
  destination-pattern 0T
   port 0/0/0:15 or trunkgroup AT&T <—- This is missing

The catchy part of this is, if the CUCM cluster is in production and the last thing you’d want to check is if the voice gateway was not properly configured. Obviously it was configured and not tested during the initial site migration. Go figure and find the contractor who did this job – take his/her half of the day rate 🙂

The fact was, user complained that it was working 🙂