BLF: A call ringing on a monitored extension sometimes displays as ringing, sometimes not

Paul Mossman added a comment - 2009-01-05 12:58 Dale: As requested see also XTRN-245, in particular my 2008-12-16 14:25 comment. Note however that unlike what Martin observes, the XTRN-245 #2 problem is fixed after a reboot.

Dale Worley added a comment - 2009-01-09 15:31 In my tests yesterday and today, the BLF for my extension seemed to be working fine. I'm going to need a specific example to track this down. Can you log the date/time and callee of an instance when the BLF didn't indicate ringing?

Al Campbell added a comment - 2009-01-26 14:20 Had no status information on Martin's phone (85506) when calling Joe's phone (85030). You should see that in the attached logs at 3:15pm on 1/26/2009. I placed a call from 6032757146 to 85030 and no BLF indication was seen on 85506. Other phones seem to show status on martin's set.

Dale Worley added a comment - 2009-02-02 16:15 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 (47.16.90.160) 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 47.16.90.160'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 47.16.90.160. (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.)

Dale Worley added a comment - 2009-02-02 16:17 Fixed for 3.11 by Paul Mossman in rev. 14115.