We had a simliar problem but only some of the message stream would be lost. Ours turned out to be a fault in the core switch that caused the IPCC to lose communication with the remote site and our CtiOs primary server was at the remote site. According to Cisco the CtiOs servers do not actually support real redunancy and when we lose communication IPCC would get gummed up. When communications came back on line (short failures) the servers were out of sync and you had to reestablish communications with the no back up CtiOs server. Sometimes it also resulted in all the agents getting kicked out and having to log back in. I had a monitor mode app that exhibited the same behavior as you are describing so I would perodically "refresh" my connection on a timer. That seemed to be the only way to keep the connection working.

 
You could turn up the level of tracing on a few of the misbehaving clients. You should at least get when the last message came in and what method was called last. That should at least get you to the right place to look in the code. Also are you monitoring your heart beats? Do you stop getting those too? You could try refreshing your connection when you haven't gotten any messages for an extended time. I would also open a TAC case to get some help from Cisco. Its a starting point at least

Hi Shannon,

I had to compile the my project with 7.2.7 dlls. I did try just replacing the old DLLs with the new ones but without compiling it just doesnt seem to work. I use VS2003 for build as it is the only recommended version to be used with anything below CTIOS 7.5. Are you saying that I can use VS2005 and if I set Form.CheckForIllegalCrossThreadCalls = false it should just work without any issues ?Also what is the test bed you mentioned?


I also didnt quite understand "Just remove the reference to the new ones in your project and then add a reference to the old files that are in your Program Files folder instead of the GAC. See if the problem goes away"

My Dlls are refrerenced from the same location as my CTIOSCsharp project file

 
In your VS project look under the References branch you should see NetCil and NetUtil those are both references to the Cisco .NET Cil. By default they are using the dlls in the Global Assembly Cache which are the newest DLLs. Remove those 2 references and then right click on the References itself and choose Add Reference. Then choose Browse and navigate to the Program Files folder for the Cisco Desktop install go in to the CtiOs Toolkit and keep going down until you find the .NET Cil files. Since you upgraded you will have a sub folder that has the old DLLs in it marked with the upgrade number. Its a little confusing because the ones in the top folder are the new ones and the ones in the 7.2.7 folder are the old ones. Just select whatever ones you want and that is the version you will compile with. Unless I am using the ActiveX controls or silent monitoring I don't even install the toolkit I just use the dlls for whatever version I want copied from previous installs. You don't need to install the toolkit the Cils are just wrappers around a bunch of GED TCP/IP calls.
 
As for the version thing. Yes Cisco has to officially support the product and sinse prior to 7.5 the .NET Cil was compiled with .NET 1.1 they only "reccommend/support" using VS2003/.NET 1.1.  1.1 was the only version that had "possible" breaking changes but those are in know areas of .NET specific to things not commonly used. I have used .NET 2.0, 3.5SP1 and am now using 4.0 with no problems with any of the CIL versions. I have hundreds of client instances taking hundreds of thousands of calls without a single support call regarding incompatibility. One of the principle changes from 1.1 to 2.0 in .NET was to enforce the rule that you can only access the UI from the UI thread. This was also the case for 1.1 but it was not strictly enforced it was just "reccomended" This means if an async even comes in on another thread (such as a CIL event ) that you have to switch threads to the UI thread before accessing a UI component like a text box or grid. This is very well documented by Microsoft and how to code it. You can google it very easliy. If you don't change threads .NET WinForms 2.0 throws an exception. You can turn that exception off by using CheckForIllegalCrossThreadCall = false. I did it as a test and had a customer deploy it as a beta test and it worked with no ill effects so we certified it and use it in production. This was only while we rewrote the code to do it properly to give us some slack time but I have other customers who just blew it off and just use it that way with no problems. It is not a Cisco issue but a Microsoft one so don't bother Cisco wiith it. This is bread and butter WinForms stuff. You can use a WorkerThread componenet or just recode how you react to events its your call but easy to deal with. .NET was created to run side by side DLLs for reverse compatibiliy without "DLL Hell" so you can run any version of .NET with the old 1.1 dlls as long as you are not using known breaking changes. From 2.0 on it is supposed to be 100% reverse compatible so even though 7.5 uses VS 2005 you still can use VS2008 or VS2010. FYI the sample code from 7.5 still requires the CheckForIllegalCrossThreadCalls fix because it is not much different from 7.2. Hope this helps 
 
Shannon