[SR-Users] pua 'Could not convert temporary dialog into a dialog' error

[Peter Dunkley]

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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>


-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd