Hello,
sketching the road to the next major release, so people can plan their goals for it and discuss, if needed, before the start of winter holidays:
- development freezing by end of January 2016 - test for one to one and a half month - release in the first part of March 2016
If there are important topics to decide on, we can organize an IRC meeting sometime in January 2016.
Cheers, Daniel
Hello,
replying on this announcement to get it fresh in mind for everyone and, if it is needed, start relevant discussions for upcoming major release 4.4.
Cheers, Daniel
On 14/12/15 09:07, Daniel-Constantin Mierla wrote:
Hello,
sketching the road to the next major release, so people can plan their goals for it and discuss, if needed, before the start of winter holidays:
- development freezing by end of January 2016
- test for one to one and a half month
- release in the first part of March 2016
If there are important topics to decide on, we can organize an IRC meeting sometime in January 2016.
Cheers, Daniel
Daniel-Constantin Mierla writes:
replying on this announcement to get it fresh in mind for everyone and, if it is needed, start relevant discussions for upcoming major release 4.4.
I too would like to have capability to reload tls certificates without restarting Kamailio.
-- Juha
I would like to have capability to have basic functionality file in kamailio.cfg and other integration and to have separated config file for e.g. asterisk integration, load balancing, and webRTC and many more.
Date: Fri, 8 Jan 2016 10:59:55 +0200 To: miconda@gmail.com; sr-dev@lists.sip-router.org From: jh@tutpro.com CC: sr-users@lists.sip-router.org Subject: Re: [SR-Users] [sr-dev] Panning next major release - v4.4
Daniel-Constantin Mierla writes:
replying on this announcement to get it fresh in mind for everyone and, if it is needed, start relevant discussions for upcoming major release 4.4.
I too would like to have capability to reload tls certificates without restarting Kamailio.
-- Juha
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Load balancer (dispatcher) and webrtc (websocket) have example of configuration in their documentation (module readme).
Integration with other application is approached on many web articles/blogs. There are many ways of doing it, specific for various use cases.
Cheers, Daniel
On 08/01/16 10:09, Abdul Basit wrote:
I would like to have capability to have basic functionality file in kamailio.cfg and other integration and to have separated config file for e.g. asterisk integration, load balancing, and webRTC and many more.
Date: Fri, 8 Jan 2016 10:59:55 +0200 To: miconda@gmail.com; sr-dev@lists.sip-router.org From: jh@tutpro.com CC: sr-users@lists.sip-router.org Subject: Re: [SR-Users] [sr-dev] Panning next major release - v4.4
Daniel-Constantin Mierla writes:
replying on this announcement to get it fresh in mind for everyone
and,
if it is needed, start relevant discussions for upcoming major release 4.4.
I too would like to have capability to reload tls certificates without restarting Kamailio.
-- Juha
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 08/01/16 09:59, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
replying on this announcement to get it fresh in mind for everyone and, if it is needed, start relevant discussions for upcoming major release 4.4.
I too would like to have capability to reload tls certificates without restarting Kamailio.
Afaik, tls.cfg can be reloaded at runtime, that should reload the tls certificates linked there. Have you tried and it doesn't work?
http://www.kamailio.org/docs/modules/stable/modules/tls.html#tls.r.tls.reloa...
Cheers, Daniel
Daniel-Constantin Mierla writes:
Afaik, tls.cfg can be reloaded at runtime, that should reload the tls certificates linked there. Have you tried and it doesn't work?
http://www.kamailio.org/docs/modules/stable/modules/tls.html#tls.r.tls.reloa...
I just tried by replacing ca_list file of my proxy (that contained ca certs of my peers) with a single bogus ca cert. Then I executed tls.cfg and made a call from one of the peers to my proxy. My proxy still recognized the call as coming from the peer based on its tls common name. My understanding is that this should not have been possible if the cached ca_list of my proxy would have been updated.
-- Juha
Juha Heinanen writes:
I just tried by replacing ca_list file of my proxy (that contained ca certs of my peers) with a single bogus ca cert. Then I executed tls.cfg and made a call from one of the peers to my proxy. My proxy still recognized the call as coming from the peer based on its tls common name. My understanding is that this should not have been possible if the cached ca_list of my proxy would have been updated.
It turned out that the old tls connection from the peer to my proxy was still alive. After terminating the connection, a new connection setup was correctly refused.
So looks like certs can be reloaded on the fly. I'll try later with client and server certs.
-- Juha
On 09/01/16 01:12, Juha Heinanen wrote:
Juha Heinanen writes:
I just tried by replacing ca_list file of my proxy (that contained ca certs of my peers) with a single bogus ca cert. Then I executed tls.cfg and made a call from one of the peers to my proxy. My proxy still recognized the call as coming from the peer based on its tls common name. My understanding is that this should not have been possible if the cached ca_list of my proxy would have been updated.
It turned out that the old tls connection from the peer to my proxy was still alive. After terminating the connection, a new connection setup was correctly refused.
So looks like certs can be reloaded on the fly. I'll try later with client and server certs.
OK, added some notes in the docs about it.
Cheers, Daniel
Oh, is it time to wish for things? :-)
What we would like to see is the ability to globally pause all OPTIONs checks (set ds_ping_interval temporarily to 0 at runtime).
We have a master/slave setup and the slave is failing its pings because it has no network access and it fills the log with errors.
In the long term it would be really nice to be able to share ping status between multiple instances of Kamailio servers so when the slave takes over for the former master it already knows the status of all remote hosts.
-Sven
It is always possible to propose new feature, but not guaranteed they will be in a release.
Usually, not to forget about them, we used issue tracker to collect these proposals. However, if there are going to be many of them, we may end up with a overloaded tracker with new feature requests. In that case we should consider using a wiki page where anyone can add content.
But probably at this moment it is still ok to use the tracker on github, not having too many items in it.
Cheers, Daniel
On 08/01/16 11:54, Sven Neuhaus wrote:
Oh, is it time to wish for things? :-)
What we would like to see is the ability to globally pause all OPTIONs checks (set ds_ping_interval temporarily to 0 at runtime).
We have a master/slave setup and the slave is failing its pings because it has no network access and it fills the log with errors.
In the long term it would be really nice to be able to share ping status between multiple instances of Kamailio servers so when the slave takes over for the former master it already knows the status of all remote hosts.
-Sven
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-
Abdul Basit -
Daniel-Constantin Mierla -
Juha Heinanen -
Sven Neuhaus