atcomsystems.ca/forum Forums TDM Business Telephone Systems Samsung Telephones & Systems Officeserv 7200 - SPnet Dropping Issues

Hi Guys

We currently have an issue with SPnet dropping out resulting in "no user response" messages between our sites. After a couple of attempts to dial an extension at the other site the SPnet kicks back in again but within 30-60secs of inactivity drops again.

We've raised the issue with our telecoms provider who installed the system, they are claiming its a network issue and not one with the system and then failing to assist us any further. Does anyone know how SPnet actually works?, its been explained to me that the systems should be pinging one and other to verify the connection but I have not been able to see any evidence of this in packet captures through our UTM's or with Wireshark on one of the Officeserv units - does anyone know the specifics to look for?

For reference our setup consists of two Officeserv 7200 units running v4.60 joined over VPN with SonicWALL NSA3500's and 10Mbit lease lines at each end.

Any help appreciated.

probably port 6100 is blocked in the firewall/vpn. we have had this here a few times.

what version of software are the sites running?
I've seen this on 4.53c and received a t4.53h from samsung which is supposed to fix this issue, this fix is probably in 4.60b also

Thanks for the reply guys,

Port 6100 is part of a rule set to be allowed through at both ends and does work to a point, but something seems to prematurely end the connection. We can see on the SonicWALL's that the port is opened and is assigned an expiry time of 7200 second (2 hours manually defined)once we get a call to go through to the remote site. When open we can make as many calls as we like and they go through first time every time and simply brings the expiring back to 7200. However, once we leave it and expiry starts ticking down it always terminates at approximately 7176 only 24 seconds in. We've not managed to tie any of the packet captures together to see if anything in particular is closing the connection and are starting to wonder if the devices are simply incompatible with one and other.

On the software front we upgraded to from v4.53b to v4.60b at both sites (full manual rewrite) back when it was first released early this year along with the associated software upgrades to the other boards

Are they connected via a VPN at all?

24 seconds sound like a normal close after a port is idle.

I had this same problem with a telco provider here. Both ends were sonicwall - they tried telling me too that its my system and not their problem. Well after about two weeks and various packet captures the problem ended up being that one of the sonicwall's had nat turned on. So I have to believe that your issue is telco related as well.

Nameless - Indeed we are, I believe I've changed all of the available setting for altering the timeouts. At present the VPN has a "keep alive" setting enabled which keeps it open at all times. I've altered as many of the TCP and UDP timeouts against the firewall rules, in this instance for the phones both TCP and UDP have been set to 2 hours, its possible I've missed something but I'm not sure I have as I’ve gone round and round with this problem.

Ironhedz - what SonicWALL's were you using, do you know if they had the Standard or Enhanced SonicOS on? I would have to double check but I believe NAT is enabled on both.

Hi Guys

Just a quick update to say we may have solved this mystery - not wishing to call it definate until we've given it a couple of days use.

After 2 hours on the phone with SonicWALL's techs they managed to pinpoint a few initial packets were getting blocked on 6100 when trying to dial the remote site which resulted in the "no user response" and having to repeatedly redial until eventually the packets on port 6100 got through. After making a couple of changes the packets now go through consistently and even though port 6100 expiries after approximately 25 seconds it will re-establish itself when dialling.

In case this helps anyone else the problem was to do with SonicWALL’s SSO (single sign on) which we use to restrict traffic on a user level misinterpreting the data and rejecting it because it couldn’t see any related allowed user, SonicWALL’s tech added an SSO bypass enforcement rule at each end for the SSO Agent which basically tells it to ignore the traffic for the SPnet - why it only blocked the initial packets and let the rest through later I’m not sure, but hey it worked and after weeks of tinkering and phones calls I’m glad its sorted.

I’d really like to thank you guys to trying to help and offering your insight into the Samsung system, it’s all been really appreciated.

Cheers