In this instance, several INVITEs from 6032757146 to 85030 reach phone 85030 but do not cause appropriate BLF NOTIFYs to phone 85506. The dialogs can be seen from 2009-01-26T20:10:27 to 2009-01-26T20:14:21 in sipXproxy.log in the attached snapshot.
The reason that BLF NOTIFYs were not generated was that the RLS lost its subscription for dialog events to 85030's phone (22.214.171.124) at 2009-01-26T19:31:55. Starting at 19:30:33, the RLS attempted to refresh its subscription (with CSeq 5). It first sent 3 UDP messages and then a TCP message (at 2009-01-26T19:30:37). At 19:31:55, the phone responded 500 to the TCP message. It appears that the phone received and processed one or more of the UDP messages, but the phone's answer did not reach the RLS. Then the phone received the TCP message and (correctly) responded 500 to it. This terminated the RLS's dialog subscription (in the opinion of both the phone and the RLS).
This problem is fixed by XECS-1365 "When an established subscription ends, the RLS should resubscribe", which is fixed in 3.11. With XECS-1365, the RLS would have immediately resubscribed to 126.96.36.199's dialog events, and the BLF on 85506 would have reported 85030 correctly.
An alternative fix would be for the phone to implement XTRN-10
"Suggest to Polycom adding "Retry-After: 0" header in 500 Out Of Order responses". With "Retry-After: 0", the 500 response does not terminate the dialog event subscription, and the RLS would continue to receive dialog events for 188.8.131.52. (The 500 response to a re-SUBSCRIBE shows that the phone received an earlier copy of the same re-SUBSCRIBE, so the RLS can be satisfied knowing that the subscription was successfully refreshed, even though it does not receive a response indicating such.)