10 Dec
2009
10 Dec
'09
7:12 a.m.
On Donnerstag, 10. Dezember 2009, Daniel-Constantin Mierla wrote:
Hey Daniel,
if i understand Andrei correctly then this is only a short term solution until
the correct implementation is done. So for now i think its better to go only
with the kamailio compatibility/ global option way, instead of introducing a
new parameter for a tm function which needs to be mainained and deprecated
eventually again. I doubt a bit that the additional complexity in script and
code is really worth the effort, given today multi-core CPU servers.
Regards,
Henning
does this mean
that i would need to call t_lock_onreply() as the first
thing in onreply_route?
if so, i would prefer a global parameter that defaults to locking that
script writer could override if/when needed. otherwise script writing
would become too error-prone
I was thinking of being able to control how the reply routes are
executed per transaction, not globally. I think my second proposal is
better:
t_on_reply("1"); - run onreply_route[1] with no locking (default, same
syntax as now) for current transaction.
t_on_reply("1", "0"); - run onreply_route[1] with no locking for
current
transaction.
t_on_reply("1", "1"); - run onreply_route[1] under lock for current
transaction.
In some cases, there is no need to lock for replies (no avp processing),
therefore why to have it locked.