________________________________________ From: [email protected] [[email protected]] On Behalf Of Jean-Hugues Royer [[email protected]]
When a resource (extension) is restarted, the RLS re-subscribe to the extension which is good, but instead of replacing its dead subscription (due to the restart) it stills provides both subscriptions notifications (the old/dead one and the new one) as two different instances (both active) for the same resources. The old/dead instance having the higher version number, the new one is being ignored. To overcome this problem the RLS server should only provide one instance/notification per resource. _______________________________________________ The situation is harder to to deal with than that. The underlying problem is that if a phone restarts (and does not terminate its registration(s) or subscription(s) in the process), it is impossible for sipXecs to tell that it is the same phone as before, rather than a different phone registering to the same user-name. So until the old registration/subscription times out, there will appear to be two "instances" of the resource, each with its own state. (The state of the old, "ghost", instance will not change, of course.) Better-quality phones reduce this problem by terminating their subscriptions and registrations when they reboot in a controlled manner. If the RLS were to provide only one instance per resource, it would be unable to report the status of two different phones with appearances of the same extension. However, the RLS should be faithfully reporting the status of the new phone registration and the "ghost" registration separately; if it is not, there is a bug (please provide a snapshot showing the failure). We have been considering a heuristic to reduce this problem: When a new registration is seen for a user, the RLS will force resubscriptions for all the subscriptions that go to instances of that user. A "ghost" registration will not accept the resubscription, indeed in most cases will respond with a 481, which will cause the RLS to delete the saved state of the ghost registration much faster than it would otherwise. Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
