– Kamailio SIP Server –


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

Link to this comparison view

development:irc-meeting-minutes-06-11-2008 [2008/11/06 19:22] (current) created
Line 1: Line 1:
 +<​henningw>​ http://​www.kamailio.org/​dokuwiki/​doku.php/​development:​irc-meeting-agenda-draft
 +<​miconda>​ this is the irc meeting agenda
 +<​miconda>​ not the Karlsruhe agenda :-)
 +<​henningw>​ ;) yes
 +<​miconda>​ hi everybody!
 +<​miconda>​ I guess we can start
 +<​tramjoe_merin>​ Hiiiiiii Daniieeeelll
 +<​miconda>​ I believe 1.3 is still the most used version out there
 +<​miconda>​ so we do put a lot of effort in keeping it up to date
 +<​miconda>​ any critical issue you are aware in 1.3 branch?
 +<​miconda>​ shall we release 1.3.4?
 +<​henningw>​ i think we should release
 +<​miconda>​ those questions need some answers
 +<​miconda>​ ok, so 1.3.4, probably next week is not good time
 +<​henningw>​ i'm not aware of any issues special to the 1.3 branch
 +<​miconda>​ as many travels
 +<​henningw>​ yes
 +<​Muhammad>​ if you released 1.3.4 what will be the new stuff to add to it ?
 +<​miconda>​ I saw couple of fixes in the last time to 1.3 branch, so I guess we are ok for 1.3.4, we just need the time
 +<​miconda>​ minor releases are just for bug fixes
 +<​miconda>​ no new features
 +<​Muhammad>​ ah , ok
 +<​miconda>​ those come with major releases
 +<​Muhammad>​ good , then agree with that
 +<​miconda>​ so, 2 weeks from now on?
 +<​miconda>​ for 1.3.4?
 +<​henningw>​ 18th november?
 +<​henningw>​ 20th november?
 +<​miconda>​ 20?
 +<​Muhammad>​ 20
 +<​tramjoe_merin>​ I suggest rouning releases dates to the next monday in general
 +<​henningw>​ why monday?
 +<​tramjoe_merin>​ Start of business week
 +<​tramjoe_merin>​ People usually do not fiddle too much on weekends with new versions
 +<​henningw>​ ok, new week, new release, understand :)
 +<​tramjoe_merin>​ leaves the in-between "​extra-time"​for release
 +<​tramjoe_merin>​ Developpers usually have more work done on weekends than users
 +<​miconda>​ usually people wait 1-2 day until they do upgrade
 +<​miconda>​ or it is just me :-)
 +<​osas>​ :)
 +<​miconda>​ mondays proved to me very busy
 +<​osas>​ yup
 +<​henningw>​ yes
 +<​tramjoe_merin>​ I could not say, I usually set up a staging sever for 1 week at least before upgrading production
 +<​miconda>​ and as involved in releasing, might not be appropriate
 +<​tramjoe_merin>​ This makes sense
 +<​henningw>​ perhaps we can move from thursday to wednesday or tuesday
 +<​osas>​ I don't think than setting up a rule like this is crucial ...
 +<​henningw>​ this is also true
 +<​tramjoe_merin>​ sorry then :-)
 +<​tramjoe_merin>​ (I agree it is not critical)
 +<​osas>​ let's move on with important things
 +<​miconda>​ ok, so 1.3.4 is closed?
 +<​henningw>​ 20, ack
 +<​miconda>​ anyhting else regarding 1.3.x?
 +<​osas>​ that mem leak
 +<​osas>​ from avpops
 +<​osas>​ I think that's the only issue in 1.3
 +<​osas>​ not sure if it's present in 1.4
 +<​miconda>​ osas: is on the tracker, right?
 +<​miconda>​ I will review before 1.3
 +<​osas>​ I will have soon a server in 1.4 (the one that was experiencing issues in 1.3) and I will report
 +<​osas>​ I know that it was on the ml
 +<​tramjoe_merin>​ If I may
 +<​osas>​ dunno about the tracker
 +<​osas>​ let me check ...
 +<​tramjoe_merin>​ The benchmark bugs are common to 1.3 and 1.4 and are anoying
 +<​tramjoe_merin>​ But low priority
 +<​tramjoe_merin>​ Definatily not worth rushing for 1.3
 +<​tramjoe_merin>​ In tracker, DNS_name to IP coredump is high
 +<​henningw>​ is this on 1.3.x?
 +<​tramjoe_merin>​ tagged as such
 +<​tramjoe_merin>​ http://​sourceforge.net/​tracker/​index.php?​func=detail&​aid=2102541&​group_id=139143&​atid=743020
 +<​tramjoe_merin>​ But I do not know firsthand
 +<​henningw>​ i think i discussed this with Klaus privatly with the reporter
 +<​henningw>​ he wanted to created another trace/ core dump, and send it to us. but i did not receive anything so far, did not asked though
 +<​henningw>​ asked a few times, but not recently
 +<​miconda>​ ok, 1.4.x
 +<​miconda>​ last one was Oct 23
 +<​miconda>​ several fixes meanwhile ...
 +<​miconda>​ when to go for 1.4.3?
 +<​henningw>​ there is a thing related to the SRV randomisation that needed to backported, the bugs for usrloc and cr apply also for 1.4
 +<​henningw>​ (bugs in registrar)
 +<​henningw>​ i'd suggest after 1.3.4
 +<​tramjoe_merin>​ ... and benchmark counters (I am lobbying for this one)
 +<​henningw>​ i think bastian created the benchmark module, perhaps i can ask him, don't know the code that much
 +<​tramjoe_merin>​ ok, I will take care of contacting him as I am the one begging for this.
 +<​henningw>​ ok, good
 +<​tramjoe_merin>​ in my todo
 +<​osas>​ bug created for PKG mem leak issue: https://​sourceforge.net/​tracker/​index.php?​func=detail&​aid=2229966&​group_id=139143&​atid=743020
 +<​miconda>​ osas: thanks
 +<​osas>​ np
 +<​miconda>​ hmmm
 +<​miconda>​ we get just before the Christmas travelings
 +<​miconda>​ anyone proposing a date?
 +<​miconda>​ for next 1.4.x release
 +<​tramjoe_merin>​ Well, if it is not around dec. 20th it has to be around jan 3
 +<​tramjoe_merin>​ Not before for obvious reasons
 +<​osas>​ let's plan for December and we will set up the date later on
 +<​henningw>​ begining of december, ok
 +<​miconda>​ ok, let's what we can get then
 +<​miconda>​ so, now to most interesting parts
 +<​miconda>​ roadmap to 1.5.0
 +<​miconda>​ you have details at:
 +<​miconda>​ http://​www.kamailio.org/​dokuwiki/​doku.php/​features:​new-in-1.5.x
 +<​henningw>​ its already quite a lot of stuff :)
 +<​miconda>​ http://​www.kamailio.org/​dokuwiki/​doku.php/​roadmap:​1.5.x
 +<​miconda>​ so, should we release :-)?
 +<​henningw>​ not yet
 +<​miconda>​ ok :-)
 +<​miconda>​ so, where shoud we set higher priority?
 +<​miconda>​ what is really lacking in 1.4
 +<​festr_>​ guys I cannot pass over this: INVITE sip:1234 -> timeout in failure route so forward to another sip:abcd. The problem is that 200 OK from abcd is passed to sip:1234 so the ACK from 1234 has new branche and thus it is not routed back to abcd. hope you understand this :)
 +<-> festr_> please wait a bit, we're just having a conference
 +<​stimpie_>​ hmm
 +<​osas>​ henningw, why do you think that we should not release yet?
 +<​henningw>​ i want to finish the cr reworking, make the route/ carrier lookup also O(log n)
 +<​miconda>​ osas: some of the features are half done
 +<​miconda>​ like htable module or PV migration to modules
 +<​henningw>​ we've also one or two modules/ module extensions that we most probably like to contribute
 +<​osas>​ let's set a release date target and finish the work before that
 +<​miconda>​ I, at least, planned to stick to 6-8 months release cycle
 +<​henningw>​ yes, make sense
 +<​henningw>​ Kamailio 1.4.0 released on August 7, 2008.
 +<​osas>​ there are already intersting features (like juha's lcr enhancements) and ppl would like to have them out
 +<​miconda>​ maybe, from the perspective of using the common core and tm asap, we can do 1.5.0 a bit earlier
 +<​osas>​ I would like to have the cr enhancements on 1.5 :)
 +<​miconda>​ anyhow, I doubt it can be done before the new year
 +<​henningw>​ hehe :-)
 +<​osas>​ no, not before the new year
 +<​henningw>​ then lets target Januar
 +<​miconda>​ maybe we can freeze by mid january
 +<​osas>​ but end of january
 +<​osas>​ freeze by the end of the year (no new features)
 +<​osas>​ and in the freeze period: bug fixes
 +<​osas>​ and then release it
 +<​henningw>​ sounds resonable
 +<​osas>​ and a minor release after two weeks ;)
 +<​miconda>​ we can try ..
 +<​miconda>​ he he :D
 +<​osas>​ well ... this is how it works
 +<​osas>​ ppl really start testing after the release date
 +<​henningw>​ nobody tries a pre-release,​ :-/
 +<​osas>​ yup
 +<​miconda>​ you are so laizy, I do testing
 +<​miconda>​ for my configs, of course ... :)
 +<​tramjoe_merin>​ ... and freeze before vacation guarantees no testing
 +<​tramjoe_merin>​ it is already difficult to get people to test before release ...
 +<​miconda>​ how is the testing framework henning?
 +<​miconda>​ can we do some performance regretion, etc...
 +<​miconda>​ no to summarize
 +<​miconda>​ if we do freeze before Christmas, nobody tests
 +<​henningw>​ i added new/ extended old tests, buts its still a long way to a good coverage
 +<​miconda>​ but not many do before release anyhow
 +<​henningw>​ this came up in the past, perhaps we can release a beta, or RC candiate? not sure if this helps in this regards
 +<​henningw>​ SER does it IMHO
 +<​osas>​ I don't think that it really helps
 +<​osas>​ just release and do a minor release in two weeks
 +<​henningw>​ yes, its more or less the same, and we're used to it ;)
 +<​tramjoe_merin>​ I agree, only "final versions"​really trigger a reaction from community
 +<​osas>​ ppl will not test a release candidate
 +<​osas>​ yup :)
 +<​tramjoe_merin>​ So we know it is a beta, let's call it final .0
 +<​miconda>​ :)
 +<​miconda>​ I have many x.y.0 in production still
 +<​miconda>​ but because it was tested for those configs before release
 +<​tramjoe_merin>​ ok, so to be really honenst about this, mention somewhere in the wiki that .0 is "for preproduction"​
 +<​miconda>​ if we say so, then nobody will use it before one is set production
 +<​miconda>​ it is what we have for long time
 +<​osas>​ c'mon guys, we are burning to much gas here ....
 +<​miconda>​ does not mater if it is called beta, rc or preproduction
 +<​miconda>​ if one sees that won't use
 +<​miconda>​ from my point of view, .0 is production ready
 +<​miconda>​ I am not using all modules though
 +<​miconda>​ but we cannot do more that that
 +<​miconda>​ so, let's stick to .0 as major release
 +<​miconda>​ no, rc, beta, preproduction or other namings ...
 +<​miconda>​ all those shall be done before, if it is a need for such
 +<​tramjoe_merin>​ the issue is not the naming scheme, the issue is to get an organised community, and this is tuff work, requires people dedicated to it
 +<​tramjoe_merin>​ but this could be the topic of an other meeting
 +<​tramjoe_merin>​ and will probably be something raised for sip-router meeting
 +<​miconda>​ we will need to go for a release manager
 +<​miconda>​ and some assistants ...
 +<​miconda>​ there are quite many devs, so we need to coordinate somehow
 +<​miconda>​ probably we will have another irc discussion just before freezing
 +<​tramjoe_merin>​ When I was working at mandrakesoft,​ we used a 3 circles approch: circle one are developpers,​ circle 2 are reference users tat get a benefit for that status and in exchange test pre releases in their environment,​ circle 3 is the community at large. The challenge is to create that 2nd circle and MANAGE it
 +<​tramjoe_merin>​ Creating that subset can be done with develloppers time: exchaneg a commitment to test for some free support
 +<​henningw>​ i tried to make testing easier, building this daily debian packages of trunk for example, but this should be extended
 +<​henningw>​ you're right, it will be a challenge in creating such a circle
 +<​tramjoe_merin>​ It is possible, believe me
 +<​tramjoe_merin>​ I could give details at a proper time
 +<​henningw>​ lets bring this topic on the table in the next week with the SER guys
 +<​tramjoe_merin>​ ok, I will mark in my todo list to send an email to developpers with my ideas about this
 +<​tramjoe_merin>​ well, ok, then I will prepare some doc for monday
 +<​henningw>​ good, thanks
 +<​osas>​ another thing that I would like to discuss ...
 +<​osas>​ last time I was pushing for cvs to svn migration
 +<​osas>​ what about svn to git or hg migration?
 +<​henningw>​ sip-router.org is already planned to run on git
 +<​osas>​ moving away form a centralized repo
 +<​osas>​ that's good
 +<​tramjoe_merin>​ I thought git was a requisite of sip-router
 +<​osas>​ it helps a lot in porting forward stuff
 +<​osas>​ the issue is that sf doesn'​t support git (afaik)
 +<​osas>​ is that right?
 +<​henningw>​ i also think so
 +<​osas>​ so, what is the solution here?
 +<​osas>​ move away from sf?
 +<​henningw>​ i'd suggest that we get some experiences with git in sip-router (i now nothing), and then see how we proceed
 +<​tramjoe_merin>​ The help page says : "​CVS/​Subversion/​User Accounts/​Mailing list Admins: Security issues related to project CVS/​Subversion tools or lost user account passwords should be reported by submitting a Support Request. Project administrators may now reset their own mailing list admin passwords via the Mailing list Admin, Administer/​Update list page."
 +<​tramjoe_merin>​ No Git in there
 +<​henningw>​ (i know nothing atm about git)
 +<​tramjoe_merin>​ http://​en.wikipedia.org/​wiki/​Comparison_of_free_software_hosting_facilities
 +<​osas>​ henningw, git is very nice in the sense that each repo is a stand alone entity
 +<​henningw>​ i know the basics, did not used it yet
 +<​osas>​ and you can push and pull in any direction
 +<​osas>​ :)
 +<​tramjoe_merin>​ alioth and savannah offer git
 +<​osas>​ first, we need to see if there'​s enough traction for git
 +<​henningw>​ another option would be to host this completly by ourself, as a free service has always some issues. i'm glad for example that they finally fixed the svn commit mails problem
 +<​osas>​ and if it is, then after 1.5 we can switch to it
 +<​henningw>​ we should discuss this on the list too, as many users uses SVN atm to pull sources too
 +<​osas>​ ok
 +<​osas>​ I will send an e-mail to the list
 +<​osas>​ will collect feedback and we will go from there on
 +<​osas>​ what's next?
 +<​miconda>​ sip-router.org
 +<​miconda>​ any particular questions regarding it?
 +<​henningw>​ or suggestion for the discussion on monday?
 +<​osas>​ so ... the plan is to have in 1.6 a common core, right?
 +<​osas>​ the modules will stay the same
 +<​miconda>​ osas: too early to predict
 +<​osas>​ I think git would make perfect sense here since it can handle nested projects
 +<​osas>​ one git repo for the core, one git repo for kamailio modules and one git repo for ser modules
 +<​osas>​ this things needs to be discussed and clarified
 +<​osas>​ it is important if we want to make progress on it
 +<​osas>​ another issue: releases
 +<​osas>​ how are the releases going to be coordinated
 +<​osas>​ since the core will be common
 +<​osas>​ the two parties needs to come up with a common release cycle
 +<​osas>​ otherwise, it will be difficult to manage the core code
 +<​osas>​ and the fixes/​backports
 +<​osas>​ also, a change in the core that affects the modules should trigger a new core release
 +<​tramjoe_merin>​ Well one good reason for this is because it is easier to release a set of modules tyested against a know core
 +<​henningw>​ if both projects are in different repositories,​ then is should be not a problem to backport certain bugs
 +<​tramjoe_merin>​ backporting bugs is never an issue :-)
 +<​henningw>​ or use different branches of the core
 +<​osas>​ it will be a pain to backport all this stuff
 +<​osas>​ there are already backports back and forth between opensips and kamailio
 +<​osas>​ and it is a pain
 +<​henningw>​ yes, i know
 +<​osas>​ adding a third repo ,,,,
 +<​osas>​ so I would like to have three repo's
 +Verlassen carstenbock hat den Kanal verlassen.
 +<​osas>​ core. kmodule and sermodules
 +<​osas>​ managed by git
 +<​osas>​ to super git repos: k and ser
 +<​osas>​ and one common nested git repo: the core
 +<​osas>​ with a scheduled release cycle for the core
 +<​osas>​ every 6 months
 +<​osas>​ regrdless of the modules release cycle
 +<​henningw>​ at least it needs to be coordinated between the projects
 +<​osas>​ like this, if one project want's to release something, there is a stable core
 +<​osas>​ and there will be no interference between the projects
 +<​osas>​ until all the modules are merged
 +<​osas>​ just my 2c
 +<​henningw>​ its planned to have the core as small and stable as possible, because of the reasons you just mentioned
 +<​osas>​ yeah, but you need a clear policy for core releases
 +<​tramjoe_merin>​ you mean core + TM I suppose ? s/core/core + common modules/ in the previous conversation ?
 +<​osas>​ maybe core and tm ...
 +<​henningw>​ core and TM first, yes
 +<​osas>​ I'm not aware of any other common modules
 +<​osas>​ maybe pv ...
 +<​tramjoe_merin>​ osas: me neither, ut I assume at some poimnt it will make sense to deduplicate code for db drivers, etc...
 +<​osas>​ all this needs to be discussed and settled down
 +<​henningw>​ in the long run it makes no sense, to e.g. have two usrlocs, this could be merged. but its more long term
 +<​tramjoe_merin>​ Well, so this is a point for monday: create a roadmap of modules that should be made common, and when, after the core merge
 +<​henningw>​ i'll also take the suggestion with the repository layout with me for meeting on monday
 +<​osas>​ I won't be able to attend the meeting in Germany, but I would like to push the idea of three git repos and a stable release cycle for the core infrastructure
 +<​miconda>​ sorry, a bit caught by something else
 +<​tramjoe_merin>​ osas: I'll make sure this gets mentionned
 +<​miconda>​ we cannot foresee how things are going
 +<​miconda>​ perhaps some modules will reside separately for quite sime time
 +<oej> ...but we can SUBSCRIBE so at least we'll get notifications
 +<​miconda>​ because of duplication,​ etc ...
 +<​sanchiii>​ i wonder whether there is the possibility to create regression tests for fixed bugs from the tracker, so they don't reappear
 +<​miconda>​ let's see the result over the time, some may feel tired to maintain a module in two places, so it simple goes in the common layer
 +<​osas>​ we need a clear strategy before proceeding with the merge, otherwise it will be a slippery slope :)
 +<​osas>​ this will not be an easy/​trivial task
 +<​miconda>​ we start from common core and tm
 +<​miconda>​ plus two branches for the modules
 +<​miconda>​ those will be replica of the ser and openser repositories
 +<​tramjoe_merin>​ I feel the issue of all this will depend a lot on the developpers feelings along the road. Trying to plan thing too much might make people feel "​trapped"​and this is not the goal
 +<​osas>​ adding more modules to the '​core'​ is a good idea
 +<​henningw>​ sanchiii: i did this for a few bugs in the past, but there is no policy to do or similar
 +<​miconda>​ we will continue to use nowadays svn and cvs
 +<​osas>​ we just need a clear release strategy
 +<​tramjoe_merin>​ Still, defining the "​important set of modules"​as an indication is important I think
 +<​miconda>​ kamailio will stick to same release cycle
 +<​osas>​ yeah, but it will have a dependency on the '​core'​
 +<​miconda>​ nobody stops to branch, freeze and release
 +<​osas>​ so the core will be the one that will drive releases on both ends
 +<​miconda>​ it is an agreements that we protect both projects
 +<​osas>​ unless you stick with an old core ...
 +<​miconda>​ and we do not lose anything from both
 +<​miconda>​ core and tm will be shared resource
 +<​osas>​ I want to really push for scheduled core releases
 +<​miconda>​ in the first phase
 +<​osas>​ even if this will not trigger a project release
 +<​miconda>​ core alone is useless
 +<​miconda>​ anyhow, we will discuss it on Monday
 +<​henningw>​ i agree, even more after we ripped out some stuff, like PVs
 +<​osas>​ well, it's the base for all modules ...
 +<​miconda>​ don't expect to get that much new stuff in the core
 +<​tramjoe_merin>​ If I may point to an example I know, maybe some people could look at it: openAIS
 +<​osas>​ core without modules is useless and modules without core is useless ....
 +<​miconda>​ this is the reason we reshape what goes there
 +<​tramjoe_merin>​ it is needed by several project, each of wich maintain a "​patched"​version of it
 +<​miconda>​ doing too many releases will confuse a lot
 +<​tramjoe_merin>​ And then it eventually merges, and start again
 +<​miconda>​ why just core, when the modules, etc ...
 +<​miconda>​ i try to avoid that
 +<​miconda>​ if one sides decide to branch a release, then takes care of porting bugs found to main stream
 +<​miconda>​ anyhow, it is indeed something that needs better specs in how is going to be
 +<​osas>​ I don't see an issue with several releases on the core ...
 +<​osas>​ even if the fixes are minor
 +<​osas>​ each project can decide which core release to incorporate ...
 +<​osas>​ instead of backporting stuff, just switch to the next core minor release
 +<​henningw>​ well, a release its just a tag, we don't need to announce it that much, for example, so it will not create confusion
 +<​osas>​ yup
 +<​henningw>​ i'll take a look at this openAIS project, and how they do it
 +<​tramjoe_merin>​ henning: it is not done by intent
 +<​tramjoe_merin>​ I did not finish
 +<​henningw>​ ok
 +<​tramjoe_merin>​ But it is actually an example of what not to do
 +<​henningw>​ hehe, ok :)
 +<​tramjoe_merin>​ Look at pacemaker which uses it
 +<​tramjoe_merin>​ It needs a separate repo of a patched stable
 +<​tramjoe_merin>​ patches do not get back into openais because it would break other things
 +<​henningw>​ more repositories and patches is something what i clearly don't need
 +<​tramjoe_merin>​ all in all the point is the same when you consider a project using an API (in the larger sense of the terms)
 +<​henningw>​ apache - libapr
 +<​tramjoe_merin>​ The API must be stable enough so bug fixes are really bug fixes, and are not subject to interpretation
 +<​tramjoe_merin>​ it is the condition to get a core that does not need explicit releases to be use
 +<​tramjoe_merin>​ think "​continuous integration"​
 +<​henningw>​ we'll reach that stability probably only after some time
 +<​tramjoe_merin>​ yep
 +<​tramjoe_merin>​ this is why things must be clear from the start
 +<​tramjoe_merin>​ if the goal is to deduplicate work so each project can focus on its specific code (in modules)
 +<​tramjoe_merin>​ then the core must be THE ultimate goal
 +<​tramjoe_merin>​ If that goal is reached, then it will be time to think about more ambitious ideas
 +<​tramjoe_merin>​ BUT
 +<​tramjoe_merin>​ the example of TM , maybe usrloc, subsribers, sl, etc.... makes a case
 +<​tramjoe_merin>​ so the line must be drawn somewhere with tentative steps in a roadmap
 +<​tramjoe_merin>​ The consensus sems to be core + TM in step 1
 +<​henningw>​ yes, i also think
 +<​henningw>​ hard to predict dates, but this should be something that is feasible for 1.6.0
 +<​tramjoe_merin>​ so 10 month from now approx date ?
 +<​henningw>​ its depends of course on the ammount of work we invest in this merging
 +<​henningw>​ but 1.6.0 will be somewhere next summer i think
 +<​miconda>​ yes
 +<​miconda>​ we may do a quick release if we get good work out there
 +<​miconda>​ but let's stick to what we have today
 +<​miconda>​ so, those points will be brought to discussions in Karlsruhe
 +<​miconda>​ something else we should approach now?
 +<​tramjoe_merin>​ I have one question to all
 +<​miconda>​ yes, beer is good in Germany and wine is France :-)
 +<​tramjoe_merin>​ Am I the only one dreaming about integrating more dialog-related features ?
 +<​tramjoe_merin>​ miconda :-)
 +<​osas>​ yes, you are dreaming :)
 +<​tramjoe_merin>​ I mean I made several attempts to gather opinions about a usage scheme related to telco-like usage of kamailio for phone calls using dialog
 +<​tramjoe_merin>​ But that never triggered any response
 +<​sanchiii>​ tramjoe_merin,​ if you look at SASI in ser, this is a way to add applications with dialog state as external processes to ser, in a scalable way
 +<​tramjoe_merin>​ I understand the pros and cons I think
 +<​tramjoe_merin>​ And also the benefit of "light proxy"
 +<​osas>​ tramjoe_merin,​ what exactly are you looking for?
 +<​tramjoe_merin>​ But still, I think there is room for a non-RFC, not-yet-formerly-described network entity between a B2BUA and a statefull proxy
 +<​osas>​ using the dialog doesn'​t mean that the proxy won't be light
 +<​tramjoe_merin>​ osas: I agree
 +<​osas>​ I'm using the dialog module while handling > 100cps
 +<​osas>​ for profiling
 +<​osas>​ and it is working great
 +<​tramjoe_merin>​ Well, I think that while keeping a proxy core, it is possible to do one-stop topology hiding, call accounting, dialog-statefull security checks, etc...
 +<​tramjoe_merin>​ osas: me too, this is not the point
 +<​patito>​ hi
 +<​osas>​ unless I put something on top of it, but that's a different story
 +<​patito>​ hi irc
 +<​patito>​ i have kamailio runing
 +<​patito>​ with tls
 +<​patito>​ i have eyebeam
 +Fehler patito: Unbekannter Befehl.
 +<​osas>​ patito, there'​s a meeting going on here ....
 +<-> patito> we're still in a meeting, wait please a few minutes
 +<​patito>​ i need to install certificate
 +<​patito>​ in my user
 +<​patito>​ oh sorry
 +<​osas>​ np
 +<​tramjoe_merin>​ osas: with full DB (call start AA + routing stop + call stop) + dialog module we do 80cps
 +<​osas>​ ah ... DB
 +<​osas>​ :)
 +Verlassen l-fy hat den Kanal verlassen.
 +<​henningw>​ hi Diana :)
 +<​tramjoe_merin>​ well, per DB server, of course :-)
 +<​osas>​ yeah ... DB is a bottleneck
 +Verlassen patito hat den Kanal verlassen ("​Saindo"​).
 +<​tramjoe_merin>​ osas: indeed. Daniel and I talked about a DB load balancer / failover module
 +<​miconda>​ tramjoe_merin:​ all the efforts are incorporated
 +<​tramjoe_merin>​ like a pseudo DB driver
 +<​tramjoe_merin>​ miconda I know, it is only that I do not have a clear enough view of all this
 +<​miconda>​ but i guess each developer sets some priorities based on need
 +<​miconda>​ ok, so it is missing some clear devel docs regarding it
 +<oej> ...and we discussed a new XMPP module...
 +<​tramjoe_merin>​ And if I am the only one thinking the kind of approach I describe has any merit, I certainly won't invest work in a dead end
 +Verlassen auid_1 hat den Kanal verlassen ("​Leaving"​).
 +<​miconda>​ dialog is not a dead end
 +Verlassen carstenbock hat den Kanal verlassen.
 +<​miconda>​ depends on each one how it evolves
 +<oej> The question here is if we're a proxy project or if we're mergin into something else slowly
 +<​miconda>​ i am using it for dialoginfo
 +<​tramjoe_merin>​ Olle summarized it all
 +<oej> Adding more dialog states is moving to a generic SIP development platform
 +<​tramjoe_merin>​ oej: well, seems you read my last email about this then ?
 +<​miconda>​ we try to please everyone
 +<oej> Don't have to go all the way towards the Asterisk mess, but there'​s something in there
 +<​miconda>​ so I am of the opinion that a light core and tm, that are practically a frameword
 +<​miconda>​ framework
 +<oej> Exactly
 +<oej> The question is how much dialog states changes the core
 +<​tramjoe_merin>​ I am still tempted to non-RFCish network entity between a B2BUA and a proxy, but again, I won't go there alone
 +<​miconda>​ offer the basis for a good proxy, a good dialog-aware router, etc..
 +<oej> IAX2 anyone?
 +<​miconda>​ without interfering with the others
 +<oej> (just jking)
 +<​miconda>​ we have iax3.0
 +<​miconda>​ it is called sip :D
 +<​tramjoe_merin>​ oej: do not talk dirty please ;-P
 +<oej> I think we should try to redefine the Kamailio project
 +<​henningw>​ with IAX 2.0?
 +<​tramjoe_merin>​ ok, this is my fault, sorry :-(
 +<oej> The product is much more than just a proxy
 +<​henningw>​ ;)
 +<​tramjoe_merin>​ :-)
 +<oej> But that's just marketing.
 +<​miconda>​ redefine, maube not the right thing, more to say: evolution
 +<oej> Where'​s the marketing department?
 +<​tramjoe_merin>​ you are
 +<​tramjoe_merin>​ the more you push asterisk, that is :-)
 +<​miconda>​ just got fired!
 +<oej> Hmm. Need to check my business card.
 +<​tramjoe_merin>​ hehe :-)
 +<oej> The question remains - will a better dialog module require changes in the core?
 +<oej> And does SER have more of that than Kamailio has?
 +<​miconda>​ no
 +<​tramjoe_merin>​ Seriously, don't you peaople scratch your head when one onthe one hand we get a use case for generating requests like BYEs and on the other the RFC forbids it because we are a proxy ?
 +<oej> Ok, quick answer. Seems like we're fine then.
 +<​miconda>​ core will be just sip parser, config interpreter,​ transport layer, memory manager and some api
 +<​tramjoe_merin>​ I mean, I am sure I am not the only guy who feels there is something to it
 +<​miconda>​ the goal is to expose the core and tm to very low changes and don't turn it in some fat thing oriented to proxy, b2bua, or something else
 +<oej> Well, if you run Kamailio like a proxy you should NEVER do that. But if you run Kamailio as an SBC, you want to hangup calls.
 +<​tramjoe_merin>​ oh ... sorry, I was already past that discussion about the core
 +<​tramjoe_merin>​ obvisously this is not related to core changes
 +<​miconda>​ yes, but proxy and sbc should be transparent to core
 +<​miconda>​ it is the above layer
 +<oej> Hey, that was hurting us asterisk people - "fat thing"​.
 +<oej> Asterisk is lean and mean.
 +<oej> ;-)
 +<​miconda>​ no intention ...
 +<​tramjoe_merin>​ I thought "<​miconda>​ something else we should approach now?"​meant "now that we are done talking about the core"
 +<​osas>​ kamailio is more then a proxy ...
 +<​osas>​ so letting kamailio disconnect calls it's not a bad thing
 +<​tramjoe_merin>​ osas: but is is anti-RFc
 +<oej> Yes, for proxy use.
 +<​tramjoe_merin>​ So it will never get adopted widely unless there is a strong statement behind it
 +<​miconda>​ osas: there are two things, kamailio as core and tm, adn kamailio with all modules
 +<oej> As long as there'​s power failures in homes, we need to disconnect calls somewhere.
 +<​osas>​ it was design as a proxy fundamentally,​ but it is a SIP router
 +<​miconda>​ yes, with some modules, kamailio is lot more
 +<​tramjoe_merin>​ oej: yes, but we are talking about something NOT a B2BUA there,
 +<​miconda>​ and we encourage this
 +<​miconda>​ but none of functionality driven features should pollute the core
 +<oej> Well, I can configure Kamailio not being a proxy really, but doing some of these things to keep stuff going and protect some internal stuff.
 +<​osas>​ and there'​s nothing that prevents creating a b2bua module
 +<​miconda>​ all can reside in modules
 +<​tramjoe_merin>​ miconda: well, then "​sip-router"​project should be "​sip-core"​!!! :-)
 +<​miconda>​ the "​KERNEL"​ :-D
 +<​tramjoe_merin>​ right
 +<oej> sip-routing-runtime,​ srr
 +<​tramjoe_merin>​ "​primitive people"​vs "fat people"​ ??? :-)
 +<​sam__>​ exit
 +<​klaus_darilion>​ miconda: Does dialoginfo work for you?
 +<​miconda>​ for the limited tests I did
 +<​miconda>​ but it is in my next solution
 +<​miconda>​ thanks for developing it
 +<​miconda>​ i guess others here are very happy as well ...
 +<​tramjoe_merin>​ Dialog info is specific to presence, right ?
 +<​miconda>​ so, can we conclude here the meeting?
 +<​miconda>​ and continue free conversation?​
 +<​tramjoe_merin>​ ok for me
 +<​tramjoe_merin>​ (as I am the main trouble maker)
 +<​miconda>​ we will try to get minutes and post them on the dokuwiki
 +<​miconda>​ and maybe a summary on mailing lists
 +<​sanchiii>​ tramjoe_merin,​ how would you create in-dialog requests without being b2bua? (apart from BYE, which ends the dialog afterwards anyway)
 +<​tramjoe_merin>​ sanchii: well, you have to pretend you are one of the endpoints involved in the dialog
 +<oej> there'​s a case for SEMS++ here :-)
 +<​sanchiii>​ oej ;)
 +<​samu60>​ I arrived quite late :( is there any irclog besides the minutes that will be posted in the wiki?
 +<​tramjoe_merin>​ If you are not an other UA, you must fake being one of them
 +<​sanchiii>​ yes, but i guess you will run into lots of troubles with that
 +<​tramjoe_merin>​ I use sems, but it does this with its b2bua module
 +<oej> yes, that will mean trouble
 +<​sanchiii>​ if you are doing this, then it is imo better to do b2bua
 +<​sanchiii>​ whether in the process/​software that is the proxy, or outside of it
 +<oej> Who said "​b2bua'​s rock!"?​ Hmm. I just did.
 +<​sanchiii>​ i hope it wasn't me
 +<​henningw>​ samue60: not know a completle log atm, but we'll post the log of this meeting on the wiki
 +<​samu60>​ thnx Henning
 +<​tramjoe_merin>​ henningw: please do so, my log got truncated :-(
 +<​osas>​ L-info has a website with all the logs ...
 +<​henningw>​ also from #kamailio?
 +<​henningw>​ Jerome: i'll do later today
 +<​osas>​ dunno about that :p
 +<​tramjoe_merin>​ I did not know #kamailio was archived ?
 +<​tramjoe_merin>​ thx
 +<​osas>​ it was openser
 +<​osas>​ I forgot that w switched channels
 +<​samu60>​ L-info, can u publish the website address, please?
 +<​tramjoe_merin>​ well, THIS is a topic: have channel; archives somewhere for the fututre, if anyone knows who to contact ...
 +<​henningw>​ perhaps we just ask l-info
 +<​henningw>​ he's in the channel too