Been having an issue lately with the Samsung OfficeServ SMT IP Phones losing their connection to the server and just giving a "Connecting to Server" message in the display of the phone. LAN connection is functioning properly, able to get a valid IP address and browse the network and Internet. Power cycle the phone, have run wireshark captures on the server side and can see the UDP traffic coming in from the public IP of the SMT on either port 6000 and/or 9000 for registration and see the server sending traffic back out to the public address. Only way I can get the phone back up and connected is to go into the programming of the phone itself and do a Factory reset then re-program system information back into the phone. Anyone ever have a problem like this?

A few questions for you:

1) are the phones on latest firmware?
2) is the system on latest firmware?
3) How often does this happen?
4) are the phones local or remote?
5) What is the network configuration? Any VLAN, etc?

Hey Badger,

Yes, phones are on the latest firmware currently released by Samsung.

System software is V4.75 and OAS cards are on V2.05 (latest releases for the states)

No really set timeframe, just happens randomly but pretty frequent. I'd say at least 2 to 3 times a month.

Phones are remote

No VLANs in use. Has happened with Cisco, Netgear and Sonicwalls on the system side. And many various routers on the phone side. Has happened to my remote phone at my house and we have a Sonicwall TZ215 at the office and I have a Netgear at my house (has also occurred on a Linksys and Juniper installed at my house)

In the firewall on the remote side, have you allowed for ports 6000, 9000 and 9001 udp/tcp to go through the firewall without interference? I know I have had to set this up for my remote locations and it works without a hitch.

Haven't needed to do that before, but I will certainly give it a try. We didn't really have this problem until the newer software releases, starting around maybe 4.60D.

The biggest changes with the new software releases is security, especially 4.65 and later. Do you have your SMTi phone IP addresses listed in the phone White List?

I do not. We have Use IP White List disabled under 2.7.1 IPT Information do to the fact that these remote users are DHCP from their carriers. I had that enabled before, and whenever the carrier renewed their public IP, the user had to call us and we'd have to get the new IP information and update the table.

We're having the same thing happen, very intermittently on SMT-i3105 sets at one customer. OS7400 V4.70

They have 100+ phones, it happens on about 1 phone every couple months or so. We've found the phones always seem to try to DHCP bind to the same IP address, even on a power cycle, so if the address the phone wants is grabbed by something else or some other change happens in the LAN environment, the phone doesn't come up. Re-running the Easy Install seems to force it to refresh the network settings. Have never had to do the factory reset.

Most of our other SMT sites we define the phones with static IPs and we haven't had the issue. Just can't do that with this site.

Have you tried to Wire Shark it? I'm learning Wire Shark is my friend when all else fails.
John 807

Yes, I have run wireshark on both the server side and the ipt side. I see the packets reaching each device utilizing 6000 and 9000 UDP, but for some reason the phone will still not register. IP addresses in the packets are correct as well for the local IPs. I just don't get it.

if you plug a laptop into the phone pc port can you ping the server? And from the server side ping the phone?

Here is my suggestion. Software 4.70 is junk. Even Samsung has said it. That is why they released the 4.75. Update to the newest software and your problems should go away. Why they can't just make a good release, is beyond me. That's coming straight from the mouth of their tech support.

PC plugged into the PC port of the SMT phone works fine, and yes I can ping the server and get replies.

Server software is on V4.75

Wireshark captures have been ran simultaneously on both sides and we can see the traffic from the phone and the server responding to each other. But for some reason the phone just will not link up.