Hi Federico, I certainly don't mean to presume upon your free time. :-)
But of course, either of those options would be wonderful! Of the two, I think the second function, addressing the transaction by index and label, would be the most useful. -- Alex > On 2 Dec 2023, at 01:13, Federico Cabiddu <federico.cabi...@gmail.com> wrote: > > 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: -- 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:
