Hello,
Kamailio SIP Server v5.0.2 stable release is out!
This is a maintenance release of the latest stable branch, 5.0, that
includes fixes since the release of v5.0.1. There is no change to
database schema or configuration language structure that you have to do
on previous installations of v5.0.x. Deployments running previous 5.0.x
versions are strongly recommended to be upgraded to v5.0.2.
For more details about version 5.0.2 (including links and guidelines to
download the tarball or from GIT repository), visit:
* https://www.kamailio.org/w/2017/06/kamailio-v5-0-2-released/
RPM, Debian/Ubuntu packages will be available soon as well.
Many thanks to all contributing and using Kamailio!
Cheers,
Daniel
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Hello!
I am working on Kamailio based IMS setup. During testing I noticed that the
UE sends unprotected register, challenge is returned but after that the UE
doesn't attempt to send REGISTER with authentication data.
I believe this happens due to the lack of support of sec-agree extension in
Kamailio. After a short google search I found this thread:
https://www.mail-archive.com/sr-users@lists.sip-router.org/msg29269.html
After that I spoke with miconda in IRC, he confirmed that no one works on
this and suggested to ask for help in this mail list.
So in nutshell - I believe without this feature (correct me if I am wrong)
a real UE can't attach to Kamailio based IMS setup. I am willing to work on
it, but I need some guidance.
Is there someone willing to help me with advice how to fit this feature in
the whole project?
At the moment my concerns are:
- Is this feature really needed in real LTE network?
- Is there a vision how this feature should be implemented in the Kamailo
landscape? E. g. as separate module, as part of ims_usrloc_pcscf /
ims_registrar_pcscf? What ipsec library to use?
Best regards,
Tsvetomir
Module: kamailio
Branch: master
Commit: 3b0ffe28df3590d76d985d18b9f3b3b0bf9ce056
URL: https://github.com/kamailio/kamailio/commit/3b0ffe28df3590d76d985d18b9f3b3b…
Author: Kamailio Dev <kamailio.dev(a)kamailio.org>
Committer: Kamailio Dev <kamailio.dev(a)kamailio.org>
Date: 2017-06-14T13:46:27+02:00
modules: readme files regenerated - auth ... [skip ci]
---
Modified: src/modules/auth/README
---
Diff: https://github.com/kamailio/kamailio/commit/3b0ffe28df3590d76d985d18b9f3b3b…
Patch: https://github.com/kamailio/kamailio/commit/3b0ffe28df3590d76d985d18b9f3b3b…
---
diff --git a/src/modules/auth/README b/src/modules/auth/README
index a89538a5b6..51ba685b48 100644
--- a/src/modules/auth/README
+++ b/src/modules/auth/README
@@ -429,19 +429,19 @@ modparam("auth", "one_time_nonce", 1)
size).
Instead of using single arrays for keeping nonce state, these arrays
- can be divided into more partitions. Each ser process is assigned to
- one of these partitions, allowing for higher concurrency on multi-CPU
- machines. Besides increasing performance, increasing nid_pool_no has
- also a negative effect: it could decrease the maximum supported
- in-flight nonces in certain conditions. In the worst case, when only
- one ser process receives most of the traffic (e.g. very busy tcp
- connection between two proxies), the in-flight nonces could be limited
- to the array size (nc_array_size for nonce_count or otn_in_flight_no
- for one_time_nonce) divided by the partitions number (nid_pool_no).
- However for normal traffic, when the process receiving a message is
- either random or chosen in a round-robin fashion the maximum in-flight
- nonces number will be very little influenced by nid_pool_no (the
- messages will be close to equally distributed to processes using
+ can be divided into more partitions. Each Kamailio process is assigned
+ to one of these partitions, allowing for higher concurrency on
+ multi-CPU machines. Besides increasing performance, increasing
+ nid_pool_no has also a negative effect: it could decrease the maximum
+ supported in-flight nonces in certain conditions. In the worst case,
+ when only one Kamailio process receives most of the traffic (e.g. very
+ busy tcp connection between two proxies), the in-flight nonces could be
+ limited to the array size (nc_array_size for nonce_count or
+ otn_in_flight_no for one_time_nonce) divided by the partitions number
+ (nid_pool_no). However for normal traffic, when the process receiving a
+ message is either random or chosen in a round-robin fashion the maximum
+ in-flight nonces number will be very little influenced by nid_pool_no
+ (the messages will be close to equally distributed to processes using
different partitions).
nid_pool_no value should be one of: 1, 2, 4, 8, 16, 32 or 64 (the
No worries, if it crashes there is an issue and I want to discover as soon as possible, I use htable everywhere. It just didn't feel the right place for the issue, but a side effect of something else, so that's why I tried to figure out where, not to have a patch that can hide it a bit better, but not really fixing it.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/commit/be46742ebe162a2c48ee5ce27e09497…