Hi, the title says it all! I have a customer with a 7200s V4.91 that has a number of 3rd party SIP softphones and 4 Polycom SIP conference units. A couple of months ago they decided to expand their network and split it into Voice/Data using VLAN's. I went to site to work with their IT guy's and after the network implementation all IP phones registered and have worked fine ever since. All the SIP devices, both Soft and Real registered and worked fine, for about 2 weeks. I logged onto the system and all devices were registered. If I exited any of them, they deregistered immediately and when turned back on they register straight away. The issue is that none of them can dial internally/ externally or be called, you just get busy. After a bit of experimenting I found that if I changed the Session Expire Time in 5.2.12 (MMC 837) from 1800 seconds to anything else (even 1799) then the SIP phones start working immediately. Since discovering this the problem has reoccurred a couple of times, although there seems to be no pattern to when it stops.

These are the things I know;

1. The Softphones are on laptops that connect to the Data VLAN, although there is inter-VLAN routing and they use DHCP to get an address.
2. The Conference phones have static addresses on the Voice VLAN, the reason being that the customer can log into them easily if needed.
3. The problem effects both sets of devices at the same time so I think I can rule out a VLAN issue.
4. The system was upgraded prior to the VLAN implementation (I know it is only to 4.91 and I can't remember why it was decided to take it there).
5. Samsung Support do not recognise this as a fault and wanted a load of stuff I cannot get easily.

I don't know why the SIP Expire Time brings the calling ability back, I only tried it because I have had to reduce it in the past to get WeVoip to work.

Any help or ideas would be appreciated as this has me stumped.

In 838 Private IP do you have the ip scheme of the Data Vlan programmed?

Short answer, no. The Voice VLAN has a subnet of 255.255.255.0, the Data has 255.255.254.0. I had a go at working out the wildcard for the Data VLAN but I couldn't get it right. The reason I didn't push further with that is because the 4 SIP conference units are statically assigned to the Voice VLAN and suffer the same problem. I'm happy to throw the wildcard in if you can tell what it is Thanks for reading and responding!

Have you tried updating s/w to 4.99 and see what happens then?

I haven't yet but it's not my call. Upgrading of firmware is a chargeable job and there is the argument from above that this is a customer created problem, they changed the network which has effected the SIP phones. Customer would argue that there is a fault and until that discussion is resolved I can only look at the config I have.

Wild cards in samsung need to be entered as x.x.x.255

In the case of your data vlan 255.255.255.254.0 is just 2 x 255.255.255.0

eg 192.168.0.0 with a subnet of 255.255.254.0 includes ip address's 192.168.0.1-192.168.0.255 AND 192.168.1.0-192.168.1.254
so you would enter it as 192.168.0.255 and 192.168.1.255 in the whitelist.

MMC838 only applies if the system is configured as private with public (eg for sip trunks, remote ip phones, etc)

If this were the issue then the phones likely wouldn't register at all.

Sip devices send a registration message then if they aren't called or used won't send anything more until the registration timer expires.
After successfull registration, the system will show them as registered until it fails to receive the next registration message (this is just how sip works, and not a system fault).

As you are manually de-registering the devices they are sending a message to the system stating they are de-registering which is why it shows this.

It sounds like there is some intermittent packet loss on the network, ask the customers IT dept to prioritise the voice vlan traffic and sip traffic between the vlans.

You may have some success changing the devices to use TCP for SIP rather than UDP as it may be a bit more stable.

Tech support will likely be after wireshark traces from the system, at the time it fails.