Hi, I see the complexity of the problem.
The RLS definitely reports the ghost and the new subscription separately (you get two instances for the same resource) so there is no bug from your point of view. This only produces a temporary inaccurate state of the resource that gets fixed when the ghost instance disappear. Your heuristic will definitely help to fix the inaccuracy faster by removing faster the ghost instance. Regards. Worley, Dale R (Dale) wrote: > 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/
