[SR-Users] Re: tsilo dependency on usrloc
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 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 (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 > 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 > 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:] 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 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 > >
[SR-Users] Re: tsilo dependency on usrloc
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 (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 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:] 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 > 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] Re: tsilo dependency on usrloc
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:] 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 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:
