[Di Feb 19 2008] [14:01:12] <henningw> Hi everybody, welcome the the (third) IRC meeting! [Di Feb 19 2008] [14:01:19] <miconda> hello! [Di Feb 19 2008] [14:01:25] <NormB> hello [Di Feb 19 2008] [14:01:26] * stimpie greets everybody [Di Feb 19 2008] [14:01:39] <DanB> Hey! [Di Feb 19 2008] [14:02:11] <erm> hi everybody [Di Feb 19 2008] [14:02:21] <henningw> I suggest that we follow the Agenda on the wiki.. The first point is the release schedule. [Di Feb 19 2008] [14:02:51] <anonymouz666> never saw so many good people together :)

[Di Feb 19 2008] [14:03:19] <miconda> for the minor release, everybody should list the blocker items in their list … [Di Feb 19 2008] [14:03:27] <miconda> and eta for the fix [Di Feb 19 2008] [14:04:19] <miconda> I have a deadlock at shutdown reported by osas [Di Feb 19 2008] [14:04:45] <henningw> There is the usrloc stuff from bogdan, carrierroute has nothing crititcal at the moment. [Di Feb 19 2008] [14:04:50] <miconda> not really a blocker #1891453 [Di Feb 19 2008] [14:05:43] <miconda> anybody else? [Di Feb 19 2008] [14:05:45] <NormB> osas isn't here but i think he has a dialog issue. [Di Feb 19 2008] [14:05:51] <bogdan_vs> I have several critical bugs I'm still testing on trunk [Di Feb 19 2008] [14:06:04] <bogdan_vs> (1) usrloc - henning mentioned it [Di Feb 19 2008] [14:06:28] <NormB> osas has an “in-dialog_requests.patch”. [Di Feb 19 2008] [14:06:35] <bogdan_vs> (2) TM - memory corruption in the callbacks (acc heavily affected) [Di Feb 19 2008] [14:06:53] <bogdan_vs> NormB: is this patch posted? [Di Feb 19 2008] [14:07:20] <NormB> i think it is. as i recall, you and he were in some discussions about it. [Di Feb 19 2008] [14:07:21] <bogdan_vs> (3) bug - 1864152 [Di Feb 19 2008] [14:07:44] <bogdan_vs> NormB: sure - no problem [Di Feb 19 2008] [14:07:57] <henningw> Ok. what about a target date? Sounds the next week resonable? Or perhaps two weeks? [Di Feb 19 2008] [14:08:07] <henningw> How long should we test this issues? [Di Feb 19 2008] [14:08:38] <miconda> for me is fine next week [Di Feb 19 2008] [14:08:53] <bogdan_vs> henningw: one week is too short [Di Feb 19 2008] [14:09:05] <bogdan_vs> there are bug with fresh fixes [Di Feb 19 2008] [14:09:26] <bogdan_vs> I see no point of a minor release if we do not fix the know critical bugs [Di Feb 19 2008] [14:09:29] <NormB> I've seen the most critical issue being the “memory” problem. [Di Feb 19 2008] [14:09:36] <bogdan_vs> I suggest at least 2 weeks [Di Feb 19 2008] [14:10:33] <henningw> i thought that too. Then we will check for the usrloc fix in two weeks, if we need more time then we must delay. [Di Feb 19 2008] [14:10:52] <bogdan_vs> henningw: make sense to me [Di Feb 19 2008] [14:11:02] <miconda> that sets it for an update on 4th of march [Di Feb 19 2008] [14:11:20] <henningw> good. Then lets move to the next point, 1.4 release. [Di Feb 19 2008] [14:11:51] <henningw> We have two possibilites: [Di Feb 19 2008] [14:12:26] <henningw> a) do the release before the summer holidays, not so much time for major reworking, b) do the release after the holidays in autum, winter [Di Feb 19 2008] [14:12:40] <miconda> as we had it so far, 6months devel, plus 1-2months testing, goes to end of summer [Di Feb 19 2008] [14:12:57] <miconda> so I guess is b) [Di Feb 19 2008] [14:13:49] <henningw> 12+5 + 2 means july, i would prefer this. [Di Feb 19 2008] [14:15:01] <miconda> for your proposal, freeze on end of May, … [Di Feb 19 2008] [14:15:02] <henningw> but september is ok for me too, if we really need the time. Then we should do more minor release. [Di Feb 19 2008] [14:15:10] <bogdan_vs> henningw: I think it depends of how much stuff we want to put in 1.4….. [Di Feb 19 2008] [14:15:14] <miconda> depends on roadmap [Di Feb 19 2008] [14:15:30] <henningw> yes, as ususal. Freeze in May? [Di Feb 19 2008] [14:15:49] <miconda> if we focus mainly in cleanup, I guess it could be feasible [Di Feb 19 2008] [14:16:03] <miconda> but let's see first the roadmap, put priorities, and decide then [Di Feb 19 2008] [14:16:46] <henningw> this leaves three months now.. There are many iteams on the agenda that are not yet on the roadmap.. [Di Feb 19 2008] [14:16:49] <miconda> having in mind either July either september [Di Feb 19 2008] [14:17:32] <miconda> yes, right [Di Feb 19 2008] [14:17:45] <henningw> ok. Then we will discuss later the topics, and come back to the schedule question. Next point: Documentation. [Di Feb 19 2008] [14:17:51] <bogdan_vs> I think July it might be a better choice from practical reasons [Di Feb 19 2008] [14:18:11] <bogdan_vs> Just a sec - I think there is an important reason we should not overlook [Di Feb 19 2008] [14:18:16] <henningw> ok [Di Feb 19 2008] [14:18:43] <bogdan_vs> summer is the vacation time and if we do release after summer, I guess it will be nobody doing testing or fixing [Di Feb 19 2008] [14:18:56] <bogdan_vs> and this does not sound right to mee [Di Feb 19 2008] [14:19:28] <bogdan_vs> I would prefer to do a release when we have the full support from the users, testers and developers [Di Feb 19 2008] [14:19:40] <bogdan_vs> and this in the month previous the release [Di Feb 19 2008] [14:19:59] <bogdan_vs> just my 2 cents on this [Di Feb 19 2008] [14:20:17] <NormB> i have to agree [Di Feb 19 2008] [14:20:24] <bogdan_vs> as in december I saw what how it was to do a release in the holiday season :P [Di Feb 19 2008] [14:20:25] <miconda> in both cases we hit the summer, more or less, the beginning or the ending [Di Feb 19 2008] [14:20:50] <henningw> i agree. Any other opinions on this date topic? [Di Feb 19 2008] [14:21:36] <henningw> daniel, do you need more time for your work? [Di Feb 19 2008] [14:21:45] <miconda> no, let's set July [Di Feb 19 2008] [14:22:16] <henningw> we'll come back to this question, if we see that the roadmap don't match at all to the date. [Di Feb 19 2008] [14:22:16] <miconda> we can have other meeting if we cannot do it and postpone new stuff to be added/or the release [Di Feb 19 2008] [14:22:37] <miconda> agree

[Di Feb 19 2008] [14:23:02] <miconda> documentation: we use lot of xml stuff already [Di Feb 19 2008] [14:23:05] <henningw> Documentation: I think its a good move, the SGML stuff is getting really old, most projects moves to the XML too [Di Feb 19 2008] [14:23:34] <miconda> as docbook focuses more on xml, we should do the migration at some point anyhow [Di Feb 19 2008] [14:24:16] <miconda> in this way, we will have coherence in required tools (db schema is xml, …) [Di Feb 19 2008] [14:24:21] <miconda> other opinions? [Di Feb 19 2008] [14:24:27] <henningw> yes, another good point [Di Feb 19 2008] [14:24:54] <NormB> if the doc is being reworked, can a structure be put in place so that the various pieces can be combined into, perhaps, a “real” book ? [Di Feb 19 2008] [14:25:16] <NormB> right now, there isn't much structure to the various doc out there. [Di Feb 19 2008] [14:25:41] <henningw> Norman, do you suggest to combine all module docs to one document? [Di Feb 19 2008] [14:26:08] <NormB> i don't know the “best” way to do it. was just thinking there is a little duplication of effort. [Di Feb 19 2008] [14:26:32] <NormB> “Examples” is a good example. [Di Feb 19 2008] [14:26:52] <NormB> maybe keeping them separate on the web site. [Di Feb 19 2008] [14:27:09] <NormB> but created with a structure that they could be combined with other sections. [Di Feb 19 2008] [14:27:33] <henningw> there were some effort to integrate them into the wiki, but doing this manually is not easy [Di Feb 19 2008] [14:27:50] <NormB> exactly. [Di Feb 19 2008] [14:28:09] <henningw> if we have them in a XML format, we can extract this sections and move them to the webserver. [Di Feb 19 2008] [14:28:52] <NormB> can wiki read xml ? [Di Feb 19 2008] [14:29:09] <NormB> if so, then we can perhaps standardize on xml and pipe it into the wiki. [Di Feb 19 2008] [14:29:24] <henningw> not sure. But you can create a XSL that converts them to HTML, and link from the wiki [Di Feb 19 2008] [14:29:37] <miconda> xml is well formatted, should be easy to create xsl to convert [Di Feb 19 2008] [14:30:01] <henningw> once you've get around XSL, yes :) [Di Feb 19 2008] [14:30:41] <miconda> :) [Di Feb 19 2008] [14:30:56] <miconda> ok, so migration to xml is ok for everybody? [Di Feb 19 2008] [14:31:12] <miconda> we can follow on mailing list about a redesign of the content [Di Feb 19 2008] [14:31:16] <henningw> ok, i'll investigate about a tool (perhaps creating some) to convert SGML to XML, should be not that hard. [Di Feb 19 2008] [14:31:49] <miconda> most of the documents should be already xml compliant… if they close the tags [Di Feb 19 2008] [14:32:14] <henningw> Yes, the only missing step is probably a renaming of the tags. [Di Feb 19 2008] [14:32:34] <miconda> many tags are also common [Di Feb 19 2008] [14:32:47] <miconda> the header has to be changed [Di Feb 19 2008] [14:33:48] <henningw> Ok, lets work out the details on the devel list, as you suggested. It seems there is no oposition against this move. [Di Feb 19 2008] [14:33:57] <miconda> ok [Di Feb 19 2008] [14:34:39] <henningw> This brings us direct to the next point(s), we could really use some help in this areas: docs and webpage. Most content is written from developers, we have a hard time understanding our users, because we know all details.. [Di Feb 19 2008] [14:35:11] <stimpie> I would like to participate in this [Di Feb 19 2008] [14:35:17] <henningw> at least this is my experience, not want to insult anyone :) [Di Feb 19 2008] [14:35:24] <miconda> I agree [Di Feb 19 2008] [14:36:11] <NormB> my best 1st line techies are the guys that are “not” experts. i agree. [Di Feb 19 2008] [14:36:18] <stimpie> As a new 'user' and module developer I'am missing lots of documentation [Di Feb 19 2008] [14:36:44] <henningw> stimpie, ok. What do you suggest, perhaps starting another mailling list for doc related topics? Or simply better organize us? [Di Feb 19 2008] [14:36:59] <NormB> would be great to have some users participate here. [Di Feb 19 2008] [14:37:11] <stimpie> The devel mailinglist is way to active I suggest a doc mailing list [Di Feb 19 2008] [14:38:18] <stimpie> I believe the best way is to have 2 approaches one from the users perspective and one from de devs [Di Feb 19 2008] [14:39:02] <henningw> Yes, sure. No user should write doxygen docs ;) [Di Feb 19 2008] [14:39:26] <miconda> stimpie is in, anybody else jumping in? (trying to get a core group that leads) [Di Feb 19 2008] [14:40:10] <miconda> too silence … :) [Di Feb 19 2008] [14:40:37] <DanB> I can give a helping hand as well [Di Feb 19 2008] [14:40:44] <NormB> stimpie, i can help you, just can't lead. [Di Feb 19 2008] [14:41:13] <miconda> them, stimpie, please write an email on devel, how you see the process, what you need (new mailing list, etc…) and work on it [Di Feb 19 2008] [14:41:29] <henningw> Good. We can start also a request on the user list about this. At the end, if nobody want to work on docs, then the users must live with the actual state.. [Di Feb 19 2008] [14:41:31] <miconda> you got some lieutenants … [Di Feb 19 2008] [14:41:46] <stimpie> I will send a proposal to devel list [Di Feb 19 2008] [14:42:02] <miconda> thanks [Di Feb 19 2008] [14:42:34] <miconda> next?

[Di Feb 19 2008] [14:43:48] <henningw> The next point “publicity” could be probably also discussed on the devel list, as we should save some time for the next big section. Its great when the docs gets improved for a start. [Di Feb 19 2008] [14:44:49] <henningw> or we can move this to the next meeting. Lets move to the next topics, Major changes, DB API. Daniel? [Di Feb 19 2008] [14:45:01] <miconda> ok

[Di Feb 19 2008] [14:45:38] <miconda> I want to get rid of using the module exporting interface for DB functions [Di Feb 19 2008] [14:45:54] <miconda> they are exposed to “hidden” bugs due to casts [Di Feb 19 2008] [14:46:24] <miconda> the DB modules should export a single function that will bind the DB functions to a structure [Di Feb 19 2008] [14:46:31] <henningw> like the usrloc mod? [Di Feb 19 2008] [14:46:37] <miconda> as we have already in other modules [Di Feb 19 2008] [14:46:38] <miconda> yes [Di Feb 19 2008] [14:46:48] <miconda> sl module as well, tm, … [Di Feb 19 2008] [14:47:12] <miconda> should be easy to do [Di Feb 19 2008] [14:47:26] <miconda> and we can have dual mode at begining, if migration takes time [Di Feb 19 2008] [14:48:10] <miconda> look for function export_dbapi() or so. if exists, then use it, otherwise, fall back to old fashion [Di Feb 19 2008] [14:48:37] <miconda> we need to define the name of the function for binding [Di Feb 19 2008] [14:48:49] <miconda> any porposal? bind_dbapi()? [Di Feb 19 2008] [14:49:26] <henningw> this sounds resonable, otherwise we will break again many of the existing modules. I would suggest db_bind_api(), this fits better to the existing structure (after my renames) [Di Feb 19 2008] [14:49:37] <miconda> ok [Di Feb 19 2008] [14:50:36] <miconda> next: too many parameters in some db functions [Di Feb 19 2008] [14:50:52] <miconda> I was thinking to compact a bit the related parameters [Di Feb 19 2008] [14:50:59] <miconda> might be lot of work [Di Feb 19 2008] [14:51:09] <miconda> what is your opinion on this? [Di Feb 19 2008] [14:51:51] <henningw> i get used to the actual interface, after a longer learning period. Its really much work, i've done this for the db_key_t change.. [Di Feb 19 2008] [14:51:55] <miconda> now, for query, colum names are a parameter (array), operators another array, values another one [Di Feb 19 2008] [14:52:18] <miconda> and number of items in arrays, another one [Di Feb 19 2008] [14:52:22] <henningw> but of course a nicer, cleaner interface would be good [Di Feb 19 2008] [14:52:49] <miconda> :) all the time [Di Feb 19 2008] [14:53:04] <miconda> I will set lower priority on this one [Di Feb 19 2008] [14:53:15] <miconda> let's see how time goes to the release [Di Feb 19 2008] [14:53:31] <miconda> conclusion: nice to have [Di Feb 19 2008] [14:54:04] <miconda> I'm done with DB api [Di Feb 19 2008] [14:54:04] <henningw> you'll do the work, i guess, so its up to you. Perhaps we can move gradually, first move some parameter like the number of keys, then another.. [Di Feb 19 2008] [14:54:45] <miconda> ok, we will have a devel discussion before starting [Di Feb 19 2008] [14:55:08] <miconda> to get feedback from more brains, to choose something we keep at lest for several years :) [Di Feb 19 2008] [14:56:10] <henningw> Sounds good [Di Feb 19 2008] [14:56:42] <henningw> Bogdan, we already discussed a little bit this prepared statements stuff on the devel list. Do you want to give a short update on this? [Di Feb 19 2008] [14:58:03] <bogdan_vs> sure [Di Feb 19 2008] [14:58:50] <bogdan_vs> this is more focus on the DB engine itself (rather than interface) with the main focus of speeding up the DB ops [Di Feb 19 2008] [14:59:20] <inspired> is it possible to implement timed call forwarding on openser? I guess not? [Di Feb 19 2008] [14:59:26] <bogdan_vs> the introduction of prepared statements will affect both the DB modules and the modules using DB [Di Feb 19 2008] [14:59:55] <bogdan_vs> the DB modules will have to implement the specific functions for prepared statements [Di Feb 19 2008] [15:00:10] ↔ inspired> please wait a little bit, we're in the middle of a meeting [Di Feb 19 2008] [15:00:16] <bogdan_vs> the modules using DB, will need to learn how to use this new capability [Di Feb 19 2008] [15:00:29] <bogdan_vs> of course, this will require some extension of the DB API [Di Feb 19 2008] [15:00:59] <bogdan_vs> practically, the targets are the mysql module and the auth/usrloc modules [Di Feb 19 2008] [15:01:27] <bogdan_vs> this is a part of a bigger plan (i have) for working on the real slow part of openser [Di Feb 19 2008] [15:03:06] <henningw> ok. What about DBs that not providing this capability, bascically for a start anything !MySQL i guess, do you plan some autodetection in e.g. usrloc? [Di Feb 19 2008] [15:03:24] <edsonBR> Bogdan, are You thinking in do it in the same “dual-layer” approach, or make a direct change? [Di Feb 19 2008] [15:03:48] <edsonBR> the question is on Henning's way… [Di Feb 19 2008] [15:04:23] <bogdan_vs> henningw: this will be in a first stage - a new flag for capabilities, but this complicates the modules using DB ops [Di Feb 19 2008] [15:05:07] <bogdan_vs> henningw: long term plan (if this really provides a speed up) is to symulate [Di Feb 19 2008] [15:05:23] <bogdan_vs> this in the DB module (even if not supported) [Di Feb 19 2008] [15:05:59] <bogdan_vs> this will simplify the interaction with DB API also [Di Feb 19 2008] [15:06:08] <henningw> yes, this would mean much of duplicated code.. Simulation, ok, like just skip the compilation of the prep query, and just execute directly [Di Feb 19 2008] [15:06:50] <henningw> ok, now to the question of edsonBR [Di Feb 19 2008] [15:07:54] <henningw> edsonBR, with dual layer do you mean the actual approach: modules → db_mysql → libmysqlclient → server? [Di Feb 19 2008] [15:08:17] <edsonBR> no…. triggering the behavior by a flag/parameter… [Di Feb 19 2008] [15:08:43] <bogdan_vs> edsonBR: this will be at the beginning when not all module will support this feature [Di Feb 19 2008] [15:09:02] <edsonBR> ok… thanks. [Di Feb 19 2008] [15:09:18] <bogdan_vs> edsonBR: as said, the target will be to move all DB queries (where possible) to prepared states. [Di Feb 19 2008] [15:11:49] <bogdan_vs> if no other questions, we can move on with the next topic

[Di Feb 19 2008] [15:12:24] <henningw> Module merging: perhaps we can combine this a little bit, no need to discuss every module in the list seperatly. [Di Feb 19 2008] [15:12:44] <miconda> merging module: I proposed that because there are tiny modules that are more or less related [Di Feb 19 2008] [15:13:07] <henningw> gflags and diversion are really small, and should be merged as you proposed [Di Feb 19 2008] [15:13:08] <miconda> and the overhead to maintain is higher by keeping separately [Di Feb 19 2008] [15:14:05] <bogdan_vs> henningw: I rather say diversion can be obsolete as you can do the same with PV [Di Feb 19 2008] [15:14:14] <NormB> radius could be merged [Di Feb 19 2008] [15:14:15] <bogdan_vs> there are trivial text ops [Di Feb 19 2008] [15:14:47] <henningw> obselete this is even better, don't thought about the PV possibility. [Di Feb 19 2008] [15:15:24] <bogdan_vs> henningw: not 100%, but on a fist look, it can be done with PVs [Di Feb 19 2008] [15:15:40] <miconda> for URI*, just thought that uri param functions (check value, add param), belong to textops, where we have subst_uri, etc… [Di Feb 19 2008] [15:16:03] <miconda> has_totag() – same … [Di Feb 19 2008] [15:16:24] <henningw> tel2sip.. [Di Feb 19 2008] [15:16:38] <bogdan_vs> miconda: for URI* and subst_uri() is not the same. [Di Feb 19 2008] [15:17:16] <bogdan_vs> uri_* provides functions to operate the URI by parsing and validating the URI - you can operate on params in a simpler way [Di Feb 19 2008] [15:17:48] <miconda> yes, are not the same, but related [Di Feb 19 2008] [15:17:49] <bogdan_vs> subst_uri() is regexp based, so you need to write a correct regexp to match a URI, or worst, a specific param [Di Feb 19 2008] [15:17:55] <miconda> why I proposed to merge [Di Feb 19 2008] [15:18:36] <miconda> not to remove [Di Feb 19 2008] [15:19:23] <miconda> uri_db is mostly used with auth_db … [Di Feb 19 2008] [15:19:50] <miconda> so, my question is: does make sense to merge uri* to auth*+textops? [Di Feb 19 2008] [15:19:58] <bogdan_vs> more or less is the same with pike and ratelimit [Di Feb 19 2008] [15:20:20] <bogdan_vs> even if there are the related, there are totally different cases. [Di Feb 19 2008] [15:20:34] <bogdan_vs> textops is intended for dummy string ops [Di Feb 19 2008] [15:20:45] <bogdan_vs> with no notion of syntax or format [Di Feb 19 2008] [15:20:48] <henningw> like it would require a internal reworking of the code of both modules? [Di Feb 19 2008] [15:21:56] <bogdan_vs> “uri_db is mostly used with auth_db” - not true [Di Feb 19 2008] [15:22:18] <bogdan_vs> uri_db provides mapping between SIP URIs and auth URIs [Di Feb 19 2008] [15:22:29] <bogdan_vs> it has nothing to do with how you do the auth [Di Feb 19 2008] [15:22:58] <bogdan_vs> from functionality point of view, they are doing different jobs [Di Feb 19 2008] [15:23:50] <miconda> so tehy cannot be merged? or? [Di Feb 19 2008] [15:24:01] <henningw> perhaps we can exlude this modules for now, and start with the trivial (and not controversial) ones? [Di Feb 19 2008] [15:25:16] <bogdan_vs> ok - let's merge/trash “gflags” and “diversion” [Di Feb 19 2008] [15:25:21] <henningw> After this is finished, and perhaps the radius one, we can revise this question. [Di Feb 19 2008] [15:25:34] <henningw> NormB: what do you mean with merge? The point that Daniel proposed, or another thing? [Di Feb 19 2008] [15:25:42] <miconda> fine, with me, just made my proposals [Di Feb 19 2008] [15:26:24] <NormB> the point that daniel proposed. [Di Feb 19 2008] [15:26:39] ↔ miconda> i've no opinion on this at the moment, i need to do some analysis first [Di Feb 19 2008] [15:26:50] <NormB> in addition, radiusclient-ng should be upgraded [Di Feb 19 2008] [15:27:13] <NormB> i've looked at the new radiusclient implementation in freeswitch recently. [Di Feb 19 2008] [15:27:26] <miconda> for radius I am looking to see if we can find some way to move radius related functions under some common module [Di Feb 19 2008] [15:27:49] <henningw> with a API like the (proposed) DB API? [Di Feb 19 2008] [15:27:52] <miconda> there is lot of duplication, and if lib radius changes, will affect all modules [Di Feb 19 2008] [15:28:20] <miconda> not sure if possible like DB API, but would be a solution, I guess Juha is not around [Di Feb 19 2008] [15:28:28] <miconda> any other RADIUS folk around? [Di Feb 19 2008] [15:28:54] <miconda> my main concern is acc, where we cannot package is an easy way the module with radius support [Di Feb 19 2008] [15:28:58] <NormB> a few months ago there was also an issue raised about non standard attributes for sip methods. this should be addressed. [Di Feb 19 2008] [15:29:37] <miconda> Debian want to add it by default and impose dependece on radius client library for openser packages [Di Feb 19 2008] [15:29:44] <drutlandxpt> Can lcr route the call based off of display instead of ruri? I see the caller id in display but the sip trunk username in ruri [Di Feb 19 2008] [15:29:47] <bogdan_vs> miconda: right, but doesn;t make more sense to change acc and not the whole radius support? [Di Feb 19 2008] [15:30:11] ↔ drutlandxpt> please wait a little bit, we're in the middle of a meeting [Di Feb 19 2008] [15:30:16] <miconda> it is lot of duplication that is hard to maintain in case of radius lib changes [Di Feb 19 2008] [15:30:18] <miconda> see above [Di Feb 19 2008] [15:30:31] <bogdan_vs> never happened so far [Di Feb 19 2008] [15:30:47] <bogdan_vs> in more than 5 years since radius support was added in SER [Di Feb 19 2008] [15:30:52] <miconda> I think is easier to keep it compact, as we have it with DB servers [Di Feb 19 2008] [15:30:57] <henningw> sounds good for me, have the same API like the DB would be of course nice, but another API would be ok too. [Di Feb 19 2008] [15:31:06] <henningw> as long we have a API :) [Di Feb 19 2008] [15:31:09] <miconda> a new library is under way [Di Feb 19 2008] [15:31:17] <miconda> I do not know if it has some changes [Di Feb 19 2008] [15:31:26] <miconda> but you never know in the future [Di Feb 19 2008] [15:31:48] <miconda> I am saying about the lib radius that is going to be maintained by freeradius project [Di Feb 19 2008] [15:31:58] <bogdan_vs> sure, but does make sense to add a new API just because something might happen [Di Feb 19 2008] [15:32:15] <bogdan_vs> yes, I read Maxim posts [Di Feb 19 2008] [15:32:28] <miconda> I guess Juha will have a final word, being maintainer of most of radius modules [Di Feb 19 2008] [15:32:42] <miconda> I will restart discussion on devel that I started some time ago with Juha [Di Feb 19 2008] [15:33:11] <henningw> for me the main point is code duplication, and the unnecessary modules like auth_radius, uri_radius could be integrated into the main one i guess. [Di Feb 19 2008] [15:33:11] <miconda> by doing that, we can even get rid of all *_radius module [Di Feb 19 2008] [15:33:26] <bogdan_vs> what I really dislike is to add a new API, a new data structure, data conversion, etc…(not to mentions the increased complexity) for no real reasons [Di Feb 19 2008] [15:34:12] <miconda> I target what henning is suggesting, as well [Di Feb 19 2008] [15:34:18] <NormB> i might have a radius person coming over. [Di Feb 19 2008] [15:34:31] <apolinux> hi all [Di Feb 19 2008] [15:34:50] <NormB> s3f_failt: hi, we are talking about radius. [Di Feb 19 2008] [15:34:56] <NormB> s3g_fault: [Di Feb 19 2008] [15:34:59] <bogdan_vs> henningw: why do you consider that the *_radius modules are unnecessaey? [Di Feb 19 2008] [15:35:05] <apolinux> how to configure a linux with iptables for an openser server? [Di Feb 19 2008] [15:35:07] ↔ apolinux> please wait a little bit, we're in the middle of a meeting [Di Feb 19 2008] [15:35:11] <miconda> so, I guess we can move to next, discussion will go on devel, as requires more debates [Di Feb 19 2008] [15:35:47] <NormB> miconda: are there any radius questions we can ask s3g_fault ? [Di Feb 19 2008] [15:36:25] <henningw> bogdan_vs: i don't think that [Di Feb 19 2008] [15:36:27] <miconda> maybe too many for now, can he join devel mailing list and help there? [Di Feb 19 2008] [15:36:53] <henningw> NormB: i guess the question was, how difficult its to implement a SQL select base interface for radius? [Di Feb 19 2008] [15:36:55] <miconda> ups, he is on the room [Di Feb 19 2008] [15:37:11] <s3g_fault> i can re-join the list [Di Feb 19 2008] [15:37:17] <s3g_fault> sure [Di Feb 19 2008] [15:37:18] <henningw> good, then we do this [Di Feb 19 2008] [15:37:20] <miconda> :) [Di Feb 19 2008] [15:37:49] <bogdan_vs> I still thing it is not a good idea to merge radius with DB… [Di Feb 19 2008] [15:37:57] <miconda> you got it [Di Feb 19 2008] [15:38:15] <bogdan_vs> of course we can invent a lot of interface and so on…. [Di Feb 19 2008] [15:38:25] <bogdan_vs> but I fail to see the logical reason [Di Feb 19 2008] [15:38:28] <miconda> my answer was to henning [Di Feb 19 2008] [15:39:10] <henningw> bogdan, please lets discuss this point on the devel list, otherwise we'll never finish this agenda today. [Di Feb 19 2008] [15:39:39] <bogdan_vs> henningw: sure, but I though the idea of the meeting was to clarify things [Di Feb 19 2008] [15:39:49] <bogdan_vs> but let's move one [Di Feb 19 2008] [15:40:48] <henningw> sure, but we have only limited time, unfortunally. We don't have a descicion on this yet [Di Feb 19 2008] [15:41:06] <NormB> s3g_fault: thanks for coming over. [Di Feb 19 2008] [15:41:33] <henningw> s3g_fault: thanks

[Di Feb 19 2008] [15:41:33] <miconda> next: developer frameworl: I have started to redesign fixup functions to have a more meaningful representation, and to be less exposed to bugs [Di Feb 19 2008] [15:42:01] <henningw> i think juha has only done some work in this area [Di Feb 19 2008] [15:42:29] <miconda> I want to have strict checking of parameter number, good naming for common fixups [Di Feb 19 2008] [15:42:48] <miconda> not even an idea, but future may force us to add more than two parameters [Di Feb 19 2008] [15:43:08] <miconda> now there are fixups that do not check if parameter number is greater than 2 [Di Feb 19 2008] [15:43:08] <henningw> i have a module laying around that has 7 [Di Feb 19 2008] [15:43:16] <miconda> :) [Di Feb 19 2008] [15:43:35] <miconda> so, all fixups that go in core, being common acros modules should be very strict [Di Feb 19 2008] [15:44:20] <miconda> for now, I just replaced the old common fixup functions to be more coherent … [Di Feb 19 2008] [15:44:44] <henningw> this all sounds resonable, but in order to really improve the modules, we should also request that new modules must use this functions. Otherwise they will be keep implementing them again. [Di Feb 19 2008] [15:44:48] <miconda> I want to get a feedback, whether you have a better idea, or comments [Di Feb 19 2008] [15:45:07] <miconda> henning, yes, if they are not something very specific [Di Feb 19 2008] [15:45:57] <miconda> put some guidelines at: http://www.openser.org/dokuwiki/doku.php/development:new-devel [Di Feb 19 2008] [15:46:28] <henningw> its the same with any other existing core infrastructure. Good idea with the guidelines, we really need something like this. [Di Feb 19 2008] [15:46:39] <miconda> want to improve and get a common set of rules agreed by the developers [Di Feb 19 2008] [15:47:05] <miconda> for now, it is by me, not the spread the ideea as being imposed by the project [Di Feb 19 2008] [15:49:19] <miconda> I guess we can work on it and get the consensus of the developers and move it as a requirement [Di Feb 19 2008] [15:49:25] <henningw> i like the idea that we have a infrastructure for common cases like fixups, header additions etc.. And if this is all documented and agreed from the project its even better. [Di Feb 19 2008] [15:49:43] <miconda> yes, that is the next one [Di Feb 19 2008] [15:49:54] <henningw> Ok, module interface autogeneration: [Di Feb 19 2008] [15:50:06] <miconda> at a short check, there are duplicates of functions [Di Feb 19 2008] [15:50:15] <miconda> sorry, I created confusion [Di Feb 19 2008] [15:50:28] <henningw> its a real pain to change manually over 80 modules, after a small interface change [Di Feb 19 2008] [15:50:43] <miconda> yes [Di Feb 19 2008] [15:51:08] <henningw> and we have already all the module interface and parameter in some XML file. So i thought that we could autogenerate a .h (and some parts of .c) file for the module interface. [Di Feb 19 2008] [15:51:45] <henningw> this way we have always a consistent interface, the docs are matching everytime too. [Di Feb 19 2008] [15:52:04] <miconda> perhaps the .c should include only the interface [Di Feb 19 2008] [15:52:18] <miconda> and the rest to be implemented in a separate file [Di Feb 19 2008] [15:52:20] <henningw> yes [Di Feb 19 2008] [15:52:37] <miconda> would be some work to adjust it … but, indeed, would be nice [Di Feb 19 2008] [15:53:10] <henningw> and this way we could easily enforce naming conventions too. Sure, this is some work, but we can start with a small module first, lets see how this work out, and then decide how to proceed. [Di Feb 19 2008] [15:53:15] <miconda> here comes also the name of these .c .h files [Di Feb 19 2008] [15:53:28] <miconda> agree [Di Feb 19 2008] [15:54:17] <miconda> there are modules with huge interface, let's see how we get it there [Di Feb 19 2008] [15:54:56] <henningw> but to not duplicate effort, the first step will be to convert the docs to a proper XML format. And for huge or really special modules things could stay the current way. [Di Feb 19 2008] [15:55:20] <miconda> ok [Di Feb 19 2008] [15:55:21] <henningw> But i think mainly about this bunch of small (3 params, 4 functions) type of modules [Di Feb 19 2008] [15:56:05] <henningw> ok, i'll investigate after the docs conversion, lets see how difficult code generation is with XSL, brrr ;) [Di Feb 19 2008] [15:56:19] <miconda> :)

[Di Feb 19 2008] [15:56:33] <henningw> Bogdan, the next point of from you again, SIP parsing [Di Feb 19 2008] [16:00:31] <bogdan_vs> I thinks these are too low level things to be discussed now and here, under time presure [Di Feb 19 2008] [16:00:53] <bogdan_vs> I would open a thread on devel [Di Feb 19 2008] [16:01:03] <henningw> we could skip the last one “feature additions”, this are not that controversial i think, then we have time. [Di Feb 19 2008] [16:02:03] <bogdan_vs> you mean klaus addition? [Di Feb 19 2008] [16:02:52] <henningw> no, i mean the whole section “Feature additions, minor changes”, because these are mainly new features, don't think that they need that much discussion.

[Di Feb 19 2008] [16:04:45] <bogdan_vs> I prefer not to skip it as there are some interesting things in there [Di Feb 19 2008] [16:05:38] <stimpie> realtime changing of the sip msg also is [Di Feb 19 2008] [16:05:43] <henningw> sure, i don't want it either [Di Feb 19 2008] [16:07:44] <henningw> then lets sort some things out. I think that SDP parser is basically aggreed, its on the tracker, Osas, do you have any comments on this? [Di Feb 19 2008] [16:09:24] <henningw> or bogdan, are there any problems with the patch on the tracker? [Di Feb 19 2008] [16:10:51] <osas> I will need to update the patch to the latest version [Di Feb 19 2008] [16:11:16] <osas> support for multipart is already present [Di Feb 19 2008] [16:12:26] <osas> I would like to be ablr to push this in asap, in order to collect more feedback [Di Feb 19 2008] [16:14:59] <osas> if bogdan is to busy to review the patch, I would appreciate comments from other reviewers too :) [Di Feb 19 2008] [16:15:32] <bogdan_vs> osas: I will take care of it - just update it [Di Feb 19 2008] [16:15:39] <osas> bogdan_vs, thx :) [Di Feb 19 2008] [16:16:09] <bogdan_vs> osas: it will take a bit (not much) as I need to correlate it with other changes in nathelper [Di Feb 19 2008] [16:16:23] <osas> sure [Di Feb 19 2008] [16:16:35] <osas> my patch doesn't touch nathelper [Di Feb 19 2008] [16:16:56] <osas> it woyuld be nice to integrate mediaproxy and nathelper with the parser [Di Feb 19 2008] [16:17:34] <bogdan_vs> osas: I know, but I would like to have it in this way ;) [Di Feb 19 2008] [16:18:52] <henningw> good. any more comments on this? [Di Feb 19 2008] [16:19:07] <osas> I think we are all good :) [Di Feb 19 2008] [16:19:13] <osas> next item on the list [Di Feb 19 2008] [16:19:37] <henningw> timeout_route [Di Feb 19 2008] [16:19:55] <henningw> especially dialog timeouts [Di Feb 19 2008] [16:20:17] <osas> the fact that the dialog expires in a silent way is kind of annoying [Di Feb 19 2008] [16:20:51] <osas> givving the admin a chance to decide what to be done on dialog would really help [Di Feb 19 2008] [16:21:09] <osas> we could terminate the dialog [Di Feb 19 2008] [16:21:18] <osas> or we could re-arm the timer [Di Feb 19 2008] [16:21:57] <osas> this will help pre-paid apps [Di Feb 19 2008] [16:22:35] <osas> and apps that are sitting on top of the dialog module [Di Feb 19 2008] [16:23:09] <osas> bogdan_vs, do you have any comments on this? [Di Feb 19 2008] [16:25:04] <bogdan_vs> I need to investigate [Di Feb 19 2008] [16:25:13] <bogdan_vs> looks a bit complicates [Di Feb 19 2008] [16:25:56] <osas> I was making an analogy to error_route when I proposed this [Di Feb 19 2008] [16:26:35] <osas> we don't have a sip_msg when we are back in the script, but we can have some PVs in order to identidy the dialog [Di Feb 19 2008] [16:27:07] <osas> re-arming the timer doesn't require a sip_msg [Di Feb 19 2008] [16:27:24] <osas> terminating the dialog via BYEs doesn't require a sip_msg [Di Feb 19 2008] [16:27:54] <osas> bogdan_vs, when you have a chance, please take a look and update the feature request in the tracker [Di Feb 19 2008] [16:28:10] <bogdan_vs> Ovidiu, let's continue the technical discussion on private or devel - let's try not get people bored ;) [Di Feb 19 2008] [16:28:15] <osas> I think we can move now to the next item on the dialog list [Di Feb 19 2008] [16:28:23] <osas> bogdan_vs, sure :) [Di Feb 19 2008] [16:28:30] <henningw> this are from you, bogdan [Di Feb 19 2008] [16:28:42] <bogdan_vs> yes [Di Feb 19 2008] [16:29:06] <bogdan_vs> some improvements for dialog module [Di Feb 19 2008] [16:29:27] <bogdan_vs> to be able to classify dialog based on certain criterias [Di Feb 19 2008] [16:30:14] <henningw> can you give a example? [Di Feb 19 2008] [16:30:18] <bogdan_vs> and to be able to see (1) how many calls a user has, (2) how many calls you have to PSTN, (3) from a single IP, etc [Di Feb 19 2008] [16:30:37] <bogdan_vs> it will very useful for access and load control [Di Feb 19 2008] [16:31:00] <osas> I agree with this [Di Feb 19 2008] [16:31:05] <henningw> sounds good [Di Feb 19 2008] [16:31:17] <osas> bogdan_vs, do you have a proposal, on how to control this thing? [Di Feb 19 2008] [16:31:41] <osas> right now we have a PV holding the number of active dialogs [Di Feb 19 2008] [16:32:11] <bogdan_vs> osas: this is my first concern and dilemma - how to apply the counting criteria in an efficient and felxible way [Di Feb 19 2008] [16:32:25] <bogdan_vs> osas: yes, the overall dialogs [Di Feb 19 2008] [16:32:46] <henningw> we can of course add more PVs, but this would be not that flexible [Di Feb 19 2008] [16:32:51] <osas> do you think about turning this PV into an array and use an avp to control the index of the array that will be updated along with the main PV? [Di Feb 19 2008] [16:33:08] <bogdan_vs> but I will do more thinking (cold water is involved) and come up with something realistic [Di Feb 19 2008] [16:33:18] <osas> this functionality was on my todo list :) [Di Feb 19 2008] [16:33:27] <osas> but I'm glad that you brought it up [Di Feb 19 2008] [16:33:32] <bogdan_vs> osas: I prefer to avoid a static approach (limited criteria) [Di Feb 19 2008] [16:33:52] <bogdan_vs> ok, next - pike module [Di Feb 19 2008] [16:34:27] <bogdan_vs> some work need to be done for a better reporting (an easy way to interact with it) [Di Feb 19 2008] [16:35:08] <bogdan_vs> (1) - logging - to log only start and stop of blocking ; now each blocked message generates a log….quite annoying … [Di Feb 19 2008] [16:35:43] <bogdan_vs> (2) MI integration - to be able to monitor it remotely (for IS integration) [Di Feb 19 2008] [16:36:09] <bogdan_vs> (3) new feature - to be able to force a certain destination to be blocked [Di Feb 19 2008] [16:36:24] <henningw> i don't think that we need this “inject IPs to block” feature that much in pike, this can be easily achieved with iptables [Di Feb 19 2008] [16:37:07] <henningw> or i'm wrong? haven't use this module at all [Di Feb 19 2008] [16:37:44] <bogdan_vs> henningw: there are cases where you need to control the SIP service in a easy way [Di Feb 19 2008] [16:37:56] <henningw> iptables is easy :) [Di Feb 19 2008] [16:38:07] <henningw> but if you say this is needed, ok [Di Feb 19 2008] [16:38:24] <bogdan_vs> it was just a foreseen :)…. [Di Feb 19 2008] [16:38:45] <bogdan_vs> let's see if really need it or not [Di Feb 19 2008] [16:39:15] <bogdan_vs> next topic - quite debated in the past [Di Feb 19 2008] [16:39:32] <henningw> multi-domain [Di Feb 19 2008] [16:39:34] <bogdan_vs> multidomain and RR module [Di Feb 19 2008] [16:39:55] <bogdan_vs> there were discussions if this is needed or not [Di Feb 19 2008] [16:40:22] <bogdan_vs> and the conclusion is it's needed only for preloaded route [Di Feb 19 2008] [16:41:05] <bogdan_vs> only there you can have names and not IPs and RR module needs to know the configured domains [Di Feb 19 2008] [16:41:09] <bogdan_vs> solutions: [Di Feb 19 2008] [16:41:36] <bogdan_vs> (1) make domain module to import the domains as aliases (used by RR) [Di Feb 19 2008] [16:41:51] <bogdan_vs> (2) make some specific trick only for RR+domain module [Di Feb 19 2008] [16:43:42] <bogdan_vs> shortly, we need this to be RFC compliant, but if too technical for this meeting, we can move it on devel…no prob [Di Feb 19 2008] [16:44:15] <henningw> i have the actual thread in this was discussed not ready at the moment, so i can't comment sorry [Di Feb 19 2008] [16:46:32] <bogdan_vs> I suggest for the following meeting to split in different levels of discussions…. [Di Feb 19 2008] [16:46:38] <henningw> good idea [Di Feb 19 2008] [16:46:53] <bogdan_vs> like a certain meeting for politics and a separate one for technical issues [Di Feb 19 2008] [16:47:08] <henningw> and do more regular meetings, this way the agenda gets not that full [Di Feb 19 2008] [16:47:24] <bogdan_vs> I think some people are interested more in politics and other on technical side and make no sense to waist time [Di Feb 19 2008] [16:47:59] <henningw> ack. I'm also interested in technical, but i need preperations before i can discuss low level SIP parsing stuff, unfortunally ;) [Di Feb 19 2008] [16:48:52] <osas> next topic? [Di Feb 19 2008] [16:51:32] <henningw> Bogdan, Daniel, what do you think? Should we move the remaining topics to the next one, and close for today? Or should we continue? [Di Feb 19 2008] [16:51:38] <henningw> (next meeting)

[Di Feb 19 2008] [16:52:03] <miconda> I am done, mainly [Di Feb 19 2008] [16:52:26] <miconda> if someone has very important things to discuss I am here, but not for long time [Di Feb 19 2008] [16:52:47] <miconda> seems the discussion goes very slow, not like a conversation [Di Feb 19 2008] [16:53:08] <henningw> yes, IRC is not like real life :/ [Di Feb 19 2008] [16:53:20] <miconda> :) yes [Di Feb 19 2008] [16:53:41] <miconda> so, those having remaining items to speak up [Di Feb 19 2008] [16:53:58] <miconda> otherwise we can close here, and move on devel/next meeting [Di Feb 19 2008] [16:55:00] <henningw> I think it makes more sense to discuss the proposes cr stuff from me on devel. Then there are only some topics from Bogdan not discussed yet. [Di Feb 19 2008] [16:55:55] <Nix> hey guys [Di Feb 19 2008] [16:56:26] <Nix> sorry I missed the discussion on radius, but I see s3g_fault was here [Di Feb 19 2008] [16:56:49] <NormB> Nix: hey [Di Feb 19 2008] [16:57:00] <miconda> hi! conclusion was that it will be a follow up on devel mailing list [Di Feb 19 2008] [16:57:11] <miconda> I will summarize there, and have you cc-ed [Di Feb 19 2008] [16:57:55] <miconda> irc log and maybe meeting minutes will be available online [Di Feb 19 2008] [16:58:22] <henningw> I don't see anything from bogdan.. I don't think we should prolong this meeting over three hours. Yes, i'll provide the minutes later on. [Di Feb 19 2008] [16:58:36] <miconda> I agree [Di Feb 19 2008] [16:59:00] <miconda> 3h is quite a lot [Di Feb 19 2008] [16:59:05] Verlassen bogdan_vs hat den Kanal verlassen. [Di Feb 19 2008] [16:59:33] <miconda> perhaps Bogdan lost connection [Di Feb 19 2008] [16:59:37] <miconda> as I can see [Di Feb 19 2008] [17:00:13] <miconda> will continue on devel@ [Di Feb 19 2008] [17:00:42] <miconda> so, ready to close? last chance to push an item for debate … [Di Feb 19 2008] [17:00:47] <miconda> on this meeting, of course [Di Feb 19 2008] [17:01:02] <henningw> Nothing? Then lets close for today. Thank you all for participating!