SIP Trunk/Remote

yveslacoste · ‎02-18-2016

Hello,

I have a question about remote SIP trunking.

We have a host site with 2 remote site. Everything is connected in VPN between router. When the router lose internet connection the remote SIP trunk show no service. When we try to reset the trunk it still come up as no service, the only way we find out to be working so far is by rebooting the CUCM.

By doing this we lose all site connection to phones and calls. Is there a way to check or reset something for just that trunk either on the CUCM or gateway so we don't lose the host and others remote connectivity?

We have CUCM version 10.5.2.12901-1 and the status reason in the trunk say local=1

If any more information needed please asked.

Thank you

Chris Deren · ‎02-20-2016

Do you have options ping enabled on the trunk?

What is this trunk pointing to? Is it to the voice gateway at the remote site? Please elaborate on your topology.

A reboot of CUCM should never be needed to bring SIP trunk up, so there must be something odd here.

yveslacoste · ‎02-21-2016

options ping is not enable on the trunk

the trunk pointing to a Cisco 2901 voice gateway at a remote site.

We have a router at both end that as VPN connection between both of them. Our voice gateway is connected to the router. Our CUCM have a SIP trunk pointing to the remote gateway.

Chris Deren · ‎02-22-2016

I would recommend enabling SIP options ping between CUCM and the remote GW. This way CUCM can nicely track the status of the trunk, and hopefully this would resolve your issue.

yveslacoste · ‎02-22-2016

I have the option ping enable at CUCM and the voice gateway now (it was not enable on the gateway before) but still same issue when we lode internet at the remote site the trunk does not come back up unless we reboot the CUCM.

When doing a show dial-peer voice summary we have in the keepalive part busyout on the voice gateway and it stay like that, waited for 20 minutes and never change and on the CUCM still said no service.

Chris Deren · ‎02-23-2016

this is odd, at this point I would open a TAC case with Cisco to identify what is happening here.