– Kamailio SIP Server –


This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
development:irc-meeting-minutes-20-04-2007 [2011/08/10 14:21]
development:irc-meeting-minutes-20-04-2007 [2012/03/22 13:34] (current) removed spam
Line 1: Line 1:
 +====== Greetings ======
 + [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! :-)
 +====== Experiences with OpenSER 1.2 ======
 + [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
 +====== OpenSER hosting ======
 + [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
 +====== Documentation ======
 + [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/