This problem is almost more of a bug than enhancement and so it shouldn't be
closed.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1968#issuecomment-1813796746
You are receiving this because you are subscribed to this thread.
Message ID:
This change is a very nice to have and shouldn't be closed.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2011#issuecomment-1813795417
You are receiving this because you are subscribed to this thread.
Message ID:
Has anyone figured out a clean alternative for this problem?
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2137#issuecomment-1813794358
You are receiving this because you are subscribed to this thread.
Message ID:
Thank you very much @miconda!
--
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/pull/2570#issuecomment-737509778___
Kamailio (SER) - Development
Created the pull request @miconda. I hope it is all right!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
- Access to the d_table entries should be done by reference so there is
no risk of race conditions to get and release the lock
!-- Kamailio Pull Request Template --
!--
IMPORTANT:
- for detailed contributing guidelines, read:
Hello there, just checking if there are any feedback about this issue and our
analysis?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
### Description
Kamailio is configured to use the DMQ replication for dialog.
When running a load test Kamailio DMQ workers eventually becomes unresponsive
and stops processing DMQ messages. As a side effect the shm memory is fully
consumed then SIP processing stops happening properly and
It is worth mentioning that the INVITE authentication which depends on the cseq
tracking, still works fine after the change.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
After our change to == 0, the load test ran for over 20 hours with no problems!
Just to be aligned we compiled the latest from the 5.4 branch and started
running the test again. So far, 3h+ in with no problems. I think we are safe to
say the deadlock is not happening anymore.
Thank you for your
Also continuing the investigation we saw that the function dlg_cseq_msg_sent we
saw it was processing a KDMQ message and went past the condition of your
commit. However from the conversation it seemed DMQ message should not go
through the track cseq logic. So after checking the patch, the
Hi Daniel, we've run the test, but unfortunately the problem happened again
after about 5 hours of test.
The UDP receiver had the DMQ lock (0x7f28bd321478) and tried to get the dialog
lock(0x7f28bdf8b5b4), and the Timer process got the dialog lock
(0x7f28bdf8b5b4) and tried to get the DMQ
Hi Daniel, thanks for your review, appreciate it!
We will test that change tomorrow but isn't it then also possible to fall in
the deadlock when receiving/processing an invite?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
Actually I forget to mention that the track_cseq_updates was set to 0, not 1 as
per your comment 0 is what breaks the authentication and also it was already
set to 1
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Hi Daniel, thanks for your attention!
Regarding the tests you suggested, we ran all changes individually and both
dm_worker and worker_usleep didn't work and problem still happened.
The track_cseq_updates is still under test but is already running for 7 hours
without having the issue. Usually
The investigation done so far regarding the dead lock shows that 2 process
entered a dead lock, a udp worker and the timer process.
The timer process was trying to delete a dialog reference, and got the dialog
lock (d_table->entry lock) and then tried to get the DMQ node list lock.
On the other
Thanks henningw! I was just wondering about some config in the DMQ or dialog
which can be causing the issue because it looks like others in the community
are using DMQ + dialog without issues.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
Hello, sorry for being pushy, but just hoping someone could acknowledge the
problem or if this is some config on my side which is causing the issue. This
is a major problem, it is worst than a crash, a manual intervention with kill
-9 is necessary to restore the service back.
--
You are
### Description
When running a load test Kamailio eventually becames unresponsive and stops
processing calls.
Kamilio is configured to use the DMQ replication for dialog and usrloc. Also
the dialog keepalived is enabled.
### Troubleshooting
>From investigation, the problem happens faster
Sorry to comment on a closed ticket, but this problem is happening again for
the 5.2.8 version from the rpm.kamailio.org/centos repo. Looks like the fix was
reverted somehow
# yum install kamailio-sipcapture-daemon-config
Loaded plugins: fastestmirror
Loading mirror speeds from cached
### Description
When trying to use the pseudovar $dns(xyz=>addr[0]) Kamailio script parser
complains there is a syntax error and script won't start. However if a variable
with value 0 is used, it works.
There is no reason why one should not access those indexes directly using the
value 0.
### Description
It was discovered that the function t_newtran() is causing a conflict with the
transaction flags. When calling it before setting transaction flags, the flags
are apparently lost, so for instance when using the ACC module, if the ACC
flags are set after the t_newtran, these
After reading the purpose of the corex module, I think the idea can be changed
to add a new function in the corex module which would do the same as the
set_advertised_address, but accepting variables as parameters. Then there is no
need to modify the old function.
--
You are receiving this
Sergey, you can use the $fs variable for this purpose:
$fs = $proto + ":" + $Ri + ":5060"
But anyway, many old functions are string only and not all have an equivalent
method that supports pseudo variables I think all legacy functions need a
rework allowing pseudo-variables as parameter.
Closed #2128.
--
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/2128#event-2813242870___
Kamailio (SER) - Development Mailing List
Thanks for the info Daniel. I created the ticket because I thought the
behaviour had changed at some point, but if it was always like this it is fine.
I will close the ticket now.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
Although you can workaround the issue with the set_advertised_address, I
created this ticket https://github.com/kamailio/kamailio/issues/2137 to allow
variables instead of strings as parameter for the function.
--
You are receiving this because you are subscribed to this thread.
Reply to this
### Description
Currently the functions set_advertised_address and set_advertised_port only
accept strings as parameters. Trying to use it with variable causes an error.
Having the function using a hard coded value is not a good practice and in
order to add flexibility to the script in
Just giving my 2 cents in this matter, but by having the function
set_advertised_address accepting variables instead of only pure strings would
probably help solving this problem in the script logic.
I asked about this possibility not too long ago and Daniel pointed me out some
workaround which
### Description
When trying to iterate over a semi-colon separated string list, the s.select
transformation seems to be returning empty string instead of null, so the
suggested idea from here does not work ->
https://www.kamailio.org/wiki/tutorials/faq/main#how_to_iterate_through_the_ite
It
Closed #2105.
--
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/2105#event-2732013395___
Kamailio (SER) - Development Mailing List
Hi Juha,
Thanks for the info, I just tested the solution and it works!
Appreciated your help!
Cheers,
Patrick
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
### Description
Multiple rules with the same prefix and with the stopper flag are added. All
the rules have the same priority in the target table.
When routing calls to this prefix (load_gw + next_gw), the LCR module does not
load balance the calls, it always sends to the same GW.
Yes. As long as the script actually expects OPTIONS to an external domain,
calling a loose_route() will route it properly.
I usually do not allow OPTIONS passing through my Kamailio to external users
but had to add this exception for this case, reason why I think a flag can be
added to avoid
### Description
When using the PATH header option to keep track of original Kamailio node that
received the REGISTER, if nathelper is also used with SIP ping enabled, the SIP
OPTIONS is sent to itself following the PATH header and not sent directly to
the destination.
The nathelper/user
### Description
The dmq_usrloc module is not replicating the extra attributes saved in the xavp
for the contact. So remote nodes don't receive these values, being unable to
access it properly.
It is expected that the attributes are replicated as well.
Reproduction
Setup two nodes
### Description
Currently ds_is_from_list() matches all GWs in the dispatcher list, not
considering if the GW is disabled or not. It might have situation where a GW is
permanently disabled but can't be removed (because of CDR references for
instance). In this case it is not desired to match a
Daniel, something was really fixed in the 5.2.2 version because now the error
message about the closed websocket are not happening anymore. It's been one
week with no occurrence. On version 5.2.1, it was pretty common to start seeing
the message at some point.
--
You are receiving this
Closed #1886.
--
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/1886#event-2212402712___
Kamailio (SER) - Development Mailing List
Thanks Daniel.
I will upgrade my server and keep testing to see whether it happens again or
not!
Kind regards,
Patrick Wakano
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Hi Sergey,
Check below. I think it is ok. It is not properly configured so it dies after
the start, but service itself is there.
```
# systemctl status sipcapture.service
● sipcapture.service - Kamailio SIP router server daemon for sipcapture
Loaded: loaded
Hi Sergey,
I think so. Check below what was installed. Is that what you expected?
```
# repoquery --list kamailio-sipcapture-daemon-config
/etc/kamailio/kamailio-sipcapture.cfg
/etc/sysconfig/sipcapture
/usr/lib/systemd/system/sipcapture.service
/usr/lib/tmpfiles.d/sipcapture.conf
```
--
You
Hi Sergey,
I just tested and now it is installing fine!
Thanks for your time!
Patrick Wakano
```
# yum install kamailio-sipcapture-daemon-config-5.2.1
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: mirror.ventraip.net.au
* epel:
kamailio-sipcapture-daemon-config can't be installed because it depends on the
kamailio-sipcapture package, which can't be found...
Use the
http://download.opensuse.org/repositories/home:/kamailio:/v5.2.x-rpms/CentOS_7/
repo and try to install the kamailio-sipcapture-daemon-config. The
Reopened #1604.
--
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/1604#event-1939535594___
Kamailio (SER) - Development Mailing List
Closed #1604.
--
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/1604#event-1939535428___
Kamailio (SER) - Development Mailing List
Hello @sergey-safarov and @miconda,
Was this task done?
Just tried today and the installation from the opensuse repo is not working
Running the "clean metadata" does not solve the problem.
Patrick Wakano
`Downloading packages:
Delta RPMs disabled because /usr/bin/applydeltarpm not
### Description
Centos RPM repo is generating Kamailio 5.0.7 packages that can't be installed
### Troubleshooting
Reproduction
By using the repo
https://download.opensuse.org/repositories/home:/kamailio:/v5.0.x-rpms/CentOS_7/home:kamailio:v5.0.x-rpms.repo
when trying to install
Hi Daniel,
I am using the RPM packages for CentOS so I was not able to make my environment
work with head from Master so easily. nonetheless I applied the change to
the head of 5.0 branch and it did work fine!
No more increase in the "delayed_free", instead it counted on the "freed" stat.
Hi Daniel,
Thanks for the prompt reply! I will try to test your patch by today!
This is the case I detected the problem. During investigation, I also saw same
problem with the SIP ping from the LCR module, but I guessed they had the same
root cause in the TM module.
--
You are receiving this
### Description
When SIP message fails to be sent due to no socket found, apparently the TM
module is not deleting the transaction and so it is causing a memory leak.
### Troubleshooting
Reproduction
The easiest way to reproduce the problem is to setup a dispatcher destination
with SIP
51 matches
Mail list logo
