2 Dec
2023
2 Dec
'23
7:13 a.m.
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: