******************************************************************************* IRC MEETING LOG: MAY 16, 2013 at #Kamailio on irc.freenode.org ******************************************************************************* *** #Kamailio was created on Wednesday 2008/07/30 03:46:08 PM ***************** MEETING STARTS ***************************************** hi everyone! preparing to start in 1-2 min, to allow some people getting in... :-) :-) [16:01] meanwhile, check the agenda: https://www.kamailio.org/wiki/devel/irc-meetings/2013a and add there or propose here if you have something new to discuss ok … so I guess we can start now first one - any critical issue with the latest stable series? (I will try to follow the topics from the wiki, with the last one being the roadmap to next major release v4.1.0) [16:04] we did a minor release 4.0.1 recently, from that moment not many changes, iirc perhaps we will do 4.0.2 after few more weeks any comments? or I am disconnected :-) [16:06] No comments from me non lurking I'm here! - I've just added a possible feature to the agenda no need to reply everytime for no comments, I was just probing for this one... [16:07] hughw: ok hughw: nice one ok, so moving to next [16:08] compile time enabled features from core to be moved as module sctp is the one left from the list of stun and dnssec any other you are aware of? I don't know of anything else. Neither do I ************** COMPILE-TIME OPTIONS VS CONFIGURATION FILE OPTIONS ************* Are there any compile-time options that should be configuration file options? [16:10] regarding sctp: i looked a bit at, I thought would be easy to make an api just for the functions related to libsctp There's some old flags for TLS and IPv6 in the build system, but I think the meaning got lost years ago... but it is not that simple I will try another approach moving all as module, including the core parameters for sctp and make an api for the core as oposite of an api for sctp options set via libsctp [16:11] IPv6 can still be disabled at compile time Yes, but I realize it's not depending on external libx libs oej: perhaps removal of old flags and consideration over whether any should be runtime in configuration file should be done during any code re-structuring? Presumably the Makefiles will need a lot of changing then anyway? [16:12] but making it a runtime option might not be useful (we need to force people use ipv6, so we compile it by default, if they don't want ipv6, they need to work a bit) ************************* TLS COMPILE SETTINGS ****************************** for TLS, I don't have proper knowledge at this moment [16:13] have to check the makefiles, but iirc, Andrei let an option to link the tls module statically to the core might be that one ... I don't know if all the TLS flags are valid since we made it a module. Is it possible to compile TLS without the module? [16:14] afaik, there is no tls code in the core but core may be able to link the files from the module when this core-tls option is enabled [16:15] Well, as I said in a private conversation, I think it's time for some TLS work later. :-) Mainly, I want to be able to verify the connection properties on outbound TLS connections BEFORE we send the first message. If I'm not happy with the cert I should be able to close connection and fail. [16:16] Didn't you promise me a beer for something related to that ;-) I think I already owe you a few beers, so let's add one for that... guess beer will come if this will be added … now waiting for the commit notification We need beer-bountys. [16:17] I just suggested how it might be done. oej said he had an idea as to who might do it... oej: yes, some work to refresh a bit tls options and flexibility won't harm at all ***************** OPENSSL VS GNUTLS ISSUE ********************************** BTW: can you remember me what is the problem about openssl vs gnutls The difference is that OpenSSL is poorly documented. And so is gnuTLS too… [16:18] Not much of a difference ;-) linuxmaniac: implementation, Andrei Pelinescu-Onciul went with openssl back in 2004 or so but if someone wants to do a gnutls alternative, it is ok [16:19] might be easier now as it is just a module, thus it needs to implement an interface OpenSSL licensing has issues with GNU GPL if I remember correctly. But GNUtls had more issues with Tekelec commercial side I guess. Are all parts that use TLS using the module? [16:20] What if LDAP or Postgres use TLS? There are other modules that use OpenSSL too. in the past it was in the core, an alternative would have been a bigger problem so maybe we can create a gnutls module? That could lead to SSL initialization issues. Kevin solved that with a libwrapper in Asterisk. no, each module links by its own outbound, websocket, and stun all link to it to make use of some of the encryption and hashing functions. Not going to be easy to use OpenSSL or GnuTLS and still have all the features available in both. [16:21] So each module initialize. As long as they are in different processes I don't think that's a problem. But if a core process use SIP/TLS and PGSql with TLS we're in trouble. oej: not sure tekelec ever used tls, such transport layer hasn't penetrated carriers :-) Used to be that you had to link core with OpenSSL for STUN. Shouldn't need to at all now that STUN is in its own module. Well, we have no bug reports on OpenSSL init problems, so let's let that sleep. [16:22] linuxmaniac: What would be then benefit of GNUtls? oej: there were some problems in the past Ok, waking up. we (I :-) ) solved it somehow need to check the logs oej: be able to package a kamailio-tls for debian :-P [16:23] In Asterisk we had problems with 3rd party libraries using OpenSSL at the same time as the core process. i think we initialize tls first time, via mod_register() linuxmaniac: Sorry, haven't followed that thread. Why is it not possible today? then the rest of the modules linuxmaniac, oej: and package outbound, websocket, and stun for Debian too pdunkley: sure [16:24] We should make the interfaces that these modules use available through the TLS module. oej: it's a bit of a heavy-weight solution putting interfaces into TLS. These other modules just use a couple of hashing and encryption functions. [16:25] Like? [16:26] Especially if you want to make those interfaces generic enough that other libraries could be used. You'll end up with all sorts of extra data copying and munging to get it to fit. in short: gpl claims openssl license is not compatible, and needs an exception from developers Just stuff like HMAC-SHA1 [16:27] what is not clear for me: the exception must be given by all developers of kamailio, or just by developers of modules linking to openssl Yes, we did that in Asterisk. I belive those modules are part of deb packages Literally a few single function calls without any related state in OpenSSL. if only developers of the modules, then should be easy at least pdunkley can do it for its modules I think it just has to be in the project docs I've never given a personal statement in regards of this in Asterisk. [16:28] http://lists.debian.org/debian-legal/2004/05/msg00595.html It's in our LICENSE file for Asterisk [16:29] "Specific permission is also granted to link Asterisk with OpenSSL, OpenH323 and/or the UW IMAP Toolkit and distribute the resulting binary files." I have to ask for advice on debian-legal [16:30] if a module or library is under GPL everything which links to it should be GPL. I think we just have to mail sr-dev and ask if any of the developers object to adding a text like this (or the one in the mail) to our LICENSE that is why they invented LGPL I mean GPL or GPL compatible in should be GPL. [16:31] oej: we can tr that The mail you linked to is very clear, I don't think we have to ask. We just ask everyone on sr-dev if it's ok, add a LICENSE.OpenSSL to the git repo and the tar.gz files this mail is from 2004 I suggest we make a decision here to move forward with this process. [16:32] Yes, but we also have Asterisk that did this and is accepted by Debian. oej: ok Given that many other modules link to lots of other libraries are there other examples of this that should be handled at the same time? Have we done a license review lately? [16:33] There was a library I asked about a number of times on the list, but got no answer. I don't remember what it was now. Libunistring should be no problem. There was a change in memcache [16:34] Chairman: Just thinking that, instead of asking on the list about OpenSSL, there should be one email covering all module/license related issues. Get it sorted in one go. The only one we are aware of is OpenSSL yes, memcache is using a different lib now, from what I could understand from Henning's commits There's a number of recent modules doing json and other things too. ok .. so we can discuss on sr-dev what to do review and ask devs Let's try to make a wiki page with all third party libraries and their licenses and package names in centos and debian [16:36] oej: yes, we should do that If I understand right we have two proposals: 1. Start a process of adding an OpenSSL exception to our LICENSE [16:37] 2. Create a wiki page to list all possible 3rd party library dependencies - name, URL, license and various package names DId I forget anything proposed? As part of 2 make sure there are no other exceptions needed in LICENSE [16:38] Right! Or accidents that may not be compatible with our GNU license. 3. Create a mechanism to appropriately chastise developers who add/change 3rd party library dependencies and don't update the wiki [16:39] Have them buy a round of beer at next dev meeting. I would suggest :-) ok … next topic? 3. Add a process for reviewing license of 3rd party libraries BEFORE you start using it in a module. That'll really cramp my hacking at 2am style of working ;-) [16:40] Oh, I'm sure that there are other developers awake in some weird time zone, like Texas. ******* TM MODULE - FAILURE ROUTES ON DELIVERY ERRORS ************************* ok -- on to: t.m module failure routes on delivery errors [16:41] practically, related to tcp/tls when connection does not exists and cannot be created now t_relay() returns error some people want to trigger failure route yes, it would greatly simplify cinfig [16:42] especially the new one added by hughw - branch failure route yes, at this point that would be most important to me bits to clarify: 1) should t_relay() return true in this case? [16:43] Although, if all the branches fail in that way presumably you'd need failure_route to trigger as well? 2) what return code should be generated? Is this also where Kamailio use some non-standard SIP response codes? [16:44] i would say that return code is 408 we patch the standard, if needed :-) To add to the soup If a request is parallel forked, but only one of the branches fails to make a connection, the entire t_relay() call is still a success. What kind of response codes should T_relay give when we connect and can't accept a TLS certificate? We propably need to overhaul or add a more detailed response code in addition to the return value. [16:45] if some parallel branch succeeds then t_relay() succeeds too. Right. So a code we can read in branch_failure_route. [16:46] jh__: usually t_relay() does not wait for branch completion hello if udp destination is unreacheble 408 is returned after a while. in case of tco 408 should be returned immediately in case of wrong tls cert, i guess some other response code should be invented unless there is a standard one (perhaps not acceptable here) [16:48] 488 relates to SDP. Probably going to cause problems if it is reused for other things like TLS. That's a 408, but a different one. We need to add warning codes 408a?!? [16:49] Warning/reason headers something. Like the 488 has a reason for IPv6 perhaps we can make a mod param for it ... Create a Kamailio class of responses 7xx :-) Just make sure none of them leak out to the real world. I would suggest reason codes 9xx :-) [16:50] 7xx was reserved for geoloc stuff a while ago 7xx is taken by siemens, iirc What a bunch of hackers new class for local codes is ok if they don't leak which can be prevented in config ohh, its quite crowded in 7xx room :-) the idea from oej might be good [16:51] a pv that gives independent codes that can be used for config logic http://www.iana.org/assignments/sip-parameters/sip-parameters.xml#sip-parameters-5 These are additional information to response codes There are no for TLS, but there should be yes, for tls failure there definitely should be an ietf assigned code [16:52] There are 380 and 381 for SIPS, but nothing for TLS errors I've discussed that at a number of SIPits but it boils down to "so go write a draft". I have a number of drafts waiting to be written. [16:53] Anyhow, I think this is the way to go, that we have a PV for warning codes We should also be able to add them to responses I wonder why all are in the 3xx class oej: sounds resonable "A first digit of "3" [16:54] indicates warnings specific to SIP. " From RFC 3261 [16:55] once the response code is selected, is it difficult to get branch failure route triggered from t_fwr? So for really private ones, we should be able to use 9xx And don't let the slip outside. anything else for this topic? [16:57] - sip code configurable - internal warning code via pv If a failure to deliver is detected (either failed TCP or invalid TLS) we still need to send an response back to the previous hop. If a response goes through branch_failure and failure, it may be sent back to the caller. If someone creates those routes they should be presumed to know enough to catch and drop stuff that should be kept local (or convert it to something OK to send outside). [16:58] At the moment we have checks such as t_branch_timeout() and others to find out if this was locally generated. now out goes 477 which is not standard I think those private response codes needs to go and be replaced by standard + warning code. If there's not a generic warning code, use one in the 9xx class. [16:59] I might need to use that between two Kamailio's to know what's going on, but that's soemthing I will have to code. Then we can create a funciton in tmx called add_warning_code_header(code, "text") [17:00] That sounds good to me I think warning codes are cool :-) That'll be why no-one uses them. [17:01] ************ DIALOG VS DIALOG_NG ********************************************** ok -- next topic dialog vs dialog_ng not sure any of dialog_ng devs is here?!?! [17:02] if not, we can take it to sr-dev I wanted to know how far dialog_ng implemented what's on the wiki for the new dialog it's a bit confusing to have two of them, if are not compatible [17:03] agree. i would rather use a different name like ims_dialog if it is strictly built for ims moules if dialog_ng wants to be "next generation" they have to work to complete it as a full replacement. oej: yes Otherwise, let's rename it to ims_dialog and "backport" stuff to dialog if needed [17:04] but if it's to ims specific, it might be heavy to use it on casual cases... yes, let's challenge them on the mailing list :-) ************** SOURCE TREE RESTRUCTURING ************************************** ok next topic: source tree restructuring move the core code to /xmpp to hide it from new developers. [17:05] there were voices about grouping core code in a dedicated dir Sorry. Could not resist. :-) i could prefer shallow struccture, i.e.. core at root oej: even goolge is dropping xmpp :-D I think it's hard to find text docs and examples since everything is in one big messy dir +1 for core dir [17:06] I want people to read all the docs we have, make it more visible so move to /core or /src - but move all code away from / i would rather move all code in src/ with core/ lib/ modules/ and tools/ there tools being parts of utils dir now "there" being where? there being src like: src/core/... [17:07] src/modules/... +1 from Sweden (made myself Sweden's representative in the kingdom of Kamailio) src/core means more writing or clicking when moving around in tools will be what is strictly related to kamailio operations (kamctl and sercmd now) [17:08] Any other options? I like the idea of src/core Maybe a few more clicks, but it makes the tree much neater. Maybe a few more clicks, but it makes the whole tree much neater. fine, it is not a big issue to me as long as *.c files don't appear at root [17:09] it's not going to be an easy task, a lot of #includes have to be updated not to say about Makefiles from core perhaps a script could be written to automate the update with src we can probably move main makefiles in src leaving in the root dir a simple one that invokes commands in src [17:10] Should the include files in / that other modules use be moved to core/include when we're up to cleaning ? btw, I have a question regarding to list of modules and dependencies, is there any easy way to collect them instead of parsing Makefile's ? I'd like to build ncurses-based gui tool to choose a modules instead of cli eZz: not on this part of the agenda. Pls stand by [17:11] We'll discuss that later. eZz: perhaps we can add some specs for such needs let's discuss a bit later ok, thanks, will wait So where are we? [17:12] Seems like there are no objections about moving all the source to /src we have ./src/*... vs ./core and move the .[ch] files in the current root directory to /src/core Time to speak up now, fellow developers! [17:13] I like it this is related to the src tree: would there be an advantage to putting modules in their own repos and then use git submodules? but have includes in the same or separate directory? mgw: that would be awful when doing developer branches, wouldn't it. torrey: That's what I asked - is that a good idea? might make grepping the api a bit easier... [17:14] That's what I thought too. Anyone else having opinions? oej: keeping core (and lib) includes that modules use in a separate directory would be nice. The lib include files still are in their own directories [17:15] Or? Would mean that directory could be added to the include path and just use #include <---> instead of #include "../../---" Since we have to change a *lot* of include directives we might as well do this in my opinion oej: would it? I guess it might be hard to keep the submodules pinned correctly. This is where sed might come in handy... Any reg-ex experts around? mgw: There are a lot of module interdependencies sounds good, and if they ever move again, fixing will just be a makefile change +1 [17:16] And a top-level included Makefile change at that. miconda: any opinion on include files? I don't have anything against collecting in a folder but hast to be with some hierarchy inside it Ok. [17:17] like mem/ , parser/ ... So I guess we need to book an evening or time when we can have a commit war and make this happen. Or open a shared branch to play with Because things will be broken while this is going on yes, we have to plan that ... [17:18] I guess we have to start a wiki on this one as well play separately with branches to build migration tools good idea i.e., to allow time for pdunkley to learn regexps :-) Seems like we have reached a general agreement on the direction on this. We can hash details out on sr-dev [17:19] pdunkley: is already planning a holiday for the time this is happening. pdunkley: Oreilly has a great regexp book. I understood most of the first couple of chapters. Then I got lost. ok, let aim to collect some sed/perl commands that will do the most of the job [17:20] them plan a hacking day/night for it where at least some devs are available where 'some devs' mean more than 1 :-) we need pdunkley's holiday planning too. [17:21] I'm travelling a lot over the next few months, but if I am around I will join in. ok … going to next topic? Fine with me ohh .. i'm done, @pdunkley turn now OK [17:22] ************** OUTBOUND/GRUU ************************************************** Outbound/GRUU. Does any more need done? If so, does anyone want to do it? i'm happy with the current capabilities except for the missing branch failure stuff we already discussed about [17:23] oej? I'm not really up to date. I would like to "unhide" gruu's. But that's not a dependency on outbound. http://www.kamailio.org/wiki/devel/completing_outbound I never like stuff that happens like magic. If a gruu is a r-uri I want to handle that as a gruu in the config script ;-) [17:24] pdunkley: in single server mode, is there any path? I'd like to tidy up the single-server stuff so that received parameters and AVPs aren't needed (unless you want them). But it isn't something I can prioritise now. No Path: in a single server. i don't use path in single server mode But that's tidying up. What's needed to make it work (tm) oej: there is a function _is_gruu() to detect such cases That's one of the things that needs sorted to do it properly. [17:25] miconda: But how are gruu's resolved into contacts? by lookup() if(is_gruu) lookup(…) yes But the gruu's aren't visible in the location table - are they? yes they are [17:26] Worth doing a myself check at the same time as is_gruu() or you end up trying to resolve a non-local gruu. pdunkley: i'm confused about first bullet regarding registrar module at: http://www.kamailio.org/wiki/devel/completing_outbound ok. I rest my case until furhter investigation ;-) yes, ie_gruu test is done only when there is no more entries left in route set after loose_route() My thoughts were to fudge an entry into the location Path field and then make registrar spot that the Route: it was added was local and effectively loose_route() there and then. My thoughts were to fudge an entry into the location Path field and then make registrar spot that the Route: it added was local and effectively loose_route() there and then. my tests are working fine without anything extra in route header uris [17:28] if there is a path header, registrar will add it as route header but you want to be immediately visible? yes, and the path uri will point to ob proxy [17:29] registrar will set dst_uri to the first address in path jh__: but isn't this the case for single server, no ob proxy at all? in single server case, there is no path header Basically, in single server mode (using outbound instead of received parameters and AVPs) you need some way to get the flow-token into the location table. [17:30] Once that flow token is in the location table you need to use it to set $du, not the Contact: address. Although the Contact: address still becomes the R-URI after lookup(). So adding a path to token@localhost is a good call oej: yes ok, i'll give it some thoughts [17:31] But to avoid Kamailio wasting effort looping a request back to itself, you want to detect that the Route: added is indeed local, remove it, and set $du after lookup(). now we use received to keep the src address if you do that, make it configurable, since i don't like at flow tokens in the uris. as i have explained, they break gruu. might be the right place to store token@localhost received field is used only for natted devices [17:32] I use an edge proxy at the moment, so I've not had to get single-server outbound working properly. ok … so now is a bit more clear we can move to next topic ... [17:33] in my test i have two proxies where each acts are ob and registrar How does flow tokens break gruu? if contact uri changes, flow leads to dead end That's a 431 right [17:34] 430 is flow broken Right SO branch_failure can take care of that. It's basically the thread on dispatch@ietf.org . Probably best to leave the debate on there. [17:35] but since route set cannot change during the dialog, there is nothing you can do to fix the flow token ok, lets leave the topic. as i said, i'm currently fine what peter has implemented - branch failure [17:36] hughw get's the credit for that one. hughw gets the credit for that one. Next topic? [17:37] * oej gives hughw lots of credit Thanks :) Next topic! oej: hughw doesn't drink beer Oh, we can fix that too :-) ******************* MSRP ****************************************************** MSRP: http://www.kamailio.org/wiki/devel/completing_msrp [17:38] msrp Couple of things missing from the current MSRP Relay implementation MSRP replies are hop-by-hop. So if there is a failure in a relay a REPORT needs to be generated and sent back (if the SEND indicates that one is needed). [17:39] for report, might be easier not to do it by storing required info inside the cmap MSRP relays can receive infinitely large messages over TCP. A relay needs to be able to handle this. On Kamailio we wait until we've received the entire message. [17:40] is the report hop by hop as well? REPORT is end-to-end ok, so practically we need to store the headers [17:41] We need to be able to chunk large SENDs into multiple smaller ones. So we receive a huge SEND in and send lots of small ones out (that have the same message ID). Yes. until we get the reply if the reply is ok, then drop the headers I think the solution to the REPORT and the SEND chunking are related. We need some transaction state for SENDs that are bigger than the receive buffer and for ones which may need a report generated. isn't any option to tell back to use smaller chunks? [17:42] just as quick option ...