that you've really thought this through. :-) This is the hard work
the dialog module does.
-- Alex
> On 26 Jan 2024, at 15:00, Alex Balashov wrote:
>
> There are some real risks with taking dialog state transitions into your own
> hands via this rather crude method.
>
&
sues with that?
>
> Thanks,
> Stefan
>
>
> ___
> Kamailio (SER) - Development Mailing List
> To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: ht
st
>> To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
> ___
> Kamailio (SER) - Development Mailing List
> To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
W
Oh, okay! Did not know. Sorry.—Sent from mobile, apologies for brevity and
errors.On Jul 27, 2023, at 2:30 AM, Daniel-Constantin Mierla ***@***.***>
wrote:
This is not a bug, but how it is designed/supported by the index part, which
can be a number or a variable, not an expression. Same is for
Running `5.7.1:441300`, trying to loop through the results of an `HGETALL`
operation in Redis:
```
127.0.0.1:6379[1]> keys *
1) "customer_params:14045551212:1.1.1.1"
127.0.0.1:6379[1]> hgetall customer_params:14045551212:1.1.1.1
1) "auth_ha1"
2) "9febe8cf72c6bd063b8978cded892e4bb"
```
This
t;
> --
> Henning Westerholt - https://skalatan.de/blog/
> Kamailio services - https://gilawa.com
>
> -Original Message-
> From: Alex Balashov
> Sent: Thursday, January 5, 2023 3:59 PM
> To: Henning Westerholt
> Cc: Kamailio (SER) - Users Mailing List
> Subj
Ah, okay. Personally, it seems to me the real problem is in the documentation's
claim that `reload_delta` creates separation between "RPC reloads", vs. no
clear conception of what an "RPC reload" is. In thinking about it generally, I
would expect such a reload to encompass both tables.
--
You would be correct in that `rpc_trusted_reload()` and `rpc_address_reload()`
call the same `rpc_check_reload()` function, which uses a single timer. So,
calling a reload on either of those would reset the timer.
But why do you want to reload them separately? Does it matter?
--
Reply to
When relaying this `200 OK` repeatedly with calls to `rtpengine_answer()`
failing because all RTPEngines in a set are unreachable...
```
Dec 8 06:24:38 gw kamailio[4823]: ERROR: rtpengine [rtpengine.c:2960]:
select_rtpp_node(): rtpengine failed to select new for calllen=36
on in the city center.
>
>
> Y!
>
> Super!
>
> --
> Sincerely,
>
> Giovanni Maruzzelli
> OpenTelecom.IT
> cell: +39 347 266 56 18
>
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
a -- www.linkedin.com/in/miconda
>
>
> ___
> Kamailio (SER) - Development Mailing List
> sr-dev@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
--
Alex Balashov | Principal | Evariste Systems
e to register and wait for calls, so another
> sipexer instance can be used for register and initiate calls.
>
> Writing the sip traffic in a pcap file is something that I would like to
> add as well.
>
> Cheers,
> Daniel
>
>> On 14.02.22 19:27, Alex
s
> WebSocket transport in all platforms.
>
> -- Juha
>
> ___
> Kamailio (SER) - Development Mailing List
> sr-dev@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
--
Alex Balashov | Principal | Evar
all
>
>
> Kamailio 5.5.2 on debian bullseye
> rtpengine 10.0.1.8 on debian bullseye
>
> Thanks.
> ___
> Kamailio (SER) - Development Mailing List
> sr-dev@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr
Very useful! Thank you!!
—
Sent from mobile, with due apologies for brevity and errors.
> On Aug 27, 2021, at 12:31 PM, Daniel-Constantin Mierla
> wrote:
>
> Module: kamailio
> Branch: master
> Commit: 697f34d484e1507b480a89c11db8b86c923ea084
> URL:
>
Now that is a very useful contribution! Thank you!
—
Sent from mobile, with due apologies for brevity and errors.
> On Oct 19, 2020, at 9:20 AM, Alex Hermann wrote:
>
>
> Pre-Submission Checklist
>
> Commit message has the format required by CONTRIBUTING guide
> Commits are split per
Very useful! Saves a lot of effort in having to do this manually all over the
place. Thank you!
—
Sent from mobile, with due apologies for brevity and errors.
> On Oct 14, 2020, at 9:56 AM, Daniel-Constantin Mierla
> wrote:
>
> Module: kamailio
> Branch: master
> Commit:
or whether this is
unexpected behaviour.
Thanks,
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
___
Kamailio (SER) - Development
That really is an excellent feature, thank you for putting it together!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
And this happens via the normal usrloc timer processes, right?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Very nice feature, cheers for that!
But just to be clear, how do the contact bindings get aged out, in the absence
of delete operations pushed across DMQ? Are they subject to the same local
`usrloc` expiration logic in that case?
--
You are receiving this because you are subscribed to this
Submitting this on behalf of Jacob Greene, who posted a day or two ago:
https://lists.kamailio.org/pipermail/sr-users/2020-May/109315.html
Version in production is Debian 9 and Kamailio 5.3.4 from Debian packages:
```
ii kamailio5.3.4+bpo9amd64
I manually cherry-picked the patch into my clone of 5.3 before it was
backported, and haven’t had a crash since.
However, I also hadn’t had a crash the few days prior.
So, it remains to be seen what happens. But I am optimistic this will fix the
issue. Thank you very much to you both!
—
Sent
@miconda To answer a few other questions:
1. I always set `$http_req(suspend) = 1` on async HTTP client transactions;
2. There are no `event_routes` anywhere;
3. The flow is complex, though. After this async HTTP query, there is another
_synchronous_ HTTP query using the normal `http_client`
Hi, thank you very much for investigating this!
Unfortunately, the causes of the crash do not appear to arise dependably; as
luck has it, there hasn't been one in the days since I submitted this issue.
So, all I can do is cherry-pick this patch into the source and hope for the
best.
I will
Just had another crash -- identical backtrace; it seems any attempt to access
this AVP explodes:
```
(gdb) print *avp
Cannot access memory at address 0xabcdefed
```
```
Program terminated with signal 11, Segmentation fault.
#0 0x005d479b in match_by_name (avp=0xabcdefed, id=45,
Hi -- thanks for the response!
Alas, nothing has really changed that I know of.
Actually, this is a scenario where multiple HTTP queries are being run as well;
this is the first stage, but subsequently the scenario is more complicated and
requires use of the synchronous 'http_client', so it's
Version: 5.3.3 `065668`
Platform: CentOS 7 (3.10.0-862.14.4.el7.x86_64)
I seem to have a persistent intermittent crash on all five gateways which use
`http_async_client` to query an HTTP API.
In all cases, the crash is on attempt to access or reference an AVP called
`$avp(is_subscribe)`:
```
.com
> phone: +34669448337
> ___
> Kamailio (SER) - Development Mailing List
> sr-dev@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-70
If you didn’t get the answer you wanted on the users list, posting to the dev
list is not the socially correct alternative strategy. The dev list is for
project development issues. Moreover, you are reposting an identical question,
suggesting that you did not consider the answers you have
t; Commit: ef8238a58dc901904e53655cf9e14028fd190c2b
> URL:
> https://github.com/kamailio/kamailio/commit/ef8238a58dc901904e53655cf9e14028fd190c2b
>
> Author: Alex Balashov
> Committer: Henning Westerholt
> Date: 2020-02-21T17:26:43+01:00
>
> usrloc: Updated docs for 'timer_procs' parameter
Sorry!
—
Sent from mobile, with due apologies for brevity and errors.
> On Feb 21, 2020, at 2:17 AM, Henning Westerholt wrote:
>
> Hello,
>
> as discussed in https://github.com/kamailio/kamailio/commit/
> 5750b405e78de7d2f701708f9c41126c3173d8f5 - commit author Alex Bal
No worries. Thanks!
—
Sent from mobile, with due apologies for brevity and errors.
> On Feb 20, 2020, at 12:25 PM, Henning Westerholt
> wrote:
>
>
> Hi Alex, as you pushed already to the public git master, it is better not to
> change it now as other people have already checked it out. The
Argh, I accidentally committed this without setting `git config user.email` &
`user.name` on my repository clone, sorry. I've amended the commit on my side
but can't push it because it's a non-FF. Can this be rebased or otherwise fixed?
--
You are receiving this because you are subscribed to
On Kamailio 5.3.0 (`ad1905`) on CentOS 7, with `libcurl` 7.29.0-46, an
`http_connect()` request to an unresponsive server...
```
http_connect("stuff", "/url, "$var(http_res)");
```
.. correctly sets `$var(http_res)` to `28`, which is an operation timeout per
Module: kamailio
Branch: master
Commit: e9545ae1e490ff768270d03ea28f14b751d2c132
URL:
https://github.com/kamailio/kamailio/commit/e9545ae1e490ff768270d03ea28f14b751d2c132
Author: Alex Balashov
Committer: Alex Balashov
Date: 2019-11-09T01:17:44-05:00
evapi: Removed cast of bind port to short
I think this has evolved into an issue that is quite clearly not a Kamailio
issue, so I am going to close it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #2075.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2075#event-2666436417___
Kamailio (SER) - Development Mailing List
This has evolved to a goose chase into `app_perl`, I think, as it seems to be
occurring during an interpreter reload, possibly upon reaching `reset_cycles`.
Stand by for further info.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
I did get this sequence of events on the last crash:
```
Sep 26 14:01:30 switch /sbin/kamailio[15614]: ERROR: [receive.c:173]:
receive_msg(): core parsing of SIP message failed (x.x.x.x:/1)
Sep 26 14:01:33 switch /sbin/kamailio[15614]: ERROR: tm [t_reply.c:533]:
_reply_light(): ERROR:
Yep, it's definitely occurring in one of the UDP receivers. The problem is that
all I get out of GDB is a normal exit:
```
(gdb) Continuing.
Program exited with code 0377.
```
And because it's detached, I don't know exactly what the context is and so it's
hard to track down where the exit is
The plot thickens. It looks like the problematic message actually came in on
one of the UDP receivers.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Yeah, so this issue is mis-titled. It looks like every EOF is followed by:
```
Sep 26 13:09:01 softswitch1b /sbin/kamailio[628]: ALERT: [main.c:740]:
handle_sigs(): child process 666 exited normally, status=255
```
And that is one of the TCP workers. So, for some reason they just keep exiting,
I attached an `strace` to the main TCP receiver process, and saw this preceding
the crash:
```
recvmsg(10, {msg_name(0)=NULL, msg_iov(1)=[{"", 16}], msg_controllen=0,
msg_flags=0}, MSG_DONTWAIT) = 0
```
This then engenders the following sequence of events:
```
sendto(5, "<26>Sep 26 13:09:01
No, and no.
—
Sent from mobile, with due apologies for brevity and errors.
> On Sep 26, 2019, at 2:18 AM, Henning Westerholt
> wrote:
>
> Do you get also a second error message from the handle_io function? Is there
> an error from errno printed?
>
> —
> You are receiving this because you
Running `Kamailio 4.4.7:97f308` with heavy `app_perl` usage, `usrloc`
(`db_mode` 3) and not much else.
After an upgrade from 4.1, getting periodic death like this:
```
Sep 25 20:54:28 switch /sbin/kamailio[29771]: CRITICAL: [pass_fd.c:277]:
receive_fd(): EOF on 9
```
Also happens on 4.2.x.
lio (SER) - Users Mailing List
> sr-us...@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_
>
> > ___
> > Kamailio (SER) - Development Mailing
> > Listsr-dev@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
> >
> > --
> > Henning Westerholt - https://skalatan.de/blog/
> > Kamail
}
> + break;
> + default:
> + goto error;
> + }
> + sp->pvp.pvn.type = PV_NAME_INTSTR;
> + sp->pvp.pvn.u.isname.type = 0;
> +
> + return 0;
> +
> +error:
> + LM_ERR("unknown PV ltt key: %.*
Thank you very much for this!!
--
Sent from mobile. Apologies for brevity and errors.
-Original Message-
From: Daniel-Constantin Mierla
To: sr-dev@lists.kamailio.org
Sent: Tue, 09 Oct 2018 10:19 PM
Subject: [sr-dev] git:master:5d0494f9: sl: new pv $ltt(key) - return local
generated
is not being
appropriately sourced by the init script? Have you checked the init
script to make sure it doesn't expect to use /etc/sysconfig/rtpproxy or
some other path for the inclusion of these configuration options into
the startup environment instead?
If rtpproxy cannot be reached on its control so
4x and 5x installed in seperate servers. Can you tell me
>where should i start to set up this.
>
>On Thu, Aug 9, 2018 at 2:20 PM Alex Balashov
>
>wrote:
>
>> There are not any quick solutions or shortcuts to elementary
>> understanding of what you are doing, no.
>>
uments. But none of them
> tells the correct and complete path to set up this rtpproxy. I need to
> solve this quick.
>
> On Wed, Aug 8, 2018 at 3:48 PM Alex Balashov
> wrote:
>
> > On Wed, Aug 08, 2018 at 01:36:14PM +0530, ANOOP V M wrote:
> >
> > >
On Wed, Aug 08, 2018 at 01:36:14PM +0530, ANOOP V M wrote:
> Aug 8 07:34:51 ip-172-30-0-26 rtpproxy[1521]: ERR:create_twinlistener:
> can't bind to the IPv4 port 63826: Cannot assign requested address
It seems to me the error is staring you in the face. :-)
--
Alex Balashov | Pri
Reply to this email directly or view it on GitHub:
> https://github.com/kamailio/kamailio/pull/1534
> _______
> Kamailio (SER) - Development Mailing List
> sr-dev@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listin
Notwithstanding the fact that not all operations work in async routes, I would
be curious to know why distributing the workload into a pool of async workers
is "still a bottleneck of sorts". Are there architectural reasons for this that
I am failing to consider?
Also: I use set_dlg_profile(),
Module: kamailio
Branch: master
Commit: a1648fe782bf5c4a65c249403c3e13f8448bdfb1
URL:
https://github.com/kamailio/kamailio/commit/a1648fe782bf5c4a65c249403c3e13f8448bdfb1
Author: Alex Balashov <abalas...@evaristesys.com>
Committer: Alex Balashov <abalas...@evaristesys.com>
Date: 2018
ds to more consistent, maintainable code and more predictable
outcomes, while providing a level of flexibility people have come to
expect with the RDBM-backed modules.
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evari
This sounds like either an empty route block, or, more likely, a curly brace
imbalance.
-- Alex
--
Sent via mobile, please forgive typos and brevity.
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
59 matches
Mail list logo
