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

Hi Andrei,

thank you for looking at the problem.

You mean t_uac_prepare() (called via tmb->t_request, request(), t_uac(), t_uac_with_ids(), t_uac_prepare()) ?

Yes, that's it.

Rather then adding a parameter for not reseting the avp list to build_cell() and commenting it out in t_request(), I think the solution is not copying the avp lists at all for the local transaction (so a parameter for creating a transaction with an empty avp list).

I already tried to change the build_cell() function in this way. When

new_cell->uri_avps_from new_cell->uri_avps_to new_cell->user_avps_from new_cell->user_avps_to are zero-pointers, kamailio dies a few seconds after sending out the PUBLISH request.

Which changes would you recommend to create an empty avp list?

Thank you very much.

Best Regards Jasmin

Am Mittwoch, den 11.08.2010, 15:14 +0200 schrieb Andrei Pelinescu-Onciul:

On Aug 11, 2010 at 05:45, Jasmin Schnatterbeck js@data-cmr.net wrote:

...

Hello List,

some months ago I reported a problem with pua_dialoginfo: Avps declared in request route are not available anymore in branch route, if pua_dialoginfo module is loaded.

I do not know whether there are some experiences with this problem or not, so I looked for the reason.

pua_dialoginfo uses pua for sending PUBLISH request pua uses tm t_request for sending PUBLISH request

t_request() is located in uac.c (tm):

You mean t_uac_prepare() (called via tmb->t_request, request(), t_uac(), t_uac_with_ids(), t_uac_prepare()) ?

...

• in line 411 avp list is reset
• in line 276 build_cell() is called: build_cell() is located in h_table.c, where lines 305-323 delete avps

If I comment out the mentioned lines, which delete avps, then avps set in request route are also available in branch route. But I do not know, what is also affected by this change.

So would it be reasonable, to add a parameter to build_cell() for not changing the AVP list?

The problem is that the AVP lists cannot be shared between several transactions and in your case there are probably 2 transactions that would share them without the reset: the transaction created by t_relay()/t_newtran() and the local PUBLISH transaction created by pua_dialoginfo. Rather then adding a parameter for not reseting the avp list to build_cell() and commenting it out in t_request(), I think the solution is not copying the avp lists at all for the local transaction (so a parameter for creating a transaction with an empty avp list). Another possibility would to clone the avp list instead of linking to it in the t_uac_prepare() case, but this would be expensive and I don't think anybody needs a local transaction that would inherit the avps (there is only an event route executed on the local transaction creation an that can access the original avps anyway).

Andrei