– Kamailio SIP Server –

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/