As we get other functional problems removed from the RLS (and SAA, which has a very similar internal structure and uses the same stack-level code), I expect that a growing fraction of the remaining user-visible problems will be due to obsolete but unexpired registrations of phones that have rebooted or suffered similar fates.
If a phone reboots but does not do its new registration in a way that allows the Registrar to determine that the new registration is a continuation of the previous registration (namely, if the Call-Id and contact are different), the RLS/SAA will continue to keep a record of the last reported status of the phone when it was using the previous registration, along with the current status of the phone (recorded under its new registration). If the phone had active calls at the time that it rebooted, this will cause the extension (AOR) to be reported as busy until the old registration expires. I think we can fix this by adding the following logic: If reg events for a resource show a new contact URI for the resource, the RLS/SAA should suspect that one of the other contacts may be obsolete. It can fix that problem by ordering all of the existing subscriptions for the existing contacts to re-SUBSCRIBE immediately. (We may have to add a method to SipSubscribeClient to order immediate re-subscription.) With that change, a rebooting phone will usually cause this sequence of events: - phone reboots, selects a different contact URI than before, either because it has a different address, or it chooses a different listening port or adds a different anti-spit URI parameter - phone registers - Registrar delivers new contact to RLS/SAA in reg event - RLS/SAA causes existing dialog subscriptions for that AOR to re-subscribe - the re-SUBSCRIBE for the "orphaned" subscription receives a 481 (if the phone is at the same address) or 408 (if the phone is at a different address) In either case, the orphaned subscription is cleared from the RLS/SAA either immediately (by a 481) or within about 15 minutes (by a 408), as compared to the current situation, where the orphaned subscription is not cleared until either the orphaned registration expires or the orphaned subscription is scheduled for re-subscription. Comments/ideas? Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
