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@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 <abalas...@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-le...@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to > the sender! > Edit mailing list options or unsubscribe: >
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
