SIP Trunk to Avaya PBX "No Service"

[aniket0422]

Hello Guys,

We have CUCM 14.0 SU3 Cluster of 2 Nodes on same UCS Hardware.

SIP Trunk to Avaya PBX is showing "no service". and we are not able to make calls to Avaya PBX from Cisco PBX. However, surprisingly calls from Avaya PBX are landing perfectly fine on the Cisco PBX.

We have another SIP Trunk to 8300 Router for PSTN calling from Same Call Manager. That trunk is up and running fine.

A am attaching logs. Can someone please guide. What wrong is going on. I can see that call from Cisco is not at all going to Avaya PBX. It is stuck on CUCM itself.

[Roger Kallberg]

If the trunk is not in service CM won’t send any call to it. You’ll have to check on the Avaya end as it is likely on that end where you have the problem.

[aniket0422]

Hi Roger, 

Thanks for your reply.

Not sure, how we are getting Calls from Avaya PBX via same SIP Trunk even if its status is "No Service".

In RTMT We can See. CCM_SIP_503_Service Unavailable for Calls made from Cisco to Avaya PBX.

[Roger Kallberg]

Calls are working in that direction because the trunk on the CM is operational in the inbound direction. A 503 service unavailable means that the trunk is not operating on the Avaya end in the inbound direction. SIP option ping only shows the state on the opposite end, so No Service refers to the state on the Avaya end.

[Nithin Eluvathingal]

The Avaya-to-CUCM call connection operates seamlessly, which is a common occurrence during the integration of CUCM and Avaya systems. While CUCM requires minimal configuration to handle incoming calls, Avaya necessitates specific adjustments, such as adding routes. Although I’m not an Avaya expert, our past integrations from 5 to 6 years ago encountered similar issues, and the call functionality worked after Avaya engineers made the necessary modifications and route additions on Avaya.

Additionally, there are numerous knowledge base articles available on the Avaya side. Be sure to follow them diligently

[Elliot Dierksen]

The first thing that comes to mind is that control traffic could come from any one of the CM nodes in your cluster. The Avaya may not recognize all of them and thus the 503 failure.