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@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