any plans for releasing sr_3.0? i personally don't have any pending issues with it and it has worked ok in my tests. i have tested with the modules listed below.
-- juha
loadpath "/usr/lib/sip-proxy/modules" loadmodule "db_mysql" loadmodule "avpops" loadmodule "tm" loadmodule "lcr" loadmodule "auth_radius" loadmodule "cfg_rpc" loadmodule "ctl" loadmodule "dialplan" loadmodule "enum" loadmodule "mediaproxy" loadmodule "misc_radius" loadmodule "mi_rpc" loadmodule "peering" loadmodule "tls" loadmodule "utils" loadmodule "xmlrpc" loadpath "/usr/lib/sip-proxy/modules_k" loadmodule "tmx" loadmodule "cfgutils" loadmodule "pv" loadmodule "sl" loadmodule "rr" loadmodule "maxfwd" loadmodule "usrloc" loadmodule "registrar" loadmodule "auth" loadmodule "acc" loadmodule "siputils" loadmodule "textops" loadmodule "permissions" loadmodule "nathelper" loadmodule "xlog" loadmodule "pike" loadmodule "msilo" loadmodule "uac_redirect" loadmodule "htable" loadmodule "uac" loadmodule "kex" loadmodule "path" loadpath "/usr/lib/sip-proxy/modules_s" loadmodule "domain"
On Nov 26, 2009 at 06:31, Juha Heinanen jh@tutpro.com wrote:
any plans for releasing sr_3.0? i personally don't have any pending issues with it and it has worked ok in my tests. i have tested with the modules listed below.
There are some minor sctp and tcp dynamic config issues: some options will be set immediately even if one uses cfg.set_delayed_* and not at the cfg.commit time. E.g.: sercmd cfg.set_delayed_int sctp hbinterval 2000 which should set the option only after a cfg.commit, sets the option immediately. (like sercmd cfg.set_now_int sctp hbinterval 2000)
I'm working on them, but these are not critical (it will affect only people that use cfg_set_delayed & cfg.commit).
We should also decide if we merge all the doxygen and doc changes from master (I still have about 1 week of those to review). I'm for merging them, but they might introduce some minor delay (e.g. break compilation of some not-often compiled module).
Apart from that I don't remember any other bug.
We have sr in limited testing (thanks to Jan), using: acc_db auth auth_db avp avp_db cfg_rpc ctl db_mysql db_ops domain enum eval exec gflags iptrtpproxy maxfwd nathelper options registrar rr sanity sl speeddial textops timer tm uri uri_db usrloc xlog
(modules_s version for the ones that are not in modules/). So far it looks ok (no memleak, or visible errors).
Andrei
loadpath "/usr/lib/sip-proxy/modules" loadmodule "db_mysql" loadmodule "avpops" loadmodule "tm" loadmodule "lcr" loadmodule "auth_radius" loadmodule "cfg_rpc" loadmodule "ctl" loadmodule "dialplan" loadmodule "enum" loadmodule "mediaproxy" loadmodule "misc_radius" loadmodule "mi_rpc" loadmodule "peering" loadmodule "tls" loadmodule "utils" loadmodule "xmlrpc" loadpath "/usr/lib/sip-proxy/modules_k" loadmodule "tmx" loadmodule "cfgutils" loadmodule "pv" loadmodule "sl" loadmodule "rr" loadmodule "maxfwd" loadmodule "usrloc" loadmodule "registrar" loadmodule "auth" loadmodule "acc" loadmodule "siputils" loadmodule "textops" loadmodule "permissions" loadmodule "nathelper" loadmodule "xlog" loadmodule "pike" loadmodule "msilo" loadmodule "uac_redirect" loadmodule "htable" loadmodule "uac" loadmodule "kex" loadmodule "path" loadpath "/usr/lib/sip-proxy/modules_s" loadmodule "domain"
On Thu, Nov 26, 2009 at 6:49 PM, Andrei Pelinescu-Onciul andrei@iptel.org wrote:
On Nov 26, 2009 at 06:31, Juha Heinanen jh@tutpro.com wrote:
any plans for releasing sr_3.0? i personally don't have any pending issues with it and it has worked ok in my tests. i have tested with the modules listed below.
There are some minor sctp and tcp dynamic config issues: some options will be set immediately even if one uses cfg.set_delayed_* and not at the cfg.commit time. E.g.: sercmd cfg.set_delayed_int sctp hbinterval 2000 which should set the option only after a cfg.commit, sets the option immediately. (like sercmd cfg.set_now_int sctp hbinterval 2000)
I'm working on them, but these are not critical (it will affect only people that use cfg_set_delayed & cfg.commit).
We should also decide if we merge all the doxygen and doc changes from master (I still have about 1 week of those to review). I'm for merging them, but they might introduce some minor delay (e.g. break compilation of some not-often compiled module).
Apart from that I don't remember any other bug.
We have sr in limited testing (thanks to Jan), using: acc_db auth auth_db avp avp_db cfg_rpc ctl db_mysql db_ops domain enum eval exec gflags iptrtpproxy maxfwd nathelper options registrar rr sanity sl speeddial textops timer tm uri uri_db usrloc xlog
(modules_s version for the ones that are not in modules/). So far it looks ok (no memleak, or visible errors).
Andrei
loadpath "/usr/lib/sip-proxy/modules" loadmodule "db_mysql" loadmodule "avpops" loadmodule "tm" loadmodule "lcr" loadmodule "auth_radius" loadmodule "cfg_rpc" loadmodule "ctl" loadmodule "dialplan" loadmodule "enum" loadmodule "mediaproxy" loadmodule "misc_radius" loadmodule "mi_rpc" loadmodule "peering" loadmodule "tls" loadmodule "utils" loadmodule "xmlrpc" loadpath "/usr/lib/sip-proxy/modules_k" loadmodule "tmx" loadmodule "cfgutils" loadmodule "pv" loadmodule "sl" loadmodule "rr" loadmodule "maxfwd" loadmodule "usrloc" loadmodule "registrar" loadmodule "auth" loadmodule "acc" loadmodule "siputils" loadmodule "textops" loadmodule "permissions" loadmodule "nathelper" loadmodule "xlog" loadmodule "pike" loadmodule "msilo" loadmodule "uac_redirect" loadmodule "htable" loadmodule "uac" loadmodule "kex" loadmodule "path" loadpath "/usr/lib/sip-proxy/modules_s" loadmodule "domain"
Yeah, we have been testing those ser modules and it looks good (in fact too good) so far.
I agree we should merge the doc changes, I can help with that (Andrei, let me know if you want to split the reviewing/merging work).
Apart from that, I personally think we are almost ready to release and I think we should do it by Christmas.
Daniel, how is the work with Kamailio 3.0 going? Anything missing there?
-Jan
On 27.11.2009 11:35 Uhr, Jan Janak wrote:
[...]
Yeah, we have been testing those ser modules and it looks good (in fact too good) so far.
I agree we should merge the doc changes, I can help with that (Andrei, let me know if you want to split the reviewing/merging work).
Apart from that, I personally think we are almost ready to release and I think we should do it by Christmas.
Daniel, how is the work with Kamailio 3.0 going? Anything missing there?
lab testing looks ok, but there are some hidden traps in the code (like those related to tm callback for local generated requests, how the modules are loaded and when the response function list is built, ...) -- code compiles, runs, but the behavior in some special cases might not be correct.
Therefore it was released a RC1, these days will be RC2 and then the full release (2-3 weeks).
Personally I think that merging doc changes (those inside the code) could create new issues and I would avoid it -- they will be in the next release and can be browsed online all the time -- from past experience there were not many reading code of stable releases, development happens within the trunk version.
Cheers, Daniel
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Jan Janak -
Juha Heinanen