From abalashov@evaristesys.com Sun Dec  3 02:16:46 2023
From: Alex Balashov <abalashov@evaristesys.com>
To: sr-users@lists.kamailio.org
Subject: [SR-Users] Re: tsilo dependency on usrloc
Date: Sat, 02 Dec 2023 21:15:59 -0500
Message-ID: <A49D6026-4EBC-4D32-9C6A-0D3DE89CF771@evaristesys.com>
In-Reply-To:
 <CAFOaF_iLWnH=WS-nLD+F23rX7iXP-nsR9aoUfEKtqXBoHYZ0RQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0999113071=="

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

Hi Federico,

I certainly don't mean to presume upon your free time. :-)=20

But of course, either of those options would be wonderful! Of the two, I thin=
k the second function, addressing the transaction by index and label, would b=
e the most useful.

-- Alex

> On 2 Dec 2023, at 01:13, Federico Cabiddu <federico.cabiddu(a)gmail.com> wr=
ote:
>=20
> Hi Alex,
> sorry for the late reply. I had to revisit the tsilo code, long time withou=
t looking at it :)
> When I designed the module I had in mind what I considered a "natural" scen=
ario for the push notifications: the entity acting as a registrar being the o=
ne responsible for a call forking.
> Of course other scenarios have arisen which are not covered by the current =
implementation, one of which is to be able to add branches without the usrloc=
/registrar mechanism.
> We could add two new functions that do the same as ts_append and ts_append_=
to but without performing the look:
> - ts_append_no_lookup(ruri, [contact]): add to all the transactions stored =
for ruri a new branch for <contact> (if not specified extracted from the curr=
ent SIP message)
> - ts_append_to_no_lookup(tindex, tlabel, [contact]): add to the transaction=
 specified by tindex and tlabel  a new branch for <contact>=20
> Maybe names are a bit long but is to give the idea.
> Do you think that a solution like this would cover your (and others') scena=
rios?
> I can try to find the time to work on it :)
>=20
> Cheers,
>=20
> Federico
>=20
>=20
>=20
> On Tue, Nov 28, 2023 at 8:39=E2=80=AFPM Alex Balashov via sr-users <sr-user=
s(a)lists.kamailio.org> wrote:
> PS. It seems to me there are some kludgy options to work around this limita=
tion, i.e. to basically reinvent tsilo.=20
>=20
> They all boil down to suspending the transaction and using some sort of IPC=
 mechanism to queue new branch destinations, then, after some defined interva=
l, using some dequeueing mechanism as a semaphore to kick-start the forking p=
rocess.=20
>=20
> For instance, one could do this by hashing the RURI destination, transactio=
n index and label in htable, then suspending the transaction, then piling som=
e branches into it and then setting the expiration value of the RURI key to i=
mmediate, causing event_route[htable:expired:<table>] to kick off. Depending =
on where exactly that executes, this could resume the transaction, add the br=
anches and manage the forking. Or one could try some tricks with config locks=
, or mqueue's unique key mode.
>=20
> But none of these solutions allow the continuous drip of new serial forking=
 destinations into an active transaction. They all require suspending and wai=
ting a sufficient amount of time to believe oneself to have collected all the=
 potential destinations, then to reanimate. This is not necessarily how the r=
eal world works. These mechanisms are also quite complicated, and complexity =
breeds fragility.
>=20
> -- Alex
>=20
> > On 28 Nov 2023, at 13:38, Alex Balashov <abalashov(a)evaristesys.com> wro=
te:
> >=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=
 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"
> >=20
> > Why is this extensive coupling to usrloc necessary? This makes it impossi=
ble 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 mi=
d-registrar. What would make more sense is a generic mechanism that allows on=
e to "drip" new contacts into an existing transaction, whether suspended or a=
ctive.=20
> >=20
> > 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 t=
he transaction in question. The key parlour trick of `tsilo` is that it permi=
ts dripping new branches into a *different* transaction.
> >=20
> > 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.=20
> >=20
> > What is really wanted and needed for the downstream PN gateway use-case i=
s a means of extracting contacts from incoming registrations (or other source=
s, 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.
> >=20
> > Is this somehow possible by means other than tsilo? Am I overlooking some=
thing?
> >=20
> > Cheers,
> >=20
> > -- Alex
> >=20
> > --=20
> > Alex Balashov
> > Principal Consultant
> > Evariste Systems LLC
> > Web: https://evaristesys.com
> > Tel: +1-706-510-6800
> >=20
>=20
> --=20
> Alex Balashov
> Principal Consultant
> Evariste Systems LLC
> Web: https://evaristesys.com
> Tel: +1-706-510-6800
>=20
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to th=
e sender!
> Edit mailing list options or unsubscribe:

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


--===============0999113071==--