<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” <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