– Kamailio SIP Server –

<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