|
|
|
development:irc-meeting-minutes-06-11-2008 [2008/11/06 19:22]
212.227.35.68 created |
development:irc-meeting-minutes-06-11-2008 [2008/11/06 19:22] (current)
212.227.35.68 created |
| | <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 |
| |
