cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1670
Views
0
Helpful
4
Replies

one-way calls over inter-cluster SIP trunk

Hi All,

We have a SIP trunk between two CUCM clusters. But calls are getting connected only in one direction. When making a call in another direction the call hits the remote cluster but then is dropped. The trace in the originating CUCM shows the following: Sip_disc_cause= 503 cause=63

Does anybody have an idea what can potentially cause a call getting disconnected with such dissconnection cause in the trace?

Thanks.

4 Replies 4

fkarami
Level 1
Level 1

Hi Alex,

Many things could cause this issue. Here are a couple of recommendations that I have:

1- Check network connectivity between your phones:

     Try using a laptop on the subnet that the phones are on in one cluster and see if you can ping the phones in the other cluster from it.

2- Check your CUCM clusters and make sure that all your Route Patterns are configured correctly and the routing of calls are done correctly.

3- Try and look at your codec issues and MTPs. Try enabling the MTP and make sure that the codecs are matching. Also check the transcoders are transcoding your codecs correctly between clusters.

Hope this helps.

Cheers,

Farbod

Hello, thanks a lot for the answer. We have tried all different things but unfortunately nothing has helped. So we have simply decided to use a normal ICT instead a SIP trunk. And funny enough it worked all right strait away.

Yufang Zhou
Cisco Employee
Cisco Employee

503 service unavailable discnonection normally means a call (SIP INVITE) is received by a node which has no corresponding active SIPD running. Each SIP trunk is run by a SIPD process inside of CCM service. The typical cause of the problem is that the node received the call is NOT part of the callmanager group which is assigned to the SIP trunk. as a result the SIP process will not be active and running for this SIP trunk. When a call is orginated from cluster A, the node ip address may be confiruged in the destintation address of SIP trunk of cluster A, but this node was not included in the callmanager group of SP trunk of cluster B.

Hello, thanks a lot for the answer. We have tried all different things but unfortunately nothing has helped. So we have simply decided to use a normal ICT instead a SIP trunk. And funny enough it worked all right strait away.