[15:00:06] <Henning> ok! [15:00:16] <Henning> Now is the time. [15:00:31] <micond1> ok, hello everybody! [15:00:38] <osas> hello [15:00:38] <Henning> I hope anybody have joined us again. [15:00:57] <Henning> I think we try for now unmoderated, [15:01:16] <micond1> I guess, Henning will lead the conversation, based on wiki agenda … [15:01:21] <Henning> so please speak only up, if you have something meaningful to say [15:01:32] <Henning> thanks daniel!

[15:01:43] <Henning> Ok, the first topic: Experiences with openser 1.2 [15:02:10] <Henning> I heard about some problems on the list and on irc, is anybody using this in production right now? [15:02:23] <micond1> well, yes, we have it [15:02:30] <micond1> :) [15:02:33] <Henning> any problems, e.g. with zombies? [15:02:39] <martin–> we too [15:02:45] <micond1> voipuser.org has int in production before full release [15:02:52] <Henning> how many users do you have? roughly? [15:03:00] <martin–> we only have 500 users [15:03:06] <martin–> but the half of them are call center agents [15:03:30] <Henning> and they call a lot, i think [15:03:52] <martin–> yes, they do [15:04:14] <martin–> but we use solaris, never saw a zombie there ;) [15:04:26] <micond1> all issue we discovered are fixed … no other issues [15:04:39] <micond1> pending [15:04:44] <Henning> whats the state of presence? I see a lot of these issues [15:05:00] <micond1> we don't have it in production :) [15:05:19] <Henning> yeah, cesc is probably the only who is using this.. [15:05:38] <micond1> is indeed still a moving target … but mainly in terms of internal design [15:06:01] <micond1> we have it in testing environment … [15:06:29] <Henning> ok. We're planing to move to 1.2 in summer [15:06:47] <micond1> there are lot others using presence, or at list testing it [15:07:00] <micond1> just resuming to mailing list traffic [15:07:03] <Henning> ok, i missed this, sorry [15:07:22] <bogdan_vs> cesc's issues were related to presence + dbtext [15:07:45] <osas> dbtext should be integrated with openserctl [15:07:58] <bogdan_vs> this combination revealed minor issues on both sides [15:08:23] <Henning> yeah, i read about it. osas: can you speak up? [15:08:50] <Henning> what kind of integration do you mean? [15:08:56] <osas> well, most of the time dbtext is not kept in sink with the other dbengines [15:09:18] <osas> the script for updating the tables [15:09:26] <bogdan_vs> yes, thst is true [15:09:31] <Henning> yes. There was some discussion about the generation of this script from some metaformat [15:09:35] <bogdan_vs> mainly because it is not so used [15:09:50] <osas> true, but it is part of the product [15:09:56] <bogdan_vs> right :) [15:10:12] <osas> and for small embedded systems (routers, arm platforms) is is very useful [15:10:26] <micond1> but when nobody uses it … effort is too high [15:10:33] <micond1> just setting the env … [15:10:40] <Henning> yes [15:10:46] <micond1> probably, all issues were fixed, if reported [15:11:04] <bogdan_vs> probably distributing the effort among several people will solve the problem [15:11:28] <Henning> osas, how many resources do you have to work on this problem? [15:11:34] <osas> if the script would be merged, then the developer that is updating the mysql tables would see that it needs to update the other tables 2 (postgres/dbtext) [15:11:46] <osas> 1 (me) :) [15:11:47] <klausdarilion> Hi! Soory to interrupt you. I just wanted to say that I have to leave soon, thus putting the irc session log on the homepage would be nice [15:12:02] <Henning> klaus: allready planned [15:12:13] <klausdarilion> IMO a developer should know that there are 3 db-scripts to update [15:12:34] <osas> yes … should … [15:12:39] <micond1> :) [15:12:58] <Henning> perhaps we can write a some file with the tables, and use a perl script to generate the tables for the 3 other scripts from them? [15:12:58] <micond1> after cesc's update, all are being updated [15:12:59] <osas> the mysql and postgres are somehow integrated and dbtext is left aside … [15:13:02] <micond1> as of my knowledge [15:13:02] <bogdan_vs> right - but from my experience, knowing C and mysql and postgres and dbtext is not realistic ;) [15:13:08] <micond1> big troubles were in the past [15:13:38] <bogdan_vs> I mean having the knowledge to deal with all of these parts [15:14:27] <bogdan_vs> ideally, each person should perform tasks he is good at - this will minimize the effort and time required to complete the taks [15:14:35] <osas> on the other hand, sc.dbtext is not installed, maybe that's why is not that used [15:14:59] <Henning> ok, perhaps we should install this. [15:15:25] <NormB> to add to the possible confusion, is sqlite something that is worth spending effort on ? this would mean yet another engine to be kept in sync . [15:15:48] <Henning> NormB: perhaps we can talk later about this? [15:15:49] <osas> we have unixodbc … [15:15:56] <Henning> as part of the roadmap discussion.. [15:16:26] <Henning> and we could move to the next topic, if nobody object

[15:16:37] <Henning> → OpenSER hosting: [15:17:08] <codestr0m> Henning: I know I'm new to openser, but I'm willing to offer any hosting or build system that's need [15:17:10] <codestr0m> needed* [15:17:12] <Henning> At the moment the server is hosted at voice systems? Daniel? [15:17:23] <micond1> is hosted in Germany [15:17:31] <bogdan_vs> yes it is hosted by VS [15:17:32] <codestr0m> with the possibility to setup a build bot for regression testing and or packaging for a couple archs [15:17:37] <Henning> codestr0m: thanks [15:17:38] <micond1> let's say, just sponsored by VS [15:18:01] <Henning> we can sponsor a dedicated server too [15:18:17] <bogdan_vs> the issues is that the machine is used for both openser related taks and for our internal needs [15:18:37] <Henning> and you plan to move the openser stuff to an dedicated machine [15:18:46] <bogdan_vs> and this mix generates a lot of problems - mainly, people from outside VS cannot have access to this machine [15:19:07] <Henning> ok, understand, a dedicated server would be nice [15:19:26] <Henning> what are your requirements, in kind of hardware? [15:19:31] <Henning> CPU, Mem, HD space [15:19:36] <bogdan_vs> that will be the idea - to have a dedicated server for openser and grant access to people interested in contributing to its maintaince [15:19:44] <NormB> I'm still willing to sponser a dedicated server here in NJ. We had one running back when sourceforge was having problems. Haven't done much with it as resources are tight. [15:20:25] <jesusr> we can also offer the server, bandwidth, etc… [15:20:28] <bogdan_vs> there is also another offer for a dedicated server from Voztelecom - the guys contributing the weSIP AS [15:20:44] <bogdan_vs> jesusr: talking about you [15:21:04] <Henning> ok, i see, we have enough possibilities [15:21:59] <bogdan_vs> so, we have like 4 options so for, right? jesusr, _Henning_, codestr0m, SormB [15:21:59] <L-info> i have space, power and bandwidth at telehouse UK if its of use also.. [15:22:17] <jesusr> now 5 :) [15:22:33] <codestr0m> I've got 20Mb at SJC with another pop going in at AMX-IX within 60 days [15:22:42] <Henning> ok, all this offers are dedicated servers with a root account and no virtual server stuff? [15:23:08] <Henning> i mean, we are the only users on the machine? [15:23:48] <bogdan_vs> good question :) [15:23:53] <codestr0m> Henning: is that really needed? what are the real needs and or differences that would be desired? [15:23:54] <L-info> i can offer everything but the box at the moment.. [15:24:43] <codestr0m> well. on the wiki I read that have binaries built would be interesting.. I'm already building packages for multip dist across 3 arch and can cross build more if needed [15:24:49] <NormB> The box here would be dedicated. This could lead to an interesting distributed/load balanced environment [15:25:00] <Henning> here too [15:25:10] <jesusr> yes in our case… dedicated server with root access… [15:25:28] <bogdan_vs> actully the servers will be needed for multiple purposes [15:25:36] <Henning> ok, to wrap this up: we have at least three different servers for us [15:25:39] <codestr0m> I would offer that, but the box wouldn't be impressive then… on it's own vlans and throttled [15:25:41] <bogdan_vs> like : web, ftp, svn [15:25:57] <Henning> mailman, wiki [15:26:16] <bogdan_vs> Henning: right [15:26:42] <Henning> so who will do the administration of this services? security updates are important too [15:26:55] <L-info> i can make a specific service or services available.. so if http, or ftp was needed.. maybe as part of a mirror.. [15:27:03] <bogdan_vs> any volunteers ?:) [15:27:13] <codestr0m> well. I was going to do it, but if I give root [15:27:21] <bogdan_vs> Henning: we can split the tasks [15:27:28] <codestr0m> I will just let it be someone else's responsibility [15:27:39] <bogdan_vs> there is no need for a single person [15:27:47] Verlassen jesusr hat den Kanal verlassen. [15:27:49] <Henning> codestr0m: understand [15:28:00] <Henning> bogdan: yes [15:28:07] <codestr0m> well. I already host and manage 20+ servers and can just as easily plugin one more site in [15:28:41] <Henning> codestrom: this should not be the problem [15:29:03] <codestr0m> k. If anything is needed. I'll take the passive on this then.. doesn't effect me [15:29:26] <Henning> codestrom: no, i mean that the administration is the hard part.. [15:29:34] <bogdan_vs> I think we need to go step by step - what services we need to run, what machine and how mwny to use, hoe will be in-charge and for what [15:29:59] <Henning> yes, we don't need run into all this detail now [15:30:28] <Henning> http, mail, wiki, svn, shell? [15:30:42] <codestr0m> Henning: what would shell be used for? [15:30:42] <bogdan_vs> let us build a list on wiki [15:30:57] <Henning> just ask, i don't need this [15:31:33] <Henning> ok, i'll start a new page on the wiki, development:hosting after the meeting. [15:31:59] <bogdan_vs> Henning: super - lets first close the list of services we need [15:32:14] <Henning> anything else? you mentioned build service? [15:32:34] <bogdan_vs> Henning: yes, there is an important and critical issue [15:33:02] <bogdan_vs> unfortunately we do not have access on different OS or ARCH [15:33:07] <Henning> for what machines? x86, x86_64 and sun? [15:33:09] <toady> why not using virtualization for creating a build farm if the server is powerfull enough ? [15:33:18] <codestr0m> I can crossbuild for all of them [15:33:20] <toady> bogdan_vs, well qemu is interesting in that case [15:33:22] <bogdan_vs> and openser wants to be supported on as many as possible [15:33:27] <Henning> toady: that could be an option, thanks [15:33:44] <toady> (btw, I am SebastienTricaud) [15:34:01] <bogdan_vs> in the last year there were a lot of complains about openser on Solaris [15:34:27] <Henning> i think the situation is now better, but a build host would be nice [15:34:28] <toady> bogdan_vs, thus, that would be nice to introduce a buildbot and have unit testing for each plateform [15:34:30] <codestr0m> not to get too technical, but as long as gcc will compile it and I can chroot into it.. a package is possible [15:34:40] <bogdan_vs> not necessary related to compilation, but for runtime experience, install tolls. etc [15:34:45] <L-info> i can make a zone available on x86 solaris [15:35:06] <bogdan_vs> sorry : tolls → tools [15:35:20] <Henning> L-info: thank you for the offer [15:36:02] <Henning> ok, for this we need people with solaris experience [15:36:04] <bogdan_vs> so far we had the compile farm from SF, but they closed it :( [15:36:13] <toady> Henning, I can help setting the virtualization up [15:36:33] <Henning> toady: good, noted [15:37:31] <bogdan_vs> Henning: should we start a new list of what OS and ARCH people can offer access on for compile / install test purposes ? [15:37:41] <bogdan_vs> maybe on WIKI too :) [15:37:54] <Henning> just think about it.. [15:38:03] <L-info> or maybe os and arch you guys want to test on [15:38:15] <L-info> then people can approach as and when resource is avail [15:38:16] <L-info> ? [15:38:27] <bogdan_vs> L-info: as many and as vary as possible :) [15:38:32] <L-info> :) [15:38:35] <bogdan_vs> as time they are unix like [15:38:37] <bogdan_vs> of course [15:38:51] <Henning> ok, you'll reach this page from the hosting wiki page i'll create [15:39:09] <Henning> what is with bugtrack? bugzilla? [15:39:42] <Henning> do we would go away from sf.org completly? [15:39:47] <bogdan_vs> it is a bug tracker system [15:40:05] <Henning> bogdan: yes, do we need our own? [15:40:07] <codestr0m> jira offers a very nice system to open source projects [15:40:18] <bogdan_vs> Henning: no - I would say we should stay with SF for SVN and tracker [15:40:37] <Henning> ack, my opion too [15:40:46] <bogdan_vs> SF provide a visible place for projects [15:41:06] <bogdan_vs> no need to complicate our lives more than necessary :) [15:41:11] <toady> bogdan_vs, or switch to trac is an option maybe [15:41:19] <toady> :) [15:41:35] <Henning> yes. good, to wrap this up: two pages on the wiki for hosting and buildservice, and sf.org for svn and tracker

[15:42:02] <Henning> next topic: OpenSER documentation [15:42:26] <Henning> we don't have any hacking/ starting guide for new developer at all [15:42:35] <Henning> at least no that i know about [15:43:02] <osas> the old admin tutorial from the SER site is pretty good [15:43:11] <osas> it is still hosted on the old iptel website [15:43:22] <Henning> yes, i read it too. perhaps we can update this? [15:43:23] <osas> maybe it should be updated for openser [15:43:27] <L-info> svn co svn:openser.oralnet.co.uk/guide/trunk [15:43:33] <L-info> universal read access [15:43:40] <L-info> docbook approach to doing exactly that [15:43:44] <L-info> but its taking a long time [15:43:58] <Henning> L-info: thanks! do you start this from the scratch? [15:44:02] <L-info> yea [15:44:21] <Henning> how much work still needs to be done? [15:44:37] Nick Defraz_ nennt sich jetzt Defraz. [15:44:55] <Henning> L-info: or is this guide ready? [15:45:07] <L-info> plenty.. i got a lot of writing done, and some of the scripts [15:45:39] <L-info> but have only got the mysql db/nathelper/rtproxy stuff done.. i.e. the basics [15:45:44] <Henning> ok, perhaps you can add a link to the wiki? [15:45:57] <L-info> havent approached avps, dispatcher and the other more pertinent topics that answer a lot of repeat questions [15:46:26] <bogdan_vs> Henning: or generate the docs in html format - not sure what is on the SVN [15:46:40] <L-info> i will get it html-ized daily and post a link to that.. then post the svn details on dev mailing list [15:46:47] <L-info> if that is okay? [15:46:52] <Henning> L-info: thanks [15:47:07] <bogdan_vs> L-info: yes, that will be great [15:47:08] <Henning> bogdan: i think what is need is some kind of high level overview about the code [15:48:09] <Henning> bodgan: do you have any spare resources at VS for documentation? I mean, you now all this history behind the code [15:48:14] <bogdan_vs> Henning: right - an overview of the openser's architecture [15:48:43] <bogdan_vs> Henning: well…..difficult question…:D [15:48:52] <Henning> i know, nobody likes to documents.. [15:49:40] <Henning> for users it [15:49:53] <bogdan_vs> Henning: for development purposes? [15:50:00] <Henning> yes [15:50:16] <Henning> like the old SER hacking guide [15:50:30] <bogdan_vs> Henning: I do not make any time promises, but I will give it a try….. [15:50:36] <jih> For development I would like to have a document describing even shortly on how to add new presence event packages. [15:52:01] <bogdan_vs> jih:later we can integrate detailed documentation for modules [15:52:29] <bogdan_vs> Henning is right - we do not have the documentation of the “big picture” yet [15:53:06] <Henning> ok, from the high level more closer to the code.. [15:53:12] <Henning> we're using Doxygen now.. [15:53:18] <micond1> jih: Anca will prepare some docs in the near future [15:53:44] <micond1> just committed a better architectured presence module [15:54:13] <micond1> as I understood, adding handling for new events should be easier [15:54:30] <Henning> daniel: thats good to hear [15:55:05] <Henning> do we plan to use more doxygen documentation for files and functions? [15:55:14] <osas> bogdan_vs: maybe an update of the old SER Programmer's Guide (you were listed as author [15:55:59] <osas> that was our starting point in digging into the openser code … [15:56:17] <Henning> or should we try to work first on this high level issues? [15:57:06] <bogdan_vs> osas: to me honest I have no clue what's in that guide…..:) [15:57:15] <osas> lol [15:57:21] <Henning> [15:57:33] <osas> http://old.iptel.org/ser/doc/serdev/serdev.html [15:58:55] <Henning> ok, as documentation is not such a priority.. Let's move to the next topic: ====== RTPProxy ====== [15:59:09] <Henning> → RTPProxy [15:59:17] <Henning> Daniel: this is from you? [15:59:27] <micond1> yes [15:59:42] <micond1> there is at least a patch on our tracker [16:00:10] <micond1> osas and danb (plus some I don't recall), expressed intention to add improvements [16:00:20] <osas> yup [16:00:32] <micond1> mainly to accounting reporting, transconding, scalability [16:00:34] <NormB> perhaps a rewrite ? [16:00:45] <osas> one was already done thx to VS [16:00:52] <micond1> I contacted Maxim in january, got so reply so far, I will do it again … [16:01:20] <micond1> but, as NormB says … rewrite() or ??! [16:01:24] <micond1> what to do? [16:01:54] <micond1> so, the options: [16:01:57] <osas> well, first a re-contact and will see after that [16:02:00] <NormB> I've been looking a a redesign for awhile, but need additional resources. [16:02:06] <micond1> pushing forward with Maxim [16:03:11] <NormB> if someone wants to take the lead, i'll sign on to help. [16:03:12] <micond1> in the happy case, we will have good collaboration [16:03:45] <micond1> second: redesign from scratch [16:03:59] <Henning> ok.. That should be much work [16:04:03] <NormB> think threads [16:04:04] <micond1> many resources to be allocated in the begin [16:05:00] <micond1> NormB seems to be for second [16:05:06] <micond1> osas for first [16:05:11] <Henning> first [16:05:13] <micond1> any other? [16:05:49] <Henning> no.. [16:05:55] <micond1> in first case, how long we should wait? [16:05:57] <bogdan_vs> Iwould say first [16:06:22] <Henning> waiting for an e-mail reply? [16:06:28] <micond1> yep [16:06:35] <micond1> or collaboration agreement [16:06:36] <osas> rtpproxy is part of the SER repo … is that right? [16:06:41] <bogdan_vs> yep [16:06:54] <micond1> it might be a matter of patch acceptance as well [16:06:58] <micond1> how long will take [16:07:01] <osas> is there someone here who is part of the SER mailing list? [16:07:18] <osas> maibe we should post the question/patch on the SER mailing list [16:07:46] <osas> rtpproxy enhancements should benefit both projects [16:07:59] <codestr0m> I'm on the ser mailing list [16:08:06] <Henning> i think the same [16:08:08] <micond1> I could do it, but if I would say the patch is on openser tracker, I will get some “noisy” feedback … [16:08:20] <osas> can you point the SER community about this patch? [16:08:20] <codestr0m> I don't care what feedback I get [16:08:46] <osas> let's not worry about feedbacks for now [16:08:53] <osas> we want to move forward [16:09:06] <Henning> ack. codestr0m: could you ask about this patch? [16:10:30] <osas> I can subscribe to SER mailing list and ask … [16:10:54] <osas> I will do it [16:10:59] <osas> let's move forward [16:11:01] <L-info> if we take option 2 (rewrite), i might be able to get some funding for this project.. [16:11:08] <L-info> just as an aside [16:11:10] <Henning> osas: thank you [16:11:36] <micond1> http://sourceforge.net/tracker/index.php?func=detail&aid=1575919&group_id=139143&atid=743022 [16:11:45] <micond1> just to have the link to patch [16:12:14] <Henning> ok, we'll try this with the patch, and if the response is negative, we'll think again about option 2 [16:12:33] <bogdan_vs> Henning: ok ====== Next Release ====== [16:12:43] <bogdan_vs> should we move to “Next Release” ? [16:12:52] <Henning> → next release [16:13:04] <micond1> major or minor? [16:13:24] <Henning> there are allready some important fixes in 1.2, i go for minor [16:13:44] <micond1> ok, both should be discussed, which first [16:13:48] <micond1> ok, minor [16:13:52] <bogdan_vs> first the minor [16:13:57] <micond1> when? [16:14:11] <Henning> next month? [16:14:21] <micond1> and how? (I mean, all packaging from scratch …) [16:14:37] <bogdan_vs> Henning: should be ok - we have time to hunt for more issues [16:15:03] <bogdan_vs> actually what is important is the feedback from people using 1.2 version [16:15:11] <Henning> bogdan: yes [16:15:58] <Henning> packaging.. debian is no problem, for rpm we had the opensuse service [16:16:20] <bogdan_vs> Jesus will handle the FreeBSD port [16:16:53] <bogdan_vs> Jesus (jesusr) from Voztelecom [16:16:58] <bogdan_vs> :) [16:17:53] <Henning> all the packaging stuff should work for the minor release, the change is not so big [16:17:57] <micond1> Julien Blache did good job with openser in official debian … [16:18:10] <micond1> ok [16:18:32] <Henning> So, rough date: middle of may? [16:18:45] <bogdan_vs> ok [16:19:21] <Henning> major release..: [16:20:39] <Henning> we don't have a roadmap now.. so planning is a little bit difficult [16:21:27] <bogdan_vs> we can try to identify the areas of interest for the next major [16:21:44] <bogdan_vs> and based on this, to make a time estimation [16:22:58] <Henning> ok. [16:23:10] <Henning> presence? [16:23:13] <Henning> and releated modules? [16:23:26] <jih> one item for the next major release might be tighter integration of xmpp into openser. [16:24:39] <osas> and dialog enhancements [16:24:47] <micond1> some steps already done with xmpp [16:24:56] <micond1> simple-xmpp presence in the trunk right now [16:25:28] <bogdan_vs> osas: I have dialog on my list - there are already 2 patches pending on this topic [16:25:39] <jih> Yes, but it would be nice to get rid of two lavel addressing for xmpp. [16:26:34] <micond1> indeed [16:26:50] <osas> is there any interest in better diameter support? [16:27:34] <Henning> we don't use this [16:27:52] <jih> How about SIPS URI scheme? I Ipersonally don't like the whole idea, but there is some demand. [16:27:55] <osas> it is more IMS oriented … [16:29:20] <bogdan_vs> Juha: are there any missing part for SIPS [16:29:21] <bogdan_vs> ? [16:29:22] <jih> Regarding TLS in general, perhaps openssl lib should be replaced by gnutls. [16:29:40] <Henning> yes, to get rid of the licencing problem for debian [16:30:00] <jih> bogdan: There is some missing pieces in the parser at least. [16:30:42] <jih> Also, in some modules “sip:” is hard coded. [16:32:03] <mircea> regarding TLS: gnutls seems to be more stable and bug-free, however there is a performance issue here: gnutls seems to be 2 times slower then openssl [16:32:21] <jih> I have heard that gnutls also supports offering multiple certs during ssl setup, which would allow getting rid of multiple listening ports. [16:32:57] <Henning> anybody know how different is the interface of gnutls to the from openssl? [16:33:09] <micond1> TLS - Julien Blache announced to me the intention of patching for gnutls [16:33:15] <micond1> I have to check the status [16:33:37] <micond1> but for sure is something worth investigating [16:33:49] <micond1> gnutls seems fore flexible and dynamic [16:33:56] <mircea> it is :) [16:34:51] <Henning> i could work on application db clustering for really big installations [16:35:34] <jih> henning: is that something else than mysql based clustering? [16:36:02] <codestr0m> I do postgres near real time replication with slony [16:36:13] <Henning> it is openser based, so you have e.g. 1/3 of the userloc data in three dbs [16:36:34] <micond1> DB layer redesign should be on the topic of next irc meeting [16:36:43] <micond1> we have some interesting ideas, hope to get more [16:36:57] <micond1> mainly related to scalability an failover [16:37:19] <micond1> now we may get the meeting too long for some … [16:37:27] <Henning> i think the same.. [16:37:43] <Henning> we have 2 more issues left, p2psip and openser as library [16:38:13] <micond1> p2p – did minor investigation [16:38:29] <osas> rtpproxy patch posted to SER dev mailing list: http://lists.iptel.org/pipermail/serdev/2007-April/009885.html [16:38:29] <jih> isn't the idea of p2psip that there is nothing in the middle? [16:38:37] <micond1> not sure if worth right now, unless big involvement from third parties [16:38:52] <micond1> jih: something has to be [16:38:53] <Henning> i think the same [16:38:58] <micond1> for auth … [16:39:05] <micond1> but routing is different [16:39:08] <jih> that something could be dns. [16:39:32] <micond1> dns authentication and authorization? [16:40:20] <jih> i'm not familiar with the latest regarding p2psip, but i have heard about user certs for authentication. [16:41:09] <micond1> there are proposals and proposals [16:41:22] <micond1> the point is where money is going [16:41:33] <micond1> certs is the best for CAs [16:42:17] <jih> perhaps p2psip is still too much a moving target for openser. [16:42:41] <Henning> ack [16:42:47] <Henning> the openser lib question is from toady [16:42:50] <micond1> unless someone do really invest on it resources … [16:43:01] <frey> Hope it's not OT, but I'm using OpenSER with some C++ code. One problem I had was OpenSER's use of C++ keywords as identifiers (e.g. delete, class). Including the header made the C++ compiler break compilation. If you are thinking about libifying OpenSER, I think this should be taken into account (and maybe it could even be fixed short term, since it should not be a big deal)… [16:43:23] <Henning> frey: please wait some minutes, we're in a meeting [16:44:09] <Henning> frey: but thank for the remark! [16:44:10] <toady> Henning, I am here [16:44:51] <bogdan_vs> the problem with extracting a stack from openser is that there is no clear separation line between parser and engine [16:45:22] <toady> bogdan_vs, actually, I did made a lib from the parser very easily [16:45:47] <toady> bogdan_vs, first of all, instead of technically worries, what do you think of the idea ? [16:46:11] <bogdan_vs> probably only for parsing a sip requests ? [16:46:23] <toady> yes [16:46:34] <osas> and responses [16:46:42] <toady> well… parsing sip [16:46:50] <Henning> for this task there exist allready SIP libraries that are better suited to the task, i think [16:46:52] <toady> I guess parser/ directory is for that [16:46:57] <bogdan_vs> toady: well…as I never had the need for it, I never did too much thinking on the topic [16:47:07] <toady> Henning, I am not that sure on this [16:47:30] <toady> bogdan_vs, I am working on a SIP intrusion detection system [16:47:43] <Henning> ok, you need high performance? [16:47:51] <toady> bogdan_vs, using netfilter queue library [16:47:55] <toady> Henning, right :) [16:48:17] <Henning> ok, then is a java/ c++ lib probably not the right thing to use.. [16:48:19] <toady> Henning, and I did look at several sip parsers and I can tell the one is pretty good :) [16:48:33] <toady> Henning, especially when manipulating things on top of netfilter [16:48:50] <toady> and I think there is a room for such a parser [16:49:53] <bogdan_vs> toady: did you do any changes in the code in order to extract the parser as a lib? [16:50:04] <toady> bogdan_vs, a little bit [16:50:16] <toady> bogdan_vs, most of changes where to move some headers etc.. [16:50:35] <toady> it really took me 3 hours to get the lib working [16:50:46] <bogdan_vs> toady: can you post them? we could integrate and have a “make sip_parser” for who's interested [16:50:53] <toady> bogdan_vs, sure [16:51:06] <Henning> i would also like to look [16:51:17] <toady> bogdan_vs, I can even work on it. I am very interested. [16:51:24] * toady is putting stuff online [16:51:42] <Henning> toady: ok, simple join the devel list [16:51:54] <toady> I am on the devel list :) [16:52:10] <Henning> ah, sorry. [16:52:13] <bogdan_vs> toady: submit a patch on tracker + devel [16:53:14] <bogdan_vs> there is one more think I;m considering for 1.3 [16:53:36] <toady> www.wallinfire.net/files/libsipparser.tar.gz [16:53:49] <toady> bogdan_vs, ok, I'll do that then [16:54:04] <bogdan_vs> toady: OK - thanks [16:54:09] <toady> bogdan_vs, ok then I have an other idea: [16:54:14] <Henning> bogdan: yes? [16:54:19] <toady> if we think of splitting stuff in libraries [16:54:25] <toady> we would have something like: [16:54:30] <toady> [ parser ] [ …] [16:54:45] <toady> [ base ] [16:54:46] <bogdan_vs> ok - let's finish the lib discussio [16:55:02] <Henning> ack. Do you have another thing for 1.3? [16:55:02] <toady> the base would handle stuff like memory allocation [16:55:11] <toady> -but- [16:55:19] <toady> there are already such libs [16:55:24] <toady> I am thinking of libapr from apache [16:55:29] <toady> maybe there are other [16:55:43] <Henning> toady: this was my first though after i saw pck_malloc [16:55:56] <toady> maybe this is a bad idea since the base library is exactly what is needed by openser [16:56:02] <toady> Henning, :) [16:56:19] <toady> so, I'd like to know whether you would like it or not [16:56:27] <toady> practically, this mean: [16:56:45] <bogdan_vs> toady: could you detail your idea in an email? [16:56:45] <toady> - I look of its feasibility (and provide a patch for the base library first) [16:56:49] <toady> bogdan_vs, ok [16:56:55] <toady> bogdan_vs, I will do that then [16:57:09] <Henning> Ok. We're are allready much to late.. I thank you all for your participation! I'll add the minutes to the wiki, and keep you informed about the next meeting! [16:57:11] <bogdan_vs> I thinl we are getting too technical for this discussion ;) [16:57:31] <Henning> bogdan: or do you have some last point for 1.3? [16:57:51] <osas> maybe next time we should set a target for the duration and try to stick with it [16:57:54] <bogdan_vs> Henning: short one - about the ASM code from openser [16:58:27] <Henning> osas: i planned one hour, not exactly a perfect match.. [16:58:37] <bogdan_vs> there were/are problems with it depending of the exact arch, compiler capabilities, etc [16:59:29] <bogdan_vs> so, I was investigating the following idea: instead of having ASM code depending of ARCH, why not reusing asm code provided by OSs?? [17:00:01] <bogdan_vs> doing this we do not have to maintain ASM code in openser, but rely on OS [17:00:20] <bogdan_vs> linux, solaris and bsd offers asm functions for spinlock, atomic ops, etc [17:00:33] <Henning> ok, so then we should use them [17:00:50] <bogdan_vs> but first we need to do some performance tests ! [17:01:05] <bogdan_vs> to avoid any perf. degradation [17:01:13] <Henning> i know that would you say this [17:01:27] <bogdan_vs> :) [17:01:49] <bogdan_vs> I will take this task on me…. [17:01:57] <bogdan_vs> so, I'm done ====== Bye ====== [17:02:01] <micond1> ok then, hope was an interesting electronic meeting :) [17:02:16] <bogdan_vs> e-meeting ;) [17:02:29] <Henning> next time we're doing this over RTP [17:02:33] <Henning> [17:02:34] <bogdan_vs> next time we should use SIP IM conference!! [17:02:36] <L-info> quick note: there's a quick'n'dirty log of daily irc chat @ http://openser.oralnet.co.uk/irc/openser/