Hi Bogdan,
I tried your patch, works perfectly, absolutely no problem so
far. It's exactly what we needed.
Just one more question (for now ;): Is the same procedure safe
to be used with 0.9.5 and 0.9.0 devel? Obviously the patch
must be applied manually for 0.9.x;
Looking at the sources and comparing the affected 0.9.x and
0.10.x files I am pretty sure that moving the lock in the
0.9.x t_reply.c is supposed to do exactly the same thing like
in 0.10 devel. And, as written above, anything works as
expected - also for 0.9.x.
So, is there something we miss?
Thanks again,
best regards
--Joachim
-----Original Message-----
From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro]
Sent: Mittwoch, 19. Oktober 2005 17:07
To: Joachim Fabini
Cc: users(a)openser.org; 'Joachim Fabini'
Subject: Re: [Users] Persistently storing headers from
onreply_route()?
Hi Joachim,
apply the attached tm.patch - it's trivial change that will
synchronize
the execution of on_reply route. And it will be safe to use avpops
functions in on_reply routes. Note that you have to change the module
interface of AVPOPS and add the ONREPLY_ROUTE flag.
regards,
bogdan
PS: if you get a coredump, I'm free of any responsibilities :D
Joachim Fabini wrote:
Hi Bogdan,
>the reason haven't changed: avps doesn't work in on_reply
>
>
route since
the avp
belong to a transaction and the on_reply route
execution is not synchronized and may be done in parallel for same
transaction.
For the moment there is no solution to this - synchronizing
the on_reply routes will be quite ugly :-/
Do you see another - even proprietary - very-short-term-workaround
that can provide this functionality (storing avps within
onreply_route
in the database that can be later on accessed from
the route block
using avp-ops) without extra module coding?
Ugly is not important at all if it works. After all it's just about
prototyping, the final code should be clean... ;))
But what will be done (there was a discussion with
Juha on
this topic) is to add global avps which not being bound to
a transaction can be used inside on_reply route. I guess this
will solve your problem....
Definitely. That's also conceptually closer to what Service-Route
is supposed to do - it's valid for the lifetime of a registration
(although it might be changed by re-registrations) and not just
for one transaction. Any estimate when this will be available?
Thanks for your help,
regards
--Joachim