[sr-dev] Suggesting fix for t_request and pua_dialoginfo

[Henning Westerholt]

On Monday 16 August 2010, Jasmin Schnatterbeck wrote:
> The issue is visible, whenever pua_dialoginfo sends out a PUBLISH
> request. During that process, build_cell is called, which destroys avps.
> 
> I experimented with adding a parameter. It works - nearly.
> PUBLISH is sent out, avps are OK, but after additional 2-3 seconds, one
> child process dies.

Hello Jasmin,

i think this happens probably because of the reasons Andrei mentioned in his 
reply (last wednesday) - that an internal AVP list cannout be shared between 
several transactions.

> So there are these 2 possibilities:
> - AVPs get destroyed
> - kamailio dies a few seconds after sending out the PUBLISH
> 
> Which scenario happens depends on these lines in build_cell() (tm
> h_table.c:~300):
> 
> 		old = set_avp_list(AVP_TRACK_FROM | AVP_CLASS_URI,
> [..]
> 		*old = 0;
> 
> If these lines are present, AVPS get destroyed. If not, kamailio child
> dies a few seconds after sending out PUBLISH.
> 
> I tried different things here, but I did not figure out yet, why this
> happens.
> I assume that somewhere (may through a timer) somewhat is called, which
> uses the parameters of the cell, which refer to avps. And if there is no
> AVP list (but e.g. a 0 pointer), the child processing this code dies.

There is a delete timer for transaction which does some cleanup, maybe in a 
way like you described here.

> So I would like to ask Andrei, whether if it is possible to investigate
> this problem - because at this moment, it makes the use of
> pua_dialoginfo totally impossible.

There are tow two other workarounds, but both are not really good or 
practical:

* changing your proxy that it not keep transaction state
* changing pua_dialoginfo that it not send its PUBLISH transactional

So i think the best way to proceed is doing a change in TM like Andrei 
suggested, changing the code that it not copy the AVP list for a local 
transaction and instead create one with an empty AVP list.

Cheers,

Henning