====== Meeting minutes for 2009-04-14 ======

===== beginning =====

<code>

<henningw> http://sip-router.org/wiki/devel/irc-meetings/next - hello by the way :)
<ibc> hi ;)
<miconda> hello!
<mariuszbi> hello ... 10 minutes and counting
<CrazyTux> Morning all
<erm_> hi!
<miconda> sooo, we can start
<miconda> others will join as we go ...

</code>

===== kamailio 3.0.2 release =====

<code>

<miconda> kamailio 3.0.2
<miconda> anyone having some showstoppers?
<henningw> 3.0.1 was released 8th of march, so a 3.0.2 sounds resonable
<miconda> when? 2 weeks from now?
<Guest23310> i don't have any stoppers
<henningw> there are probably a few smaller bugs, but i see no major problems
<henningw> two weeks is just fine for me
<mariuszbi> 2 weeks are also fine... i have some small bugs to cherry-pick from master...
<henningw> (smaller bugs like the this opensuse thing from today..)
<henningw> so perhaps 27th or 28 of april
<henningw> ?
<miconda> ok for me
<miconda> closer to that date we will see which one exactly
<henningw> ok, we'll just announce the list end of next week
<miconda> ok

</code>

===== sip-router =====

<code>

<miconda> sip-router stuff now
<miconda> andrei is not yet in ...
<ibc> he is
<miconda> or is under cover :-)
<ibc> ah no, I see "andrew_p"
<ibc> he is not andrei :)
<miconda> :-), yes, i thought the same first time, very close ...
<timo_r> Guest23310 ?
<andrew_p> ibc: right :) i have been using kamailio for a while so decided to watch the meeting
<Guest23310> guest23310 is juha
<henningw> ok, perhaps we can come back to this points later on, after he joined
<timo_r> ah ok
<miconda> yes

</code>

===== new dialog design =====

<code>

<miconda> so, one thing that was really discussed is the dialog module
<miconda> new design, etc...
<miconda> personally I was too busy to follow closely
<henningw> miconda: what about your points, the lua stuff
<henningw> ?
<henningw> or we wait for Andrei for this as well?
<miconda> yes, my points ... I thought to decide about them when we have andrei to plan a date for next release
<henningw> sure
<ibc> ok, when we deep into the dialog module proposal timo and me have some doubts about the TM behavior
<miconda> but we can go on them
<henningw> no, just continue with dlg
<ibc> ok, the doub about TM is the following:
<miconda> i know andrei has some vacation, hope he is able to connect somehow ... emailed him
<ibc> RFC 3261 states that a client transaction should be destroyed upon receipt of the first 200
<ibc> but it causes problems as a retranmission of the INVITE would be considered as a new INVITE
<ibc> then the draft invfix fixes it (updates RFC 3261): a client transaction must remain in memory for a while after the first 200. It allows matching a retranmission of the INVITE or 200
<ibc> such feature is required for the dialog module proposal
<timo_r> (if you wanna take a quick look: http://tools.ietf.org/html/draft-sparks-sipcore-invfix-01)
<ibc> does TM behaves like that?
<henningw> there is the delete timer in TM
<miconda> yes, tm keeps the transaction in memory for a while
<timo_r> is it 64*T1 by chance?
<henningw> sorry, i mean wt_timer
<miconda> i think the parameter name is wait timer or so
<henningw> "Time for which a transaction stays in memory to absorb delayed messages after it completed."
<ibc> the point is that dialog module should mantain for a while the other dialog_out entries (other branches) after the first 200 has arrived, rather than immediately remove them
<ibc> yes, it's 64xT1, but it's a new timer ("D" I think)
<andrew_p> yep it's defined as "D" in 3261#section-17.1.1.3
<ibc> sorry, Timer L:
<ibc> If the SIP elements's TU issues a 2xx response for this transaction
<ibc> while the state machine is in the "Proceeding" state, it MUST
<ibc> transition to the "Accepted" state and set Timer L to 64*T1
<ibc> "Accepted" state is a new state not present in RFC 3261
<ibc> does TM already implement it?
<timo_r> ibc: there timer M also: "Instead, the machine will transition to a new "Accepted" state, and remain there just long enough, determined by a new timer M, to receive and pass to the TU any retransmissions [...]"
<ibc> right timo, timer M (64*T1) is the new timer for "Accepted" state in the client transaction after receiving a 200
<timo_r> L is for the server part, M for the client
<ibc> yeah
<miconda> so, we hat the wait timer for years, being configurable
<miconda> the defaut value might not be 64*T1, though
<miconda> but easy to fix from config anyhow
<ibc> what we need is: a 200 arrives and after such timer the dialog callback is called in order to destroy all the entries under dialog_out table (but the confirmed one)
<miconda> it is the TMCB_DESTROYED which is called when tm structure is destroyed
<miconda> well, just before being destroyed
<miconda> dialog module uses that even now
<ibc> ok, so this was the only pending issue we have with the new dialog module proposal, solved now
<miconda> good ... i was a bit scared by the volume of emails exchanged :-)
<ibc> has somebody took a look to the wiki page explaining it? any doubt or question?
<timo_r> miconda: understandably :)
<miconda> now, what is the plan with it
<miconda> do you want it in 3.1?
<miconda> i will look at the wiki page
<miconda> i wanted to be sure is the latest version
<miconda> updated with conclusions from ML discussions
<timo_r> considering the length of the thread, the proposal is more frightening than it really is now
<ibc> I will make a small update to the wiki page today, it should be the final version (if no changes are required)
<miconda> an implementation? how long would you estimate
<timo_r> I think we can hold on to a good deal of the current dialog module, especially the state machine...
<timo_r> splitting the single table into two will require some effort as well as covering corner cases, like "concurrently confirmed calls" (that's my creation)...
<timo_r> I've also implemented some part of the spiral code in 1.5 way before we started this proposal
<mariuszbi> two weeks is a little steep.. IMHO
<timo_r> yeah probably more
<henningw> i think the question is more for 3.1, or 3.2?
<ibc> also note that modules on top of dialog module should also be updated
<timo_r> true
<timo_r> what's the schedule for 3.1 and 3.2 again?
<miconda> well, we try to figure it out based on need
<miconda> waiting few weeks won't be a problem
<henningw> its still a few months..
<henningw> 3.1
<mariuszbi> another q: do we plan to keep the old module also, or replace it with the new functionality and force modules maintainers to upgrade ?!
<miconda> i was thinking to enter testing phase in june/july
<timo_r> I'm thinking 3-4 weeks should be good
<miconda> and release beginning of autumn
<miconda> i would say to keep current module one more release at least
<miconda> some modules might not be updated because of time constraints
<ibc> IMHO the new design is an improvement over the current module, it makes no sense to mantain both at the same time
<henningw> ack
<Guest23310> the new dialog module coulf go to modules dir
<miconda> ibc: if everything is ugraded to the new one, it is fine for me
<mariuszbi> (OFFTOPIC) hehe.. fixed the problem with mysqlclient on opensuse... link with -lm :D
<ibc> yes, the new module would be coded in other branch or with a temporal name as "dialog_new" or whatever until it's merged and replaces the dialog module
<miconda> it was for eventuality of not updating
<miconda> mariuszbi: ok, tnx
<Guest23310> i tried to say that now dialog module is in modules_k. the new one could go to modules under name 'dialog'
<miconda> we can use a new name, like dlg
<ibc> it would really make sense as it just depends on TM module
<miconda> iirc, there is dialog module in modules_s, or?
<timo_r> I'd rather see dialog2
<henningw> hm.. other modules where also updated quite extensivly, like e.g. LCR, and they just kept the name
<henningw> afaik there is the versioning on DB, which is sufficient
<Guest23310> why new name, when using 'modules' dir would make it unique anyway?
<henningw> also true
<miconda> it was a proposal
<miconda> anyhow, this is last thing to think about, dialog is just fine
<ibc> humm, fix: dialog module also depends on rr module, and for now there is a rr under modules_k and other under modules_s
<miconda> right
<miconda> hopefully we will merge them soon
<miconda> at least sl is on my todo list
<Guest23310> so moving rr to modules would make sense too
<ibc> so then the new dialog module could jsut be "modules/dialog"
<miconda> the rr in modules_k and modules_s have some differences
<miconda> how they handle addition of new parameters, etc...
<miconda> not sure what ser modules depend on rr
<ibc> but will they be merged soon into modules/rr then?
<miconda> but i would really want them merged
<henningw> miconda: this would be indeed nice
<miconda> so, anything else about dialog-ng?
<timo_r> does anyone see a problem with having to abandon conventional SIP header matching mode in dialog module in favor of the RR way?
<timo_r> I'm not sure if some modules can't use RR mode
<miconda> there are some UA stripping parameters in RR
<timo_r> possibly making upgrading difficult
<miconda> that is the only problem
<ibc> jsut to clarify: the problem is that legacy/conventional SIP header matching for dialog is not valid to detect an spiral
<henningw> perhaps we can then keep this mode, and document it appropriatly?
<miconda> not even using via?
<ibc> INVITE --> P1 --> P2 --> P1
<ibc> when the INVITE arrives again to P1 it has 2 Vias more than the first time, but it should be required to inspect all the Via values, and such info is not stored within dialog information
<henningw> but the current mod does not work for spiral either
<ibc> no, it doesn't
<miconda> right, either keeping a reference to invite transaction or for dealing with spirals, rr matching is required
<ibc> the easiest solution is matching the dialog using the rr cookie
<miconda> ok ... if someone will need, then can extend to go through via stack and match local ip
<timo_r> I think it should be feasible with conventional matching mode too... you'd have to remember the via set when the dialog structure is created
<miconda> and cookie type
<miconda> ahh, adding a cooking in via should solve
<ibc> timo: but what about when an in-dialog request (BYE) arrives?
<ibc> sorry, there is no need for that as no new dialog would be created
<miconda> ok
<ibc> humm, but... the BYE would match the dialog twice! it's not ok
<miconda> i would go for first version with rr
<ibc> me too
<miconda> then add on if needed
<timo_r> same here
<miconda> if you don't keep the dialog twice for spiral, will match all the time twice
<ibc> and destroy UA's which remove parameters in RR :)
<timo_r> it's just that unless we add that conventional matching feature, modules requiring it cannot upgrade
<timo_r> if such modules exist... just wondering.
Beenden Pazzo hat den Server verlassen (Quit: ...).
<miconda> ok, done with this one?
<Guest23310> if UA removes RR params then lost of other things break too
<henningw> right

</code>

===== module merging =====

<code>

<miconda> next: merging/splitting some modules
<miconda> I, Ovidiu and Juha added on agenda
<miconda> sl, textops ... for merging
<Guest23310> i suggest merging textop modules, because features from both are needed
<Guest23310> i could try to do that myself
<miconda> a problem might be with common functions expecting different type of parameters
<miconda> in K side most of the accept PVs
<miconda> not sure what is the situation in S side
<Guest23310> are there such functions where params differ?
<miconda> but i think won't be a problem to combine them to support both cases
<miconda> haven't looked at S textops
<miconda> the best is if are not
<Guest23310> ok, i'll take a look and report to the list
<miconda> ok, thanks
<miconda> sl I think is easy to do
<miconda> based on same idea
<miconda> to keep compatibility with both
<miconda> is not a big module to rise issues
<Guest23310> what about domain module, is it ok to make s version modules version?
<henningw> i think the problem is here the DB structure?
<Guest23310> i don't have access to k version now, but does domain table there contain anything else than domain col?
<henningw> but don't used it that much
<miconda> i think s version of domain is ok
<Guest23310> what i tried to say that s table structure is superset of k one
<miconda> i will add some part which is missing that I added in modules_k/domain before 3.0
<miconda> the part to register domains to myself conditions, which is off by default
<henningw> (this is the doc from Jan where he evaluated all DB structs from s and k : http://iptel.org/jan/db_merge)
<henningw> Recommendation 
<henningw> Make sure that the merged table contains all columns from both schemes: 
<henningw> CREATE TABLE domain ( id INT(10) UNSIGNED AUTO_INCREMENT did VARCHAR(64) NOT NULL, domain VARCHAR(128) NOT NULL, flags INT UNSIGNED NOT NULL DEFAULT '0', last_modified DATETIME );
<miconda> yes, as Juha said, s table structure includes what k version needs
<henningw> he said this about the domain module
<miconda> ok
<miconda> this is easy then
<miconda> move modules_s/domain to modules
<miconda> once the myself stuff is ported, can remove modules_k/domain
<henningw> with mysql stuff, you refer to the scripts and stuff?
<henningw> admin interface..
<miconda> no, it is myself
<miconda> not mysql
<miconda> to match if(uri==myself) for example
<henningw> ah, sorry
<henningw> sure
<miconda> if uri has one of the domains in the table
<miconda> it is off by default
<miconda> but it is handy from script point of view
<miconda> osas: are you here?
<miconda> Ovidiu suggested to split radius part from acc, being hard to package it
<Guest23310> please don't change the default, i want myself to mean only the proxy itself
<miconda> which I would like as well
<miconda> Juha, no, it won't change. I understood that
<henningw> radius is deactivated by default in acc. but i'd guess that its indeed a bit of a problem for not that common systems
<henningw> same problem as in cr (libconfuse), ovidiu also mentioned it a few times here
<mariuszbi> does "myself" benefits from having a db backend ? there is a command to add aliases at runtime / or reload them from db?
<henningw> marius: there are fifo cmds
<henningw> to reload from DB
<miconda> mariuszbi: the idea with myself and domain is that domain module register a function to be called when myself condition is executed
<miconda> then domain matches or not what is r-uri, etc. with its list
<miconda> if you reload domain table, then the new values will be used
<mariuszbi> understood..

</code>

===== accounting module =====

<code>

<miconda> the problem with acc is different than cr
<miconda> the problem is packaging
<miconda> if we enable radius, the acc should go in radius modules package
<henningw> ah, debian packaging structure vs. packaging problems, i see
<miconda> which is not acceptable since lot of people use acc without radous
<henningw> hm.. perhaps its possible to hack something as a workaround on the packaging level, but this would be probably not pretty
<miconda> if we have acc for syslog and db, then acc_radius separate, it is easy to group them
<miconda> how?
<miconda> including acc in both packages?
<miconda> will be a conflict of names
<henningw> hm.. yes something like this. not sure if it works, just an idea. you could do replace and something like this.. but it would be of course way better to fix it in the src
<henningw> like acc export an API, and then acc_radius use it
<miconda> yes, kind of
<miconda> i see osas is here, but probably not in front of computer
<miconda> to see if he thought about some solution
<henningw> he stays in way another timezone
<henningw> perhaps we can discuss it further on the mailing list?
<miconda> sure ... ok, so, we covered sl. domain, rr, textops. acc ... any other modules that should have high priority to merge?
<osas> miconda: here
<miconda> hi osas!
<osas> hello all
<miconda> we discussed about acc and radius, you proposed the topic, have you thought about some solution?
<osas> can we merge the acc modules for the next release?
<osas> s modules are already separated, irc
<osas> s acc modules
<miconda> ok, then we have to see the differences
<osas> I see that the sl module was covered
<miconda> I think db_extra and multi leg stuff are additions done by kamailio
<osas> as soon as the sl module is migrated to the common list, many other modules can be merged too
<miconda> sl will be for 3.1
<osas> good
<osas> sl should be a priority
<osas> because it blocks other modules

</code>

===== module export interface =====

<code>

<osas> also, what should we do about the module_export stuff
<osas> we have version 1 (ser) and version 2 (openser)
<osas> I uploaded a patch by adding the ser rpc to openser modules
<osas> should we keep the rpc in the export_structure or should we let each module register it's own rpc functions?
<osas> It would be nice to merge the module exports for 3.1
<osas> it makes development easier
<andreip> I would go for the module register
<miconda> Andrei is working on a new interface, I guess from the mailing lists
<miconda> I won't alter existing ones
<osas> you mean the way that the register modules regiter it's own rpc's?
<miconda> since it is possiblity to register from mod init
<andreip> actually I was thinking to keep the old one too8unless someone really wants to update all the 100x modules)
<osas> I already did for k modules
<miconda> is done this way in some modules
<andreip> osas: yes, each module register its own rpcs
<osas> it wasn't fun ... I have to admit :)
<miconda> :-)
<osas> I found later about the export stuff :(
<miconda> adreip: yes, keeping old ones would be good
<osas> ok
<miconda> but I won't change them
<osas> then the patch can be discarded
<andreip> so the question is, do we add a new old one?
<miconda> if something is going to be added, should be on a new one
<andreip> e.g.: ser, kamailio, sr 3.1 and sr_ng ?
<andreip> where sr_31 = min(ser, k)
<osas> we can do that
<osas> should we mark it as an item for 3.1?
<osas> unified module_export?
<miconda> andreip: osas did a patch to enhance kamailio interface with rpc command structure
<andreip> for me it's ok either way
<osas> I would like to have it unified
<andreip> miconda: I haven't seen it yet (sorry), but wouldn't it break existing k modules?
<miconda> which makes no sense in my opinion .. it is better to define one new, and migrate modules to it
<osas> and if we unify it, maybe we should keep the rpc's in the structure
<osas> less code to write in the init
<andreip> osas: but more 0's to add for module that don't have any rpcs :-)
<osas> in the beginning
<osas> but the goal is to migrate all k modules to ser's rpc
<osas> I started to work on ratelimit's rpcs
<osas> and this was the firt thing that I hit
<miconda> maybe we should discuss on mailing list about the new mod interface
<miconda> i am more of slimmer structure
<osas> once the interface is there, more modules will be migrated
<miconda> and register functions
<osas> ok, we can discuss this in the ml
<miconda> it does not require updating 150 modules every time
<osas> but we should agree about migrating to a single sversion
<henningw> agree
<miconda> yes, it should be one version from now on
<andreip> I don't think we should migrate them all
<miconda> or from soon on :-)
<osas> micond, the modules will be touched anyway (while migrating)
<osas> so I don't see an issue here
<miconda> but they will be migrated as needed
<osas> but for new functionality, we can go via the register method
<miconda> not as must because don't compile
<andreip> we can make a new 3.1 version (we already have mod interface versioning) and we leave the option open for the module maintainers (stick with the old, or update to the new)
<osas> anyway, more duscussion on the ml
<osas> discussions
<miconda> andreip: i would require the new interface for new modules
<osas> for now, do we agree to migrate to a new interface?
<miconda> and the old to be updated as time allows/some needs it
<andreip> it's ok for me
<miconda> osas: not a "force everyone to migrate"
<miconda> but a new interface to be used by new modules
<osas> ok, then we agreed to migrate to a new interface
<miconda> and if someone is bored and has time, can migrate from existing modules :-)
<osas> implementation details: TBD on ml
<miconda> ok
<andreip> jut to eliminate confusion: in 3.1 we will have sr_3.1 mod interface, sr ng (another function format) and old ones for backward compat (ser & k)
<osas> next thing that I would like to have fixed is flavours
<osas> andreip: fine by me
<miconda> andreip: what is sr_3.1?
<andreip> sr_3.1 is what osas is proposing
<andreip> a variation/unification of ser & k mod interfaces
<osas> maybe it's time to merge the dev path for sr and k releases :)
<osas> to avoid any confusion
<osas> and maybe we should release only sr
<osas> no more ser or kamailio ...
<Guest23310> i fully support releasing only sr
<miconda> that is not easy, will discuss on other time
<osas> this will require migrating most (it not all) the modules from s and k to generic
<andreip> I agree, but technically it might not be possible
<osas> ok
<osas> let's get back on track
<andreip> (limited time, and different DB interfaces)

</code>

===== config compatiblity mode and flavours =====

<code>

<osas> flavours
<miconda> yes ... back on track
<osas> can we get rid of them?
<miconda> for config file, the #!XYZ, I think yes
<henningw> we speak now about the make flavours, not the different compat modes in cfg
<henningw> ?
<miconda> i think is config compat modes
<henningw> ah
<miconda> i think we can get rid of that
<osas> I have issues with accounting (I get different results based on different flavours)
<Guest23310> me too
<osas> and it is confusing
<henningw> yes
<miconda> with acc?
<osas> well, I need to digg more on it
<miconda> what are the differences?
<miconda> ok
<osas> it seems to be related to $T_reply_code
<miconda> anyhow, I think cfg compat mode should dissapear
<osas> I will send an e-mail to the ml
<miconda> and if is something that needs to behave differently, it has to be a modparam or so
<osas> Iiirc, drop was an issue for ccompat mode
<osas> maybe we can come up with abort instead of drop
<osas> to avoid confusion
<miconda> the only thing I see pretty much different is reply code handling in failure cases
<andreip> drop should now be the same everywhere
<osas> or, we can keep drop and document it properly
<osas> andreip: even on branch route?
<miconda> no, drop is the same
<miconda> in branch route is not yet in any
<osas> miconda, which one was different?
<andreip> yes, replies + adding branches in the failure route are slightly different
<miconda> it was a pacth i sent
<Guest23310> does drop work on branch route? readme says 'no'
<miconda> I made a patch for Andreas Granig, he said it is working
<miconda> i was waiting for Andrei to see if it is ok
<miconda> that was forgotten during the integration work
<miconda> many seem to use the drop feature in branch route
<osas> ok
<miconda> andreip: that can be controlled via tm parameter
<Guest23310> yes, it would be important (drop in branch)
<osas> are there any other constrains in dropping flavours?
<miconda> so we get rid of compat mode and have a new tm parameter
<osas> miconda: I would like to have drop behaving in a single way
<miconda> osas: flavour is something else that config compat
<osas> to many config params leads to confusion
<miconda> flavour is when you want binary to be called kamailio
<miconda> and want db structure from kamailio
<osas> ok, then I suppose we are talking about compat
<miconda> cfg compat is kind of hidden global parameter controlled by #!KAMAILIO or #!SER at beginning of config
<osas> srry for the confusion
<miconda> this should be removed
<osas> yup
<miconda> and i see no problem
<Guest23310> i too don't like tm param for drop bahevior, better a new function (abort) if necessary
<miconda> Juha, drop was cleared
<miconda> it is the same
<miconda> the other thing is about selecting the winning branch in failure route
<Guest23310> the same documented where?
<osas> but no extra config params in tm
<miconda> in kamailio we discarded automatically the previous branches in a serial forking case
<miconda> in ser is different
<osas> I don't want to move cfg compat from config file to module params
<miconda> so if you get first time 302, you handle via uac_redirect and then get a 500, in failure route you get 302
<miconda> again
<miconda> well cfg compat is at global level
<miconda> there are module parameters controlling such behavior
<osas> yes, but it was controling drop
<miconda> like auto appending of branch or not with dispatcher
<osas> I don't want a new param for drop
<miconda> osas: I think you are confusing
<osas> maybe ...
<miconda> it is not about drop at all
<miconda> forget about it
<osas> ok
<miconda> it is the same everywhere now
<miconda> I can explain later with an email
<miconda> the only difference which is related to serial forking, not drop
<osas> miconda: you confused me by this: [12:32] <miconda> andreip: that can be controlled via tm parameter
<osas> that's why I thought that you want to control drop via a tm param
<miconda> it is about serial forking
<osas> k
<osas> so, is there anything else that needs to be addressed?
<miconda> not about new mod interface and cfg compat
<osas> I think these were the most important ones ... along with the sl migration
<osas> migration/merging
<miconda> ok

</code>

===== release 3.1 =====

<code>

<miconda> now, back to the 3.1 schedule
<miconda> here comes ongoing devel and how much each developers estimate to take
<Guest23310> i would suggest 3.1 rel in sep
<miconda> or, in other words: when you think we should have 3.1 out?
<miconda> ok, Juha thinking ahead :-)
<miconda> i think sep is fair, i am for it
<osas> beginning of sept we should have a code freeze
<osas> and a release by the end of september
<osas> september is a good month for testing
<miconda> maybe freeze a bit earlier
<osas> august, not quite :)
<osas> ther are a lot of stuff that needs to be done ...
<miconda> always will be lot to do
<osas> miconda: what's your proposition for code freeze?
<miconda> but we should not bring to many radical changes to make upgrade too hard
<miconda> I am for release in september, as said
<osas> well, sooner or later one needs to bite the bullet
<miconda> so i will freeze in summer (not myself, but the code)
<osas> miconda: begining of september?
<henningw> i'd also go a bit earlier
<osas> I doubt that ppl will do a lot of testing in august ...
<miconda> anyhow, let's see the plans
<miconda> how lone each one needs for proposed additions
<miconda> andreip has quite some big plans
<henningw> right
<miconda> with async tls and mod interface
<miconda> I think i can finish what I have in mind for 3.1 in 2 months or so
<miconda> henningw said something about a new module
<Guest23310> will async tls be in 3.1?
<henningw> its already done
<miconda> ibc and timo_r work with dialog-ng
<henningw> the new mod, only need to adapt to sr, and probably test and document a bit
<osas> If sl is done on time, I can migrate ratelimit
<miconda> then the merging of duplicated modules, some can be done in testing phase
<miconda> henningw: ok, great
<osas> sl is one of the key module
<andreip> async tls will be in 3.1
<osas> it blocks other modules to be migrated
<miconda> ok, will put some priority on it
<andreip> it would make it into master in 2w - 1 month
<Guest23310> how about possiblity to specify that for example http query function should be executed async?
<andreip> that's most likely not for 3.1
<andreip> (it would require a lot of work and experimenting to make it work in general)
<Guest23310> ok, tls is more important
<miconda> Juha, you can do it from code
<miconda> not in a generic way
<miconda> bind to tm and use t_suspend and t_resume ...
<Guest23310> example somewhere?
<miconda> I haven't seen ...
<Guest23310> i'm copy paste programmer :-)
<miconda> I was looking for something async for some specific sip needs
<henningw> there are some genereic docs in tm readme about this function
<henningw> but no example code ;)
<miconda> get invite, park it with t_suspend, send an options, and based on result resume the invite
<miconda> the reply for options will come in another process, latter
<ibc> hi, let me a question also related to http://tools.ietf.org/html/draft-sparks-sipcore-invfix-01
<Guest23310> easier to implement in sems!
<ibc> such draft (which updates RFC 3261) states that "If the server transaction is no longer available to handle the transmission, the response is simply discarded."
<miconda> andreip: any favorite time for branching 3.1?
<andreip> miconda: no, I was thinking end of June
<andreip> so August or September are ok with me
<miconda> ibc: you can do something like: check if transaction exists and if not drop the reply
<ibc> this is: the draft tells that responses not maching a server transaction must be droped rather than statelessy forwarded
<miconda> andreip: ok
<ibc> yes I know, but I wonder if it should be the default behavior
<ibc> in fact I already coded this feature in TM in Kamailio
<miconda> default behavior with sip router is to drop every request
<miconda> :-)
<andreip> ibc: dropping unmatched replies could cause more problem and I don't really see what it solves
<ibc> do you mean "responses"?
<miconda> no, requests
<miconda> if you don't call forward or t_relay :-)
<ibc> according to http://tools.ietf.org/html/draft-sparks-sipcore-invfix-01 forwarding responses statelessy is a secury risk
<miconda> ibc: i agree they can be used to flood hosts
<ibc> yes
<miconda> being possible with config option is fine for me
<miconda> you will never have something working and pleasing everybody with ietf specs (you know it), so config is the solution
<ibc> I coded it in kamailio TM: http://www.kamailio.org/docs/modules/1.6.x/tm.html#id2530689
<miconda> ok, can we conclude: target for 3.1 is september, freeze as we accomodate the planned development any time starting end of june
<miconda> ibc: ahh, so this was forgotten as well ...
<miconda> will check to see if can be accomodated
<ibc> well, it's also possible by doing "onreply_route[0] { drop; }", but I did like a TM config option for that :)
<miconda> yes: a function: route_sip_as_I_whish() would be good for me :D
<miconda> other topics?
<henningw> miconda: september release, July or so freeze should be fine

</code>

===== control tool unification =====

<code>

<henningw> miconda: i think Marius also wanted to discuss a bit about this ctl tool unification
<henningw> Marius, are you back?
<miconda> ok, let's go
<miconda> he is in a time zone where it becomes a bit late
<henningw> yes..
<miconda> he wants to move from fifo to binrpc interface
<miconda> in order to use sercmd, right?
<henningw> yes, think so
<henningw> in order to properly support the sr cmds, like cfg value reload and such in K modules
<henningw> which he worked on
<miconda> that would be helpful, considering it can be used remotely
<Guest23310> i too would prefer rpc for everything
<henningw> xmlrpc?
<osas> for next release, we should add ser rpc and still keep fifo
<miconda> sercmd uses binrpc
<osas> it will provide an easier transition
<miconda> osas: might be hard in the same tool
<henningw> agree, the transition was also our concern
<miconda> we can have kamctl and kamrpc
<osas> we keep kamctl as is
Beenden andreip hat den Server verlassen (Read error: Connection reset by peer).
<osas> and yes, we can have kamrpc
<osas> and in 3.2 we can drop kamctl
<henningw> i think in the medium term we should also try to remove the nr of config cmds
<osas> but I would prefer to have sr-rpc
<osas> all the tools should be migrated to sip-router
<miconda> kamctl uses the kamailio database
<miconda> it is not only about control commands
<miconda> but adding users, etc...
<henningw> i think this was actually our agreement. keep kamdbctl, and strip all FIFO functionality from kamctlrc, and let serctl do most of the work
<osas> once most of the modules are merged, it makes no sense to have ser/kamailio
<henningw> s/kamctlrc/kamctl
<osas> henningw: we can do that only if all modules are migrated to ser rpc
<henningw> so kamctl would only do the DB stuff, like adding subscriber and stuff
<osas> for now, I would leave it as is
<miconda> osas: any mi commad can be executed via rpc
<osas> oh ... I forgot about that :p
<miconda> with rpc command 'mi'
<henningw> the functionality in the end would be the same, only name change
<henningw> ah, marius went back
<osas> yeah, but it will need to be documented
<mariuszbi1> hello all :) i am back
<henningw> mariuszbi1: we just discussed the ctl tool unification
<miconda> what i will try to avoid is to make too many tools
<osas> cause right now, changes via kamctl are reloaded via fifo
<mariuszbi1> ok
<osas> and if the fifo is removed from kamctl, it will be a differnt behavior
<miconda> you can reload via rpc
<miconda> rpc mi pdt_reload
<osas> yes, but it needs to be documented
<miconda> but kamctl pdr add adds in database
<osas> and a warning printed out in kamctl
<mariuszbi1> henning is updating with the discussion so far
<miconda> then using another tool to reload will be odd
<henningw> there is actually a cmd from the ser side, ser_ctl which provide means for DB interaction
<osas> I would propose: leave kamctl as is
<mariuszbi1> i have documented the requirements for sercmd/readline ... ATM we can completly drom kamctl for mi commands
<osas> add srctl
<henningw> its written in python, but not yet included in sr repo
<osas> and in the next next relase, drop kamctl
<miconda> python ... brrr :-)
<henningw> ;)
<mariuszbi1> my suggestion was just at documentation level to unify and use sercmd
<henningw> miconda: better than bash
<osas> henningw: it adds another dependecy ...
<miconda> bash is soo small comparing with python :D
<osas> yup
<mariuszbi1> and specify what modules you need to work with sercmd
<henningw> osas: the docs are a bit a problem. to what kind of tool should we refer in the README?
<mariuszbi1> i don't want to remove anything from kamctl atm
<osas> I don't like having a dependency on python
<mariuszbi1> maybe just add a warning that the feature is deprecated
<henningw> osas: kamdbctl already have a python dependency, for dbtext i think
<osas> yeah, but it's small
<henningw> right ;)
<osas> I can get away with ...
<osas> I don't have a need all the time for dbtext
<henningw> ack
<osas> but if python is required for everything ...
<miconda> then, ok, let's keep kamctl as it is
<osas> And I'm not keen in learning python right now :p
<henningw> hm.. i think you agree the current structure of the ctl tools are not that nice
<miconda> have a new tool done by Marius
<miconda> and will see what wins
<henningw> osas: understand :)
<mariuszbi1> my suggestion is like this... all of commands for K/Ser are done only via sercmd
<mariuszbi1> we already support it
<mariuszbi1> and for DB stuff that's another discussion
<osas> why sercmd?
<osas> why not srcmd
<mariuszbi1> current name sercmd
<osas> if the goal is to merge ser and kamailio?
<mariuszbi1> maybe will rename it somehow
<miconda> osas: let's not divert
<miconda> the names are what we have now
<mariuszbi1> but i like more sercmd atm then kamctl ... written in C, support for readline etc
<osas> yes, but all this ser, kamailio sip-router is so ambiguous
<henningw> the tab completion stuff is indeed neat
<miconda> Marius, the problem is that sercmd is just for binrpc comands
<miconda> kamctl can do db operations
<mariuszbi1> yes but with mi_rpc module it can execute mi commands
<mariuszbi1> I know I know
<miconda> and would be odd to have something like
<miconda> kamctl pdt add abcd
<miconda> and sercmd pdt reload
<mariuszbi1> ok
<henningw> what about just calling kamctl if there is a 'db' cmd executed, like a wrapper? not that nice probably, but should work
<mariuszbi1> but atm I have sercmd cfg.set_now_int registrar ....
<miconda> i would like to get rid of fico and use sercmd internally
<miconda> at the end kamctl is just a wrapper
<miconda> a shell wrapper
<henningw> so another wrapper ;)
<miconda> we can have kamctl cmd xyz
<miconda> like we have kamctl fifo xyz
<mariuszbi1> ok
<mariuszbi1> this might work
<osas> better kamctl rpc xyz
<miconda> we can remove the 'fifo' part and stick with 'cmd'
<henningw> ah :)
<henningw> sounds ok
<miconda> osas: will do it configurable so everyone has something he likes :-)
<osas> lol
<mariuszbi1> understood
<mariuszbi1> but still it's a bit messy
<miconda> :-)
<miconda> what do you propose then?
<miconda> different tools for db
<miconda> and direct usage of sercmd?
<mariuszbi1> have one tool for rpc/mi commands and one tool for db operation
<Guest23310> i agree with different tool for db ops
<henningw> perhaps move this from ctl to dbctl tool?
<miconda> but one tool for rpc is there
<miconda> sercmd
<henningw> kamdbctl
<miconda> and calling sercmd from kamctl is one line
<mariuszbi1> miconda: and with that tool we can ran fifo commands
<henningw> i meant move the DB parts of kamctl to kamdbctl
<osas> well, we can create different tools for db and mi and use kamctl as a wrapper ;)
<miconda> fifo is deprecated, or?
<miconda> hmm, i started to get lost
<Guest23310> fifo dep yet
<miconda> kamctl is anyhow a wrapper
<osas> let's reset here ...
<osas> what's the goal here?
<osas> to from mi_fifo?
<miconda> to "cat" for fifo and to "mysql" for mysql
<osas> drop
<mariuszbi1> my goal it to logically separate the command of kamailio/ser from the db operations so that we have a unitary way to write documentation ... and maintain fewer modules
<henningw> and to reduce the number of cfg tools that we have 
<Guest23310> i meant we should deprecate fifo
<osas> deprecating fifo should be easy
<mariuszbi1> my goal: the user doesn't care about what mechanism are behind... it cares about the interface
<Guest23310> and have different command for db (because i don't use any)
<osas> as miconda suggested, we switch to rpc
<mariuszbi1> i don't have anything against fifo, but I don't want to have two frameworks doing the same thing
<miconda> marius, so you want to enhance sercmd with fifo support?
<osas> mariuszbi1, your new tool creates a dependency for python, right?
<henningw> osas: no, this was just another idea
<osas> oh ...
<osas> ok
<henningw> osas: there is a DB tool from the ser side that needs python. but the thing marius suggested don't need it
<osas> good
<osas> then let's have the tool
<osas> and replace all the internal db commands from kamctl with the new tool
<osas> replace all fifo commands from kamctl with the new cmd or rpc
<osas> and we are done
<osas> we keep kamctl as a wrapper (for new backwards compat)
<mariuszbi1> osas: I agree
<osas> and we have two separate new tools for db and fifo
<osas> ait should work for all
<Guest23310> +1
<osas> kamctl will be good for newbee
<osas> and the tools for others
<miconda> ok, clear
<osas> yes, it creates more tools, but it's clean
<osas> later on we can drop kamctl
<osas> glad that we nailed that out :)
<osas> anything else?
<mariuszbi1> I think will continue on the mailing list
<mariuszbi1> with the conclusions
<miconda> let me see the wiki
<mariuszbi1> if everyone agrees
<osas> gsure
<osas> sure
<miconda> if we haven;t missing something ...
<mariuszbi1> I have the cfg framework changes
<miconda> hmm, xlog it a bit tough
<mariuszbi1> mariuszbi1: I have the cfg framework changes
<miconda> not sure to discuss it now
<miconda> if we want to merge
<miconda> maybe we let it for mailing list
<mariuszbi1> ok
<miconda> one thing more from me :-)

</code>

===== long term release =====

<code>

<miconda> shall we look at: long term release (LTS)?
<henningw> you mean, one release that is maintained longer as "usual"?
<miconda> so we have one release that we officially support for 3 years?
<miconda> yes, kind of ...
<miconda> ser 0.9.x i think is one of such :-)
<osas> maybe, after we migrate all modules and we have a true sip-router release
<ibc> this sounds ok, very "enterprise grade" :)
<Guest23310> would mean too much work
<osas> my 2c
<henningw> Juha: i also see the problem of maintenance
<osas> it is too messy now
<ibc> but I agree, perhaps such TLS should be done when more merging work is done
<miconda> ok, let's think about it in the future
<osas> yup
<miconda> depending on what we have in 3.1
<osas> it is to early now ...
<ibc> sorry, TLS -> LTS
<miconda> good then
<miconda> done?!?!
<osas> yup
<osas> more on the ml

</code>

===== ending =====

<code>

<miconda> anyone volunteering to do a summary?
<osas> the details ;)
<miconda> from irc log and put on wiki, like in the past
<miconda> I think Henning did them :D
<henningw> wel... ;)i can do the log, tomorrow
<henningw> :)
<osas> cool
<miconda> thanks, no hurry
<osas> each one shold chck and update where neccesary
<mariuszbi1> of course
<henningw> will send the link to devel
<miconda> yes
<henningw> then
<osas> k
<mariuszbi1> and we'll continue the discussion on the mailing list
<miconda> of course
<miconda> btw, osas, sr-docs mailing list is back live
<miconda> we should start sync'ing some documentation worl
<miconda> work
<osas> sure
<osas> the thigs that I know, I updated in the wiki
<miconda> ok, thanks
<osas> np
<ibc> for those interested, this night the wiki apge about new dialog module proposals will be terminated
<miconda> then, thanks everyone for your time! back to coding for 3.1 -- it is no longer much till we freeze :-)
<Guest23310> thanks
Beenden Guest23310 hat den Server verlassen (Quit: leaving).
<henningw> bye
<henningw> have a nice evening
<mariuszbi1> have a nice evening to all
<ibc> byt and regards to all
<osas> bye all
<miconda> bye
<andreip> bye
<timo_r> bye

</code>