atcomsystems.ca/forum Forums Other TDM Phone Systems Iwatsu Telephones & Systems ECS alarm code 4

We installed an ECS cabinet on an Adix M (I believe) system, the CCSU is now running the system. The main reason was to install the new Icon's new SIP voicemail system. Whenever we connect to the ECS and do a change with the Icon Programmer (sometimes just connecting/disconnecting) we get a '4' on the ECS display for a few seconds along with several red LEDs on the CCSU upon disconnecting.

The IP addresses the customer gave us were in the 172.20.x.xxx range for the CCSU, MBU and IConnection voicemail. This even happened back at the shop with the ECS cabinet by itself after we entered those IP addresses, occasionally even when not connecting/disconnecting. At the customer site we disconnected the network and set everything back to default, LAN2 - 10.0.0.1, When connecting a PC with a static IP in the 10,x range to the MBU, we don't get that error when disconnecting the programmer.

Could there be some kind of internal ECS conflict since the customer's IP is close to the LAN1 172.30.30.30 address? I don't think it's a conflict of a device on their network as we got the same error with the ECS cabinet back at our shop. Should the customer maybe put us on a different VLAN?

Is this 'MAJOR' or 'MINOR' error code? a MAJOR 4 relates to issues with the Compact Flash card on the CCSU, either a corrupted file or a problem with the CCU.

A MINOR 4 relates to system congestion or files needing updating. In either case, check that your license version and software version are at the same level (or withing one step of each other) and that all of your IP devices and SIP channels are properly configured and licensed.

I think it's MINOR. System congestion makes sense because at times it seemed like the system was running slow. I did download and install the required licenses, but we can check the versions on Tuesday when we return.

When removing the 8 SIP channels but keeping the customer's specified 172.x. etc. addresses we still got the error. When adding the SIP channels back in (configured for voicemail) and defaulting the IP addresses of the MBU and CCSU we didn't get the error. Of course that rendered the new voicemail system unusable

For now the ECS cabinet is running the system and the old analog Esna is connected as usual. We were hoping to have both so the customer can record their greetings on the new system. I wonder if we'll need to change the default LAN1 address? The guy I was with who's been working on Iwatsus much longer than I said there is one customer where he had to do that.

You may want to try changing the sub net mask address on LAN 1 to 255.255.255.0 instead of 255.255.0.0.first. You probably have some sort of IP conflict with a wide open sub net.

Change LAN1 to something else entirely if that doesn't help.

Do you have anything connected to LAN1 when the system is operating, other than a programming PC?

Right now LAN1 is 255.255.0.0. We could try what you suggested. Spoke to the IT guy, their other LAN is 172.20.8.xxx. Back at the shop we setup the IConnection voicemail and ECS to the customer's IP (the 172.20.7.xxx range) and the system did work even though our local IPs are the typical 192.168.1.xxx. Of course to administer the ECS and voicemail we'd set the PC to a static IP in the 172. range temporarily. I'm not much of a network guy so I'll ask - would the customer's network pass traffic in the 192.168... range on their 172. network? The IT guy thought no, even if we could that would probably prohibit any public IP access - unless port forwarding could route to an IP address not within the 172 range?

On site watching the system now. Did a couple of minor changes and haven't got the 4 error. Kinda strange that I changed 2 keys from CCI to CCN in the front office for the 2 attendant consoles (yea they still use them here, all 4) and it still audibly rang. I had to completely delete the keys.

LAN1 is normally not connected to anything.

Changing the CCI and CCN keys requires a STATION reboot as I recall...

Since the LAN1 connection doesn't have any provision for a gateway address, you really don't have to have anything connected with it. I generally connect my pc to the bottom port of the MBU so I'm on the same network if I'm on-site.

The 3rd octet zero in the subnet for LAN1 means that ANY address in the 172.20.x.x range will try to connect LAN1 to the network, so you effectively had TWO connections to their network going at the same time.

Networking is FUN!

Fun is right! Yea I was doing some research on subnetting last night. With systems on the customer's network I typically do the same as you, connecting to the MBU. With some I have the luxury of being on the same VLAN of the PBX with their WiFi.

So that third 0 in the subnet is significant as you said. We're probably going to set up another ECS at the shop with the customer's database and fool with that. We may have a 2nd IConnection system, if not we can still probably simulate the error.

Before we brought the ECS to the customer's site it was in the shop for a while. I'm pretty sure we did not have that 4 MINOR alarm until we put their 172. addresses in.

What if we totally removed the subnet for LAN1?

If you remove the subnet, you may not be able to connect through the LAN1 port. I'm thinking if you just set the third octet to 255 you shouldn't have any more trouble with LAN1

The third octet to 0 could be a solution. Back at the shop yesterday the other guy set up an ECS with the customer's database, including the 172.20.xx... addresses in the MBU and CCSU. I connected my laptop with a static IP in that range on our network. Was able to connect to the ECS which was connected to our network.

Several times did changes, like name, key pattern, etc. No errors at all - kept an eye on the ECS. What I should do - and have not yet, is to connect my laptop to LAN1 using the standard 172.30.30.30 address. (of course setting my laptop IP accordingly). Then again, if everything was working like this at the customer's site I wouldn't need to connect to LAN1 as long as I'm on their network.

Went to the customer's site yesterday. Different CPU in the ECS (replaced the Adix cabinet/CPU a while back), same error. We disconnected the iConnect with the ECS on their network, no error. Brought the voicemail to the switchroom, connected it to the ECS via the MBU. Got the error with the customer's network disconnected. Our other guy brought the Iconnect voicemail back to our shop and connected it to a spare ECS with the customer's db. Same errors. He disabled CSTA in the voicemail (I had to look CSTA up) and no errors (when uploading or downloading data). So it seems the congestion error '4' is being caused by the new voicemail, specifically due to CSTA activity.

If I understand it correctly, it's sort of like a D channel with SIP. No voice traffic, but as our chief engineer put it, used for Lamping in the new voicemail system. So it's an out of band protocol, unlike the analog voicemail we tried using which of course used just DTMF on one of the channels sending feature codes followed by the extensions to set/deactivate message waiting. We're going to see what Icon (the developer of the new voicemail) can do.

If for some reason CSTA is incompatible with this particular ECS, maybe have the message waiting set inband using codes on one of the SIP channels? We have 8 which is plenty. Of course that's having to involve Icon.