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.