V9 losing SIP trunks randomly 1

[BFG9K]

Hi All,

We have a V9.0.12.0 build 1006 system that will sporadically lose it's SIP trunk, it will stop trying to register and the trunk will go Out of Service. This being a V9 there is no way to shut down/start up SIP trunks without a reboot, has anyone else encountered this? We are obviosuly recommending upgrading but wanted to see if anyone else has had this issue as well.

 

[janni78]

I've had this issue in similar release.

For some reason the SIP provider sometimes would respond with a 4xx response and that stopped the IP Office from trying to register.

"Trying is the first step to failure..." - Homer

 

[TheSmash]

The SIP stack in 9.0 is a disaster. Inconsistent behavior, just a nightmare to work with.

Time to get it upgraded.

ACSS (SME)

 

[BFG9K]

I figured as much. Easier said than done to upgrade them when the customer counts every penny.

 

[Nutritional_Info]

Maybe if they considered every penny lost as a result of the unregistration.

 

[BFG9K]

Such is life. Clients don't want to spend the money today to prevent wasting more money later.

The SIP stack in v9 really is atrocious...

 

[critchey]

You can set the SIP trunk out of service and do so with a merge instead of immediate reboot, then put it back into service with a merge. I make all SIP trunk changes with a merge even when it asks for an immediate reboot on R9 and R9.1 systems and have not run into issues doing so. I have also been able to get SIP trunks up and running on R9.0.12 without to much troubles before.

How is the SIP trunk setup and how is the SIP URI setup and how is the network topology setup? Do you have binding refresh setup and keepalives setup? Is there a "SIP Device" from the provider or going through a firewall or SBC or how are you connecting? If firewall have you disabled SIP_ALG/SIP Transformations/SIP Helpers/SIP shaping?

The truth is just an excuse for lack of imagination.

 

[BFG9K]

I tried the merge method to bring the trunk out/in service, didn't help in this case. I think there's something else at play here, we rebooted the system to bring the trunk back which worked for 5 minutes then the trunk died again. Monitor shows the IPO attempting to register (Lots of REGISTER Tx), but was recieving nothing back.

 

[BFG9K]

Oh btw, their trunk is set up to present a single number (local URI, Contact, Display Name). Reg expiry is 1 minute, we've adjusted this to various different values and nothing has affected it (this is a long-running issue that reoccurs randomly). Definitely no ALG going on, the IPO connects to the SIP NTU through a switch I believe.

 

[critchey]

Monitor shows the IPO attempting to register (Lots of REGISTER Tx), but was recieving nothing back.

This is a big clue for you right there. I would bet that your firewall is closing the connection after so long of inactivity. You never went over how your network topology tab was setup. You also never said if you have keepalives setup.

The truth is just an excuse for lack of imagination.

 

[ogTOKYO]

if they dont want to spend money to upgrade, maybe getting them to 9.0.12 is a good idea, there was a decent amount of bug fixes by then, dont know if it fixes the SIP handling but it might. Maybe someone else can chime in.

______________________
|........................................|
|.....i.eat.bunny.children......|
|______________________|
(\__/) ||
(•Y•). ||
/ < )<||

 

[BFG9K]

Network Topology is set to Unknown on both interfaces, the trunk comes in on LAN1. SIP reg expiry is 1 minute, however we have tried multiple different values for this with no effect, and the RTCP keepalives are enabled with default settings.

They're already running the latest 9.0.12

Thanks for the assist here guys

 

[critchey]

For keepalives try RTP, 30 second timeout, initial keepalive enabled. Under network topology try static port block (provided you are using a firewall right?). I find on R9.0 and R9.1 static port block worked best but newer it doesn't work so well anymore.

Do you have binding refresh setup and if so what is the value? Is the public IP address of the firewall entered into the network topology? What kind of firewall are you using?

I say this a lot but I will say it again... the more information you provide the better chance you have of getting helped.

The truth is just an excuse for lack of imagination.

 

[BFG9K]

Hi All,

We actually got this going again, what we had to do was firstly re-create the trunk under a new line ID and enter everything from scratch, we set the network topology to 'Open Internet' (as the trunk is accessed through a dedicated network, no FW), and tweak some of the 'Caller ID from From header' and the call routing method 'To Header'.

What's really weird is we applied the settings, rebooted and the trunk was still not playing ball. Hand on heart, all I did was reboot it twice more (with no changes to settings) and the trunk came into service, and has been stable since. I am honestly dumbfounded.

I appreciate the help.

 

[critchey]

I say this alot but the golden rule for Avaya is if it doesn't work do it again the same way and it probably will. A bit odd you had to reboot a few times to get it going but whatever works. The open internet does make sense if you have no firewall.

The truth is just an excuse for lack of imagination.