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:
Outbound Call (phone to PSTN)
=> 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.
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
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 🙂
I am facing the same issue now but the solution you have provided does not seem to work, could you please help.
I am facing the same issue now, both the CUCM and HQ GW are in the same L2 subnet and the issue is exactly the same. But the solution you have given does not seem to work for me. Can you please help.
I am expereincing the same problem, the config did not change at all and the I checked the dial-peers theay all have the destination pattern and the port configured and they are pots dial-peer not voip dial-peer. this issues just started 24 hours ago and all was working fine
i am facing a problem where outbound call (iphone to PSTN) to certain number (IVR prompted) caller hear silence but it works fine when dialing mobile/line. Inbound call are all working fine. Debug q931 shows call connect and disconnected normal, so does CUCM. Not sure how to proceed next. Any idea?
Sorry for seeing this late. Hopefully your issue must been sorts out by now.