– Kamailio SIP Server –

Differences

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)
212.227.35.68 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