ICT calls disconnecting with (47) Resource unavailable, unspecified

[kiranoddiraju]

Hello folks,

I am having some trouble with calls on the CUCM intercluster trunk (non GK). Calls from Cluster-A (v8.0.3) to Cluster-B (10.5.1) are working fine but when Cluster-B calls someone in Cluster-A the call gets disconnected after 3-4 seconds with Fastbusy tone. My first thoughts were codec negotiation failed, so we tried g279/g711, tried MTP, Xtranscoders but I haven't been successful. Disconnect cause code is (47) Resource unavailable, unspecified. 

BTW: there is a firewall in between but I've triple checked and confirmed the Permit IP ANY ANY between the two clusters IP Subnets.

Any help would be very much appreciated.

Thanks,

KO

[Ayodeji Okanlawon]

KO,

We will need to look at cucm logs to accurate determine whats going on here. On CUCM 8, ensure cucm traces are set to detailed. Do a test call and send us cucm logs. Ensure that the cucm you are collecting logs from is the one the trunk is using and the ip phone is registerd to it. If the trunk CUCM and phone cucm are different you will need to get the logs from both cucm servers.

Send both cucm10.5 logs and cucm 8 logs. Include calling, called number and time of call.

[kiranoddiraju]

Thanks for the quick response Ayodeji. Please see attached detailed SDL logs from both cucm servers.

x117028 is registered to cluster B (10.200.13.11/.12)

x101667 is registered to cluster A (10.129.121.40/.41)

KO

[Ayodeji Okanlawon]

I forgot to mention that we need SDI traces from cucm 8. Can you please send them

[kiranoddiraju]

See attached...

[Ayodeji Okanlawon]

Kiran,

The issue you are having is that CUCM10,5 is unable to establish h245 tcp connection to cucm8.

Once the h225 setup is complete, h245 capabilities exchange needs to happen at the connect phase of h225. At this phase you see the call come into the ip phone and that's when media negotiation actually happens. In the logs we see CUCM10.5 trying to set up tcp connection for h245..on port 47180. As you can see the connection failed. The ports used by h245 are Ephemeral / TCP ports and these should be allowed on your firewall

62680672.001 |14:16:37.049 |AppInfo  |DET-H245Interface-(135)::start_Transition, networkFlag=13, mIsSRTPAllowed=0
62680672.002 |14:16:37.049 |AppInfo  |DET-H245Interface-(135)::start_Transition, (H245Client session) ip = (10.129.121.41), port = 47180, TA provided by Callee

62680697.000 |14:16:37.050 |SdlSig   |H245CapabilitiesOutgoingIndication     |waitForTransportEstablishment  |H245SessionManager(3,100,29,135)                                                             |H245Interface(3,100,191,135)     |3,100,14,5114.5^10.129.121.41^*          |[R:N-H:0,N:1,L:0,V:0,Z:0,D:0]
62680698.000 |14:16:37.050 |SdlSig-S |H245CapabilitiesOutgoingIndication     |waitForTransportEstablishment  |H245SessionManager(3,100,29,135)                                                             |H245Interface(3,100,191,135)     |3,100,14,5114.5^10.129.121.41^*          |
62680699.000 |14:16:37.050 |SdlSig   |ConnRes                                |tcc_await7                     |Cdcc(3,100,219,70364)        

62681029.001 |14:16:45.052 |AppInfo  |TranslateAndTransport(135)::waitForSdlRsp_TcpAwaitRespTimer - ERROR: Fail to setup H245 signaling connection!!!
62681029.002 |14:16:45.052 |AppError |H245Log: Process=TranslateAndTransport LogicalChannelNumber=1011 -- TCP ERROR: TcpAwaitRespTimer times out, or received SdlCloseInd from H245Handler, Perform cleanup of H245 Session

The TCP ephemeral port range is 32768 - 61000

[Suresh Subramanian]

we faced the same issue when we had our cucm8.6 in firewall zone and H323 gateway in non-firewall zone, so instead of opening all these ports, we changed to SIP in the gw where we opened only 5060TCP/UDP.

[kiranoddiraju]

That is so weird, I have Full IP open between the two IP subnets. I will take a further look again.

As suggested by Suresh, we tried to setup a SIP trunk between the two cluster. On Cluster-B the SIP trunk is not coming up, the status is:

Service Status: Unknown - OPTIONS Ping not enabled

Duration: Unknown

I created a SIP Profile with SIP OPTIONS Ping Enabled but the Trunk still doesn't come up. I can ping each other fine and telnet on port 5060 works fine. Any ideas?

[Ayodeji Okanlawon]

Service status doesn't mean the trunk is not working. Service status is from options ping perspective. Have you enabled options ping on both CUCM? and reset the sip trunk? I don't believe CUCM8 has service status. So you can ignore that. What happens when you make a call over the trunk?

[kiranoddiraju]

Options Ping is available only on CUCM10, I can't find that option on CUCM8. It is currently disabled on CUCM10, when I enable it, I see the Trunk status is remote=503

[Ayodeji Okanlawon]

Okay you will need to diable options ping on cucm10 because its not available on cucm8.0 ( available on cucm 8.5).

A destination address is considered to be "out of service" if it fails to respond to an OPTIONS Request, if it sends a Service Unavailable (503) response or Request Timeout (408) response, or if a TCP connection cannot be established

So CUCM will not send calls to that trunk if it sees 503. So disable it and reset your sip trunk, then test again

[kiranoddiraju]

OK I disabled the options ping on CUCM10 but I can't dialout, I get Fast Busy tone. From CUCM8 I can call DNs on CUCM10. 

Under SIP information, Destination address section I see Trunk Status is N/A, Status Reason N/A and Duration N/A

[Ayodeji Okanlawon]

Like I said earlier, I wont worry about the status. This is because options ping is not in use and hence cucm cant determine the status of the trunk.

Can you send CUCM logs from CUCM10 for the test for sip calls..include calling and called number.

[kiranoddiraju]

Please ignore my previous comment. There are two CUCM servers in both clusters and the SIP was configured pointing to only one server. I created a new Trunk on CUCM8 and on CUCM10 enabled 'Run on All Active UC Nodes'. It's all working fine now.

Many thanks Ayodeji and Suresh.

[Suresh Subramanian]

Hi Kiran,

Why don't you configure SIP Trunk between these 2 clusters as both are above 8.X version which Cisco also recommends.

While H.323 trunks are still supported, SIP trunks are the recommended trunk type for Unified Communication deployments because SIP trunks provide additional features and functionality not available with H.323 trunks.

Also it is easy to troubleshoot the SIP with Session Trace in RTMT :)