Meeting minutes for 2009-07-07

<henningw> https://sip-router.org/wiki/devel/irc-meetings/2009-07-07
<miconda2> hello!
<miconda2> i guess we can start
<ibc> hi
<vpascual> shall we go for it?
<henningw> hi all
<miconda2> since we are mixed, shall we start first kamailio, ser or sip-router?
<henningw> perhaps just follow the agenda you posted?
<andreip> i guess you could skip ser
<miconda2> I cannot say much about plans of ser releases, so i am more interested in kamailio and sip-router
<miconda2> for others might be different
<andreip> well, there will be another ser release when: someone volunteer to create the packages and some release news or
<miconda2> ok
<andreip> when kamailio is released based on sip-router

<miconda2> so kamailio 1.5.2
<miconda2> andreip: ok
<henningw> 1.5.1 was on 2009-04-29
<henningw> so 1.5.2 is due
<miconda2> thought maybe people have questions about it ... so was included in announcement
<henningw> imho
<miconda2> back to K
<miconda2> there were some fixes, and traditionally, we did minor releases each few months
<miconda2> in my list is the issue with timers, that seems to behave contradictory from the reports i got
<miconda> my messages are getting very delayed in the channel ...
<miconda> expect some more to arrive ... probably was a connection problem
<miconda2> any other major bug any of you is aware?
<miconda2> seems my connection is poor
<miconda> henningw: yes, it is time
<miconda2> some messages don't get through ... hmm
<miconda> andreip: maybe September
<henningw> there were this report about crash with empty RR header
<ibc> I'm just afraid of dialog module, they have been various vulnerabilities discovered in Kamailio and OpenSIPS about dialog module
<henningw> ibc: yes, i refered to this
<[Latino]> hi all
<ibc> too much IMHO
<klaus_darilion> are all crashes fixed (nathelper body, empty RR header)?
<miconda> andrei: when is path support in tm planned?
<miconda> I did some fixes for dialog and empty rr after 1.5.1
<miconda> the other ones for nathelper were committed
<miconda> maxim did a different one in sip-router
<miconda> but probably does not worth backporting since it is corner case
<ibc> how about nathelper and message body *real* size instead of using "Content-Length" value?
<miconda> ibc: that was fixed somehow
<miconda> but not an agreement for the final fix
<ibc> iI though it was just a workaround to avoid a crash
<miconda> exactly
<miconda> some prefer to return with 400 bad message
<miconda> some to fix on proxy
<miconda> maybe we can agree here ...
<ibc> but it could still generate wrong memory access, rigth?
<[Latino]> I want to speak about the BlackList support on s-r, so I could complete the drouting integration into s-r ... does anyone know how they run on s-r ?
<miconda> Latino: ok, we ca do it a bit latter
<miconda> let's finish k 1.5.2 release now
<miconda> ibc: should not generate that as it returns error now
<ibc> I definitively thing that an UDP request/response in which *real* body size different than the Content-Length value should be rejected automatically as wrong message.
<[Latino]> ok
<[Latino]> ibc I agress with that
<[Latino]> s/agress/agree/g
<ibc> If a UA sends a message with wrong Content-Length value, that UA should be.... killed
<miconda> ibc: that can be done now using sanity module ...
<klaus_darilion> rejecting is a little bit hard (be tolerant what you expect), but otherwise we never know if the body is corrupted or the length is wrong
<miconda> but maybe we should let a door open, to cope with future dead UAs
<ibc> Daniel, I understood from your previous comment that those messages (with wrong Content-Length) are already rejected *automatically*
<miconda> klaus: yes, that is the big dilema
<miconda> ibc: only if you use sanity module at the beginning of the script
<[Latino]> klaus_darilion it doesn't matter ... it's a wrong message
<klaus_darilion> ibc: not automatically, but sanity modul can check
<ibc> @daniel, you said:
<ibc> "should not generate that as it returns error now"
<ibc> When does it generate error?
<miconda> in ser, the approach is: use sanity if you want to discard, nathelper with fix the content length
<ibc> did you mean the nathelper function when trying to write on the body?
<klaus_darilion> latino: yes, it is a wrong message. But if you are a service provider, and all customers leave because they love to use buggy lcients (or have a buggy NAT ALG), then you want to deal with broken clients
<miconda> the nathelper function generate error
<ibc> ok
<miconda> ibc: is actually propagated from a core function
<miconda> anyhow, crash should be fixed
<miconda> nobody reported otherwise
<klaus_darilion> so, nathelper uses the real body length now?
<ibc> perhaps a core parameter:
<ibc> discard_on_wrong_contentlength = yes
<miconda> klaus: no, nathelper returns error
<henningw> hm, perhaps a #define?
<ibc> klaus_darilion: I understand that nathelper just returns error ib real an announced content length are not the same
<andreip> ibc: you have the sanity module, it doesn't make sense to add yet another way to do it
<ibc> ok
<miconda> let's move on, have this continued on devel list if it is still the case
<miconda> back to 1.5.2, ibc: what other vulnerabilities are reported for dialog and you are aware
<miconda> ?
<miconda> and should stop 1.5.2 now?
<ibc> let me check
<miconda> ok, then you can send an email
<miconda> later
<miconda> so, 1.5.2 in a week or so?
<miconda> say next Tuesday if nobody rises some critical report ...
<miconda> I will try to get more on timer stuff by then

<miconda> now, shortly about 1.4
<henningw> 2009-03-25 Kamailio v1.4.4 released
<miconda> probably after 1.5.2 we can see what worth porting to 1.4 and do another one
<miconda> some patches cannot be ported easily
<miconda> like fix for multi-part body for nathelper
<miconda> anyone else wanting to say something about 1.5 or 1.4?
<miconda> if not, we can move to 3.0 and sip-router
<henningw> 1.5.2 next week is ok

<[Latino]> ok, let talk about 3.0 and s-r
<miconda> we have 30min to talk about it :-)
<miconda> so, who did testing so far, what have you discovered missing?
<miconda> from your usual configs...
<[Latino]> I'll begin to test as soon as finish to port drouting, it's my priority
<miconda> ok, if nothing, then we can release sooner :-)
<[Latino]> by now it compiles, but I have to test agains DB modules
<miconda> Latino: using srdb1 should go smooth ...
<klaus_darilion> I did some testing of "make", and currently working on Kamailio debian package
<[Latino]> miconda it's supposed to .. :)
<klaus_darilion> I want to start with a Kamailio debian package which just uses modules and modules_k, abd if this works, I want to add support for modules_s too.
<henningw> klaus_darilion: i did a bunch of updates for the kamailio ones, and they are also some pending changes (regarding update procedure)
<[Latino]> any s-r modules where I could read how to use the BL functions ?
<andreip> tm :-)
<klaus_darilion> henning: con you commit your changes?
<henningw> klaus_darilion: i'll do today, sure
<miconda> my top priorities are exit/drop compatibility, core statistics as much as they can be done, path in tm
<[Latino]> andreip thx, will check it
<[Latino]> miconda what would we do with exit/drop ? ...
<andreip> Latino: you have basically 3 functions that matter for checking if some destination is blacklisted, blacklisting a destination and deleteing a blacklist
<[Latino]> there are situations where I must DROP a branch, and when I mean DROP, mean drestroing it
<miconda> Latino: I need it too
<miconda> so will be there
<miconda> so, in K, the behavior is:
<miconda> - return - get out of current processed route block
<[Latino]> andreip BL funtions are linear lists? .. or some kind of tree ?
<andreip> Latino: hash tables
<miconda> - exit stop processing config and continue with default action for that route block
<miconda> - drop processing of config and don't execute the default actions
<miconda> drop and exit are the same for request route and failure route
<miconda> but differ for branch and onreply routes
<[Latino]> miconda k behavoir it's ok to me ... what is the proposed one for s-r ?
<miconda> I hope the same
<[Latino]> me too
<miconda> right now in sr, drop and exit are identical from all point of view
<klaus_darilion> @latino: you can find docu about blacklist in doc/dst-blacklist.txt
<miconda> and makes no sense to keep both for same purpose
<[Latino]> klaus_darilion thx
<miconda> personally I hate all these aliases to config file parameters and functions
<miconda> like exit and drop, or rewriteuri/seturi
<miconda> one variant should be enough, easy to document and no confusion ...
<[Latino]> miconda yes .. also on some modules are duplicated inline code for do_actions about rewrite_ruri
<miconda> @andreip: any opinion about this exit vs drop?
<miconda> what is the most used in ser: exit or drop?
<ibc> miconda2: I agree, aliased function names are a pain
<andreip> miconda: I think the most used is drop
<miconda> considering that drop will have same behavior as exit in request route blocks, will the impact be major?
<miconda> semantically, drop is more appropriate to use when you want to drop current processed message, while exit is for finishing the execution of config ... IMO
<andreip> i think the impact will be minor (most people use return in branch routes anyway)
<miconda> ok, that's good
<[Latino]> miconda I agree with that
<miconda> ok, so this seems be sorted out -- in the ultimate case, it can be controlled by compat mode of the config file ...
<miconda> something else here (missing features)?
<henningw> i'm still on some strange db_postgres problem, but this is probably more like some regression caused from the porting
<andreip> support for ser selects and ser style avps in kamailio modules
<miconda> andreip: ser avps should be reachable now via $avp(name)
<miconda> if name is in ser style, the appropriate avp list should be used
<miconda> for selects, probably will be a new PV class
<andreip> i was thinking more on changing the kamailio fixups in a similar way to the ones in ser
<miconda> so they get accessed via pv framework ...
<andreip> e.g. fixup_igp* will try select, pvar, avp, int
<miconda> that need to be investigated
<andreip> and maybe fixup_pvar* select , pv & avp
<miconda> not all modules use them
<miconda> some do directly parse_pvar_spec() ... or keep pv spec in custom structures
<miconda> e.g., htable
<miconda> but we can have both, so those using common fixup functions can get access to selects using select naming format
<henningw> klaus_darilion: commited
<andreip> ok, but at least some of them could be updated (not all ser modules use the fixup either)
<miconda> the others, using custom structures, via pv framework
<miconda> andreip: yes
<andreip> an alternative would be to update them to use fixup_var_str/int*
<henningw> andreip: can you suggest some simple module that can act as example on how to support selects?
<andreip> henningw: you just need to call fixup_var_str() and then use get_str_fparan
<henningw> andreip: ok, this is easy :)
<andreip> henningw: an example would be tm t_set_fr (tm.c)
<henningw> ok, thanks
<andreip> the problem would be that you won't get an error for an invalid pv, since if there is no pv it would be assumed that's an avp
<henningw> ok
<miconda> at the end, we should get to some common format for parameters, just that doing radical changes in config language should be avoided for first release based on s-r
<andreip> miconda: at the end we should go for module interface 3.0, that would support expressions as parameters and maybe even return expressions
<miconda> right
<miconda> btw, mi and statistics fields in kamailio module interface are no longer used
<miconda> public modules use mod_register() function to register them
<miconda> what should be done, print a error message and exit if the fields are set in module interface
<miconda> remove them from there?
<miconda> we need a way to tell to people that have private modules
<miconda> that those fields are no longer in used
<henningw> will it works when i use only the old interface?
<miconda> (the reason for this is that mi and statistics are libraries, no longer part of core)
<miconda> henningw: not sure I got your question...
<henningw> there is no backward compatibility?
<miconda> no, not at this moment
<henningw> so i need to convert to mod_register?
<miconda> right now, yes ...
<henningw> then we should fail compilation or during startup
<miconda> to fail compilation, then we can remove them from mod interface
<klaus_darilion> I have to leave now. Just wanted to say that the sip-router core cookbook is now mostly finished, except a few parameters whose meaning I could not find out. bye
<miconda> probably this is the safest way
<miconda> ok, thanks Klaus!
<henningw> thanks klaus!
<andreip> klaus_darilion: thanks a lot, I'll try to have a look this week
<miconda> maybe we can extend discussion about k mod interface on devel list
<miconda> to get the other devels on board

<miconda> next: release roadmap
<miconda> starting with September we should look at a new major release
<miconda> is this doable? any opinions pro/con?
<andreip> by major you mean 4.0?
<henningw> 3.0 ?
<henningw> 1.6 ?
<[Latino]> with mayor release do you mean k 3.0 more or least at January/Febrery
<miconda> for a proper testing, as August is vacation for many countries, I think end of September is more appropriate
<miconda> andreip: :-)
<miconda> I mean about so code-named now 3.0
<miconda> kamailio based on sip-router core
<andreip> ah, ok, I thought you were speaking of a new release after the September one
<miconda> including all kamailio modules and probably those that do not overlap from ser
<miconda> andreip: no, not so soon
<miconda> trying to see what are the main concerns about 3.0
<miconda> - not all features in K will be there
<miconda> - too many changes to get it stable by that time
<miconda> - no proper documentation for easy migration ...
<miconda> or should be enough time to cover all by Sep
<andreip> there is very little time for testing
<[Latino]> we need to try to get the doc ready for the migration, or will be a dissater, at least mainlines of needed changes
<miconda> andreip: we had 1-2 months focused only on testing (feature freeze) for each major release in openser
<klaus_darilion> I think if somebody only uses Kamailio modules and Kamailio syntax, the changes should be minimal. Problems are if ser modules will be used which haev different DB tables layout. The db formats of ser and Kamailio differ a lot
<miconda> that seemed ok so far
<miconda> Latino: I agree
<miconda> if we have proper docs, then we get more testing
<klaus_darilion> so for 3.0 (Kamailio based on sip-router core) it shouldn't be a problem. But if we want to merge further that will be a problem
<miconda> klaus: no, we should not go further
<miconda> that will make things to complex to deal with
<miconda> the k 3.0 should not include overlapping modules from ser (e.g., auth_db, usrloc)
<miconda> but can include modules like iptrtpproxy
<miconda> ctl, cfg_rpc
<klaus_darilion> if somebody mangages to build iptrtpproxy :-)
<miconda> :-)
<henningw> error: linux/netfilter/xt_RTPPROXY.h: No such file or directory :)
<miconda> you need a kernel module
<miconda> and I think a patch ...
<henningw> hm, ok
<klaus_darilion> and AFAIK you need to have the proper kernel version as Linux kernel is very dynamic
<miconda> ok, so, proposal
<miconda> for k-3.0 we should avoid syntax changes and merging that affect database structure, config and interfaces to external applications
<klaus_darilion> yes
<miconda> branches can be used for those willing to do such merges ...
<miconda> or, if it is a huge pressure, we can branch 3.0
<miconda> as milestones:
<miconda> - try to freeze by mid-end of august
<miconda> - by then get most of the missing features in repository
<miconda> - afterwards, main focus on documentation and testing
<miconda> - release end of september/beginning of october
<andreip> a list with missing features sorted by priority would help a lot
<miconda> I will try to compile one
<miconda> path extension is in top :-)
<miconda> will send a link to sr-dev ML
* [Latino] away: (Toy en otro lao...: [10 mins]) [BX-MsgLog Off]
<miconda> (will be on wiki)
<miconda> and last topic
<henningw> ok

<miconda> what is good/bad in s-r environment
<miconda> any proposal?
<miconda> we should have most of the tools in place
<miconda> tracker does not seem very used
<miconda> ML is main one for reporting issue
<andreip> is the tracker ok? do we keep it or try another one?
<miconda> since it was not pushed to limits at all, seems ok, but if you have other proposals ...
<andreip> no I haven't
<andreip> we should perhaps announce that the tracker is no longer experimental
<miconda> ahh, was experimental so far :-) ... maybe that was not much in use ...
<henningw> it is experimental? ok..
<andreip> we should also standardize on a way of linking a commit to a bug id
<andreip> in ser we used something like: "closes SER-123"
<henningw> is this automatically evaluated?
<henningw> from the tracker?
<miconda> ok, in openser we tried to use (closes #123)
<andreip> henningw: in ser it was, I don't know about flyspray though
<henningw> andreip: ok, i just wondered
<andreip> iirc, Jan said that it had git integration, so there should be a way
<miconda> any other idea to make easier for people the testing/developing/advertising of the project?
<miconda> is sr-dev too verbose? mainly because of git commits?
<miconda> it is fine for me, as I don;t want another list, just asking ...
<andreip> i think the git commits messages are the most important feature
<andreip> i mean if somebody is interested in devel then he is interested in the commits
<miconda> interest could be also for devel help and debates, I prefer the way is now
<miconda> any other question?
<miconda> last call
<henningw> for the list: i just use filtering, it easy to setup
<miconda> if not, we can conclude (probably one of the fastest meetings, probably because of the new core :-) -- we always planned 1h, but couldn't stick to it)
<miconda> ok then! thanks everybody! see you on mailing lists! I will stick around this channel daily, feel free to ask questions about testing/devel s-r
<henningw> thanks daniel
<henningw> miconda: should i upload the protocol to the wiki?
<miconda> yes, thanks