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

[Peter Dunkley]

Hi,

I only use PostgreSQL, so I'd have no way to test changes made to db_mysql
(which is why I only added the APIs to PostgreSQL).  That said, I don't
believe it will be hard to do and most (if not all) of the PostgreSQL code
should be re-usable (although some of the locking stuff might be
PostgreSQL specific - but even then there should be MySQL equivalents). 
If someone wants to do work on MySQL this I'd be happy to help out if I
can.

The DB locking stuff (or rather its use in the presence modules - the
locking API itself is fine I think) is still something of a work in
progress.  At the moment the locking is very strict everywhere to ensure
that there is no chance of conflicts between processes and servers.  It
can probably be loosened off a bit in some areas.  Loosening up the
locking would increase performance, but it is a bit of balancing act
finding the minimum set of locking needed to prevent problems.


The db_mode that affects this error should be the PUA one, not the RLS one.

If the problem is occurring in db_mode=0 in PUA there might be a way to
fix it by moving the hash table locking around.  At the moment the hash
table is locked in the insert_htable() function (called sometime after the
SUBSCRIBE is sent - that is before the call to tmb.t_request_outside() in
send_subscribe()).  If the hash table was locked before the SUBSCRIBE is
sent and then unlocked after the insertion it wouldn't be possible for the
2XX to be processed (and the dialog converted) before the dialog record
exists.  The insert_htable() function would need tweaking (perhaps a
second argument) so that it can be run without obtaining a lock itself in
this case.

The downside to this is that locking the hash table for longer may reduce
performance - but if you are seeing this problem perhaps it is necessary?

Regards,

Peter

> peter,
>
> thanks for the explanation.  i was using in rls db_mode=0 when i saw the
> error message.  i then switched to db_mode=2 for rls just in case you
> had fixed something there and i haven't seen the error since then
> although i'm using mysql where your fix should not help.
>
>> The temporary dialog record cannot be created until after the SUBSCRIBE
>> has been sent (the call-id and from-tag are generated by the TM module).
>> This means, on a single server with RLS back-end subscriptions over the
>> local loopback, it is theoretically possible for the SUBSCRIBE to be
>> sent
>> and the 2XX generated, sent, received, and processed before the
>> temporary
>> record is created.
>
> i have exactly the above situation, i.e., backend subscriptions are send
> over loopback interface.
>
> i'll keep on watching if i see the error again with db_mode=2.  it would
> be nice to get your DB API enhancement implemented for mysql too.
>
> -- 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