Dale R. Worley - 2008-08-04 17:30 Ugh, you're going to have to specify one of the BLF'ed extensions and describe what happened with the BLF light. There are 14 different calls whose status might be reported incorrectly!

Mark Gertsvolf - 2008-08-04 17:52 - edited Apologies for the vague description. I should point out that RLS server stops sending the NOTIFY messages to the phone and no updates take place. The same set subscribing for BLF is making a paging call Call-ID: 94c10518-2f87a24e-13c4-1b3ee-5068d4df-1b3ee@scsalpha.ca.nortel.com paging a single monitored set 19264. RLS server initially sends a burst of NOTIFY requests. I am noticing that RLS server creates multiple active transactions. I could not find clearly in the rfcs whether supporting multiple active transactions is a must. Note that LG set produces "500 CSeq too small for this call" responses if requests arrive out of order. It can be seen from the "lg.log" that NOTIFY with CSeq 3 never arrives at the set, while subsequent NOTIFYs with CSeq 4 and 5 do. The set generates 200OK for the later requests. After NOTIFY with CSeq 5 no more NOTIFYs are send to the set. I also noticed that RLS server seems to have discarded the subscription dialog. Later on when the set attempts to refresh the subscription it gets 481 response. After teh first page the same set makes a different paging call. Call-ID: 94c106c0-2f87a24e-13c4-1b3f9-5e16af0d-1b3f9@scsalpha.ca.nortel.com This time no NOTIFYs are sent.

Dale R. Worley - 2008-08-05 13:58 Ah, that description helps greatly. SIP requires that a UA be able to handle overlapping transactions. Given that the network can reorder messages, the only way to avoid overlapping transactions would be to require that the UA await a response before sending another request. However, the UA is allowed to process overlapping requests in any order it desires. In this case, it processes NOTIFY 2 before it processes NOTIFY 1, so NOTIFY 1 gets a 500 response. But the phone is clever and puts "Retry-After: 0" in the 500 response, so the 500 response does not implicitly terminate the subscription. RFC 4235 suggests that NOTIFYs not be generated more than 1 per second. sipX does not enforce that because it would be difficult to do so. But due to network delays, there can be no guarantee that the recipient will not see bursts of NOTIFYs at higher than that rate. From the RLS's point of view, it sends a series of NOTIFYs, but NOTIFY 3 gets no response, which is an implicit 408 response. The 408 terminates the subscription. The phone sends the NOTIFY via UDP 3 times and then attempts to send it by TCP (but the phone does not listen on TCP). The phone does not appear to be receiving the NOTIFY. The next step is to get a packet trace to see whether sipX or the phone is dropping this NOTIFY.

Dale R. Worley - 2008-08-05 13:59 Can you get a packet trace to see which component is dropping the critical NOTIFY?

Paul Mossman - 2008-11-14 13:30 This problem has been fixed as XECS-1810.