28 Nov
2023
28 Nov
'23
10:09 p.m.
PS. It seems to me there are some kludgy options to work around this limitation, i.e. to
basically reinvent tsilo.
They all boil down to suspending the transaction and using some sort of IPC mechanism to
queue new branch destinations, then, after some defined interval, using some dequeueing
mechanism as a semaphore to kick-start the forking process.
For instance, one could do this by hashing the RURI destination, transaction index and
label in htable, then suspending the transaction, then piling some branches into it and
then setting the expiration value of the RURI key to immediate, causing
event_route[htable:expired:<table>] to kick off. Depending on where exactly that
executes, this could resume the transaction, add the branches and manage the forking. Or
one could try some tricks with config locks, or mqueue's unique key mode.
But none of these solutions allow the continuous drip of new serial forking destinations
into an active transaction. They all require suspending and waiting a sufficient amount of
time to believe oneself to have collected all the potential destinations, then to
reanimate. This is not necessarily how the real world works. These mechanisms are also
quite complicated, and complexity breeds fragility.
-- Alex
On 28 Nov 2023, at 13:38, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Hi,
I wanted to revisit the topic of tsilo dependence on the location service. All three
ts_append*() functions have the following quality:
- ts_append(): "performing a contact lookup on the table specified by the domain
parameter."
- ts_append_by_contact(): "the contact lookup is performed"
- ts_append_to(): "performing a contacts lookup on the table specified by the domain
parameter"
Why is this extensive coupling to usrloc necessary? This makes it impossible to use
`tsilo` in case of providing a push-notification add-on that front-ends an upstream
registrar, requiring a kind of local shadow registrar or mid-registrar. What would make
more sense is a generic mechanism that allows one to "drip" new contacts into an
existing transaction, whether suspended or active.
Kamailio has a mechanism to add more branches to an existing transaction, but the scope
of that mechanism is only from *inside* the vantage point of the transaction in question.
The key parlour trick of `tsilo` is that it permits dripping new branches into a
*different* transaction.
ts_append_to() almost does the trick, providing a target index and label, but it just
insists on doing a registrar lookup to source the contacts.
What is really wanted and needed for the downstream PN gateway use-case is a means of
extracting contacts from incoming registrations (or other sources, potentially) without
storing them in any fashion locally, without using or even loading usrloc, and just
throwing them over the fence into a different transaction.
Is this somehow possible by means other than tsilo? Am I overlooking something?
Cheers,
-- Alex
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800