From your log...
13:22:27.500 [MS105000] C:75.6: No RTP packets were received:remoteAddr=192.168.1.104:11794,extAddr=0.0.0.0:0,localAddr=192.168.1.10:7282
13:22:23.234 [MS105000] C:75.3: No RTP packets were received:remoteAddr=192.168.1.118:11782,extAddr=0.0.0.0:0,localAddr=192.168.1.10:7276
13:22:20.421 [MS105000] C:75.4: No RTP packets were received:remoteAddr=192.168.1.112:11782,extAddr=0.0.0.0:0,localAddr=192.168.1.10:7278
13:22:13.312 Currently active calls [none]
13:22:01.609 [MS105000] C:75.8: No RTP packets were received:remoteAddr=192.168.1.105:11798,extAddr=0.0.0.0:0,localAddr=192.168.1.10:7286
13:21:53.734 [MS210001] C:75.6:Answer received. RTP connection[unsecure]: 192.168.1.104:11794(11795)
13:21:53.734 Remote SDP is set for legC:75.6
13:21:50.906 [CM503008]: Call(75): Call is terminated
13:21:49.906 [MS210001] C:75.3:Answer received. RTP connection[unsecure]: 192.168.1.118:11782(11783)
13:21:49.906 Remote SDP is set for legC:75.3
13:21:48.156 [CM503003]: Call(75): Call to sip:
[email protected] has failed; Cause: 302 Moved Temporarily; from IP:192.168.1.111:5062
13:21:47.265 [MS210001] C:75.4:Answer received. RTP connection[unsecure]: 192.168.1.112:11782(11783)
13:21:47.250 Remote SDP is set for legC:75.4
13:21:43.390 [MS210001] C:75.8:Answer received. RTP connection[unsecure]: 192.168.1.105:11798(11799)
13:21:43.390 Remote SDP is set for legC:75.8
13:21:41.312 Currently active calls - 1: [75]
13:21:40.703 [CM503007]: Call(75): Device joined: sip:
[email protected]:5062
I'm not sure what is happening. It looks as if one set answers and the call is "joined", yet two other IP's also show answer. Then it shows No RTP Packets received from the remaining IP's in the Ring Group. I'm not sure if the Invite was sent to the sets but that some were not able to acknowledge it in which case a ring cancel message was unsent. (speculation). Since the system did not originality behave this way, I have to assume that something has changed, even slightly, to cause this. the only other explanation would be some sort of data corruption.
I would suggest reviewing whatever, seemingly slight modifications, were done to the system/Network/sets, etc., just before this issue began.
One other thing, to test if it is a change in the 3CX settings that have caused this (and this action should be reserved only if you become desperate), is to restore an old backup, of the 3CX system, from a point before the problems began. Before you even think of doing this however, make a couple of current backups of the system. If the current problems are still there, then you know that it is a set, server, or network problem. You could then try out some computers running the 3CX Phone (to temporarily replace the Yealinks sets), to eliminate them as the problem.