Hi, There are still issues with sipXecs 4.2.1 in the Resource List behavior:
When you subscribe to the RLS for the first time you get a fullstate (RFC4662) of the list which is good, but for each resource you get the last notification received which can be a partial state (RFC4235). So it is impossible to know the full state of the extensions whom the last notification was a partial state. To overcome this problem the RLS server at sipXecs should not only remember the last notification of every resources in the list but also construct a full state out of it to give it in the first RLS subscription. 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. Finally the RLS is not compliant with RFC4662 (and even RFC3261) because it only accepts subscription with a single "Accept" line: Accept: application/dialog-info+xml,application/rlmi+xml,multipart/related while RFC4662 shows in its examples (and RFC3261 allows) multiples "Accept" lines: Accept: application/dialog-info+xml Accept: application/rlmi+xml Accept: multipart/related Regards. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
