Have not had any similar reports so far as I know, that certainly is troubling...
From your description it sounds like perhaps incoming messages from CUCM to the application are not being received or are blocked.
* Is it possible that the Windows firewall has somehow been enabled/re-enabled or the allowed connection ports cleared? For default/insecure connection port is 2748, if the TSP is configured for secure connection port is 2749.
* To recover function temporarily, would it be possible try removing one or both of the Windows update KBs?
* For further troubleshooting purposes it may be helpful to have:
1) All TSP logs from a system restart through reproduction of the issue (set the TSP config trace level to all-types/detailed)
2) A network packet capture (e.g. using Wireshark) from the Windows 2016 server for application startup/repro
3) CTI Manager logs, see: https://developer.cisco.com/site/tapi/help/case-opening-steps/
* The CUCM version is over 2.5 years old. There have been a number of changes to default/supported TLS version/cipher details for CUCM (and Windows - for example I think I recall a situation where a recent update for Win7 was forcing some TLS connection minimums which caused problems.) during that time. If your TSP is configured for secure connection it's possible there may be some conflict/issue. Not that you would necessarily need to upgrade to resolve this particular issue (at least until we know final root cause and any options for workarounds), but it may be a good time to start the wheels for considering an upgrade at some point.
Regarding the support experience, that's very disappointing :/ Indeed, a forum is not the intended support channel for production verified partner apps:
* Cisco IVT verified partner applications should receive 'coordinated/cooperative' support, where Cisco product TAC and the vendor support organization work together with Cisco DevNet to analyze and resolve issues involving integration between products. TAC/vendor/DevNet keep all 3 cases open and linked until resolution.
* I know Arc (now Enghouse per my understanding) has long been a verified partner (indeed OEM in the case of CUAC) for their operator console products, however I don't see that the QMS product has been through the official testing - at least it doesn't appear on DevNet Ecosystem Exchange: https://developer.cisco.com/ecosystem/solutions/#key=call%20recording . It would be good if it did, perhaps we can prompt them to consider testing if not already planned...
* Verification status is pretty secondary here, as this is an 'integration' issue - in such cases, part of the partner agreement is the understanding that the vendor is the primary owner of the issue - I don't believe they should have passed you to TAC (who are not trained for, nor will accept developer support issues.) Ideally, Enghouse would analyze the problem (which they did - i.e. not seeing inbound messages) and open a case with Cisco DevNet Developer Support, who can work with them directly to understand/troubleshoot the issue.
* In this particular case, I suspect Enghouse may not necessarily need to update their code or 'fix' anything on their side - so most of the actual investigation may involve DevNet trading trace requests and thing to try with your team - however Enghouse would benefit from understanding the issue/resolution in case future customers encounter it and/or they need to add info to their UI/help/docs/FAQs, etc. (e.g. maybe a specific Windows 2016 config/caveat)
- Generally an end-user customer would not open a DevNet case for an app they aren't developing themselves - the likelihood DevNet can resolve the issue without analysis and cooperation with the developer of the app is low.
In general, I would suggest putting together the traces/info mentioned above and sending with full description via email to developer-support@cisco.com; as well as requesting Enghouse open a DevNet dev support ticket for the investigation. In the mean-time I will give a heads-up to the DevNet support engineers about your issue in anticipation of your email, in the hopes we can get some investigation started with you directly with the Enghouse ticket coming in parallel.
