10 Dec
2009
10 Dec
'09
4:45 a.m.
On Dec 10, 2009 at 10:45, Juha Heinanen <jh(a)tutpro.com> wrote:
Klaus Darilion writes:
I'll have a quick fix in the next few days (similar to k, but I'm
thinking of going for read-only avps by default and a modparam to turn
them r/w at the price of locking the reply route). In the long run
we need a better fix.
Juha Heinanen wrote:
what is the conclusion about this? Andrei Pelinescu-Onciul writes:
Yes. So sr has a different default behavior than k. (should be
documented in migration guide) > K's tm module can be configured to have
transaction AVPs or message AVPs:
> http://kamailio.org/docs/modules/1.5.x/tm#id2530480
>
> What is the behaviour of ser's tm module? I need AVPs in reply route -
> is it supported?
In theory, yes by default. In practice it looks like there's a bug if
several replies are processed in the same time.
As a quick fix for sr_3.0 I might introduce the same mechanism as in k.
i didn't quite get this. in sr_3.0, i do see avps in onrely_route that
were set in route block before t_relay was called. is this what andrei
means in above by default behavior? if so that is fine with me.
it is ok with me if in in sr_3.0 onreply_avp_mode is on by default
(and even on always), but i'm very worried, if it does not work when
several replies are processed simultaneously.
Yes, if avps are written in the onreply_route and replies for the same
transaction are processed in parallel there's the chance of corrupting
the transaction avp list or even crashing.
Andrei