On Wed, Apr 15, 2020 at 08:38:42AM -0400, Luis Rojas G. wrote:
Thanks for all the details. Wow, such nice implementation. It requires a deep knowledge of Kamailio.
Well, thank you -- I think that's much too generous. :-)
I see, this is the part where the transaction is saved.
mq_add("reinvite_q", "$T(id_index):$T(id_label)", "");
I didn't know much about pseudo-variables. I am reading now.
https://www.kamailio.org/wiki/cookbooks/5.3.x/pseudovariables#tmx_module_pse...
Pseudovariables are a confusing term, laden with historical baggage.
Historically, PVs referred to specific (and mostly read-only) variables which target parts of the message buffer, e.g.
https://www.kamailio.org/wiki/cookbooks/5.3.x/pseudovariables#ct_-_contact_h...
But now they just refer to variables of all kinds, including the namespace containers exposed by different modules (e.g. $T(...), $shv(...), $dlg_ctx(...)), $vars, $avps, you name it.
I guess, this approach could help me also in case of replies, not just requests, to add a delay to 200 OK to Invite.
I'm not sure that's possible. Remember that the request route is fully imperative; a request is dropped into them and the list of actions in the config script determines what happens to it, including any relaying (or lack thereof).
onreply_routes, by contrast, are callbacks/hooks from normal, built-in transaction-stateful behaviour; they expose the reply and allow you to modify or drop it, but otherwise they are optional, because the proxy already has an automatic reply-handling behaviour which will play out without manual invocation from you.
By the way, I assigned a value to "async_workers", and now the Invite (I was delaying any Invite, not just reinvite, just to test the api) is propagated delayed, which is great, but at the same time a
SIP/2.0 500 I'm terribly sorry, server error occurred (1/TM)
This sounds like possibly an attempt to relay twice, but I'm not sure.
-- Alex