– Kamailio SIP Server –

Differences

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]
109.254.49.8
development:irc-meeting-minutes-20-04-2007 [2012/03/22 13:34] (current)
80.250.1.245 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/​