Cisco phones have a high-functioning 3-port switch built into them for the daisy-chaining, so you can tell your folks that it will not be the hardware itself that is causing the problem. If it were a single phone, maybe that one phone is malfunctioning. But if it is all PCs running this app, then it is not the physical functioning of the phones.
This is a long-shot, but one thing I can think of where a Cisco phone would affect network traffic processing is QoS markings. By default, Cisco network switches re-mark traffic to "Normal" traffic by removing L2 and (depending on the switch) L3 QoS markings. If you have Cisco phones, I would expect that your switch folks have configured your switches to "trust" what the phone is telling them from a QoS marking perspective so that the VoIP traffic generated by the phone is handled correctly. This is called extending the trust boundary.
However, the Cisco phone itself (because it is a switch) also re-marks traffic coming out of a daisy-chained PC as Normal traffic prior to sending it to the network switch. So it is possible that the application is configuring the traffic coming out of the PC to be QoS-marked in a way that a later device is expecting to "read" so that the application's traffic is given some preference in the network. But if the phone is re-marking the traffic as Normal, then the preference might be missed.
If this is the case, the trust boundary can be extended to the PCs hanging off of the phones. Or, different QoS configuration can be implemented on the network to discover and prioritize the application's traffic.
It's a stretch, but worth looking into.
