10 Dec
2009
10 Dec
'09
6:32 a.m.
Hello,
Andrei, instead of having K compat mode, as global parameter, I would
prefer to have per transaction function:
t_lock_onreply()
Gives more flexibility.
Cheers,
Daniel
On 12/10/09 12:16 PM, Andrei Pelinescu-Onciul wrote:
On Dec 10, 2009 at 12:57, Juha
Heinanen<jh(a)tutpro.com> wrote:
Yes, I agree.
Andrei
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
* http://www.asipto.com/
Andrei Pelinescu-Onciul writes:
tm functions or functions that use tm api and try to lock replies (lock
the transaction reply_lock). I don't know of any and I don't think we'll
have any problems, but I haven't checked everything.
All the k modules functions that worked in k with the reply avp mode
will work with sr too so this leaves possible problems only in
modules_s.
Everything you mentioned above won't cause any problems.
What I'm afraid is that executing the reply
route under lock might
introduce some deadlocks (it is possible that some functions that are now
allowed to be executed from the onreply route would cause problems, I
haven't checked all of them).
what could those be? i test/set flags/avps/vars and call functions that
rewrite some parts of the message, like contact uri and sdp.
The long
term solution would be to lock only the avps and only when used,
but it requires lots of changes and testing and I'm not sure it would be
ready/good enough for 3.0.
not for 3.0, which, in my opinion, we should get out before end of this
year.