You'll need to take detailed CCM traces during the entire failed call attempt from all the nodes in the cluster. This will provide you information on whether or not the call is making it to the CUCM server to signal the other end to ring and audio setup.This will be the only way to confirm/deny what exactly is occurring at this point.
I guess the analog phone must be connected to an FXS port on the voice gateway 2. Is the FXS port MGCP controlled or H323 controlled? Have you added gateway to the CUCM? If its MGCP is it registered to the CUCM? If its H.323 have you added the dial-peers on the H.323 gateway?
Post your reply here in order to get a clearer picture of your issue.
nshk-cme#sh call his vo com A/O FAX T Codec type Peer Address IP R: disc-cause 298 ORG T0 g729r8 pre- VOIP P71 0.0.0.0:0 D2F 297 ANS T0 g729r8 pre- VOIP P841 0.0.0.0:0 D2F Total call-legs: 2
nshk-cme#sh call his vo b : ms. + + pid: dur hh:mm:ss tx:/ rx:/() IP : rtt:
media inactive detected: media cntrl rcvd: timestamp:
long duration call detected: long duration call duration : timestamp:
Telephony call-legs: 0 SIP call-legs: 0 H323 call-legs: 2 Call agent controlled call-legs: 0 Total call-legs: 2 10D5 : 298 180551560ms.291 +-1 +12170 pid:99 Originate 71 dur 00:00:00 tx:0/0 rx:0/0 2F (no resource (47)) IP 0.0.0.0:0 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g729r8 pre-ietf TextRelay: off media inactive detected:n media contrl rcvd:n/a timestamp:n/a long duration call detected:n long dur callduration :n/a timestamp:n/a
10D5 : 297 180551550ms.292 +-1 +12190 pid:1000 Answer 841 dur 00:00:00 tx:0/0 rx:0/0 2F (no resource (47)) IP 0.0.0.0:0 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g729r8 pre-ietf TextRelay: off media inactive detected:n media contrl rcvd:n/a timestamp:n/a long duration call detected:n long dur callduration :n/a timestamp:n/a
The call flow is correct. I can't add 'number 71' under voice-port 0/0/0. This commnad is not acceptable. I got the 'no resource (47)' in the voip call. Is it related to the codec mismatch ?
@ Thomas- how will forward-digits all make a difference here? AFAIK the analog phone does not know the number 71. Hence sending the digits to the phone should not make a difference.
@Leung- Try using G711 codec for the call. I dont think the codec would be making a problem here. On which gateway do you see the no resource error? Is the call even hitting gateway 2? try running 'debug voip dialpeer' on both the gateways and check whether the correct dialpeer is getting matched.
Make sure that the FXS port to which the analog phone is connected is working fine. Lift up the handset of the analog phone and check for a dial-tone.
Post the output of debug voip ccapi inout for a failed call.
Sorry for the misinformation because i saw that the no resource error is normally because of codec mismatch.
CC_CAUSE_NO_RESOURCE = 0x2F
no resource. (47) 1
1 This issue can occur due to a codec mismatch within the H323 setup, so the first troubleshooting step is to hardcode the VoIP dial-peers to use the correct codec.
Can you try making an inbound dial-peer on vg1 and ensure that the call leg from CUCM to vg1 is g711 as well. Try a test call. Make sure that you use g711 throughout the call from the IP phone to vg2. In the meantime i will try that out at my end.
After I uncheck 'The Wait For Far End H.245 Terminal Capability Set', I can make the call from ip phone to analog phone. By default, this setting is checked, Can I know the function of uncheck the setting ?
Anyway, It is working now. Thanks everyone help me to solve the problem.
Voip to Voip G/W (CUBE) will not initiate the TCS negotiation with CUCM. The real truth is that it depends on the signaling on the other side of CUBE. If that device initiates the H.245 negotiation with CUBE, CUBE will reciprocate that on the other side towards CUCM. Where you really run into trouble is when you have two CUCM boxes(your scenario) talking with this checkbox enabled. They will both halt waiting for the other side to initiate a H.245 session
This problem did not happen earlier because upto 8 the check box is by default unchecked.
This is required if the other end is a Non Cisco Call Manager(eg. Avaya) we need to wait for the codecs supported by other end and then select one and reply
To my understanding, when you have "wait for far end TCS" checked implies that:This check box specifies that Cisco CallManager waits to receive the far-end H.245 Terminal Capability Set before it sends its H.245 Terminal Capability Set.
Call could also fail if
call manager sends empty capability set to the h323 endpoint which it does not support.
times when u could run into issues are when
h323 terminal does not support empty capability set ie. IOS running h323 version 1 . thus call fails
Check you IOS version it should be greater that 12.2(46)
