By the way, I also witnessed another problem with the Full one but I didn't keep the logs and it can not be easily reproduced.
When the RLS receives two partial non consecutive notifications (ie. version="10" & version="12", version="11" missing) by RFC4235 it should refresh its subscription to get the full state. As far as I saw the RLS doesn't refresh it, resulting in a temporary inaccurate status of the extension for the clients. I think switching to the Consolidated one should also fix this problem because the Consolidated probably does refresh in that case (to be able to build a full state). If I ever witness it again I will provide you the logs... -------------------------------------------------------------------------- Hi, Thanks for the info the Consolidated RLS fixed the described problem, it does generate later more data since you get full state of an extension (even when there is only partial change) but you get an accurate status of the extension as soon as the first notification. Of course the ideal would be to have a full state on (re-)subscription then partial states with the Full RLS, if you have time to implement it in the future. Regards. Worley, Dale R (Dale) wrote: > This is true if you subscribe to the "full state" URI, ~~rl~F~[user]. But if > you subscribe to the "consolidated" URI, ~~rl~C~[user], the various dialog > events that the RLS receives are folded together into one synthetic dialog > event, and a new subscription to that URI will return the full state in the > first NOTIFY. > > It's not entirely clear from RFC 4662 whether a resource list subscription > *should* integrate the notifications that it receives. But for practical > reasons, the RLS provides URIs that do, so we haven't attacked that problem. > > Dale > _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
