From abalashov@evaristesys.com Tue Nov 28 19:10:08 2023
From: Alex Balashov <abalashov@evaristesys.com>
To: sr-users@lists.kamailio.org
Subject: [SR-Users] Re: tsilo dependency on usrloc
Date: Tue, 28 Nov 2023 14:09:40 -0500
Message-ID: <A96D132B-7B40-470A-ACF3-A16BB76D1A2F@evaristesys.com>
In-Reply-To: <1AC48029-930E-43D0-BDEF-8B0DB7714EA4@evaristesys.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0082874056=="

--===============0082874056==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

PS. It seems to me there are some kludgy options to work around this limitati=
on, i.e. to basically reinvent tsilo.=20

They all boil down to suspending the transaction and using some sort of IPC m=
echanism to queue new branch destinations, then, after some defined interval,=
 using some dequeueing mechanism as a semaphore to kick-start the forking pro=
cess.=20

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 imm=
ediate, causing event_route[htable:expired:<table>] to kick off. Depending on=
 where exactly that executes, this could resume the transaction, add the bran=
ches 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 d=
estinations into an active transaction. They all require suspending and waiti=
ng a sufficient amount of time to believe oneself to have collected all the p=
otential destinations, then to reanimate. This is not necessarily how the rea=
l world works. These mechanisms are also quite complicated, and complexity br=
eeds fragility.

-- Alex

> On 28 Nov 2023, at 13:38, Alex Balashov <abalashov(a)evaristesys.com> wrote:
>=20
> Hi,
>=20
> I wanted to revisit the topic of tsilo dependence on the location service. =
All three ts_append*() functions have the following quality:
>=20
> - ts_append(): "performing a contact lookup on the table specified by the d=
omain parameter."
> - ts_append_by_contact(): "the contact lookup is performed"
> - ts_append_to(): "performing a contacts lookup on the table specified by t=
he domain parameter"
>=20
> Why is this extensive coupling to usrloc necessary? This makes it impossibl=
e to use `tsilo` in case of providing a push-notification add-on that front-e=
nds 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 act=
ive.=20
>=20
> Kamailio has a mechanism to add more branches to an existing transaction, b=
ut 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.
>=20
> ts_append_to() almost does the trick, providing a target index and label, b=
ut it just insists on doing a registrar lookup to source the contacts.=20
>=20
> 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 e=
ven loading usrloc, and just throwing them over the fence into a different tr=
ansaction.
>=20
> Is this somehow possible by means other than tsilo? Am I overlooking someth=
ing?
>=20
> Cheers,
>=20
> -- Alex
>=20
> --=20
> Alex Balashov
> Principal Consultant
> Evariste Systems LLC
> Web: https://evaristesys.com
> Tel: +1-706-510-6800
>=20

--=20
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800


--===============0082874056==--