Hello,

you can re-use the lib/kcore/faked_msg.{c,h} in your code, same being done by many event routes. Alternative is to build it yourself from the outgoing buffer, which is in transaction structure, inside the uac field (see tm_cell_t structure).

Easier might be to run this event route with the response sip msg structure -- if you run it only when 200ok is received, the callback from tm has the response structure.

Cheers,
Daniel

On 26/05/14 16:46, Roberto Fichera wrote:

On 05/26/2014 01:04 PM, Roberto Fichera wrote:

Ciao,

[...]

On 26/05/14 12:13, Roberto Fichera wrote:

On 05/26/2014 12:03 PM, Daniel-Constantin Mierla wrote:

Hello,

Ciao!

good that you sent a reminder -- I checked while offline traveling, but then forgot to follow up.

I expect that ps->req is null in this case, because there is no request received by kamailio. That results in xlog not doing anything.

In other words, I expect the event route being executed, just the action inside is doesn't do anything in this case.

Does this mean that I'll have to set a "faked" ps->req in order to get the event route executed?

that's the safe way. The event route is executed, but many functions that you can use inside config routing blocks require a non-null sip message structure. It is the case of xlog() for example, which simply returns -1 if request is null.

Ok! Can you suggest the safest and reasonable way to setup the request for this case?

Ah! No! Wait! The event route is executed within a tm callback via tmb.t_request() so I'd expect a valid ps->req,
don't you think so?

I've found how to change the code ... just testing the logic. I'll get back to you in case.

After a while I've found that I can pass a request using the uac_r.cbp field, so I've fixed the callback
to use the passed fields instead a straight int (previously mid==message id) but I'm not sure how to
build a fake sip_msg request regarding the given msilo dumped msg, could you please give me a
tips how to do so?

Cheers,
Roberto Fichera.