From abalashov@evaristesys.com Tue Nov 28 18:39:00 2023
From: Alex Balashov <abalashov@evaristesys.com>
To: sr-users@lists.kamailio.org
Subject: [SR-Users] tsilo dependency on usrloc
Date: Tue, 28 Nov 2023 13:38:36 -0500
Message-ID: <1AC48029-930E-43D0-BDEF-8B0DB7714EA4@evaristesys.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1633829215=="

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

Hi,

I wanted to revisit the topic of tsilo dependence on the location service. Al=
l three ts_append*() functions have the following quality:

- ts_append(): "performing a contact lookup on the table specified by the dom=
ain 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-end=
s an upstream registrar, requiring a kind of local shadow registrar or mid-re=
gistrar. What would make more sense is a generic mechanism that allows one to=
 "drip" new contacts into an existing transaction, whether suspended or activ=
e.=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 the t=
ransaction in question. The key parlour trick of `tsilo` is that it permits d=
ripping 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.=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, p=
otentially) without storing them in any fashion locally, without using or eve=
n loading usrloc, and just throwing them over the fence into a different tran=
saction.

Is this somehow possible by means other than tsilo? Am I overlooking somethin=
g?

Cheers,

-- Alex

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


--===============1633829215==--


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="===============0560386310=="

--===============0560386310==
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


--===============0560386310==--


From federico.cabiddu@gmail.com Sat Dec  2 06:14:50 2023
From: Federico Cabiddu <federico.cabiddu@gmail.com>
To: sr-users@lists.kamailio.org
Subject: [SR-Users] Re: tsilo dependency on usrloc
Date: Sat, 02 Dec 2023 07:13:55 +0100
Message-ID:
 <CAFOaF_iLWnH=WS-nLD+F23rX7iXP-nsR9aoUfEKtqXBoHYZ0RQ@mail.gmail.com>
In-Reply-To: <A96D132B-7B40-470A-ACF3-A16BB76D1A2F@evaristesys.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0579342902=="

--===============0579342902==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Hi Alex,
sorry for the late reply. I had to revisit the tsilo code, long time
without looking at it :)
When I designed the module I had in mind what I considered a "natural"
scenario for the push notifications: the entity acting as a registrar being
the one 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
current SIP message)
- ts_append_to_no_lookup(tindex, tlabel, [contact]): add to the transaction
specified by tindex and tlabel  a new branch for <contact>
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')
scenarios?
I can try to find the time to work on it :)

Cheers,

Federico



On Tue, Nov 28, 2023 at 8:39 PM Alex Balashov via sr-users <
sr-users(a)lists.kamailio.org> wrote:

> 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
>
> __________________________________________________________
> 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
> the sender!
> Edit mailing list options or unsubscribe:
>



--===============0579342902==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PGRpdiBkaXI9Imx0ciI+SGkgQWxleCw8ZGl2PnNvcnJ5IGZvciB0aGXCoGxhdGXCoHJlcGx5LiBJ
IGhhZCB0byByZXZpc2l0IHRoZSB0c2lsbyBjb2RlLCBsb25nIHRpbWUgd2l0aG91dCBsb29raW5n
IGF0IGl0IDopPC9kaXY+PGRpdj5XaGVuIEkgZGVzaWduZWQgdGhlIG1vZHVsZSBJIGhhZCBpbiBt
aW5kIHdoYXQgSSBjb25zaWRlcmVkIGEgJnF1b3Q7bmF0dXJhbCZxdW90OyBzY2VuYXJpbyBmb3Ig
dGhlIHB1c2ggbm90aWZpY2F0aW9uczogdGhlIGVudGl0eSBhY3RpbmcgYXMgYSByZWdpc3RyYXLC
oGJlaW5nIHRoZSBvbmUgcmVzcG9uc2libGUgZm9yIGEgY2FsbCBmb3JraW5nLjwvZGl2PjxkaXY+
T2YgY291cnNlIG90aGVyIHNjZW5hcmlvcyBoYXZlIGFyaXNlbiB3aGljaCBhcmUgbm90IGNvdmVy
ZWQgYnkgdGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24sIG9uZSBvZiB3aGljaCBpcyB0byBiZSBh
YmxlIHRvIGFkZCBicmFuY2hlcyB3aXRob3V0IHRoZSB1c3Jsb2MvcmVnaXN0cmFyIG1lY2hhbmlz
bS48L2Rpdj48ZGl2PldlIGNvdWxkIGFkZCB0d28gbmV3IGZ1bmN0aW9ucyB0aGF0IGRvIHRoZSBz
YW1lIGFzIHRzX2FwcGVuZCBhbmQgdHNfYXBwZW5kX3RvIGJ1dCB3aXRob3V0IHBlcmZvcm1pbmcg
dGhlIGxvb2s6PC9kaXY+PGRpdj4tIHRzX2FwcGVuZF9ub19sb29rdXAocnVyaSwgW2NvbnRhY3Rd
KTogYWRkIHRvIGFsbCB0aGUgdHJhbnNhY3Rpb25zIHN0b3JlZCBmb3IgcnVyaSBhIG5ldyBicmFu
Y2ggZm9yICZsdDtjb250YWN0Jmd0OyAoaWYgbm90IHNwZWNpZmllZCBleHRyYWN0ZWQgZnJvbSB0
aGUgY3VycmVudCBTSVAgbWVzc2FnZSk8L2Rpdj48ZGl2Pi0gdHNfYXBwZW5kX3RvX25vX2xvb2t1
cCh0aW5kZXgsIHRsYWJlbCwgW2NvbnRhY3RdKTogYWRkIHRvIHRoZSB0cmFuc2FjdGlvbiBzcGVj
aWZpZWQgYnkgdGluZGV4IGFuZCB0bGFiZWzCoCBhIG5ldyBicmFuY2ggZm9yICZsdDtjb250YWN0
Jmd0O8KgPC9kaXY+PGRpdj5NYXliZSBuYW1lcyBhcmUgYSBiaXQgbG9uZyBidXQgaXMgdG8gZ2l2
ZSB0aGUgaWRlYS48L2Rpdj48ZGl2PkRvIHlvdSB0aGluayB0aGF0IGEgc29sdXRpb24gbGlrZSB0
aGlzIHdvdWxkIGNvdmVyIHlvdXIgKGFuZCBvdGhlcnMmIzM5Oykgc2NlbmFyaW9zPzwvZGl2Pjxk
aXY+SSBjYW4gdHJ5IHRvIGZpbmQgdGhlIHRpbWUgdG8gd29yayBvbiBpdCA6KTwvZGl2PjxkaXY+
PGJyPjwvZGl2PjxkaXY+Q2hlZXJzLDwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+RmVkZXJpY288
L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rpdj48YnI+PGRpdiBjbGFzcz0i
Z21haWxfcXVvdGUiPjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5PbiBUdWUsIE5v
diAyOCwgMjAyMyBhdCA4OjM54oCvUE0gQWxleCBCYWxhc2hvdiB2aWEgc3ItdXNlcnMgJmx0Ozxh
IGhyZWY9Im1haWx0bzpzci11c2Vyc0BsaXN0cy5rYW1haWxpby5vcmciIHRhcmdldD0iX2JsYW5r
Ij5zci11c2Vyc0BsaXN0cy5rYW1haWxpby5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+PC9kaXY+PGJs
b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAu
OGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDox
ZXgiPlBTLiBJdCBzZWVtcyB0byBtZSB0aGVyZSBhcmUgc29tZSBrbHVkZ3kgb3B0aW9ucyB0byB3
b3JrIGFyb3VuZCB0aGlzIGxpbWl0YXRpb24sIGkuZS4gdG8gYmFzaWNhbGx5IHJlaW52ZW50IHRz
aWxvLiA8YnI+Cjxicj4KVGhleSBhbGwgYm9pbCBkb3duIHRvIHN1c3BlbmRpbmcgdGhlIHRyYW5z
YWN0aW9uIGFuZCB1c2luZyBzb21lIHNvcnQgb2YgSVBDIG1lY2hhbmlzbSB0byBxdWV1ZSBuZXcg
YnJhbmNoIGRlc3RpbmF0aW9ucywgdGhlbiwgYWZ0ZXIgc29tZSBkZWZpbmVkIGludGVydmFsLCB1
c2luZyBzb21lIGRlcXVldWVpbmcgbWVjaGFuaXNtIGFzIGEgc2VtYXBob3JlIHRvIGtpY2stc3Rh
cnQgdGhlIGZvcmtpbmcgcHJvY2Vzcy4gPGJyPgo8YnI+CkZvciBpbnN0YW5jZSwgb25lIGNvdWxk
IGRvIHRoaXMgYnkgaGFzaGluZyB0aGUgUlVSSSBkZXN0aW5hdGlvbiwgdHJhbnNhY3Rpb24gaW5k
ZXggYW5kIGxhYmVsIGluIGh0YWJsZSwgdGhlbiBzdXNwZW5kaW5nIHRoZSB0cmFuc2FjdGlvbiwg
dGhlbiBwaWxpbmcgc29tZSBicmFuY2hlcyBpbnRvIGl0IGFuZCB0aGVuIHNldHRpbmcgdGhlIGV4
cGlyYXRpb24gdmFsdWUgb2YgdGhlIFJVUkkga2V5IHRvIGltbWVkaWF0ZSwgY2F1c2luZyBldmVu
dF9yb3V0ZVtodGFibGU6ZXhwaXJlZDombHQ7dGFibGUmZ3Q7XSB0byBraWNrIG9mZi4gRGVwZW5k
aW5nIG9uIHdoZXJlIGV4YWN0bHkgdGhhdCBleGVjdXRlcywgdGhpcyBjb3VsZCByZXN1bWUgdGhl
IHRyYW5zYWN0aW9uLCBhZGQgdGhlIGJyYW5jaGVzIGFuZCBtYW5hZ2UgdGhlIGZvcmtpbmcuIE9y
IG9uZSBjb3VsZCB0cnkgc29tZSB0cmlja3Mgd2l0aCBjb25maWcgbG9ja3MsIG9yIG1xdWV1ZSYj
Mzk7cyB1bmlxdWUga2V5IG1vZGUuPGJyPgo8YnI+CkJ1dCBub25lIG9mIHRoZXNlIHNvbHV0aW9u
cyBhbGxvdyB0aGUgY29udGludW91cyBkcmlwIG9mIG5ldyBzZXJpYWwgZm9ya2luZyBkZXN0aW5h
dGlvbnMgaW50byBhbiBhY3RpdmUgdHJhbnNhY3Rpb24uIFRoZXkgYWxsIHJlcXVpcmUgc3VzcGVu
ZGluZyBhbmQgd2FpdGluZyBhIHN1ZmZpY2llbnQgYW1vdW50IG9mIHRpbWUgdG8gYmVsaWV2ZSBv
bmVzZWxmIHRvIGhhdmUgY29sbGVjdGVkIGFsbCB0aGUgcG90ZW50aWFsIGRlc3RpbmF0aW9ucywg
dGhlbiB0byByZWFuaW1hdGUuIFRoaXMgaXMgbm90IG5lY2Vzc2FyaWx5IGhvdyB0aGUgcmVhbCB3
b3JsZCB3b3Jrcy4gVGhlc2UgbWVjaGFuaXNtcyBhcmUgYWxzbyBxdWl0ZSBjb21wbGljYXRlZCwg
YW5kIGNvbXBsZXhpdHkgYnJlZWRzIGZyYWdpbGl0eS48YnI+Cjxicj4KLS0gQWxleDxicj4KPGJy
PgomZ3Q7IE9uIDI4IE5vdiAyMDIzLCBhdCAxMzozOCwgQWxleCBCYWxhc2hvdiAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOmFiYWxhc2hvdkBldmFyaXN0ZXN5cy5jb20iIHRhcmdldD0iX2JsYW5rIj5hYmFs
YXNob3ZAZXZhcmlzdGVzeXMuY29tPC9hPiZndDsgd3JvdGU6PGJyPgomZ3Q7IDxicj4KJmd0OyBI
aSw8YnI+CiZndDsgPGJyPgomZ3Q7IEkgd2FudGVkIHRvIHJldmlzaXQgdGhlIHRvcGljIG9mIHRz
aWxvIGRlcGVuZGVuY2Ugb24gdGhlIGxvY2F0aW9uIHNlcnZpY2UuIEFsbCB0aHJlZSB0c19hcHBl
bmQqKCkgZnVuY3Rpb25zIGhhdmUgdGhlIGZvbGxvd2luZyBxdWFsaXR5Ojxicj4KJmd0OyA8YnI+
CiZndDsgLSB0c19hcHBlbmQoKTogJnF1b3Q7cGVyZm9ybWluZyBhIGNvbnRhY3QgbG9va3VwIG9u
IHRoZSB0YWJsZSBzcGVjaWZpZWQgYnkgdGhlIGRvbWFpbiBwYXJhbWV0ZXIuJnF1b3Q7PGJyPgom
Z3Q7IC0gdHNfYXBwZW5kX2J5X2NvbnRhY3QoKTogJnF1b3Q7dGhlIGNvbnRhY3QgbG9va3VwIGlz
IHBlcmZvcm1lZCZxdW90Ozxicj4KJmd0OyAtIHRzX2FwcGVuZF90bygpOiAmcXVvdDtwZXJmb3Jt
aW5nIGEgY29udGFjdHMgbG9va3VwIG9uIHRoZSB0YWJsZSBzcGVjaWZpZWQgYnkgdGhlIGRvbWFp
biBwYXJhbWV0ZXImcXVvdDs8YnI+CiZndDsgPGJyPgomZ3Q7IFdoeSBpcyB0aGlzIGV4dGVuc2l2
ZSBjb3VwbGluZyB0byB1c3Jsb2MgbmVjZXNzYXJ5PyBUaGlzIG1ha2VzIGl0IGltcG9zc2libGUg
dG8gdXNlIGB0c2lsb2AgaW4gY2FzZSBvZiBwcm92aWRpbmcgYSBwdXNoLW5vdGlmaWNhdGlvbiBh
ZGQtb24gdGhhdCBmcm9udC1lbmRzIGFuIHVwc3RyZWFtIHJlZ2lzdHJhciwgcmVxdWlyaW5nIGEg
a2luZCBvZiBsb2NhbCBzaGFkb3cgcmVnaXN0cmFyIG9yIG1pZC1yZWdpc3RyYXIuIFdoYXQgd291
bGQgbWFrZSBtb3JlIHNlbnNlIGlzIGEgZ2VuZXJpYyBtZWNoYW5pc20gdGhhdCBhbGxvd3Mgb25l
IHRvICZxdW90O2RyaXAmcXVvdDsgbmV3IGNvbnRhY3RzIGludG8gYW4gZXhpc3RpbmcgdHJhbnNh
Y3Rpb24sIHdoZXRoZXIgc3VzcGVuZGVkIG9yIGFjdGl2ZS4gPGJyPgomZ3Q7IDxicj4KJmd0OyBL
YW1haWxpbyBoYXMgYSBtZWNoYW5pc20gdG8gYWRkIG1vcmUgYnJhbmNoZXMgdG8gYW4gZXhpc3Rp
bmcgdHJhbnNhY3Rpb24sIGJ1dCB0aGUgc2NvcGUgb2YgdGhhdCBtZWNoYW5pc20gaXMgb25seSBm
cm9tICppbnNpZGUqIHRoZSB2YW50YWdlIHBvaW50IG9mIHRoZSB0cmFuc2FjdGlvbiBpbiBxdWVz
dGlvbi4gVGhlIGtleSBwYXJsb3VyIHRyaWNrIG9mIGB0c2lsb2AgaXMgdGhhdCBpdCBwZXJtaXRz
IGRyaXBwaW5nIG5ldyBicmFuY2hlcyBpbnRvIGEgKmRpZmZlcmVudCogdHJhbnNhY3Rpb24uPGJy
PgomZ3Q7IDxicj4KJmd0OyB0c19hcHBlbmRfdG8oKSBhbG1vc3QgZG9lcyB0aGUgdHJpY2ssIHBy
b3ZpZGluZyBhIHRhcmdldCBpbmRleCBhbmQgbGFiZWwsIGJ1dCBpdCBqdXN0IGluc2lzdHMgb24g
ZG9pbmcgYSByZWdpc3RyYXIgbG9va3VwIHRvIHNvdXJjZSB0aGUgY29udGFjdHMuIDxicj4KJmd0
OyA8YnI+CiZndDsgV2hhdCBpcyByZWFsbHkgd2FudGVkIGFuZCBuZWVkZWQgZm9yIHRoZSBkb3du
c3RyZWFtIFBOIGdhdGV3YXkgdXNlLWNhc2UgaXMgYSBtZWFucyBvZiBleHRyYWN0aW5nIGNvbnRh
Y3RzIGZyb20gaW5jb21pbmcgcmVnaXN0cmF0aW9ucyAob3Igb3RoZXIgc291cmNlcywgcG90ZW50
aWFsbHkpIHdpdGhvdXQgc3RvcmluZyB0aGVtIGluIGFueSBmYXNoaW9uIGxvY2FsbHksIHdpdGhv
dXQgdXNpbmcgb3IgZXZlbiBsb2FkaW5nIHVzcmxvYywgYW5kIGp1c3QgdGhyb3dpbmcgdGhlbSBv
dmVyIHRoZSBmZW5jZSBpbnRvIGEgZGlmZmVyZW50IHRyYW5zYWN0aW9uLjxicj4KJmd0OyA8YnI+
CiZndDsgSXMgdGhpcyBzb21laG93IHBvc3NpYmxlIGJ5IG1lYW5zIG90aGVyIHRoYW4gdHNpbG8/
IEFtIEkgb3Zlcmxvb2tpbmcgc29tZXRoaW5nPzxicj4KJmd0OyA8YnI+CiZndDsgQ2hlZXJzLDxi
cj4KJmd0OyA8YnI+CiZndDsgLS0gQWxleDxicj4KJmd0OyA8YnI+CiZndDsgLS0gPGJyPgomZ3Q7
IEFsZXggQmFsYXNob3Y8YnI+CiZndDsgUHJpbmNpcGFsIENvbnN1bHRhbnQ8YnI+CiZndDsgRXZh
cmlzdGUgU3lzdGVtcyBMTEM8YnI+CiZndDsgV2ViOiA8YSBocmVmPSJodHRwczovL2V2YXJpc3Rl
c3lzLmNvbSIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9ldmFyaXN0
ZXN5cy5jb208L2E+PGJyPgomZ3Q7IFRlbDogKzEtNzA2LTUxMC02ODAwPGJyPgomZ3Q7IDxicj4K
PGJyPgotLSA8YnI+CkFsZXggQmFsYXNob3Y8YnI+ClByaW5jaXBhbCBDb25zdWx0YW50PGJyPgpF
dmFyaXN0ZSBTeXN0ZW1zIExMQzxicj4KV2ViOiA8YSBocmVmPSJodHRwczovL2V2YXJpc3Rlc3lz
LmNvbSIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9ldmFyaXN0ZXN5
cy5jb208L2E+PGJyPgpUZWw6ICsxLTcwNi01MTAtNjgwMDxicj4KPGJyPgpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPgpLYW1haWxp
byAtIFVzZXJzIE1haWxpbmcgTGlzdCAtIE5vbiBDb21tZXJjaWFsIERpc2N1c3Npb25zPGJyPgpU
byB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRvIDxhIGhyZWY9Im1haWx0bzpzci11c2Vycy1s
ZWF2ZUBsaXN0cy5rYW1haWxpby5vcmciIHRhcmdldD0iX2JsYW5rIj5zci11c2Vycy1sZWF2ZUBs
aXN0cy5rYW1haWxpby5vcmc8L2E+PGJyPgpJbXBvcnRhbnQ6IGtlZXAgdGhlIG1haWxpbmcgbGlz
dCBpbiB0aGUgcmVjaXBpZW50cywgZG8gbm90IHJlcGx5IG9ubHkgdG8gdGhlIHNlbmRlciE8YnI+
CkVkaXQgbWFpbGluZyBsaXN0IG9wdGlvbnMgb3IgdW5zdWJzY3JpYmU6PGJyPgo8L2Jsb2NrcXVv
dGU+PC9kaXY+Cg==

--===============0579342902==--


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="===============0148439153=="

--===============0148439153==
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


--===============0148439153==--