Hi Olle, On Thu, Feb 4, 2016 at 3:30 PM, Olle E. Johansson <o...@edvina.net> wrote:
> > > On 04 Feb 2016, at 12:23, Camille Oudot <camille.ou...@orange.com> > wrote: > > > > Hi Olle, > > > > It was Daniel’s recommendation to load the TLS module first since he > had fixed some generic OpenSSL magic there. > > Will add the recommendation to the doc. > > > >> - http_set_ssl_cert should have “tls” instead of “ssl”. SSL is bad. > > > > We spoke about this one, "ssl" reflects the names int the curl API. If > > we totally disable SSL though, it makes sense to use "tls”. > Exactly. So does this mean that we are going to enforce the usage of TLS? Today it's not the case anywhere in Kamailio and, sincerely, having a parameter with "tls" in its name and then allowing the user to use ssl is misleading. I would prefer: 1) not having any mention to ssl/tls in the name (like "http_set_cert") 2) raise a warning when the user tries to use a deprecated protocol version > > > >> - I still think we need to discuss the way you have to run functions > >> to set parameters for a coming function call. > >> (...) > >> What if that function doesn’t happen, will all these values be reset > >> for the next message processed in that process? > > > > Good point, that is not addressed yet: we have to figure a way to reset > > all the values previously set when a new message is processed. > > Currently, they are reset when the HTTP query is sent. > > And I think you need to rethink the way you handle this. We are quite > open for new ideas, but adding a totally new scheme for setting parameters > for > function calls is not something we need - it will just be confusing for > people who learn Kamailio. Please try to use an existing framework. > > We will rethink this part. > Sorry for being really, really, really stubborn of this, but I’ve spent > over 10 years doing Kamailio trainings… :-) > > /O No problem while the discussion is constructive, as it is in this case :) Cheers, Federico
_______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev