Calls fail after increasing the active lines on a third party IVR SIP

[merdan.aliev]

Hello,

I would like to ask for some help with this one please.

Our 3rd party partner has increased the active lines on there side, but this caused all calls to fail.

I have checked the logs but I can't see exactly what triggers 503 Service Unavailable.

I put the trace file as attachment.

Call flow: PSTN SIP - CUBE - CUCM SIP - 3rd party IVR SIP (Voxtron)

Your help would be greatly appreciated.

Thank you in advance.

Regards,

Merdan Aliev

[Leonardo Santana]

Hi,

What´s the calling and the called number to look at the traces?

CUCM: 192.168.0.240

 3rd party IVR SIP: 192.168.0.5

Is that correct?

[merdan.aliev]

Hi Leonardo,

Calling nr: 032961947

Called nr: 50555281

CUBE: 192.168.0.5

3rd party IVR: 192.168.0.26

CUCM: 192.168.0.240

Regards,

Merdan

[Leonardo Santana]

Hi,

I saw that your CUCM is sending the 503 unavailable to the CUBE.

Could you use CUCM DNA to see if you have other routes to this Called nr: 50555281.

[merdan.aliev]

Hi Leonardo,

Thank you for your reply.

Actually there is only one route to this number.

These called numbers are Translations patterns (more than 1000) which are forwarded to their respective extensions towards the SIP trunk of Voxtron IVR (pattern X?). The calls are being answered by the agents in Voxtron and thereon the calls are being forwarded to the respective end customer.

This morning it happened again and the status of the SIP trunk was "No service". But this time I have reset the SIP trunk to Voxtron and the collegue on Voxtron side has reset the IVR. The 503 Service Unavailable has cleared in less than a minute and all came to normal.

Now, my questions are: what has happened with the trunk? Why it crashed? Is there a resource limit that has been crossed?

This is, of course, a major issue for our customer, that's why I have opened a TAC case.

I'll keep updating this post, but your contribution would be greatly appreciated.

Thank you.

Regards,

Merdan Aliev

[Leonardo Santana]

Hi Merdan,

Verify when the issue arise again the status of the trunk as you said.

Is there a firewall between your CUCM and Vostron?

What was the local reason for the trunk been no service?

[Leonardo Santana]

Hi Merdan,

Local=1 (request timeout)

Local=2 (local SIP stack is not able to create a socket connection with the remote peer)

Local=3 (DNS query failed)

https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/213718-calls-through-session-initiation-protoco.html