From dries@degendt.com Wed Nov 29 21:02:49 2023
From: dries@degendt.com
To: sr-users@lists.kamailio.org
Subject: [SR-Users] No access to variables within timer route
Date: Wed, 29 Nov 2023 21:02:40 +0000
Message-ID: <170129176081.1570.7772619828783390214@main.kamailio.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1602807357=="

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

Hi,

I have a timer which is called each 5 seconds:
modparam("timer", "declare_timer", "REFRESH_CALLSTATE_TIMER=3DREFRESH_CALLSTA=
TE_TIMER,5000,slow");

I'm enabling setting the variable "testvar" and enabling the timer when an IN=
VITE is received:
if (is_method("INVITE|ACK|UPDATE|CANCEL|BYE")) {
    $var(testvar) =3D "blablabla";
    timer_enable("REFRESH_CALLSTATE_TIMER", "1");
...

route[REFRESH_CALLSTATE_TIMER] {
	xlog("L_INFO", "Testvariable: $var(test)\n");
}

However, the variable is always 0:
INFO: <script>: Testvariable: 0

I've also tried printing pseudovariables like $ci, $du but nothinh seems acce=
ssible. Is there a workaround for this?

Best regards,
Dries

--===============1602807357==--


From abalashov@evaristesys.com Wed Nov 29 21:34:52 2023
From: Alex Balashov <abalashov@evaristesys.com>
To: sr-users@lists.kamailio.org
Subject: [SR-Users] Re: No access to variables within timer route
Date: Wed, 29 Nov 2023 16:34:28 -0500
Message-ID: <3BDD4FA6-2B1B-40E5-8E53-B86E9C828680@evaristesys.com>
In-Reply-To: <170129176081.1570.7772619828783390214@main.kamailio.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0306956770=="

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

Hi,

It is important to know that the scope of $var(...) is per-process[1], and ti=
mer functions run in a different process.=20

When REFRESH_CALLSTATE_TIMER runs, it is not in response to any particular SI=
P message or call, and it does not know the context of any particular SIP mes=
sage or call.=20

-- Alex

[1] Which also has unexpected consequences when a different SIP message hits =
the same process in which a $var() was set before; they are process-persisten=
t, as the documentation notes.

> On 29 Nov 2023, at 16:02, dries--- via sr-users <sr-users(a)lists.kamailio.=
org> wrote:
>=20
> Hi,
>=20
> I have a timer which is called each 5 seconds:
> modparam("timer", "declare_timer", "REFRESH_CALLSTATE_TIMER=3DREFRESH_CALLS=
TATE_TIMER,5000,slow");
>=20
> I'm enabling setting the variable "testvar" and enabling the timer when an =
INVITE is received:
> if (is_method("INVITE|ACK|UPDATE|CANCEL|BYE")) {
>    $var(testvar) =3D "blablabla";
>    timer_enable("REFRESH_CALLSTATE_TIMER", "1");
> ...
>=20
> route[REFRESH_CALLSTATE_TIMER] {
> xlog("L_INFO", "Testvariable: $var(test)\n");
> }
>=20
> However, the variable is always 0:
> INFO: <script>: Testvariable: 0
>=20
> I've also tried printing pseudovariables like $ci, $du but nothinh seems ac=
cessible. Is there a workaround for this?
>=20
> Best regards,
> Dries
> __________________________________________________________
> 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


--===============0306956770==--


From dries@degendt.com Wed Nov 29 21:36:19 2023
From: dries@degendt.com
To: sr-users@lists.kamailio.org
Subject: [SR-Users] Re: No access to variables within timer route
Date: Wed, 29 Nov 2023 21:36:10 +0000
Message-ID: <170129377026.1570.14640202322819371530@main.kamailio.org>
In-Reply-To: <170129176081.1570.7772619828783390214@main.kamailio.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1453114982=="

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

Sorry, please ignore the variable name typo in the "REFRESH_CALLSTATE_TIMER" =
route in my initial post.

The issue still stands however.=20

route[REFRESH_CALLSTATE_TIMER] {
	xlog("L_INFO", "Testvariable: $var(testvar)\n");
}

I've also tried enabling the timer on start as well  as attempting to use $av=
p instead. All called variables within the route are either 0 or null?

--===============1453114982==--


From bkaufman@bcmone.com Thu Nov 30 14:03:44 2023
From: Ben Kaufman <bkaufman@bcmone.com>
To: sr-users@lists.kamailio.org
Subject: [SR-Users] Re: No access to variables within timer route
Date: Thu, 30 Nov 2023 14:03:28 +0000
Message-ID: <DM4PR11MB540758983B0CC67B5055D425A482A@DM4PR11MB5407.namprd11.prod.outlook.com>
In-Reply-To: <170129377026.1570.14640202322819371530@main.kamailio.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0136643910=="

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

From the rtimer documentation overview:

>   The module executes route blocks on a timer base. It can create new timer=
 processes and execute many route blocks on same timer.
>   A static faked SIP message is given as parameter to called functions, so =
all functions available for REQUEST_ROUTE can be used.


It runs in it's own processes, and as Alex noted $var() is per process.  It's=
 not clear if the process re-spawns so setting a variable inside the timer ac=
tion will be retained through multiple executions or not.
As for $avp()s, along with $xavp()s and their assorted variants, these are sc=
oped to a SIP transaction, and the timer shouldn't be handling a transaction.

Shared variables and hashtables should be available inside this route, though.

It might be good to clarify what your goal is (why you expect the variables t=
o have values in this route).


-----Original Message-----
From: dries--- via sr-users <sr-users(a)lists.kamailio.org>=20
Sent: Wednesday, November 29, 2023 3:36 PM
To: sr-users(a)lists.kamailio.org
Cc: dries(a)degendt.com
Subject: [SR-Users] Re: No access to variables within timer route

CAUTION: This email originated from outside the organization. Do not click li=
nks or open attachments unless you recognize the sender and know the content =
is safe.


Sorry, please ignore the variable name typo in the "REFRESH_CALLSTATE_TIMER" =
route in my initial post.

The issue still stands however.

route[REFRESH_CALLSTATE_TIMER] {
        xlog("L_INFO", "Testvariable: $var(testvar)\n"); }

I've also tried enabling the timer on start as well  as attempting to use $av=
p instead. All called variables within the route are either 0 or null?
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe sen=
d 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:

--===============0136643910==--


From dries@degendt.com Thu Nov 30 14:30:36 2023
From: dries@degendt.com
To: sr-users@lists.kamailio.org
Subject: [SR-Users] Re: No access to variables within timer route
Date: Thu, 30 Nov 2023 14:30:27 +0000
Message-ID: <170135462757.1570.5359339418313947418@main.kamailio.org>
In-Reply-To: =?utf-8?q?=3CDM4PR11MB540758983B0CC67B5055D425A482A=40DM4PR11MB?=
 =?utf-8?q?5407=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2075450686=="

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

Hi Ben,

I'll try my best to explain the use case here.

I have a direct trunk between our Asterisk and Kamailio servers. My goal is t=
hat when an agent is already in call, he doesn't get prompted with another in=
coming call on either of his devices. So Asterisk is supposed to perform a re=
dis check each time a call goes through the Asterisk queue.

Since Asterisk can't determine the device state here, I've set up a redis clu=
ster which is supposed to keep track of the agent's call state. For each INVI=
TE in Kamilio, I'm storing a key into redis based on the agent's number, for =
example "callstate_242680". The value is the call-id.
When a BYE/CANCEL is received, I'm retrieving the particular key and comparin=
g the current call-id agains the call-id in the redis object. If it matches, =
I'm deleting the object so the extension is "available" again.

This works pretty good but sometimes the keys are stored way too long in case=
 a BYE/CANCEL was missed (for example, restart of Kamailio process, network i=
nterruptions, ...).
I was thinking of setting a redis expiration time for each key, which would b=
e prolonged by the timer running in each call transaction. That way I could r=
etrieve the agent's number and increase the expiration of the matching redis =
key. I don't think shared memory would be possible since I can't identify the=
 call here.

As an alternative, I'm thinking of keeping track of dialogs using dlg_manage(=
) and also store these into a local redis server (since db_redis doesn't seem=
 to have redis cluster support). That way I can use a timer block to retrieve=
 all the stored dialogs and compare them to the stored callstate keys. I've n=
oticed however that the tracking of dialogs also depends of that BYE/CANCEL h=
owever so I don't think it's very usefull.

An alternative method could be to update the redis object in case of a period=
ic ACK but that's no guaruantee. I also don't want the agent to be wrongfully=
 "busy" for too long.

I'm still trying to fit all the pieces together, I was just hoping if anyone =
could confirm this is a correct approach?

--===============2075450686==--


From bkaufman@bcmone.com Thu Nov 30 19:54:07 2023
From: Ben Kaufman <bkaufman@bcmone.com>
To: sr-users@lists.kamailio.org
Subject: [SR-Users] Re: No access to variables within timer route
Date: Thu, 30 Nov 2023 19:53:48 +0000
Message-ID: <DM4PR11MB5407ABE5A021D7FA1989020AA482A@DM4PR11MB5407.namprd11.prod.outlook.com>
In-Reply-To: <170135462757.1570.5359339418313947418@main.kamailio.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1948976687=="

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

What I'm not clear on from your example is the use of the timer:

- Kamailio gets an invite, write a record to redis where the key identifies t=
he user.
- On call teardown, find the key and delete it.

What is the timer route doing?  It should be able to read redis.

-----Original Message-----
From: dries--- via sr-users <sr-users(a)lists.kamailio.org>=20
Sent: Thursday, November 30, 2023 8:30 AM
To: sr-users(a)lists.kamailio.org
Cc: dries(a)degendt.com
Subject: [SR-Users] Re: No access to variables within timer route

CAUTION: This email originated from outside the organization. Do not click li=
nks or open attachments unless you recognize the sender and know the content =
is safe.


Hi Ben,

I'll try my best to explain the use case here.

I have a direct trunk between our Asterisk and Kamailio servers. My goal is t=
hat when an agent is already in call, he doesn't get prompted with another in=
coming call on either of his devices. So Asterisk is supposed to perform a re=
dis check each time a call goes through the Asterisk queue.

Since Asterisk can't determine the device state here, I've set up a redis clu=
ster which is supposed to keep track of the agent's call state. For each INVI=
TE in Kamilio, I'm storing a key into redis based on the agent's number, for =
example "callstate_242680". The value is the call-id.
When a BYE/CANCEL is received, I'm retrieving the particular key and comparin=
g the current call-id agains the call-id in the redis object. If it matches, =
I'm deleting the object so the extension is "available" again.

This works pretty good but sometimes the keys are stored way too long in case=
 a BYE/CANCEL was missed (for example, restart of Kamailio process, network i=
nterruptions, ...).
I was thinking of setting a redis expiration time for each key, which would b=
e prolonged by the timer running in each call transaction. That way I could r=
etrieve the agent's number and increase the expiration of the matching redis =
key. I don't think shared memory would be possible since I can't identify the=
 call here.

As an alternative, I'm thinking of keeping track of dialogs using dlg_manage(=
) and also store these into a local redis server (since db_redis doesn't seem=
 to have redis cluster support). That way I can use a timer block to retrieve=
 all the stored dialogs and compare them to the stored callstate keys. I've n=
oticed however that the tracking of dialogs also depends of that BYE/CANCEL h=
owever so I don't think it's very usefull.

An alternative method could be to update the redis object in case of a period=
ic ACK but that's no guaruantee. I also don't want the agent to be wrongfully=
 "busy" for too long.

I'm still trying to fit all the pieces together, I was just hoping if anyone =
could confirm this is a correct approach?
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe sen=
d 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:

--===============1948976687==--


From dries@degendt.com Thu Nov 30 20:12:12 2023
From: dries@degendt.com
To: sr-users@lists.kamailio.org
Subject: [SR-Users] Re: No access to variables within timer route
Date: Thu, 30 Nov 2023 20:12:04 +0000
Message-ID: <170137512473.1570.11052193782945103037@main.kamailio.org>
In-Reply-To: =?utf-8?q?=3CDM4PR11MB5407ABE5A021D7FA1989020AA482A=40DM4PR11MB?=
 =?utf-8?q?5407=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1865215074=="

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

So the initial idea was to prolonge the expiry of the redis key within the ti=
mer. The expiration would be set to a value a bit higher than the timer inter=
val. At each timer iteration, the key would be renewed.
That way, if a call teardown occurs because of an unexpected event (so no BYE=
/CANCEL), the redis object would expire itself because the timer would stop r=
unning (and thus renewing the key) if the call transaction had ended?
However, I can't do that since I need to get the call-id/extension within the=
 timer route to pick the right key.

So my alternative would be to store the dialogs into redis and loop over thos=
e within the timer to compare them to the existing callstate keys. If a dialo=
g would no longer be known, I could delete the matching callstate key. Howeve=
r, it appears that the dialogs aren't cleaned up during unexpected events so =
it's of no use neither?

Regards

--===============1865215074==--