Hi,
When RLS is in DB only mode it uses separate notifier processes. This means that NOTIFYs are never sent immediately in DB only mode, but may be in non DB only mode. The use of separate notifier processes fixes a number of race conditions (but not the one you are seeing), spreads the NOTIFY generation load evenly over time, and makes the RLS module behaviour closer to that from the RFC. However, the implementation of the notifier processes is such that DB only mode is a pre-requisite.
When RLS receives a SUBSCRIBE and it is not in DB only mode it will send an immediate full-state NOTIFY containing the list of contacts and any presentity information present for this dialog in the rls_presentity table. When this is an initial SUBSCRIBE there will be nothing relating to the dialog in the rls_presentities table. This means that the first NOTIFY sent from RLS will just be a full-state NOTIFY containing a list of the contacts. The NOTIFY requests containing aggregated presentities from the contacts will start to come out (on timed intervals) once NOTIFYs have been received back from presence.
When RLS receives a SUBSCRIBE and it is in DB only mode (and the notifier parameters are at the default values), RLS will send a full-state NOTIFY within five seconds. This full-state NOTIFY will contain the list of contacts and any presentity information present for this dialog in the rls_presentity table. Because this NOTIFY will be sent up to five seconds after the SUBSCRIBE was received there is a good possibility that some (or all) back-end subscriptions will have been created and notified. This means that the first NOTIFY sent from RLS may just be a full-state NOTIFY containing a list of the contacts, but it may also be a full-state NOTIFY containing a list of contacts and some (or all) of the contacts presentities.
However, the "temporary dialog" error relates only to back-end traffic between RLS and presence (the pua database table or hash table). The DB mode parameter in RLS relates only to front-end traffic between the user-agent and RLS (the rls_watchers database table or hash table). So changing the DB mode of RLS has no direct effect on how pua uses its database table or hash table - but it may change the timing (additional processes are started, the order things happen changes, and so on).
Regards,
Peter
Peter Dunkley writes:
However, this kind of issue is timing related. So by changing the rls db_mode you have changed the timing on your system and the problem has gone away - for now.
peter,
in case of rls db_mode=0, rls server sends notify to subscriber 3 ms after it has sent 200 ok to subscribe request.
in case of rls db_mode=2, rls server starts to send subscribe requests to list members about 100 ms after it has sent sent 200 ok to subscribe request and waits until it has received all notify requests from members before it sends notify to subscriber.
i have hard time understanding, why in db_mode=0 rls server sends notify to subscriber so fast and does not wait for notify requests from list members.
anyway, the pua error that happens when rls db_mode=0, is very serious. after the pua error message, i have noticed that presence server gets totally stuck and stops processing or receiving any new request.
-- juha
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users