<varname>calculate_ha1</varname> (integer)

<varname>calculate_ha1</varname> (integer) - This parameter tells the server whether it should use plaintext - passwords or a pre-calculated HA1 string for authentification. + This parameter tells the server whether it should use a pre-calculated + HA1 string or plaintext passwords for authentification. - If the parameter is set to 1 and the username parameter of credentials + If the parameter is set to 0 and the username parameter of credentials contains also @domain (some user agents append the domain to the username parameter), then the server will use the HA1 values from the column specified in the @@ -177,7 +177,7 @@ modparam("auth_db", "password_column_2", "ha1_2") column given in the password_columnparameter. - If the parameter is set to 0 then the HA1 value will be calculated + If the parameter is set to 1 then the HA1 value will be calculated from the column specified in the password_column parameter. From miconda at gmail.com Thu Aug 20 09:42:45 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Thu, 20 Aug 2009 09:42:45 +0200 (CEST) Subject: [sr-dev] git:master: core: added log_name config parameter Message-ID: <20090820074245.4CA9CEF8070@rimmer> Module: sip-router Branch: master Commit: 95bf86454e277a7a0ef1c41c2995806f65eda17b URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=95bf86454e277a7a0ef1c41c2995806f65eda17b Author: Daniel-Constantin Mierla Committer: Daniel-Constantin Mierla Date: Thu Aug 20 10:41:02 2009 +0300 core: added log_name config parameter - log_name allows to set app name to be used when printing to syslog - useful to filter log messages when running many instance on same server --- cfg.lex | 2 ++ cfg.y | 3 +++ dprint.h | 1 + main.c | 4 +++- 4 files changed, 9 insertions(+), 1 deletions(-) diff --git a/cfg.lex b/cfg.lex index a99968d..32aed32 100644 --- a/cfg.lex +++ b/cfg.lex @@ -281,6 +281,7 @@ DEBUG debug FORK fork LOGSTDERROR log_stderror LOGFACILITY log_facility +LOGNAME log_name LISTEN listen ALIAS alias SR_AUTO_ALIASES auto_aliases @@ -577,6 +578,7 @@ EAT_ABLE [\ \t\b\r] {FORK} { count(); yylval.strval=yytext; return FORK; } {LOGSTDERROR} { yylval.strval=yytext; return LOGSTDERROR; } {LOGFACILITY} { yylval.strval=yytext; return LOGFACILITY; } +{LOGNAME} { yylval.strval=yytext; return LOGNAME; } {LISTEN} { count(); yylval.strval=yytext; return LISTEN; } {ALIAS} { count(); yylval.strval=yytext; return ALIAS; } {SR_AUTO_ALIASES} { count(); yylval.strval=yytext; diff --git a/cfg.y b/cfg.y index b51a272..e9e8d8a 100644 --- a/cfg.y +++ b/cfg.y @@ -345,6 +345,7 @@ static int case_check_default(struct case_stms* stms); %token FORK %token LOGSTDERROR %token LOGFACILITY +%token LOGNAME %token LISTEN %token ALIAS %token SR_AUTO_ALIASES @@ -758,6 +759,8 @@ assign_stm: default_core_cfg.log_facility=i_tmp; } | LOGFACILITY EQUAL error { yyerror("ID expected"); } + | LOGNAME EQUAL STRING { log_name=$3; } + | LOGNAME EQUAL error { yyerror("string value expected"); } | DNS EQUAL NUMBER { received_dns|= ($3)?DO_DNS:0; } | DNS EQUAL error { yyerror("boolean value expected"); } | REV_DNS EQUAL NUMBER { received_dns|= ($3)?DO_REV_DNS:0; } diff --git a/dprint.h b/dprint.h index 54d47fa..8f9d743 100644 --- a/dprint.h +++ b/dprint.h @@ -109,6 +109,7 @@ struct log_level_info { #define is_printable(level) (cfg_get(core, core_cfg, debug)>=(level)) extern struct log_level_info log_level_info[]; +extern char *log_name; #ifndef NO_SIG_DEBUG /* protection against "simultaneous" printing from signal handlers */ diff --git a/main.c b/main.c index 23455e7..9a771f8 100644 --- a/main.c +++ b/main.c @@ -321,6 +321,8 @@ int sig_flag = 0; /* last signal received */ int dont_fork = 0; int dont_daemonize = 0; int log_stderr = 0; +/* set custom app name for syslog printing */ +char *log_name = 0; pid_t creator_pid = (pid_t) -1; int config_check = 0; /* check if reply first via host==us */ @@ -2059,7 +2061,7 @@ try_again: #endif /* USE_SCTP */ /* init_daemon? */ if (!dont_fork){ - if ( daemonize(argv[0]) <0 ) goto error; + if ( daemonize((log_name==0)?argv[0]:log_name) <0 ) goto error; } if (install_sigs() != 0){ fprintf(stderr, "ERROR: could not install the signal handlers\n"); From klaus.mailinglists at pernau.at Thu Aug 20 10:31:16 2009 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Thu, 20 Aug 2009 10:31:16 +0200 Subject: [sr-dev] git:master: core: added log_name config parameter In-Reply-To: <20090820074245.4CA9CEF8070@rimmer> References: <20090820074245.4CA9CEF8070@rimmer> Message-ID: <4A8D09D4.3010404@pernau.at> fyi: added to http://sip-router.org/wiki/cookbooks/core-cookbook/devel Daniel-Constantin Mierla schrieb: > Module: sip-router > Branch: master > Commit: 95bf86454e277a7a0ef1c41c2995806f65eda17b > URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=95bf86454e277a7a0ef1c41c2995806f65eda17b > > Author: Daniel-Constantin Mierla > Committer: Daniel-Constantin Mierla > Date: Thu Aug 20 10:41:02 2009 +0300 > > core: added log_name config parameter > > - log_name allows to set app name to be used when printing to syslog > - useful to filter log messages when running many instance on same server > > --- > > cfg.lex | 2 ++ > cfg.y | 3 +++ > dprint.h | 1 + > main.c | 4 +++- > 4 files changed, 9 insertions(+), 1 deletions(-) > > diff --git a/cfg.lex b/cfg.lex > index a99968d..32aed32 100644 > --- a/cfg.lex > +++ b/cfg.lex > @@ -281,6 +281,7 @@ DEBUG debug > FORK fork > LOGSTDERROR log_stderror > LOGFACILITY log_facility > +LOGNAME log_name > LISTEN listen > ALIAS alias > SR_AUTO_ALIASES auto_aliases > @@ -577,6 +578,7 @@ EAT_ABLE [\ \t\b\r] > {FORK} { count(); yylval.strval=yytext; return FORK; } > {LOGSTDERROR} { yylval.strval=yytext; return LOGSTDERROR; } > {LOGFACILITY} { yylval.strval=yytext; return LOGFACILITY; } > +{LOGNAME} { yylval.strval=yytext; return LOGNAME; } > {LISTEN} { count(); yylval.strval=yytext; return LISTEN; } > {ALIAS} { count(); yylval.strval=yytext; return ALIAS; } > {SR_AUTO_ALIASES} { count(); yylval.strval=yytext; > diff --git a/cfg.y b/cfg.y > index b51a272..e9e8d8a 100644 > --- a/cfg.y > +++ b/cfg.y > @@ -345,6 +345,7 @@ static int case_check_default(struct case_stms* stms); > %token FORK > %token LOGSTDERROR > %token LOGFACILITY > +%token LOGNAME > %token LISTEN > %token ALIAS > %token SR_AUTO_ALIASES > @@ -758,6 +759,8 @@ assign_stm: > default_core_cfg.log_facility=i_tmp; > } > | LOGFACILITY EQUAL error { yyerror("ID expected"); } > + | LOGNAME EQUAL STRING { log_name=$3; } > + | LOGNAME EQUAL error { yyerror("string value expected"); } > | DNS EQUAL NUMBER { received_dns|= ($3)?DO_DNS:0; } > | DNS EQUAL error { yyerror("boolean value expected"); } > | REV_DNS EQUAL NUMBER { received_dns|= ($3)?DO_REV_DNS:0; } > diff --git a/dprint.h b/dprint.h > index 54d47fa..8f9d743 100644 > --- a/dprint.h > +++ b/dprint.h > @@ -109,6 +109,7 @@ struct log_level_info { > > #define is_printable(level) (cfg_get(core, core_cfg, debug)>=(level)) > extern struct log_level_info log_level_info[]; > +extern char *log_name; > > #ifndef NO_SIG_DEBUG > /* protection against "simultaneous" printing from signal handlers */ > diff --git a/main.c b/main.c > index 23455e7..9a771f8 100644 > --- a/main.c > +++ b/main.c > @@ -321,6 +321,8 @@ int sig_flag = 0; /* last signal received */ > int dont_fork = 0; > int dont_daemonize = 0; > int log_stderr = 0; > +/* set custom app name for syslog printing */ > +char *log_name = 0; > pid_t creator_pid = (pid_t) -1; > int config_check = 0; > /* check if reply first via host==us */ > @@ -2059,7 +2061,7 @@ try_again: > #endif /* USE_SCTP */ > /* init_daemon? */ > if (!dont_fork){ > - if ( daemonize(argv[0]) <0 ) goto error; > + if ( daemonize((log_name==0)?argv[0]:log_name) <0 ) goto error; > } > if (install_sigs() != 0){ > fprintf(stderr, "ERROR: could not install the signal handlers\n"); > > > _______________________________________________ > sr-dev mailing list > sr-dev at lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev From miconda at gmail.com Thu Aug 20 10:33:37 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Thu, 20 Aug 2009 11:33:37 +0300 Subject: [sr-dev] git:master: core: added log_name config parameter In-Reply-To: <4A8D09D4.3010404@pernau.at> References: <20090820074245.4CA9CEF8070@rimmer> <4A8D09D4.3010404@pernau.at> Message-ID: <4A8D0A61.9060602@gmail.com> On 20.08.2009 11:31 Uhr, Klaus Darilion wrote: > fyi: added to http://sip-router.org/wiki/cookbooks/core-cookbook/devel thanks! > > Daniel-Constantin Mierla schrieb: >> Module: sip-router >> Branch: master >> Commit: 95bf86454e277a7a0ef1c41c2995806f65eda17b >> URL: >> http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=95bf86454e277a7a0ef1c41c2995806f65eda17b >> >> >> Author: Daniel-Constantin Mierla >> Committer: Daniel-Constantin Mierla >> Date: Thu Aug 20 10:41:02 2009 +0300 >> >> core: added log_name config parameter >> >> - log_name allows to set app name to be used when printing to syslog >> - useful to filter log messages when running many instance on same >> server >> >> --- >> >> cfg.lex | 2 ++ >> cfg.y | 3 +++ >> dprint.h | 1 + >> main.c | 4 +++- >> 4 files changed, 9 insertions(+), 1 deletions(-) >> >> diff --git a/cfg.lex b/cfg.lex >> index a99968d..32aed32 100644 >> --- a/cfg.lex >> +++ b/cfg.lex >> @@ -281,6 +281,7 @@ DEBUG debug >> FORK fork >> LOGSTDERROR log_stderror >> LOGFACILITY log_facility >> +LOGNAME log_name >> LISTEN listen >> ALIAS alias >> SR_AUTO_ALIASES auto_aliases >> @@ -577,6 +578,7 @@ EAT_ABLE [\ \t\b\r] >> {FORK} { count(); yylval.strval=yytext; return FORK; } >> {LOGSTDERROR} { yylval.strval=yytext; return LOGSTDERROR; } >> {LOGFACILITY} { yylval.strval=yytext; return LOGFACILITY; } >> +{LOGNAME} { yylval.strval=yytext; return LOGNAME; } >> {LISTEN} { count(); yylval.strval=yytext; return LISTEN; } >> {ALIAS} { count(); yylval.strval=yytext; return ALIAS; } >> {SR_AUTO_ALIASES} { count(); yylval.strval=yytext; >> diff --git a/cfg.y b/cfg.y >> index b51a272..e9e8d8a 100644 >> --- a/cfg.y >> +++ b/cfg.y >> @@ -345,6 +345,7 @@ static int case_check_default(struct case_stms* >> stms); >> %token FORK >> %token LOGSTDERROR >> %token LOGFACILITY >> +%token LOGNAME >> %token LISTEN >> %token ALIAS >> %token SR_AUTO_ALIASES >> @@ -758,6 +759,8 @@ assign_stm: >> default_core_cfg.log_facility=i_tmp; >> } >> | LOGFACILITY EQUAL error { yyerror("ID expected"); } >> + | LOGNAME EQUAL STRING { log_name=$3; } >> + | LOGNAME EQUAL error { yyerror("string value expected"); } >> | DNS EQUAL NUMBER { received_dns|= ($3)?DO_DNS:0; } >> | DNS EQUAL error { yyerror("boolean value expected"); } >> | REV_DNS EQUAL NUMBER { received_dns|= ($3)?DO_REV_DNS:0; } >> diff --git a/dprint.h b/dprint.h >> index 54d47fa..8f9d743 100644 >> --- a/dprint.h >> +++ b/dprint.h >> @@ -109,6 +109,7 @@ struct log_level_info { >> >> #define is_printable(level) (cfg_get(core, core_cfg, debug)>=(level)) >> extern struct log_level_info log_level_info[]; >> +extern char *log_name; >> >> #ifndef NO_SIG_DEBUG >> /* protection against "simultaneous" printing from signal handlers */ >> diff --git a/main.c b/main.c >> index 23455e7..9a771f8 100644 >> --- a/main.c >> +++ b/main.c >> @@ -321,6 +321,8 @@ int sig_flag = 0; /* last signal >> received */ >> int dont_fork = 0; >> int dont_daemonize = 0; >> int log_stderr = 0; >> +/* set custom app name for syslog printing */ >> +char *log_name = 0; >> pid_t creator_pid = (pid_t) -1; >> int config_check = 0; >> /* check if reply first via host==us */ >> @@ -2059,7 +2061,7 @@ try_again: >> #endif /* USE_SCTP */ >> /* init_daemon? */ >> if (!dont_fork){ >> - if ( daemonize(argv[0]) <0 ) goto error; >> + if ( daemonize((log_name==0)?argv[0]:log_name) <0 ) goto error; >> } >> if (install_sigs() != 0){ >> fprintf(stderr, "ERROR: could not install the signal >> handlers\n"); >> >> >> _______________________________________________ >> sr-dev mailing list >> sr-dev at lists.sip-router.org >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev -- Daniel-Constantin Mierla * http://www.asipto.com/ From inge at legos.fr Thu Aug 20 10:40:34 2009 From: inge at legos.fr (inge) Date: Thu, 20 Aug 2009 10:40:34 +0200 Subject: [sr-dev] SER crash : Segmentation fault In-Reply-To: <20090818070044.GC7175@shell.iptel.org> References: <1250164029.6784.5.camel@legos01.legos.fr> <4A83FEC4.2040100@pernau.at> <1250170320.6914.1.camel@legos01.legos.fr> <20090814124548.GS22992@shell.iptel.org> <1250254903.8409.2.camel@legos01.legos.fr> <20090814143409.GB7175@shell.iptel.org> <1250262193.8409.6.camel@legos01.legos.fr> <1250512923.29814.3.camel@legos01.legos.fr> <20090818070044.GC7175@shell.iptel.org> Message-ID: <1250757634.29814.12.camel@legos01.legos.fr> Hi Andrei, As I understand, this changelog only apply to the tm module. Is there any clues that this module caused the crash we experienced ? We would like to determine which of the known and corrected bug could have caused the crash, in order to find a short-time workaround letting us some time to deploy abn upgrade to the latest rel in the 0.9.0 branch. Adrien Le mardi 18 ao?t 2009 ? 09:00 +0200, Andrei Pelinescu-Onciul a ?crit : > On Aug 17, 2009 at 14:42, inge wrote: > > Hi Andrei, > > > > Hope you are fine. > > Do you have any update on our crash ? > > Is there anything we can do to find the segmentation fault cause, maybe > > as a well-known bug, without bothering you ? > > > There are lots of changes between 0.9.5-pre and the latest 0.9.x > version. > You should try updating to the latest code on the rel_0_9_0 branch and > see if you run into this problem again. > To get the latest 0.9.x code either get the latest snapshot from > http://ftp.iptel.org/pub/ser/daily-snapshots/stable/ , use cvs to > get the rel_0_9_0 branch > (CVSROOT=:pserver:anonymous at cvs.berlios.de:/cvsroot/ser ; > export CVSROOT ; cvs co -r rel_0_9_0 sip_router ), or use git and the > ser repository (see http://sip-router.org/wiki/git/ser-repository). > > Here's a short changelog for tm, between 0.9.5 and 0.9.7+ > (git log --oneline v_0_9_5..origin/rel_0_9_0 modules/tm): > - tm: fix delete_cell() when the transaction is referenced > - variable timer fix: variable timers (avps) won't be exteneded anymore > - fix for free_rdata_list() which used to access the "next" pointer af > - deadlock when t_relay-ing a message from the failure_route fixed (e2e > - added sems specific patch. This patch is present in the ser version ship > - added diversion and rpid header cloning > -bug fix: tm insert_timer used to eat too much cpu, decreasing dramatic > - fixed misplaced set_avp list, courtesy of cesc.santa at gmail.com > - int2reverse_hex/reverse_hex2int fixes (tm with large "labels" was aff > - fix of local ACK matching provided by cesc.santa at gmail.com > - avp race condition fix (backported from HEAD) > - CANCEL terminates retransmission timers properly (backported) > > > Andrei > > > > > > Le vendredi 14 ao??t 2009 ?? 17:03 +0200, inge a ??crit : > > > Please find the requested information in attached. > > > > > > I'm aware of the need for an update. It's in the list of tasks to be > > > done, however, the priority is to troubleshoot the problem and maybe > > > find a workaround. > > > > > > Regards, > > > > > > Adrien > > > > > > Le vendredi 14 ao??t 2009 ?? 16:34 +0200, Andrei Pelinescu-Onciul a > > > ??crit : > > > > On Aug 14, 2009 at 15:01, inge wrote: > > > > > Hi Andrei, > > > > > > > > > > Thanks for your reply. > > > > > > > > > > I use ser 0.9.5-pre4. > > > > > > > > > > I don't really understand the bug you have identify, where can I find a > > > > > description ? > > > > > > > > Sorry, I was wrong (that bug was in RR and appears only in newer code). > > > > > > > > Could you run gdb on the core again , type "frame 0" and then send me the > > > > output of the following commands: > > > > > > > > print p_cell > > > > print p_msg > > > > print p_msg->buf > > > > print p_cell->uas.local_totag.len > > > > print p_cell->uas.local_totag.s > > > > print p_msg->to > > > > print p_msg->to->parsed > > > > print *((struct to_body*)(p_msg->to->parsed)) > > > > print ((struct to_body*)(p_msg->to->parsed))->tag_value.len > > > > print ((struct to_body*)(p_msg->to->parsed))->tag_value.s > > > > > > > > > > > > Andrei > > > > P.S.: you could try also upgrading to ser 2.0, 2.1 or sip-router. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Adrien > > > > > > > > > > Le vendredi 14 ao??t 2009 ?? 14:45 +0200, Andrei Pelinescu-Onciul a > > > > > ??crit : > > > > > > On Aug 13, 2009 at 15:32, inge wrote: > > > > > > > Hi Klaus, > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > I put the output of gdb in attached. > > > > > > > > > > > > > > I hope someone can decrypt this. Thank you. > > > > > > > > > > > > > > > > > > If you are using ser 2.1/latest cvs or sip-router then just update to > > > > > > the latest cvs or git. It's a known fixed bug (sip router > > > > > > git 6fcd5e or ser 2.1 commit starting with "rr: fix from header > > > > > > access"). > > > > > > > > > > > > If you are using another version then tell me which one (ser -V) > > > > > > and I'll fix it. > > > > > > > > > > > > Andrei > > > > > > > > > > > > > > > > > > > > Le jeudi 13 ao??t 2009 ?? 13:53 +0200, Klaus Darilion a ??crit : > > > > > > > > locate the core file (either in the working dir or /tmp or /) > > > > > > > > then execute: > > > > > > > > > > > > > > > > gdb /usr/local/sbin/ser /path/to/core > > > > > > > > (gdb) bt > > > > > > > > > > > > > > > > regards > > > > > > > > klaus > > > > > > > > > > > > > > > > inge schrieb: > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > My SER process had crashed today with the following logs > > > > > > > > > in /var/log/messages : > > > > > > > > > > > > > > > > > > ser[378]: child process 418 exited by a signal 11 > > > > > > > > > ser[378]: core was generated > > > > > > > > > ser[378]: INFO: terminating due to SIGCHLD > > > > > > > > > ser[421]: INFO: signal 15 received > > > > > > > > > ... > > > > > > > > > > > > > > > > > > Can someone help me to determine what kind of problem is it ? I think I > > > > > > > > > need to use gdb to extract some information from the core dump. How can > > > > > > > > > I use it to extract the uses informations ? > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > Adrien > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > sr-dev mailing list > > > > > > > > > sr-dev at lists.sip-router.org > > > > > > > > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > > > > > > > > > > > > #0 0x00e964d3 in matching_3261 (p_msg=0x81647e8, trans=0xbff74f38, skip_method=4294967294) at t_lookup.c:222 > > > > > > > 222 if (memcmp(get_to(ack)->tag_value.s,p_cell->uas.local_totag.s, > > > > > > > (gdb) bt > > > > > > > #0 0x00e964d3 in matching_3261 (p_msg=0x81647e8, trans=0xbff74f38, skip_method=4294967294) at t_lookup.c:222 > > > > > > > #1 0x00e96aff in t_lookup_request (p_msg=0x81647e8, leave_new_locked=1) at t_lookup.c:421 > > > > > > > #2 0x00e992a0 in t_newtran (p_msg=0x81647e8) at t_lookup.c:1085 > > > > > > > #3 0x00e9116a in t_relay_to (p_msg=0x81647e8, proxy=0x0, proto=0, replicate=0) at t_funcs.c:224 > > > > > > > #4 0x00e9c410 in w_t_relay (p_msg=0x81647e8, _foo=0x0, _bar=0x0) at tm.c:889 > > > > > > > #5 0x0804fc81 in do_action (a=0x8117818, msg=0x81647e8) at action.c:610 > > > > > > > #6 0x0805099d in run_actions (a=0x8117818, msg=0x81647e8) at action.c:718 > > > > > > > #7 0x08073f08 in eval_elem (e=0x8117840, msg=0x81647e8) at route.c:605 > > > > > > > #8 0x08074392 in eval_expr (e=0x8117840, msg=0x81647e8) at route.c:654 > > > > > > > #9 0x080743ce in eval_expr (e=0x8117860, msg=0x81647e8) at route.c:670 > > > > > > > #10 0x0804ec95 in do_action (a=0x8117bc8, msg=0x81647e8) at action.c:586 > > > > > > > #11 0x0805099d in run_actions (a=0x8117630, msg=0x81647e8) at action.c:718 > > > > > > > #12 0x0804ffdf in do_action (a=0x8114f70, msg=0x81647e8) at action.c:375 > > > > > > > #13 0x0805099d in run_actions (a=0x8114f70, msg=0x81647e8) at action.c:718 > > > > > > > #14 0x0804ecd3 in do_action (a=0x8114fc0, msg=0x81647e8) at action.c:603 > > > > > > > #15 0x0805099d in run_actions (a=0x8114fc0, msg=0x81647e8) at action.c:718 > > > > > > > #16 0x0804ecd3 in do_action (a=0x8114fe8, msg=0x81647e8) at action.c:603 > > > > > > > #17 0x0805099d in run_actions (a=0x8114fe8, msg=0x81647e8) at action.c:718 > > > > > > > #18 0x0804ecd3 in do_action (a=0x8115010, msg=0x81647e8) at action.c:603 > > > > > > > #19 0x0805099d in run_actions (a=0x8115010, msg=0x81647e8) at action.c:718 > > > > > > > #20 0x0804ecd3 in do_action (a=0x8115038, msg=0x81647e8) at action.c:603 > > > > > > > #21 0x0805099d in run_actions (a=0x8115038, msg=0x81647e8) at action.c:718 > > > > > > > #22 0x0804ecd3 in do_action (a=0x8115060, msg=0x81647e8) at action.c:603 > > > > > > > #23 0x0805099d in run_actions (a=0x810fe88, msg=0x81647e8) at action.c:718 > > > > > > > #24 0x0806d062 in receive_msg ( > > > > > > > buf=0x80d61e0 "ACK sip:0389719641 at domain.tld:5060 SIP/2.0\r\nMax-Forwards: 16\r\nContent-Length: 0\r\nVia: SIP/2.0/UDP 10.0.140.147:5060;branch=z9hG4bK4f1b8571c\r\nCall-ID: bf85c76a5e2066256679e3945f6b4e36 at 10.0.140.147\r\nF"..., len=592, rcv_info=0xbff76340) at receive.c:165 > > > > > > > #25 0x080843cc in udp_rcv_loop () at udp_server.c:472 > > > > > > > #26 0x0805cdaf in main_loop () at main.c:1056 > > > > > > > #27 0x0805e40b in main (argc=1, argv=0xbff76504) at main.c:1592 > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > sr-dev mailing list > > > > > > > sr-dev at lists.sip-router.org > > > > > > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > > > > > > > > _______________________________________________ > > > sr-dev mailing list > > > sr-dev at lists.sip-router.org > > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev From miconda at gmail.com Thu Aug 20 10:58:01 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Thu, 20 Aug 2009 10:58:01 +0200 (CEST) Subject: [sr-dev] git:master: tm: use server signature from config var Message-ID: <20090820085801.EF287EF8070@rimmer> Module: sip-router Branch: master Commit: d3be842237ba670d671b8af0f59a39dda7503545 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=d3be842237ba670d671b8af0f59a39dda7503545 Author: Daniel-Constantin Mierla Committer: Daniel-Constantin Mierla Date: Thu Aug 20 11:48:35 2009 +0300 tm: use server signature from config var --- modules/tm/t_msgbuilder.c | 17 +++++++++++------ 1 files changed, 11 insertions(+), 6 deletions(-) diff --git a/modules/tm/t_msgbuilder.c b/modules/tm/t_msgbuilder.c index fe0eed4..a76c3db 100644 --- a/modules/tm/t_msgbuilder.c +++ b/modules/tm/t_msgbuilder.c @@ -154,7 +154,7 @@ char *build_local(struct cell *Trans,unsigned int branch, /* User Agent */ if (server_signature) { - *len += USER_AGENT_LEN + CRLF_LEN; + *len += user_agent_hdr.len + CRLF_LEN; } /* Content Length, EoM */ *len+=CONTENT_LENGTH_LEN+1 + CRLF_LEN + CRLF_LEN; @@ -194,7 +194,8 @@ char *build_local(struct cell *Trans,unsigned int branch, /* User Agent header */ if (server_signature) { - append_str(p,USER_AGENT CRLF, USER_AGENT_LEN+CRLF_LEN ); + append_str(p, user_agent_hdr.s, user_agent_hdr.len ); + append_str(p, CRLF, CRLF_LEN ); } /* Content Length, EoM */ append_str(p, CONTENT_LENGTH "0" CRLF CRLF , @@ -1026,7 +1027,7 @@ char *build_dlg_ack(struct sip_msg* rpl, struct cell *Trans, *len += calc_routeset_len(list, cont); /* User Agent */ - if (server_signature) *len += USER_AGENT_LEN + CRLF_LEN; + if (server_signature) *len += user_agent_hdr.len + CRLF_LEN; /* extra headers */ if (hdrs) *len += hdrs->len; @@ -1077,7 +1078,8 @@ char *build_dlg_ack(struct sip_msg* rpl, struct cell *Trans, /* User Agent header */ if (server_signature) { - append_str(p, USER_AGENT CRLF, USER_AGENT_LEN + CRLF_LEN); + append_str(p, user_agent_hdr.s, user_agent_hdr.len); + append_str(p, CRLF, CRLF_LEN); } /* extra headers */ @@ -1342,7 +1344,7 @@ char* build_uac_req(str* method, str* headers, str* body, dlg_t* dialog, int bra *len += calculate_routeset_length(dialog); /* Route set */ *len += CONTENT_LENGTH_LEN + content_length.len + CRLF_LEN; /* Content- Length */ - *len += (server_signature ? (USER_AGENT_LEN + CRLF_LEN) : 0); /* Signature */ + *len += (server_signature ? (user_agent_hdr.len + CRLF_LEN) : 0); /* Signature */ *len += (headers ? headers->len : 0); /* Additional headers */ *len += (body ? body->len : 0); /* Message body */ *len += CRLF_LEN; /* End of Header */ @@ -1369,7 +1371,10 @@ char* build_uac_req(str* method, str* headers, str* body, dlg_t* dialog, int bra memapp(w, CRLF, CRLF_LEN); /* Server signature */ - if (server_signature) memapp(w, USER_AGENT CRLF, USER_AGENT_LEN + CRLF_LEN); + if (server_signature) { + memapp(w, user_agent_hdr.s, user_agent_hdr.len); + memapp(w, CRLF, CRLF_LEN); + } if (headers) memapp(w, headers->s, headers->len); memapp(w, CRLF, CRLF_LEN); if (body) memapp(w, body->s, body->len); From miconda at gmail.com Thu Aug 20 10:58:02 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Thu, 20 Aug 2009 10:58:02 +0200 (CEST) Subject: [sr-dev] git:master: core: server signature value can be set via param Message-ID: <20090820085802.17EEEEF8072@rimmer> Module: sip-router Branch: master Commit: c745469fb8af0101b26de8bee82c4314dfcafab9 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=c745469fb8af0101b26de8bee82c4314dfcafab9 Author: Daniel-Constantin Mierla Committer: Daniel-Constantin Mierla Date: Thu Aug 20 11:49:14 2009 +0300 core: server signature value can be set via param - server and user agent signature were only defines so far - two new parameters server_header and user_agent_header allow to define them via cfg parameters - default values are the same so far --- cfg.lex | 4 ++++ cfg.y | 10 ++++++++++ globals.h | 2 ++ main.c | 2 ++ msg_translator.c | 6 +++--- 5 files changed, 21 insertions(+), 3 deletions(-) diff --git a/cfg.lex b/cfg.lex index 32aed32..e15c71b 100644 --- a/cfg.lex +++ b/cfg.lex @@ -329,6 +329,8 @@ MEMLOG "memlog"|"mem_log" MEMDBG "memdbg"|"mem_dbg" SIP_WARNING sip_warning SERVER_SIGNATURE server_signature +SERVER_HEADER server_header +USER_AGENT_HEADER user_agent_header REPLY_TO_VIA reply_to_via USER "user"|"uid" GROUP "group"|"gid" @@ -765,6 +767,8 @@ EAT_ABLE [\ \t\b\r] {SCTP_MAX_BURST} { count(); yylval.strval=yytext; return SCTP_MAX_BURST; } {SERVER_SIGNATURE} { count(); yylval.strval=yytext; return SERVER_SIGNATURE; } +{SERVER_HEADER} { count(); yylval.strval=yytext; return SERVER_HEADER; } +{USER_AGENT_HEADER} { count(); yylval.strval=yytext; return USER_AGENT_HEADER; } {REPLY_TO_VIA} { count(); yylval.strval=yytext; return REPLY_TO_VIA; } {ADVERTISED_ADDRESS} { count(); yylval.strval=yytext; return ADVERTISED_ADDRESS; } diff --git a/cfg.y b/cfg.y index e9e8d8a..8a240c6 100644 --- a/cfg.y +++ b/cfg.y @@ -390,6 +390,8 @@ static int case_check_default(struct case_stms* stms); %token MEMDBG %token SIP_WARNING %token SERVER_SIGNATURE +%token SERVER_HEADER +%token USER_AGENT_HEADER %token REPLY_TO_VIA %token LOADMODULE %token LOADPATH @@ -1362,6 +1364,14 @@ assign_stm: | SCTP_MAX_BURST EQUAL error { yyerror("number expected"); } | SERVER_SIGNATURE EQUAL NUMBER { server_signature=$3; } | SERVER_SIGNATURE EQUAL error { yyerror("boolean value expected"); } + | SERVER_HEADER EQUAL STRING { server_hdr.s=$3; + server_hdr.len=strlen(server_hdr.s); + } + | SERVER_HEADER EQUAL error { yyerror("string value expected"); } + | USER_AGENT_HEADER EQUAL STRING { user_agent_hdr.s=$3; + user_agent_hdr.len=strlen(user_agent_hdr.s); + } + | USER_AGENT_HEADER EQUAL error { yyerror("string value expected"); } | REPLY_TO_VIA EQUAL NUMBER { reply_to_via=$3; } | REPLY_TO_VIA EQUAL error { yyerror("boolean value expected"); } | LISTEN EQUAL id_lst { diff --git a/globals.h b/globals.h index f7ef9f8..add1f40 100644 --- a/globals.h +++ b/globals.h @@ -108,6 +108,8 @@ extern int syn_branch; extern int child_rank; extern int sip_warning; extern int server_signature; +extern str server_hdr; +extern str user_agent_hdr; extern char* user; extern char* group; extern char* sock_user; diff --git a/main.c b/main.c index 9a771f8..c975057 100644 --- a/main.c +++ b/main.c @@ -345,6 +345,8 @@ int sip_warning = 1; be default yes, good for trouble-shooting */ int server_signature=1; +str server_hdr = {SERVER_HDR, SERVER_HDR_LEN}; +str user_agent_hdr = {USER_AGENT, USER_AGENT_LEN}; /* should ser try to locate outbound interface on multihomed * host? by default not -- too expensive */ diff --git a/msg_translator.c b/msg_translator.c index 2f14505..b6273b0 100644 --- a/msg_translator.c +++ b/msg_translator.c @@ -1953,7 +1953,7 @@ char * build_res_buf_from_sip_req( unsigned int code, char *text ,str *new_tag, } /* server header */ if (server_signature) - len += SERVER_HDR_LEN + CRLF_LEN; + len += server_hdr.len + CRLF_LEN; /* warning hdr */ if (sip_warning) { warning_buf = warning_builder(msg,&warning_len); @@ -2092,8 +2092,8 @@ char * build_res_buf_from_sip_req( unsigned int code, char *text ,str *new_tag, } /* server header */ if (server_signature) { - memcpy( p, SERVER_HDR , SERVER_HDR_LEN ); - p+=SERVER_HDR_LEN; + memcpy( p, server_hdr.s, server_hdr.len ); + p+=server_hdr.len; memcpy( p, CRLF, CRLF_LEN ); p+=CRLF_LEN; } From miconda at gmail.com Thu Aug 20 11:59:23 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Thu, 20 Aug 2009 11:59:23 +0200 (CEST) Subject: [sr-dev] git:master: core: support to add rport parameter to local via hdr Message-ID: <20090820095923.E84F7EF8070@rimmer> Module: sip-router Branch: master Commit: c37c22b4af29fed88c5655a5405876ffc640e5b2 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=c37c22b4af29fed88c5655a5405876ffc640e5b2 Author: Daniel-Constantin Mierla Committer: Daniel-Constantin Mierla Date: Thu Aug 20 12:57:01 2009 +0300 core: support to add rport parameter to local via hdr - new cfg function - add_local_rport() - to add rport parameter to local via header (rfc3581) --- action.c | 4 ++++ cfg.lex | 3 +++ cfg.y | 3 +++ msg_translator.c | 25 +++++++++++++++++++++---- parser/msg_parser.h | 1 + route_struct.h | 1 + 6 files changed, 33 insertions(+), 4 deletions(-) diff --git a/action.c b/action.c index 848ec59..8e21ee6 100644 --- a/action.c +++ b/action.c @@ -1129,6 +1129,10 @@ match_cleanup: msg->msg_flags|=FL_FORCE_RPORT; ret=1; /* continue processing */ break; + case ADD_LOCAL_RPORT_T: + msg->msg_flags|=FL_ADD_LOCAL_RPORT; + ret=1; /* continue processing */ + break; case UDP_MTU_TRY_PROTO_T: msg->msg_flags|= (unsigned int)a->val[0].u.number & FL_MTU_FB_MASK; ret=1; /* continue processing */ diff --git a/cfg.lex b/cfg.lex index e15c71b..ebe2b6d 100644 --- a/cfg.lex +++ b/cfg.lex @@ -166,6 +166,7 @@ ROUTE_SEND onsend_route ROUTE_EVENT event_route EXEC exec FORCE_RPORT "force_rport"|"add_rport" +ADD_LOCAL_RPORT "add_local_rport" FORCE_TCP_ALIAS "force_tcp_alias"|"add_tcp_alias" UDP_MTU "udp_mtu" UDP_MTU_TRY_PROTO "udp_mtu_try_proto" @@ -534,6 +535,8 @@ EAT_ABLE [\ \t\b\r] {SET_USERPHONE} { count(); yylval.strval=yytext; return SET_USERPHONE; } {FORCE_RPORT} { count(); yylval.strval=yytext; return FORCE_RPORT; } +{ADD_LOCAL_RPORT} { count(); yylval.strval=yytext; + return ADD_LOCAL_RPORT; } {FORCE_TCP_ALIAS} { count(); yylval.strval=yytext; return FORCE_TCP_ALIAS; } {UDP_MTU} { count(); yylval.strval=yytext; return UDP_MTU; } diff --git a/cfg.y b/cfg.y index 8a240c6..6950d88 100644 --- a/cfg.y +++ b/cfg.y @@ -295,6 +295,7 @@ static int case_check_default(struct case_stms* stms); %token SET_URI %token REVERT_URI %token FORCE_RPORT +%token ADD_LOCAL_RPORT %token FORCE_TCP_ALIAS %token UDP_MTU %token UDP_MTU_TRY_PROTO @@ -2886,6 +2887,8 @@ cmd: | REVERT_URI { $$=mk_action(REVERT_URI_T, 0); } | FORCE_RPORT LPAREN RPAREN { $$=mk_action(FORCE_RPORT_T, 0); } | FORCE_RPORT {$$=mk_action(FORCE_RPORT_T, 0); } + | ADD_LOCAL_RPORT LPAREN RPAREN { $$=mk_action(ADD_LOCAL_RPORT_T, 0); } + | ADD_LOCAL_RPORT {$$=mk_action(ADD_LOCAL_RPORT_T, 0); } | FORCE_TCP_ALIAS LPAREN NUMBER RPAREN { #ifdef USE_TCP $$=mk_action(FORCE_TCP_ALIAS_T, 1, NUMBER_ST, (void*)$3); diff --git a/msg_translator.c b/msg_translator.c index b6273b0..e486579 100644 --- a/msg_translator.c +++ b/msg_translator.c @@ -2382,14 +2382,31 @@ char* create_via_hf( unsigned int *len, } #endif /* USE_TCP || USE_SCTP */ + /* test and add rport parameter to local via - rfc3581 */ + if(msg->msg_flags&FL_ADD_LOCAL_RPORT) { + /* params so far + ';rport' + '\0' */ + via = (char*)pkg_malloc(extra_params.len+RPORT_LEN); + if(via==0) { + LM_ERR("building local rport via param failed\n"); + if (extra_params.s) pkg_free(extra_params.s); + return 0; + } + if(extra_params.len!=0) { + memcpy(via, extra_params.s, extra_params.len); + pkg_free(extra_params.s); + } + memcpy(via + extra_params.len, RPORT, RPORT_LEN-1); + extra_params.s = via; + extra_params.len += RPORT_LEN-1; + extra_params.s[extra_params.len]='\0'; + } + set_hostport(&hp, msg); via = via_builder( len, send_info, branch, extra_params.len?&extra_params:0, &hp); -#if defined USE_TCP || defined USE_SCTP - /* we do not need id_buf any more, the id is already in the new via header */ - if (id_buf) pkg_free(id_buf); -#endif + /* we do not need extra_params any more, already in the new via header */ + if (extra_params.s) pkg_free(extra_params.s); return via; } diff --git a/parser/msg_parser.h b/parser/msg_parser.h index a811b61..1ce00bb 100644 --- a/parser/msg_parser.h +++ b/parser/msg_parser.h @@ -109,6 +109,7 @@ enum request_method { #define FL_MTU_TCP_FB (1 << 8) #define FL_MTU_TLS_FB (1 << 9) #define FL_MTU_SCTP_FB (1 << 10) +#define FL_ADD_LOCAL_RPORT (1 << 11) /* add 'rport' to local via hdr */ /* WARNING: Value (1 << 29) is temporarily reserved for use in kamailio acc * module (flag FL_REQ_UPSTREAM)! */ diff --git a/route_struct.h b/route_struct.h index 090388c..9274340 100644 --- a/route_struct.h +++ b/route_struct.h @@ -97,6 +97,7 @@ enum action_type{ FORWARD_SCTP_T, SEND_TCP_T, FORCE_RPORT_T, + ADD_LOCAL_RPORT_T, SET_ADV_ADDR_T, SET_ADV_PORT_T, FORCE_TCP_ALIAS_T, From klaus.mailinglists at pernau.at Thu Aug 20 12:20:03 2009 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Thu, 20 Aug 2009 12:20:03 +0200 Subject: [sr-dev] git:master: core: server signature value can be set via param In-Reply-To: <20090820085802.17EEEEF8072@rimmer> References: <20090820085802.17EEEEF8072@rimmer> Message-ID: <4A8D2353.4090603@pernau.at> btw: I never understood in which case which header is used. Is there a simple rule? regards klaus Daniel-Constantin Mierla schrieb: > Module: sip-router > Branch: master > Commit: c745469fb8af0101b26de8bee82c4314dfcafab9 > URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=c745469fb8af0101b26de8bee82c4314dfcafab9 > > Author: Daniel-Constantin Mierla > Committer: Daniel-Constantin Mierla > Date: Thu Aug 20 11:49:14 2009 +0300 > > core: server signature value can be set via param > > - server and user agent signature were only defines so far > - two new parameters server_header and user_agent_header allow > to define them via cfg parameters > - default values are the same so far > > --- > > cfg.lex | 4 ++++ > cfg.y | 10 ++++++++++ > globals.h | 2 ++ > main.c | 2 ++ > msg_translator.c | 6 +++--- > 5 files changed, 21 insertions(+), 3 deletions(-) > > diff --git a/cfg.lex b/cfg.lex > index 32aed32..e15c71b 100644 > --- a/cfg.lex > +++ b/cfg.lex > @@ -329,6 +329,8 @@ MEMLOG "memlog"|"mem_log" > MEMDBG "memdbg"|"mem_dbg" > SIP_WARNING sip_warning > SERVER_SIGNATURE server_signature > +SERVER_HEADER server_header > +USER_AGENT_HEADER user_agent_header > REPLY_TO_VIA reply_to_via > USER "user"|"uid" > GROUP "group"|"gid" > @@ -765,6 +767,8 @@ EAT_ABLE [\ \t\b\r] > {SCTP_MAX_BURST} { count(); yylval.strval=yytext; > return SCTP_MAX_BURST; } > {SERVER_SIGNATURE} { count(); yylval.strval=yytext; return SERVER_SIGNATURE; } > +{SERVER_HEADER} { count(); yylval.strval=yytext; return SERVER_HEADER; } > +{USER_AGENT_HEADER} { count(); yylval.strval=yytext; return USER_AGENT_HEADER; } > {REPLY_TO_VIA} { count(); yylval.strval=yytext; return REPLY_TO_VIA; } > {ADVERTISED_ADDRESS} { count(); yylval.strval=yytext; > return ADVERTISED_ADDRESS; } > diff --git a/cfg.y b/cfg.y > index e9e8d8a..8a240c6 100644 > --- a/cfg.y > +++ b/cfg.y > @@ -390,6 +390,8 @@ static int case_check_default(struct case_stms* stms); > %token MEMDBG > %token SIP_WARNING > %token SERVER_SIGNATURE > +%token SERVER_HEADER > +%token USER_AGENT_HEADER > %token REPLY_TO_VIA > %token LOADMODULE > %token LOADPATH > @@ -1362,6 +1364,14 @@ assign_stm: > | SCTP_MAX_BURST EQUAL error { yyerror("number expected"); } > | SERVER_SIGNATURE EQUAL NUMBER { server_signature=$3; } > | SERVER_SIGNATURE EQUAL error { yyerror("boolean value expected"); } > + | SERVER_HEADER EQUAL STRING { server_hdr.s=$3; > + server_hdr.len=strlen(server_hdr.s); > + } > + | SERVER_HEADER EQUAL error { yyerror("string value expected"); } > + | USER_AGENT_HEADER EQUAL STRING { user_agent_hdr.s=$3; > + user_agent_hdr.len=strlen(user_agent_hdr.s); > + } > + | USER_AGENT_HEADER EQUAL error { yyerror("string value expected"); } > | REPLY_TO_VIA EQUAL NUMBER { reply_to_via=$3; } > | REPLY_TO_VIA EQUAL error { yyerror("boolean value expected"); } > | LISTEN EQUAL id_lst { > diff --git a/globals.h b/globals.h > index f7ef9f8..add1f40 100644 > --- a/globals.h > +++ b/globals.h > @@ -108,6 +108,8 @@ extern int syn_branch; > extern int child_rank; > extern int sip_warning; > extern int server_signature; > +extern str server_hdr; > +extern str user_agent_hdr; > extern char* user; > extern char* group; > extern char* sock_user; > diff --git a/main.c b/main.c > index 9a771f8..c975057 100644 > --- a/main.c > +++ b/main.c > @@ -345,6 +345,8 @@ int sip_warning = 1; > be default yes, good for trouble-shooting > */ > int server_signature=1; > +str server_hdr = {SERVER_HDR, SERVER_HDR_LEN}; > +str user_agent_hdr = {USER_AGENT, USER_AGENT_LEN}; > /* should ser try to locate outbound interface on multihomed > * host? by default not -- too expensive > */ > diff --git a/msg_translator.c b/msg_translator.c > index 2f14505..b6273b0 100644 > --- a/msg_translator.c > +++ b/msg_translator.c > @@ -1953,7 +1953,7 @@ char * build_res_buf_from_sip_req( unsigned int code, char *text ,str *new_tag, > } > /* server header */ > if (server_signature) > - len += SERVER_HDR_LEN + CRLF_LEN; > + len += server_hdr.len + CRLF_LEN; > /* warning hdr */ > if (sip_warning) { > warning_buf = warning_builder(msg,&warning_len); > @@ -2092,8 +2092,8 @@ char * build_res_buf_from_sip_req( unsigned int code, char *text ,str *new_tag, > } > /* server header */ > if (server_signature) { > - memcpy( p, SERVER_HDR , SERVER_HDR_LEN ); > - p+=SERVER_HDR_LEN; > + memcpy( p, server_hdr.s, server_hdr.len ); > + p+=server_hdr.len; > memcpy( p, CRLF, CRLF_LEN ); > p+=CRLF_LEN; > } > > > _______________________________________________ > sr-dev mailing list > sr-dev at lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev From miconda at gmail.com Thu Aug 20 12:36:10 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Thu, 20 Aug 2009 13:36:10 +0300 Subject: [sr-dev] git:master: core: server signature value can be set via param In-Reply-To: <4A8D2353.4090603@pernau.at> References: <20090820085802.17EEEEF8072@rimmer> <4A8D2353.4090603@pernau.at> Message-ID: <4A8D271A.6000508@gmail.com> On 20.08.2009 13:20 Uhr, Klaus Darilion wrote: > btw: I never understood in which case which header is used. Is there a > simple rule? Hi Klaus, the server header is added in local generated replies and user agent in requests. Not sure if there is RFC clarifying better when and where they must be used, but since SR core had two distinct defines, one for each, it was the way to go. Cheers, Daniel > > regards > klaus > > > > Daniel-Constantin Mierla schrieb: >> Module: sip-router >> Branch: master >> Commit: c745469fb8af0101b26de8bee82c4314dfcafab9 >> URL: >> http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=c745469fb8af0101b26de8bee82c4314dfcafab9 >> >> >> Author: Daniel-Constantin Mierla >> Committer: Daniel-Constantin Mierla >> Date: Thu Aug 20 11:49:14 2009 +0300 >> >> core: server signature value can be set via param >> >> - server and user agent signature were only defines so far >> - two new parameters server_header and user_agent_header allow >> to define them via cfg parameters >> - default values are the same so far -- Daniel-Constantin Mierla * http://www.asipto.com/ From miconda at gmail.com Thu Aug 20 15:18:36 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Thu, 20 Aug 2009 15:18:36 +0200 (CEST) Subject: [sr-dev] git:master: pv: new pv class $sel(name) Message-ID: <20090820131836.68026EF8070@rimmer> Module: sip-router Branch: master Commit: 6dac6b618015314811b94127490e906d535f44fd URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=6dac6b618015314811b94127490e906d535f44fd Author: Daniel-Constantin Mierla Committer: Daniel-Constantin Mierla Date: Thu Aug 20 16:12:35 2009 +0300 pv: new pv class $sel(name) - access select (ser cfg variables) values via PV framework - read-only PV - examples: $sel(@ruri), $sel(@via[2].host) --- modules_k/pv/pv.c | 4 +++ modules_k/pv/pv_select.c | 67 ++++++++++++++++++++++++++++++++++++++++++++++ modules_k/pv/pv_select.h | 36 ++++++++++++++++++++++++ 3 files changed, 107 insertions(+), 0 deletions(-) diff --git a/modules_k/pv/pv.c b/modules_k/pv/pv.c index f990a55..b284bbd 100644 --- a/modules_k/pv/pv.c +++ b/modules_k/pv/pv.c @@ -35,6 +35,7 @@ #include "pv_shv.h" #include "pv_time.h" #include "pv_trans.h" +#include "pv_select.h" MODULE_VERSION @@ -64,6 +65,9 @@ static pv_export_t mod_pvs[] = { { {"stat", sizeof("stat")-1}, /* statistics */ PVT_OTHER, pv_get_stat, 0, pv_parse_stat_name, 0, 0, 0 }, + { {"sel", sizeof("sel")-1}, /* select */ + PVT_OTHER, pv_get_select, 0, + pv_parse_select_name, 0, 0, 0 }, {{"avp", (sizeof("avp")-1)}, PVT_AVP, pv_get_avp, pv_set_avp, pv_parse_avp_name, pv_parse_index, 0, 0}, diff --git a/modules_k/pv/pv_select.c b/modules_k/pv/pv_select.c new file mode 100644 index 0000000..8634052 --- /dev/null +++ b/modules_k/pv/pv_select.c @@ -0,0 +1,67 @@ +/* + * $Id$ + * + * Copyright (C) 2001-2003 FhG Fokus + * + * This file is part of Kamailio, a free SIP server. + * + * Kamailio is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version + * + * Kamailio is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +/*! + * \file + * \brief Implementation for Select Pseudo-variables + */ + +#include "../../select.h" +#include "pv_select.h" + +int pv_parse_select_name(pv_spec_p sp, str *in) +{ + select_t *sel = 0; + char c; + char *p; + if (in == NULL || in->s == NULL || sp == NULL) + return -1; + + c = in->s[in->len]; + in->s[in->len] = '\0'; + p = in->s; + if(parse_select(&p, &sel)<0) + { + LM_ERR("invalid select name [%.*s]\n", + in->len, in->s); + in->s[in->len] = c; + return -1; + } + in->s[in->len] = c; + sp->pvp.pvn.u.dname = (void*)sel; + sp->pvp.pvn.type = PV_NAME_OTHER; + return 0; +} + + +int pv_get_select(struct sip_msg *msg, pv_param_t *param, pv_value_t *res) +{ + str s = {0, 0}; + select_t *sel = 0; + + sel = (select_t*)param->pvn.u.dname; + + if(sel==0 || run_select(&s, sel, msg)<0 || s.s==0) + return pv_get_null(msg, param, res); + return pv_get_strval(msg, param, res, &s); +} + diff --git a/modules_k/pv/pv_select.h b/modules_k/pv/pv_select.h new file mode 100644 index 0000000..84c872f --- /dev/null +++ b/modules_k/pv/pv_select.h @@ -0,0 +1,36 @@ +/* + * $Id$ + * + * Copyright (C) 2001-2003 FhG Fokus + * + * This file is part of Kamailio, a free SIP server. + * + * Kamailio is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version + * + * Kamailio is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +/*! + * \file + * \brief Headers for Stats Pseudo-variables + */ + +#ifndef _PV_SELECT_H_ +#define _PV_SELECT_H_ + +#include "../../pvar.h" + +int pv_parse_select_name(pv_spec_p sp, str *in); +int pv_get_select(struct sip_msg *msg, pv_param_t *param, pv_value_t *res); + +#endif From miconda at gmail.com Thu Aug 20 15:23:21 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Thu, 20 Aug 2009 16:23:21 +0300 Subject: [sr-dev] are selects documented somewhere? Message-ID: <4A8D4E49.2010004@gmail.com> Hello, is there a list with available selects in ser? I only found short introduction at: http://www.iptel.org/introduction_to_selects_and_attribute_value_pairs_avpairs Thanks, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ From klaus.mailinglists at pernau.at Thu Aug 20 15:30:31 2009 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Thu, 20 Aug 2009 15:30:31 +0200 Subject: [sr-dev] are selects documented somewhere? In-Reply-To: <4A8D4E49.2010004@gmail.com> References: <4A8D4E49.2010004@gmail.com> Message-ID: <4A8D4FF7.7040107@pernau.at> Recently posted by Miklos: -------- Original-Nachricht -------- Betreff: Re: [SR-Users] sip-router select Datum: Wed, 12 Aug 2009 10:13:11 +0200 Von: Miklos Tirpak An: M?SZ?ROS Mih?ly CC: sr-users at lists.sip-router.org Referenzen: <4A817281.4040301 at niif.hu> Hi, selects come from SER, I found these pages about them: http://www.iptel.org/introduction_to_selects_and_attribute_value_pairs_avpairs http://www.iptel.org/attribute_value_pairs_and_selects For the list of available selects you can use http://www.iptel.org/ser/doc/search (Uncheck F, R, and P) It shows a bit older state though. Miklos On 08/11/2009 03:30 PM, M?SZ?ROS Mih?ly wrote: > Hi! > > Can any of you explain how select framework is working? > Where can i find any documentation about it. > I am experiencing problem when i am try using it. > Any help highly appreciated! > > Regards, > Misi > Daniel-Constantin Mierla schrieb: > Hello, > > is there a list with available selects in ser? I only found short > introduction at: > > http://www.iptel.org/introduction_to_selects_and_attribute_value_pairs_avpairs > > > Thanks, > Daniel > From miconda at gmail.com Thu Aug 20 15:32:31 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Thu, 20 Aug 2009 16:32:31 +0300 Subject: [sr-dev] are selects documented somewhere? In-Reply-To: <4A8D4FF7.7040107@pernau.at> References: <4A8D4E49.2010004@gmail.com> <4A8D4FF7.7040107@pernau.at> Message-ID: <4A8D506F.70309@gmail.com> On 20.08.2009 16:30 Uhr, Klaus Darilion wrote: > Recently posted by Miklos: ahh, thanks, I did miss this mail... Cheers, Daniel > > -------- Original-Nachricht -------- > Betreff: Re: [SR-Users] sip-router select > Datum: Wed, 12 Aug 2009 10:13:11 +0200 > Von: Miklos Tirpak > An: M?SZ?ROS Mih?ly > CC: sr-users at lists.sip-router.org > Referenzen: <4A817281.4040301 at niif.hu> > > Hi, > > selects come from SER, I found these pages about them: > http://www.iptel.org/introduction_to_selects_and_attribute_value_pairs_avpairs > > http://www.iptel.org/attribute_value_pairs_and_selects > > For the list of available selects you can use > http://www.iptel.org/ser/doc/search > (Uncheck F, R, and P) > It shows a bit older state though. > > Miklos > > On 08/11/2009 03:30 PM, M?SZ?ROS Mih?ly wrote: > > Hi! > > > > Can any of you explain how select framework is working? > > Where can i find any documentation about it. > > I am experiencing problem when i am try using it. > > Any help highly appreciated! > > > > Regards, > > Misi > > > > Daniel-Constantin Mierla schrieb: >> Hello, >> >> is there a list with available selects in ser? I only found short >> introduction at: >> >> http://www.iptel.org/introduction_to_selects_and_attribute_value_pairs_avpairs >> >> >> Thanks, >> Daniel >> -- Daniel-Constantin Mierla * http://www.asipto.com/ From jan at ryngle.com Thu Aug 20 15:47:33 2009 From: jan at ryngle.com (Jan Janak) Date: Thu, 20 Aug 2009 15:47:33 +0200 Subject: [sr-dev] are selects documented somewhere? In-Reply-To: <4A8D506F.70309@gmail.com> References: <4A8D4E49.2010004@gmail.com> <4A8D4FF7.7040107@pernau.at> <4A8D506F.70309@gmail.com> Message-ID: Up-to-date list of implemented selects does not exist, but we once wrote a tool that can generate such list from compiled SER modules (by traversing the data structures in modules). The tool most likely won't work anymore with sip-router code, but we can try to update it if people think would be a good idea and a good think to have. The tool was called ser_objdump and its git import is here: http://git.sip-router.org/cgi-bin/gitweb.cgi?p=ser;a=tree;h=refs/heads/master;hb=refs/heads/master In addition to selects it also produced lists if implemented module functions, module parameters, and rcp commands. The output of that tool is what is being searched by the search tool recommended by Miklos and available on iptel.org site. Jan. On Thu, Aug 20, 2009 at 3:32 PM, Daniel-Constantin Mierla wrote: > > > On 20.08.2009 16:30 Uhr, Klaus Darilion wrote: >> >> Recently posted by Miklos: > > ahh, thanks, I did miss this mail... > > Cheers, > Daniel > >> >> -------- Original-Nachricht -------- >> Betreff: Re: [SR-Users] sip-router select >> Datum: Wed, 12 Aug 2009 10:13:11 +0200 >> Von: Miklos Tirpak >> An: M?SZ?ROS Mih?ly >> CC: sr-users at lists.sip-router.org >> Referenzen: <4A817281.4040301 at niif.hu> >> >> Hi, >> >> selects come from SER, I found these pages about them: >> >> http://www.iptel.org/introduction_to_selects_and_attribute_value_pairs_avpairs >> http://www.iptel.org/attribute_value_pairs_and_selects >> >> For the list of available selects you can use >> http://www.iptel.org/ser/doc/search >> (Uncheck F, R, and P) >> It shows a bit older state though. >> >> Miklos >> >> On 08/11/2009 03:30 PM, M?SZ?ROS Mih?ly wrote: >> > Hi! >> > >> > Can any of you explain how select framework is working? >> > Where can i find any documentation about it. >> > I am experiencing problem when i am try using it. >> > Any help highly appreciated! >> > >> > Regards, >> > Misi >> > >> >> Daniel-Constantin Mierla schrieb: >>> >>> Hello, >>> >>> is there a list with available selects in ser? I only found short >>> introduction at: >>> >>> >>> http://www.iptel.org/introduction_to_selects_and_attribute_value_pairs_avpairs >>> >>> Thanks, >>> Daniel >>> > > -- > Daniel-Constantin Mierla > * http://www.asipto.com/ > > > _______________________________________________ > sr-dev mailing list > sr-dev at lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > From miconda at gmail.com Thu Aug 20 15:49:10 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Thu, 20 Aug 2009 16:49:10 +0300 Subject: [sr-dev] are selects documented somewhere? In-Reply-To: <4A8D4FF7.7040107@pernau.at> References: <4A8D4E49.2010004@gmail.com> <4A8D4FF7.7040107@pernau.at> Message-ID: <4A8D5456.1020402@gmail.com> On 20.08.2009 16:30 Uhr, Klaus Darilion wrote: > Recently posted by Miklos: I started a dedicated wiki page in cookbook format: http://sip-router.org/wiki/cookbooks/selects/devel Anyone having time to dig and contribute, is very welcome. Thanks, Daniel > > -------- Original-Nachricht -------- > Betreff: Re: [SR-Users] sip-router select > Datum: Wed, 12 Aug 2009 10:13:11 +0200 > Von: Miklos Tirpak > An: M?SZ?ROS Mih?ly > CC: sr-users at lists.sip-router.org > Referenzen: <4A817281.4040301 at niif.hu> > > Hi, > > selects come from SER, I found these pages about them: > http://www.iptel.org/introduction_to_selects_and_attribute_value_pairs_avpairs > > http://www.iptel.org/attribute_value_pairs_and_selects > > For the list of available selects you can use > http://www.iptel.org/ser/doc/search > (Uncheck F, R, and P) > It shows a bit older state though. > > Miklos > > On 08/11/2009 03:30 PM, M?SZ?ROS Mih?ly wrote: > > Hi! > > > > Can any of you explain how select framework is working? > > Where can i find any documentation about it. > > I am experiencing problem when i am try using it. > > Any help highly appreciated! > > > > Regards, > > Misi > > > > Daniel-Constantin Mierla schrieb: >> Hello, >> >> is there a list with available selects in ser? I only found short >> introduction at: >> >> http://www.iptel.org/introduction_to_selects_and_attribute_value_pairs_avpairs >> >> >> Thanks, >> Daniel >> > > _______________________________________________ > sr-dev mailing list > sr-dev at lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > -- Daniel-Constantin Mierla * http://www.asipto.com/ From jan at ryngle.com Thu Aug 20 16:06:32 2009 From: jan at ryngle.com (Jan Janak) Date: Thu, 20 Aug 2009 16:06:32 +0200 Subject: [sr-dev] are selects documented somewhere? In-Reply-To: <4A8D5456.1020402@gmail.com> References: <4A8D4E49.2010004@gmail.com> <4A8D4FF7.7040107@pernau.at> <4A8D5456.1020402@gmail.com> Message-ID: On Thu, Aug 20, 2009 at 3:49 PM, Daniel-Constantin Mierla wrote: > > > On 20.08.2009 16:30 Uhr, Klaus Darilion wrote: >> >> Recently posted by Miklos: > > I started a dedicated wiki page in cookbook format: > http://sip-router.org/wiki/cookbooks/selects/devel > > Anyone having time to dig and contribute, is very welcome. I found a list I generated a while ago. It is not completely up-to-date but it won't be far from it. The list in CSV format is attached in case you wanted to import it in the wiki page. The meaning of comma separated fields is as follows * module name * ser version * function/parameter/select name * Symbol type (0-function, 1-rpc, 2-param, 3-select * Number of parameters (functions) * Flags (failure route, onsend route, ...) * Documentation string (rpc functions) Jan. -------------- next part -------------- A non-text attachment was scrubbed... Name: ser.csv Type: text/csv Size: 72895 bytes Desc: not available URL: From klaus.mailinglists at pernau.at Thu Aug 20 16:11:23 2009 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Thu, 20 Aug 2009 16:11:23 +0200 Subject: [sr-dev] are selects documented somewhere? In-Reply-To: <4A8D5456.1020402@gmail.com> References: <4A8D4E49.2010004@gmail.com> <4A8D4FF7.7040107@pernau.at> <4A8D5456.1020402@gmail.com> Message-ID: <4A8D598B.6060708@pernau.at> Daniel-Constantin Mierla schrieb: > > > On 20.08.2009 16:30 Uhr, Klaus Darilion wrote: >> Recently posted by Miklos: > I started a dedicated wiki page in cookbook format: > http://sip-router.org/wiki/cookbooks/selects/devel > > Anyone having time to dig and contribute, is very welcome. IMO it should be generated automatically by the tool Jan mentioned. klaus > > Thanks, > Daniel > >> >> -------- Original-Nachricht -------- >> Betreff: Re: [SR-Users] sip-router select >> Datum: Wed, 12 Aug 2009 10:13:11 +0200 >> Von: Miklos Tirpak >> An: M?SZ?ROS Mih?ly >> CC: sr-users at lists.sip-router.org >> Referenzen: <4A817281.4040301 at niif.hu> >> >> Hi, >> >> selects come from SER, I found these pages about them: >> http://www.iptel.org/introduction_to_selects_and_attribute_value_pairs_avpairs >> >> http://www.iptel.org/attribute_value_pairs_and_selects >> >> For the list of available selects you can use >> http://www.iptel.org/ser/doc/search >> (Uncheck F, R, and P) >> It shows a bit older state though. >> >> Miklos >> >> On 08/11/2009 03:30 PM, M?SZ?ROS Mih?ly wrote: >> > Hi! >> > >> > Can any of you explain how select framework is working? >> > Where can i find any documentation about it. >> > I am experiencing problem when i am try using it. >> > Any help highly appreciated! >> > >> > Regards, >> > Misi >> > >> >> Daniel-Constantin Mierla schrieb: >>> Hello, >>> >>> is there a list with available selects in ser? I only found short >>> introduction at: >>> >>> http://www.iptel.org/introduction_to_selects_and_attribute_value_pairs_avpairs >>> >>> >>> Thanks, >>> Daniel >>> >> >> _______________________________________________ >> sr-dev mailing list >> sr-dev at lists.sip-router.org >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev >> > From miconda at gmail.com Thu Aug 20 17:24:32 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Thu, 20 Aug 2009 18:24:32 +0300 Subject: [sr-dev] are selects documented somewhere? In-Reply-To: <4A8D598B.6060708@pernau.at> References: <4A8D4E49.2010004@gmail.com> <4A8D4FF7.7040107@pernau.at> <4A8D5456.1020402@gmail.com> <4A8D598B.6060708@pernau.at> Message-ID: <4A8D6AB0.6010304@gmail.com> On 20.08.2009 17:11 Uhr, Klaus Darilion wrote: > > > Daniel-Constantin Mierla schrieb: >> >> >> On 20.08.2009 16:30 Uhr, Klaus Darilion wrote: >>> Recently posted by Miklos: >> I started a dedicated wiki page in cookbook format: >> http://sip-router.org/wiki/cookbooks/selects/devel >> >> Anyone having time to dig and contribute, is very welcome. > > IMO it should be generated automatically by the tool Jan mentioned. fine with me, I didn't know about it, feel free to do it. However, some description/examples should be added as well. Cheers, Daniel > > klaus > > >> >> Thanks, >> Daniel >> >>> >>> -------- Original-Nachricht -------- >>> Betreff: Re: [SR-Users] sip-router select >>> Datum: Wed, 12 Aug 2009 10:13:11 +0200 >>> Von: Miklos Tirpak >>> An: M?SZ?ROS Mih?ly >>> CC: sr-users at lists.sip-router.org >>> Referenzen: <4A817281.4040301 at niif.hu> >>> >>> Hi, >>> >>> selects come from SER, I found these pages about them: >>> http://www.iptel.org/introduction_to_selects_and_attribute_value_pairs_avpairs >>> >>> http://www.iptel.org/attribute_value_pairs_and_selects >>> >>> For the list of available selects you can use >>> http://www.iptel.org/ser/doc/search >>> (Uncheck F, R, and P) >>> It shows a bit older state though. >>> >>> Miklos >>> >>> On 08/11/2009 03:30 PM, M?SZ?ROS Mih?ly wrote: >>> > Hi! >>> > >>> > Can any of you explain how select framework is working? >>> > Where can i find any documentation about it. >>> > I am experiencing problem when i am try using it. >>> > Any help highly appreciated! >>> > >>> > Regards, >>> > Misi >>> > >>> >>> Daniel-Constantin Mierla schrieb: >>>> Hello, >>>> >>>> is there a list with available selects in ser? I only found short >>>> introduction at: >>>> >>>> http://www.iptel.org/introduction_to_selects_and_attribute_value_pairs_avpairs >>>> >>>> >>>> Thanks, >>>> Daniel >>>> >>> >>> _______________________________________________ >>> sr-dev mailing list >>> sr-dev at lists.sip-router.org >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev >>> >> -- Daniel-Constantin Mierla * http://www.asipto.com/ From miconda at gmail.com Thu Aug 20 17:26:01 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Thu, 20 Aug 2009 18:26:01 +0300 Subject: [sr-dev] are selects documented somewhere? In-Reply-To: References: <4A8D4E49.2010004@gmail.com> <4A8D4FF7.7040107@pernau.at> <4A8D5456.1020402@gmail.com> Message-ID: <4A8D6B09.1070001@gmail.com> Thanks Jan, the tool sounds interesting, however, the file you attached does not include the selects ... or I overlooked something. Cheers, Daniel On 20.08.2009 17:06 Uhr, Jan Janak wrote: > On Thu, Aug 20, 2009 at 3:49 PM, Daniel-Constantin > Mierla wrote: > >> On 20.08.2009 16:30 Uhr, Klaus Darilion wrote: >> >>> Recently posted by Miklos: >>> >> I started a dedicated wiki page in cookbook format: >> http://sip-router.org/wiki/cookbooks/selects/devel >> >> Anyone having time to dig and contribute, is very welcome. >> > > I found a list I generated a while ago. It is not completely > up-to-date but it won't be far from it. The list in CSV format is > attached in case you wanted to import it in the wiki page. > > The meaning of comma separated fields is as follows > * module name > * ser version > * function/parameter/select name > * Symbol type (0-function, 1-rpc, 2-param, 3-select > * Number of parameters (functions) > * Flags (failure route, onsend route, ...) > * Documentation string (rpc functions) > > Jan. > -- Daniel-Constantin Mierla * http://www.asipto.com/ From jan at ryngle.com Thu Aug 20 17:35:28 2009 From: jan at ryngle.com (Jan Janak) Date: Thu, 20 Aug 2009 17:35:28 +0200 Subject: [sr-dev] are selects documented somewhere? In-Reply-To: <4A8D6B09.1070001@gmail.com> References: <4A8D4E49.2010004@gmail.com> <4A8D4FF7.7040107@pernau.at> <4A8D5456.1020402@gmail.com> <4A8D6B09.1070001@gmail.com> Message-ID: On Thu, Aug 20, 2009 at 5:26 PM, Daniel-Constantin Mierla wrote: > Thanks Jan, the tool sounds interesting, however, the file you attached does > not include the selects ... or I overlooked something. You are right, I overlooked this. I must have another file with just selects then because I remember generating it, I'll have a look tomorrow and get back to you. Jan. From klaus.mailinglists at pernau.at Thu Aug 20 18:01:03 2009 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Thu, 20 Aug 2009 18:01:03 +0200 Subject: [sr-dev] are selects documented somewhere? In-Reply-To: <4A8D6AB0.6010304@gmail.com> References: <4A8D4E49.2010004@gmail.com> <4A8D4FF7.7040107@pernau.at> <4A8D5456.1020402@gmail.com> <4A8D598B.6060708@pernau.at> <4A8D6AB0.6010304@gmail.com> Message-ID: <4A8D733F.3050703@pernau.at> Daniel-Constantin Mierla schrieb: > > > On 20.08.2009 17:11 Uhr, Klaus Darilion wrote: >> >> >> Daniel-Constantin Mierla schrieb: >>> >>> >>> On 20.08.2009 16:30 Uhr, Klaus Darilion wrote: >>>> Recently posted by Miklos: >>> I started a dedicated wiki page in cookbook format: >>> http://sip-router.org/wiki/cookbooks/selects/devel >>> >>> Anyone having time to dig and contribute, is very welcome. >> >> IMO it should be generated automatically by the tool Jan mentioned. > fine with me, I didn't know about it, feel free to do it. However, some > description/examples should be added as well. maybe two lists? - all selects (autogenerated, undocumented) - documented selects I think some selects will be self-explanatory if the basic selects are described klaus From jh at tutpro.com Mon Aug 24 09:32:09 2009 From: jh at tutpro.com (Juha Heinanen) Date: Mon, 24 Aug 2009 10:32:09 +0300 Subject: [sr-dev] async (delayed reply) support for t_uac_dlg in first release? Message-ID: <19090.16889.220892.672670@tutpro.com> andrei you wrote in july regarding async (delayed reply) support for t_uac_dlg: Ok, I'll add async support (in fact delayed reply support since it's not true async), at least to xmlrpc (turns out that it's quite easy since xmlrpc reuses sr tcp). For ctl/binrpc it would be easy for datagram sockets (udp or unix datagram socket) and more difficult (but possible) for stream sockets (tcp or unix stream). However it might take a while until there will be a workable version. any idea, if this will be available in first release of sip-router? if yes, i could plan to start using sip-router. if not, i need to plan for something else. -- juha From jan at ryngle.com Mon Aug 24 10:56:49 2009 From: jan at ryngle.com (Jan Janak) Date: Mon, 24 Aug 2009 10:56:49 +0200 Subject: [sr-dev] are selects documented somewhere? In-Reply-To: References: <4A8D4E49.2010004@gmail.com> <4A8D4FF7.7040107@pernau.at> <4A8D5456.1020402@gmail.com> <4A8D6B09.1070001@gmail.com> Message-ID: Attached is the select list. Jan. On Thu, Aug 20, 2009 at 5:35 PM, Jan Janak wrote: > On Thu, Aug 20, 2009 at 5:26 PM, Daniel-Constantin > Mierla wrote: >> Thanks Jan, the tool sounds interesting, however, the file you attached does >> not include the selects ... or I overlooked something. > > You are right, I overlooked this. I must have another file with just > selects then because I remember generating it, I'll have a look > tomorrow and get back to you. > > ?Jan. > -------------- next part -------------- A non-text attachment was scrubbed... Name: selects.csv Type: text/csv Size: 54914 bytes Desc: not available URL: From miconda at gmail.com Mon Aug 24 12:02:17 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Mon, 24 Aug 2009 13:02:17 +0300 Subject: [sr-dev] kamailio 3.0 - the time before freezing Message-ID: <4A926529.5030307@gmail.com> Hello everybody, during the last IRC devel meeting, we pinned end of summer to be the time to enter testing phase for the new major release - codenamed kamailio 3.0. There was quite a lot of brand new features, considering that most of devel effort was directed to integration. A try to collect new items is available at: http://sip-router.org/wiki/features/new-in-devel Of course, all ser features are available as well, resulting a large amount of new stuff in kamailio 3.0 vs kamailio 1.5.x. See: http://sip-router.org/benefits/ http://www.iptel.org/ser/features I propose to start the testing phase sometime next week. Meanwhile, let's see if something important was forgotten from kamailio core or tm. To my knowledge: - path support in tm - Andrei has it on his todo afaik - in a way or another, it must get in next release - drop compatibility - drop reply in reply_route - internally drop and exit are now differentiated by core, needs review and update of handling after running the routes - on my to-do Apart seas, all Kamailio modules are fully ugraded to new core - I started but lack of test env + busy summer resulted in delays - can be done during testing period, being just api updates. If you have discovered something else, let us know. Thanks, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ From miconda at gmail.com Mon Aug 24 12:24:26 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Mon, 24 Aug 2009 13:24:26 +0300 Subject: [sr-dev] are selects documented somewhere? In-Reply-To: References: <4A8D4E49.2010004@gmail.com> <4A8D4FF7.7040107@pernau.at> <4A8D5456.1020402@gmail.com> <4A8D6B09.1070001@gmail.com> Message-ID: <4A926A5A.9090504@gmail.com> Thanks, I used awk to generate listing in dokuwiki: http://sip-router.org/wiki/cookbooks/selects/devel#raw_list Cheers, Daniel On 24.08.2009 11:56 Uhr, Jan Janak wrote: > Attached is the select list. > > Jan. > > On Thu, Aug 20, 2009 at 5:35 PM, Jan Janak wrote: > >> On Thu, Aug 20, 2009 at 5:26 PM, Daniel-Constantin >> Mierla wrote: >> >>> Thanks Jan, the tool sounds interesting, however, the file you attached does >>> not include the selects ... or I overlooked something. >>> >> You are right, I overlooked this. I must have another file with just >> selects then because I remember generating it, I'll have a look >> tomorrow and get back to you. >> >> Jan. >> >> -- Daniel-Constantin Mierla * http://www.asipto.com/ From miconda at gmail.com Mon Aug 24 12:34:39 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Mon, 24 Aug 2009 13:34:39 +0300 Subject: [sr-dev] new PV class: $sel(name) Message-ID: <4A926CBF.1010702@gmail.com> Hello, there is a new PV class that provides access to SER select variables. A list with available selects can be found at: http://sip-router.org/wiki/cookbooks/selects/devel Therefore, all Kamailio modules relying on PV framework can get access to select values without any change. See example of usage from config at: http://sip-router.org/wiki/cookbooks/pseudo-variables/devel#selects Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ From martin.hoffmann at telio.ch Mon Aug 24 12:37:10 2009 From: martin.hoffmann at telio.ch (Martin Hoffmann) Date: Mon, 24 Aug 2009 12:37:10 +0200 Subject: [sr-dev] are selects documented somewhere? In-Reply-To: <4A926A5A.9090504@gmail.com> References: <4A8D4E49.2010004@gmail.com> <4A8D4FF7.7040107@pernau.at> <4A8D5456.1020402@gmail.com> <4A8D6B09.1070001@gmail.com> <4A926A5A.9090504@gmail.com> Message-ID: <20090824103710.GA12773@mlap.hq.telio.no> Daniel-Constantin Mierla wrote: > Thanks, I used awk to generate listing in dokuwiki: > http://sip-router.org/wiki/cookbooks/selects/devel#raw_list How do we procede from there? Should we keep the page in some format that allows magically adding new selects from ser_objdump output or do we just take it as a starter and happily modify away? Regards, Martin, who consideres spending some time on it -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From miconda at gmail.com Mon Aug 24 12:46:19 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Mon, 24 Aug 2009 13:46:19 +0300 Subject: [sr-dev] are selects documented somewhere? In-Reply-To: <20090824103710.GA12773@mlap.hq.telio.no> References: <4A8D4E49.2010004@gmail.com> <4A8D4FF7.7040107@pernau.at> <4A8D5456.1020402@gmail.com> <4A8D6B09.1070001@gmail.com> <4A926A5A.9090504@gmail.com> <20090824103710.GA12773@mlap.hq.telio.no> Message-ID: <4A926F7B.2030105@gmail.com> Hi Martin, On 24.08.2009 13:37 Uhr, Martin Hoffmann wrote: > Daniel-Constantin Mierla wrote: > >> Thanks, I used awk to generate listing in dokuwiki: >> http://sip-router.org/wiki/cookbooks/selects/devel#raw_list >> > > How do we procede from there? Should we keep the page in some format > that allows magically adding new selects from ser_objdump output or do > we just take it as a starter and happily modify away? > imo, would be good to have a read-only section where we can easily update from ser_objdump (or maybe a new dokuwiki page). It is why I wrote that adding details, examples, comments, a.s.o, should create a new entry in the section above: Selects Classes. Or, if developers commit to update the page once they add new selects, we can work directly on the list, merging the two sections. It is what we do in Kamailio side of PV/transformations - but there was no objdump tool for auto-generation, though. Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ From jh at tutpro.com Mon Aug 24 12:47:10 2009 From: jh at tutpro.com (Juha Heinanen) Date: Mon, 24 Aug 2009 13:47:10 +0300 Subject: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing In-Reply-To: <4A926529.5030307@gmail.com> References: <4A926529.5030307@gmail.com> Message-ID: <19090.28590.281902.881662@tutpro.com> Daniel-Constantin Mierla writes: > If you have discovered something else, let us know. well, just before your message i send a question to andrei about async (or delayed reply) support for t_uac_dlg. without that i'm not able to start using sip router, because having to use two xmlrpc management interfaces to manage one proxy is not acceptable to me. -- juha From ibc at aliax.net Mon Aug 24 12:49:07 2009 From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=) Date: Mon, 24 Aug 2009 12:49:07 +0200 Subject: [sr-dev] [SR-Users] kamailio 3.0 - the time before freezing In-Reply-To: <4A926529.5030307@gmail.com> References: <4A926529.5030307@gmail.com> Message-ID: 2009/8/24 Daniel-Constantin Mierla : > Hello everybody, > > during the last IRC devel meeting, we pinned end of summer to be the time to > enter testing phase for the new major release - codenamed kamailio 3.0. > > There was quite a lot of brand new features, considering that most of devel > effort was directed to integration. A try to collect new items is available > at: > > http://sip-router.org/wiki/features/new-in-devel Hi, I read: ----------------- script mode can be switched between ser compatible, kamailio compatible and max compatibility (compatible with both as much as possible), using #!SER #!KAMAILIO #!OPENSER #!ALL #!MAXCOMPAT ----------------- Is it a good approach? why not make it strict for a definitive syntax? (this will occur soon or late and when it occurs it will break config files with all these syntaxs). -- I?aki Baz Castillo From miconda at gmail.com Mon Aug 24 12:52:16 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Mon, 24 Aug 2009 13:52:16 +0300 Subject: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing In-Reply-To: <19090.28590.281902.881662@tutpro.com> References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> Message-ID: <4A9270E0.6080905@gmail.com> Hello, On 24.08.2009 13:47 Uhr, Juha Heinanen wrote: > Daniel-Constantin Mierla writes: > > > If you have discovered something else, let us know. > > well, just before your message i send a question to andrei about async > (or delayed reply) support for t_uac_dlg. without that i'm not able to > start using sip router, because having to use two xmlrpc management > interfaces to manage one proxy is not acceptable to me. > that is a new features for RPC interface in ser. Probably Andrei will do it if he committed to, but don't take my answer on his behalf, my knowledge about RPC interface is now very broad right now. You can still use one interface though - MI is fully available and does (pseudo) async xmlrpc commands. Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ From miconda at gmail.com Mon Aug 24 12:53:36 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Mon, 24 Aug 2009 13:53:36 +0300 Subject: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing In-Reply-To: <4A9270E0.6080905@gmail.com> References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> Message-ID: <4A927130.3080503@gmail.com> On 24.08.2009 13:52 Uhr, Daniel-Constantin Mierla wrote: > Hello, > > On 24.08.2009 13:47 Uhr, Juha Heinanen wrote: >> Daniel-Constantin Mierla writes: >> >> > If you have discovered something else, let us know. >> >> well, just before your message i send a question to andrei about async >> (or delayed reply) support for t_uac_dlg. without that i'm not able to >> start using sip router, because having to use two xmlrpc management >> interfaces to manage one proxy is not acceptable to me. >> > that is a new features for RPC interface in ser. Probably Andrei will > do it if he committed to, but don't take my answer on his behalf, my > knowledge about RPC interface > is now very broad right now. ^^^ is not very ... Daniel > > You can still use one interface though - MI is fully available and > does (pseudo) async xmlrpc commands. > > Cheers, > Daniel > -- Daniel-Constantin Mierla * http://www.asipto.com/ From jh at tutpro.com Mon Aug 24 12:58:22 2009 From: jh at tutpro.com (Juha Heinanen) Date: Mon, 24 Aug 2009 13:58:22 +0300 Subject: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing In-Reply-To: <4A9270E0.6080905@gmail.com> References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> Message-ID: <19090.29262.195063.958231@tutpro.com> Daniel-Constantin Mierla writes: > You can still use one interface though - MI is fully available and does > (pseudo) async xmlrpc commands. that is not true if you use modules from both s and k (like domain domain module, for example, that is much more advanced in s). besides, s xmlrpc interface is much better that k's, because it each call executes a config file route block, that allows (among other things) access control. -- juha From miconda at gmail.com Mon Aug 24 12:58:27 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Mon, 24 Aug 2009 13:58:27 +0300 Subject: [sr-dev] [SR-Users] kamailio 3.0 - the time before freezing In-Reply-To: References: <4A926529.5030307@gmail.com> Message-ID: <4A927253.3050401@gmail.com> Hello, On 24.08.2009 13:49 Uhr, I?aki Baz Castillo wrote: > 2009/8/24 Daniel-Constantin Mierla : > >> Hello everybody, >> >> during the last IRC devel meeting, we pinned end of summer to be the time to >> enter testing phase for the new major release - codenamed kamailio 3.0. >> >> There was quite a lot of brand new features, considering that most of devel >> effort was directed to integration. A try to collect new items is available >> at: >> >> http://sip-router.org/wiki/features/new-in-devel >> > > Hi, I read: > > ----------------- > script mode can be switched between ser compatible, kamailio > compatible and max compatibility (compatible with both as much as > possible), using > #!SER > #!KAMAILIO > #!OPENSER > #!ALL > #!MAXCOMPAT > ----------------- > > Is it a good approach? why not make it strict for a definitive syntax? > (this will occur soon or late and when it occurs it will break config > files with all these syntaxs). > this mechanism was introduced in the early phase of integration to provide support for eventual major conflicts. AFAIK we haven't run into a deadlock requiring selecting a specific mode. The Kamailio PVs overlapping in naming with SER AVPs was the most important case, solved by looking up first PV and if not found assume is avp using SER syntax. Andrei can correct me if I overlooked something. Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ From martin.hoffmann at telio.ch Mon Aug 24 13:01:40 2009 From: martin.hoffmann at telio.ch (Martin Hoffmann) Date: Mon, 24 Aug 2009 13:01:40 +0200 Subject: [sr-dev] are selects documented somewhere? In-Reply-To: <4A926F7B.2030105@gmail.com> References: <4A8D4E49.2010004@gmail.com> <4A8D4FF7.7040107@pernau.at> <4A8D5456.1020402@gmail.com> <4A8D6B09.1070001@gmail.com> <4A926A5A.9090504@gmail.com> <20090824103710.GA12773@mlap.hq.telio.no> <4A926F7B.2030105@gmail.com> Message-ID: <20090824110140.GE12773@mlap.hq.telio.no> Daniel-Constantin Mierla wrote: > > Or, if developers commit to update the page once they add new > selects, we can work directly on the list, merging the two sections. > It is what we do in Kamailio side of PV/transformations - but there > was no objdump tool for auto-generation, though. I think that would be nicer. How about this: I sit down and write a little script that takes the output from ser_objdump and either merges it accordingly or warns about missing selects. Regards, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From miconda at gmail.com Mon Aug 24 13:08:01 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Mon, 24 Aug 2009 14:08:01 +0300 Subject: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing In-Reply-To: <19090.29262.195063.958231@tutpro.com> References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> <19090.29262.195063.958231@tutpro.com> Message-ID: <4A927491.5030600@gmail.com> On 24.08.2009 13:58 Uhr, Juha Heinanen wrote: > Daniel-Constantin Mierla writes: > > > You can still use one interface though - MI is fully available and does > > (pseudo) async xmlrpc commands. > > that is not true if you use modules from both s and k (like domain > domain module, for example, that is much more advanced in s). > ok, I see. Solutions: - stress Andrei and/or other RPC devels :-) - add missing/needed MI commands to s modules I am considering merging sl module -- seems to be one preventing using easy some modules from both sides. > besides, s xmlrpc interface is much better that k's, because it each > call executes a config file route block, that allows (among other things) > access control. > With this one I agree. Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ From abalashov at evaristesys.com Mon Aug 24 13:14:11 2009 From: abalashov at evaristesys.com (Alex Balashov) Date: Mon, 24 Aug 2009 07:14:11 -0400 Subject: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing In-Reply-To: <4A927491.5030600@gmail.com> References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> <19090.29262.195063.958231@tutpro.com> <4A927491.5030600@gmail.com> Message-ID: <4A927603.8050209@evaristesys.com> Please be careful amidst all this to remember that this "integration" could be the undoing of the Kamailio/SR project, and may drive people to OpenSIPS. In the end, it is the users that matter. The sip-router.org documentation is already excessively complicated and difficult to understand for anyone who does not routinely work with both the K and S code. At this point, the documentation, while voluminous, is overwhelming and, in places, woefully incomplete, while in other places, I would say "exhaustively" (perhaps "exhaustingly") complete. All of this confusion - starting with the fundamental difference between K and SR, which nobody *I* know in the user community yet understands in any level of substance or detail - is starting to make OpenSIPS look very straightforward and self-evident. You don't want this. I also encounter the widespread perception from my customers that a lot of time has been spent on "fun" and "interesting" integration work, not on developing features or fixing bugs. I hope they're wrong. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 From miconda at gmail.com Mon Aug 24 13:14:52 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Mon, 24 Aug 2009 14:14:52 +0300 Subject: [sr-dev] are selects documented somewhere? In-Reply-To: <20090824110140.GE12773@mlap.hq.telio.no> References: <4A8D4E49.2010004@gmail.com> <4A8D4FF7.7040107@pernau.at> <4A8D5456.1020402@gmail.com> <4A8D6B09.1070001@gmail.com> <4A926A5A.9090504@gmail.com> <20090824103710.GA12773@mlap.hq.telio.no> <4A926F7B.2030105@gmail.com> <20090824110140.GE12773@mlap.hq.telio.no> Message-ID: <4A92762C.808@gmail.com> On 24.08.2009 14:01 Uhr, Martin Hoffmann wrote: > Daniel-Constantin Mierla wrote: > >> Or, if developers commit to update the page once they add new >> selects, we can work directly on the list, merging the two sections. >> It is what we do in Kamailio side of PV/transformations - but there >> was no objdump tool for auto-generation, though. >> > > I think that would be nicer. How about this: I sit down and write a > little script that takes the output from ser_objdump and either merges > it accordingly or warns about missing selects. > much better. Thanks, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ From ibc at aliax.net Mon Aug 24 13:32:27 2009 From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=) Date: Mon, 24 Aug 2009 13:32:27 +0200 Subject: [sr-dev] [SR-Users] [Kamailio-Users] kamailio 3.0 - the time before freezing In-Reply-To: <4A927603.8050209@evaristesys.com> References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> <19090.29262.195063.958231@tutpro.com> <4A927491.5030600@gmail.com> <4A927603.8050209@evaristesys.com> Message-ID: 2009/8/24 Alex Balashov : > Please be careful amidst all this to remember that this "integration" could > be the undoing of the Kamailio/SR project, and may drive people to OpenSIPS. > ?In the end, it is the users that matter. > > The sip-router.org documentation is already excessively complicated and > difficult to understand for anyone who does not routinely work with both the > K and S code. ?At this point, the documentation, while voluminous, is > overwhelming and, in places, woefully incomplete, while in other places, I > would say "exhaustively" (perhaps "exhaustingly") complete. > > All of this confusion - starting with the fundamental difference between K > and SR, which nobody *I* know in the user community yet understands in any > level of substance or detail - is starting to make OpenSIPS look very > straightforward and self-evident. ?You don't want this. > > I also encounter the widespread perception from my customers that a lot of > time has been spent on "fun" and "interesting" integration work, not on > developing features or fixing bugs. ?I hope they're wrong. I must agree with Alex. Sincerely I will wait until SR is really released to start with it. And with "really released" I mean: when both kamailio and SER concepts disapear entirely from SR (no more K/S-modules, K/S-functions, K/S-components, K/S-pseudovariables, no more compability features and so on). What I don't understand is the reasons to make current SR working with K and S features/modules compatibility. We don't need a SR working solution right now (since Kamailio and SER do exist), do we?. Wouldn't be better to spent devel time in porting the required K/S modules to SR instead of making them working as K/S modules in any way? Please, don't take me wrong, I just wonder what's the rush to have a SR working instead of having a real an independent SR release :) -- I?aki Baz Castillo From miconda at gmail.com Mon Aug 24 13:43:24 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Mon, 24 Aug 2009 14:43:24 +0300 Subject: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing In-Reply-To: <4A927603.8050209@evaristesys.com> References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> <19090.29262.195063.958231@tutpro.com> <4A927491.5030600@gmail.com> <4A927603.8050209@evaristesys.com> Message-ID: <4A927CDC.9040302@gmail.com> Hello, On 24.08.2009 14:14 Uhr, Alex Balashov wrote: > The sip-router.org documentation is already excessively complicated > and difficult to understand for anyone who does not routinely work > with both the K and S code. At this point, the documentation, while > voluminous, is overwhelming and, in places, woefully incomplete, can you point such places? > while in other places, I would say "exhaustively" (perhaps > "exhaustingly") complete. From K point of view, same documentation is available, the core, pv and transformations cookbooks are updated completely -- actually only core cookbook needed a major update since we had a lot of new parameters for dns, transport layers, etc... > > All of this confusion - starting with the fundamental difference > between K and SR, which nobody *I* know in the user community yet > understands in any level of substance or detail Kamailio is the same -- will be a new major release of the sip server everybody know so far -- new features in core plus some new modules, either new development (memcache) or imported from ser (iptrtproxy). To update from kamailio 1.5 to 3.0 you will need, as usual, some db structure updates (not much afaik - lcr module, maybe cr) and some updates to config file syntax (minimal as well for most of usage cases). Your questions can be rephrased as "what is the difference between linux and debian?". Debian is just a particular packaging of available linux applications. In similar way, Kamailio, is SR core plus selection of SR modules. Like in linux, where are application that overlap in functionality, and one is preferred over the others (e.g., MTA), in SR there are modules that overlap (e.g., auth) using a different concept/database structure and one is preferred to the other. > I also encounter the widespread perception from my customers that a > lot of time has been spent on "fun" I would have liked some fun, but there wasn't, not for me, very interesting perception I would say, maybe you can point me such cases. It was quite heavy work. The goal of trying to preserve max compatibility while not messing up a lot of code in core was achieved - the core impact was kept minimal, therefore inheriting stability from ser 2.0. Several modules took the load of extra features. > and "interesting" integration work, not on developing features or > fixing bugs. I hope they're wrong. What are the bugs staying unfixed? What are missing features not adopted? There was quite a lot of new development, including transport layer such as sctp, asyncronous message processing (t_suspend/t_continue which is functional), continuing with new modules (link provided in previous email). Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ From abalashov at evaristesys.com Mon Aug 24 13:44:21 2009 From: abalashov at evaristesys.com (Alex Balashov) Date: Mon, 24 Aug 2009 07:44:21 -0400 Subject: [sr-dev] [SR-Users] [Kamailio-Users] kamailio 3.0 - the time before freezing In-Reply-To: References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> <19090.29262.195063.958231@tutpro.com> <4A927491.5030600@gmail.com> <4A927603.8050209@evaristesys.com> Message-ID: <4A927D15.7010407@evaristesys.com> I?aki Baz Castillo wrote: > What I don't understand is the reasons to make current SR working with > K and S features/modules compatibility. We don't need a SR working > solution right now (since Kamailio and SER do exist), do we?. Wouldn't > be better to spent devel time in porting the required K/S modules to > SR instead of making them working as K/S modules in any way? I think the idea is that SR is a common layer - sort of like a kernel - from which subsequent features are derived in both K and S. What this fails to explain in any way is what the intended applications of K vs. SR are from an end-user perspective. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 From jh at tutpro.com Mon Aug 24 13:46:15 2009 From: jh at tutpro.com (Juha Heinanen) Date: Mon, 24 Aug 2009 14:46:15 +0300 Subject: [sr-dev] [SR-Users] [Kamailio-Users] kamailio 3.0 - the time before freezing In-Reply-To: References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> <19090.29262.195063.958231@tutpro.com> <4A927491.5030600@gmail.com> <4A927603.8050209@evaristesys.com> Message-ID: <19090.32135.480823.124439@tutpro.com> I?aki Baz Castillo writes: > What I don't understand is the reasons to make current SR working with > K and S features/modules compatibility. We don't need a SR working > solution right now (since Kamailio and SER do exist), do we?. Wouldn't > be better to spent devel time in porting the required K/S modules to > SR instead of making them working as K/S modules in any way? this is exactly how i also like it to be and which was discussed a couple of months ago on the mailing list. i would have liked to have sip-router, not k or s version of it, but officially it didn't go that way. -- juha From abalashov at evaristesys.com Mon Aug 24 13:48:21 2009 From: abalashov at evaristesys.com (Alex Balashov) Date: Mon, 24 Aug 2009 07:48:21 -0400 Subject: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing In-Reply-To: <4A927CDC.9040302@gmail.com> References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> <19090.29262.195063.958231@tutpro.com> <4A927491.5030600@gmail.com> <4A927603.8050209@evaristesys.com> <4A927CDC.9040302@gmail.com> Message-ID: <4A927E05.7070401@evaristesys.com> Daniel-Constantin Mierla wrote: > Hello, > > On 24.08.2009 14:14 Uhr, Alex Balashov wrote: >> The sip-router.org documentation is already excessively complicated >> and difficult to understand for anyone who does not routinely work >> with both the K and S code. At this point, the documentation, while >> voluminous, is overwhelming and, in places, woefully incomplete, > > can you point such places? Yes, I will review it and make a list. >> while in other places, I would say "exhaustively" (perhaps >> "exhaustingly") complete. > > From K point of view, same documentation is available, the core, pv and > transformations cookbooks are updated completely -- actually only core > cookbook needed a major update since we had a lot of new parameters for > dns, transport layers, etc... That's good to know. Half the problem is that people who don't know this scour all the documentation in an attempt to gain a holistic grasp of what the changes are, whether or not there are any. > Your questions can be rephrased as "what is the difference between linux > and debian?". Debian is just a particular packaging of available linux > applications. In similar way, Kamailio, is SR core plus selection of SR > modules. Like in linux, where are application that overlap in > functionality, and one is preferred over the others (e.g., MTA), in SR > there are modules that overlap (e.g., auth) using a different > concept/database structure and one is preferred to the other. I already understood this. The question is - why would one be preferred to the other, from a practical perspective? What are the substantive differences? >> I also encounter the widespread perception from my customers that a >> lot of time has been spent on "fun" > > I would have liked some fun, but there wasn't, not for me, very > interesting perception I would say, maybe you can point me such cases. > It was quite heavy work. The goal of trying to preserve max > compatibility while not messing up a lot of code in core was achieved - > the core impact was kept minimal, therefore inheriting stability from > ser 2.0. Several modules took the load of extra features. It's not my perception. >> and "interesting" integration work, not on developing features or >> fixing bugs. I hope they're wrong. > What are the bugs staying unfixed? What are missing features not > adopted? There was quite a lot of new development, including transport > layer such as sctp, asyncronous message processing (t_suspend/t_continue > which is functional), continuing with new modules (link provided in > previous email). As I said, not my perception, so I personally cannot answer any of that. I personally see a lot of new and interesting features and a fair bit of stability. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 From martin.hoffmann at telio.ch Mon Aug 24 13:51:20 2009 From: martin.hoffmann at telio.ch (Martin Hoffmann) Date: Mon, 24 Aug 2009 13:51:20 +0200 Subject: [sr-dev] [SR-Users] [Kamailio-Users] kamailio 3.0 - the time before freezing In-Reply-To: <4A927D15.7010407@evaristesys.com> References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> <19090.29262.195063.958231@tutpro.com> <4A927491.5030600@gmail.com> <4A927603.8050209@evaristesys.com> <4A927D15.7010407@evaristesys.com> Message-ID: <20090824115120.GA1811@mlap.hq.telio.no> Alex Balashov wrote: > > What this fails to explain in any way is what the intended > applications of K vs. SR are from an end-user perspective. There is quite some substantial differences between SER 2.x and Kamailio. However, they are at a level further up -- most importantly completely different database schemas. Thus it makes sense to merge the core, which is mostly compatible between SER and Kamailio, and make two different bundles that allow people coming from Kamailio to continue using their tested and proven configs and the same for people using SER. Eventually, the difference will go away, but for starters this really is the smartest way to get people to use SIP Router -- without them actually knowing it. Regards, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From abalashov at evaristesys.com Mon Aug 24 13:54:29 2009 From: abalashov at evaristesys.com (Alex Balashov) Date: Mon, 24 Aug 2009 07:54:29 -0400 Subject: [sr-dev] [SR-Users] [Kamailio-Users] kamailio 3.0 - the time before freezing In-Reply-To: <20090824115120.GA1811@mlap.hq.telio.no> References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> <19090.29262.195063.958231@tutpro.com> <4A927491.5030600@gmail.com> <4A927603.8050209@evaristesys.com> <4A927D15.7010407@evaristesys.com> <20090824115120.GA1811@mlap.hq.telio.no> Message-ID: <4A927F75.3010707@evaristesys.com> Martin Hoffmann wrote: > Alex Balashov wrote: >> What this fails to explain in any way is what the intended >> applications of K vs. SR are from an end-user perspective. > > There is quite some substantial differences between SER 2.x and > Kamailio. However, they are at a level further up -- most importantly > completely different database schemas. Thus it makes sense to merge the > core, which is mostly compatible between SER and Kamailio, and make two > different bundles that allow people coming from Kamailio to continue > using their tested and proven configs and the same for people using SER. > > Eventually, the difference will go away, but for starters this really is > the smartest way to get people to use SIP Router -- without them > actually knowing it. Perhaps. But, building in a mandatory premise of (nontrivial) future change as part of "eventually, the difference will go away" is not attractive. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 From jh at tutpro.com Mon Aug 24 13:54:59 2009 From: jh at tutpro.com (Juha Heinanen) Date: Mon, 24 Aug 2009 14:54:59 +0300 Subject: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing In-Reply-To: <4A927CDC.9040302@gmail.com> References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> <19090.29262.195063.958231@tutpro.com> <4A927491.5030600@gmail.com> <4A927603.8050209@evaristesys.com> <4A927CDC.9040302@gmail.com> Message-ID: <19090.32659.565550.421581@tutpro.com> Daniel-Constantin Mierla writes: > Kamailio is the same -- will be a new major release of the sip server > everybody know so far -- new features in core plus some new modules, > either new development (memcache) or imported from ser (iptrtproxy). To > update from kamailio 1.5 to 3.0 you will need, as usual, some db > structure updates (not much afaik - lcr module, maybe cr) and some > updates to config file syntax (minimal as well for most of usage > cases). how about kamctl? i don't find it in sip-router source. i understand that it is now replaced by serctl. if what you say in above would be true, there would still be also kamctl that is an important part of k. better if there would be just sip-router with srctl to control it. -- juha From miconda at gmail.com Mon Aug 24 14:05:34 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Mon, 24 Aug 2009 15:05:34 +0300 Subject: [sr-dev] [SR-Users] [Kamailio-Users] kamailio 3.0 - the time before freezing In-Reply-To: References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> <19090.29262.195063.958231@tutpro.com> <4A927491.5030600@gmail.com> <4A927603.8050209@evaristesys.com> Message-ID: <4A92820E.50301@gmail.com> On 24.08.2009 14:32 Uhr, I?aki Baz Castillo wrote: > I must agree with Alex. > Sincerely I will wait until SR is really released to start with it. > And with "really released" I mean: when both kamailio and SER concepts > disapear entirely from SR (no more K/S-modules, K/S-functions, > K/S-components, K/S-pseudovariables, no more compability features and > so on). > Well, this is not easy as you may think. Even easier from coding point of view, the management of any relevant project around the world has to take in consideration backward compatibility and easy upgrades. I am personally aware of companies using Kamailio with several millions of subscribers, using kamailio database schema. Also, I am aware of companies having more or less same level of subscriber base using SER database schema. All have additional tools for management, integration with third-party application, a.s.o. Do you think that saying "hey, you were the unlucky bastard because we are going to drop tomorrow the database schema you are using" is the solution? > What I don't understand is the reasons to make current SR working with > K and S features/modules compatibility. We don't need a SR working > solution right now (since Kamailio and SER do exist), do we? Maybe not you, but there are others. I am facing many troubles because of TCP (also TLS) layer in K which do not happen with SR core - asynchronous TCP helps a lot. I use memcache and plan to move all server to server communication to SCTP for reliability and HA. Using asynchronous processing (t_suspend/t_continue) I am able to get a very scalable routing and billing engine (prepaid) which is no way possible with other technologies. > . Wouldn't > be better to spent devel time in porting the required K/S modules to > SR instead of making them working as K/S modules in any way? > All (but seas) are ported. There is nothing else to port, just some overlapping (read conflicting) from functionality/database structure point of view. You can do your Inakilio SIP server using ser auth module and kamailio location/presence modules if that suits better. Kamailio has to provide to its users of version 1.5.x a new release on the same line of modules. Cheers, Daniel > Please, don't take me wrong, I just wonder what's the rush to have a > SR working instead of having a real an independent SR release :) > -- Daniel-Constantin Mierla * http://www.asipto.com/ From miconda at gmail.com Mon Aug 24 14:07:40 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Mon, 24 Aug 2009 15:07:40 +0300 Subject: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing In-Reply-To: <19090.32659.565550.421581@tutpro.com> References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> <19090.29262.195063.958231@tutpro.com> <4A927491.5030600@gmail.com> <4A927603.8050209@evaristesys.com> <4A927CDC.9040302@gmail.com> <19090.32659.565550.421581@tutpro.com> Message-ID: <4A92828C.3050501@gmail.com> On 24.08.2009 14:54 Uhr, Juha Heinanen wrote: > Daniel-Constantin Mierla writes: > > > Kamailio is the same -- will be a new major release of the sip server > > everybody know so far -- new features in core plus some new modules, > > either new development (memcache) or imported from ser (iptrtproxy). To > > update from kamailio 1.5 to 3.0 you will need, as usual, some db > > structure updates (not much afaik - lcr module, maybe cr) and some > > updates to config file syntax (minimal as well for most of usage > > cases). > > how about kamctl? i don't find it in sip-router source. i understand > that it is now replaced by serctl. if what you say in above would be > true, there would still be also kamctl that is an important part of k. > kamctl is in sip-router, check tools directory. > better if there would be just sip-router with srctl to control it. > You are more than welcome to implement the srctl, I am going to contribute if I am able to and use it. Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ From abalashov at evaristesys.com Mon Aug 24 14:08:39 2009 From: abalashov at evaristesys.com (Alex Balashov) Date: Mon, 24 Aug 2009 08:08:39 -0400 Subject: [sr-dev] [SR-Users] [Kamailio-Users] kamailio 3.0 - the time before freezing In-Reply-To: <4A92820E.50301@gmail.com> References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> <19090.29262.195063.958231@tutpro.com> <4A927491.5030600@gmail.com> <4A927603.8050209@evaristesys.com> <4A92820E.50301@gmail.com> Message-ID: <4A9282C7.5020101@evaristesys.com> Daniel-Constantin Mierla wrote: > I am personally aware of companies using Kamailio with several millions > of subscribers, using kamailio database schema. Also, I am aware of > companies having more or less same level of subscriber base using SER > database schema. All have additional tools for management, integration > with third-party application, a.s.o. Do you think that saying "hey, you > were the unlucky bastard because we are going to drop tomorrow the > database schema you are using" is the solution? That's true. We can say that there should be one unified code body all we want, but, at the very least we need to acknowledge that the problem is not nearly as simple as it looks on the surface. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 From jh at tutpro.com Mon Aug 24 14:14:30 2009 From: jh at tutpro.com (Juha Heinanen) Date: Mon, 24 Aug 2009 15:14:30 +0300 Subject: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing In-Reply-To: <4A92828C.3050501@gmail.com> References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> <19090.29262.195063.958231@tutpro.com> <4A927491.5030600@gmail.com> <4A927603.8050209@evaristesys.com> <4A927CDC.9040302@gmail.com> <19090.32659.565550.421581@tutpro.com> <4A92828C.3050501@gmail.com> Message-ID: <19090.33830.476206.628891@tutpro.com> Daniel-Constantin Mierla writes: > kamctl is in sip-router, check tools directory. ok, i looked at scripts dir where it used to be in k. > You are more than welcome to implement the srctl, I am going to > contribute if I am able to and use it. srctl sort of exists already, but is is called serctl. -- juha From miconda at gmail.com Mon Aug 24 14:54:31 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Mon, 24 Aug 2009 15:54:31 +0300 Subject: [sr-dev] [Kamailio-Users] [SR-Users] kamailio 3.0 - the time before freezing In-Reply-To: <4A9282C7.5020101@evaristesys.com> References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> <19090.29262.195063.958231@tutpro.com> <4A927491.5030600@gmail.com> <4A927603.8050209@evaristesys.com> <4A92820E.50301@gmail.com> <4A9282C7.5020101@evaristesys.com> Message-ID: <4A928D87.6030008@gmail.com> On 24.08.2009 15:08 Uhr, Alex Balashov wrote: > Daniel-Constantin Mierla wrote: > >> I am personally aware of companies using Kamailio with several >> millions of subscribers, using kamailio database schema. Also, I am >> aware of companies having more or less same level of subscriber base >> using SER database schema. All have additional tools for management, >> integration with third-party application, a.s.o. Do you think that >> saying "hey, you were the unlucky bastard because we are going to >> drop tomorrow the database schema you are using" is the solution? > > That's true. > > We can say that there should be one unified code if you refer to merging "duplicated" modules, could not be a solution anyhow. In the past, there were some events generating hot discussions when trying to force/limit to one way of doing things. The preliminary discussions for sip router project concluded that there must be freedom of contributors with fair control of original developer. Core, tm are sensitive parts and so called "common layer" where any piece of code getting in is carefully reviewed. Otherwise, if there is a conflict in licensing, between developers of same piece of code, creating a new module/library is the way to go. This does not mean everyone can spin off new modules, but if the contribution is relevant, has support from community members, it must get in. I see no reason of having modules for same functionality (e.g., say authentication) as long as each such module has maintainers. Time should prove which is better and obsolete the others, but also, each could be more suitable for a particular case. Just as a different example, sqlops plus some scripting could obsolete most of db-connected modules - auth_db, alias_db, speeddial, uri_db, a.s.o, but doing so is not at all a good decision. > body all we want, but, at the very least we need to acknowledge that > the problem is not nearly as simple as it looks on the surface. > Nothing is simple :-) . Also, I admit that any integration work rises controversy, which may create some degree of confusion. But all discussions were constructive so far, nothing was dismissed and the way things blended so far proves the flexibility level we achieved: keep the core and tm small and stable, build around with modules and libraries so that the impact is minimal for those not using the stuff that just got in. From my point of view, integration went smooth, but with higher work volume that anticipated, since both projects really had a lot of new features (some better documented, some not). Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ From miconda at gmail.com Mon Aug 24 14:57:57 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Mon, 24 Aug 2009 15:57:57 +0300 Subject: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing In-Reply-To: <19090.33830.476206.628891@tutpro.com> References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> <19090.29262.195063.958231@tutpro.com> <4A927491.5030600@gmail.com> <4A927603.8050209@evaristesys.com> <4A927CDC.9040302@gmail.com> <19090.32659.565550.421581@tutpro.com> <4A92828C.3050501@gmail.com> <19090.33830.476206.628891@tutpro.com> Message-ID: <4A928E55.5080404@gmail.com> On 24.08.2009 15:14 Uhr, Juha Heinanen wrote: > Daniel-Constantin Mierla writes: > > > kamctl is in sip-router, check tools directory. > > ok, i looked at scripts dir where it used to be in k. > > > You are more than welcome to implement the srctl, I am going to > > contribute if I am able to and use it. > > srctl sort of exists already, but is is called serctl. > :-) -- ahh, yes, imo, srctl sort of exists already, but is called kamctl. Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ From ibc at aliax.net Mon Aug 24 14:57:21 2009 From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=) Date: Mon, 24 Aug 2009 14:57:21 +0200 Subject: [sr-dev] [SR-Users] [Kamailio-Users] kamailio 3.0 - the time before freezing In-Reply-To: <4A92820E.50301@gmail.com> References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> <19090.29262.195063.958231@tutpro.com> <4A927491.5030600@gmail.com> <4A927603.8050209@evaristesys.com> <4A92820E.50301@gmail.com> Message-ID: 2009/8/24 Daniel-Constantin Mierla : > I am personally aware of companies using Kamailio with several millions of > subscribers, using kamailio database schema. Also, I am aware of companies > having more or less same level of subscriber base using SER database schema. > All have additional tools for management, integration with third-party > application, a.s.o. Do you think that saying "hey, you were the unlucky > bastard because we are going to drop tomorrow the database schema you are > using" is the solution? That's right, but I don't expect that migration to SR is a priority for those companies already using OpenSER/Kamailio. For example, I know some companies still using OpenSer 1.2. However, it seems that the idea is that Kamailio/SER will use SR as core, but the fact is that SR core uses current Kamailio and SER modules/features as separate (modules_k, modules_s...). Wouldn't make sense to unify SR code instead of having it splited in K and S? AFAIK this is the idea for a future, but in the meanwhile I don't fully understand why SR requires to run right now as it is. >> What I don't understand is the reasons to make current SR working with >> K and S features/modules compatibility. We don't need a SR working >> solution right now (since Kamailio and SER do exist), do we? > > Maybe not you, but there are others. I am facing many troubles because of > TCP (also TLS) layer in K which do not happen with SR core - asynchronous > TCP helps a lot. Sure that's a good reason :) But again you are speaking about Kamailio using SR as core (new and improved TM module) while I meant SR code itself (which for now is a mostly separate mix between K and S code instead of an unified technology). > All (but seas) are ported. Perhaps I understand it wrongly, but IMHO the modules will be really ported when there is a unique MI interface for all of them (instead of having to use K MI for K modules and S MI for S modules), when there are just an unique class of pseudovariables (instead of having K and S pvs)... Regards. -- I?aki Baz Castillo From jh at tutpro.com Mon Aug 24 15:05:24 2009 From: jh at tutpro.com (Juha Heinanen) Date: Mon, 24 Aug 2009 16:05:24 +0300 Subject: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing In-Reply-To: <4A928E55.5080404@gmail.com> References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> <19090.29262.195063.958231@tutpro.com> <4A927491.5030600@gmail.com> <4A927603.8050209@evaristesys.com> <4A927CDC.9040302@gmail.com> <19090.32659.565550.421581@tutpro.com> <4A92828C.3050501@gmail.com> <19090.33830.476206.628891@tutpro.com> <4A928E55.5080404@gmail.com> Message-ID: <19090.36884.426541.311620@tutpro.com> Daniel-Constantin Mierla writes: > :-) -- ahh, yes, imo, srctl sort of exists already, but is called > kamctl. are you saying that one can control s modules with kamctl? i know that one can control both s and k modules with serctl (except for async t_uac_dlg). -- juha From miconda at gmail.com Mon Aug 24 15:24:55 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Mon, 24 Aug 2009 16:24:55 +0300 Subject: [sr-dev] [Kamailio-Users] [SR-Users] kamailio 3.0 - the time before freezing In-Reply-To: References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> <19090.29262.195063.958231@tutpro.com> <4A927491.5030600@gmail.com> <4A927603.8050209@evaristesys.com> <4A92820E.50301@gmail.com> Message-ID: <4A9294A7.8000500@gmail.com> On 24.08.2009 15:57 Uhr, I?aki Baz Castillo wrote: > 2009/8/24 Daniel-Constantin Mierla : > > >> I am personally aware of companies using Kamailio with several millions of >> subscribers, using kamailio database schema. Also, I am aware of companies >> having more or less same level of subscriber base using SER database schema. >> All have additional tools for management, integration with third-party >> application, a.s.o. Do you think that saying "hey, you were the unlucky >> bastard because we are going to drop tomorrow the database schema you are >> using" is the solution? >> > > That's right, but I don't expect that migration to SR is a priority > for those companies already using OpenSER/Kamailio. For example, I > know some companies still using OpenSer 1.2. > yes, I do, even older, I have a ser 0.9.4 somewhere and no plan to upgrade it. It has 1 year 4 months without restart. > However, it seems that the idea is that Kamailio/SER will use SR as > core, but the fact is that SR core uses current Kamailio and SER > modules/features as separate (modules_k, modules_s...). some modules were moved under "modules" directory. The ones that have names overlapping and inter-dependencies are going to stay in separate directories. > Wouldn't make > sense to unify SR code instead of having it splited in K and S? probably you misunderstood something. The code is unified, but SR has support to hold modules in more than one directory. Now the structure is based on origin (again, the reason is name overlapping), but in the future could be: modules_presence modules_db IIRC, there are over 150 modules all together, so better structuring might be necessary. > AFAIK > this is the idea for a future, but in the meanwhile I don't fully > understand why SR requires to run right now as it is. > > > >>> What I don't understand is the reasons to make current SR working with >>> K and S features/modules compatibility. We don't need a SR working >>> solution right now (since Kamailio and SER do exist), do we? >>> >> Maybe not you, but there are others. I am facing many troubles because of >> TCP (also TLS) layer in K which do not happen with SR core - asynchronous >> TCP helps a lot. >> > > Sure that's a good reason :) > But again you are speaking about Kamailio using SR as core (new and > improved TM module) while I meant SR code itself (which for now is a > mostly separate mix between K and S code instead of an unified > technology). > I don't get it. Maybe you can rephrase/detail what is misleading/confusing you. The existence of 3 module directories? Everything is unified, one source repository, one project, if you think just to SR environment. >> All (but seas) are ported. >> > > Perhaps I understand it wrongly, but IMHO the modules will be really > ported when there is a unique MI interface for all of them (instead of > having to use K MI for K modules and S MI for S modules), Using RPC interface gives access to MI commands -- so ser guys are the first lucky :-). However, let's get back to the root: - there are modules implementing MI - there are modules implementing RPC interface - there are modules implementing none - there might be modules implementing both Where to position a module is just a matter of developers. Similar choise is for regular expressions - use posix or pcre library - database - use interface v1 or v2 (which has prepared statements support) - and examples can continue. I see ability to choose a great feature. > when there > are just an unique class of pseudovariables (instead of having K and S > pvs)... > Here is only one: config file variables - how they are referred in mails is a different story, to better indentify and reflex origin, but all can be used in config file. Actually, the group referred K PVs have classes. Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ From abalashov at evaristesys.com Mon Aug 24 15:29:27 2009 From: abalashov at evaristesys.com (Alex Balashov) Date: Mon, 24 Aug 2009 09:29:27 -0400 Subject: [sr-dev] [Kamailio-Users] [SR-Users] kamailio 3.0 - the time before freezing In-Reply-To: <4A928D87.6030008@gmail.com> References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> <19090.29262.195063.958231@tutpro.com> <4A927491.5030600@gmail.com> <4A927603.8050209@evaristesys.com> <4A92820E.50301@gmail.com> <4A9282C7.5020101@evaristesys.com> <4A928D87.6030008@gmail.com> Message-ID: <4A9295B7.6080208@evaristesys.com> Daniel-Constantin Mierla wrote: > Just as a different example, sqlops plus some scripting could obsolete > most of db-connected modules - auth_db, alias_db, speeddial, uri_db, > a.s.o, but doing so is not at all a good decision. In the case of my implementations, I have to do this quite frequently because I do custom integration projects that incorporate specific providers' sometimes very esoteric business logic. The sqlops module was one of the best things to ever have happened to Kamailio, and I am very thankful for it. My understanding is that the argument for using a native DB-connected module boils down to the fact that most of these modules do some sort of in-memory caching and/or buffering of large data sets, and use data structures and search algorithms that are appropriate to the nature of that data. So, this results in much faster processing with less overhead and, of course, less database load. I try to use them whenever possible. But sometimes it is not, which is why I am very grateful for the thought that went into creating parameters like this: http://www.kamailio.org/docs/modules/1.5.x/auth.html#id2505013 -- Alex -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 From miconda at gmail.com Mon Aug 24 15:34:41 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Mon, 24 Aug 2009 16:34:41 +0300 Subject: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing In-Reply-To: <19090.36884.426541.311620@tutpro.com> References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> <19090.29262.195063.958231@tutpro.com> <4A927491.5030600@gmail.com> <4A927603.8050209@evaristesys.com> <4A927CDC.9040302@gmail.com> <19090.32659.565550.421581@tutpro.com> <4A92828C.3050501@gmail.com> <19090.33830.476206.628891@tutpro.com> <4A928E55.5080404@gmail.com> <19090.36884.426541.311620@tutpro.com> Message-ID: <4A9296F1.108@gmail.com> On 24.08.2009 16:05 Uhr, Juha Heinanen wrote: > Daniel-Constantin Mierla writes: > > > :-) -- ahh, yes, imo, srctl sort of exists already, but is called > > kamctl. > > are you saying that one can control s modules with kamctl? i know that > one can control both s and k modules with serctl (except for async > t_uac_dlg). > i don't think serctl can add K users nor do other K management commands. serctl (actually I refer to sercmd since I have no idea about serctl) does RPC commands and since I added the mi_rpc command you can invoke a MI command via RPC. Never tried, but see: http://sip-router.org/docbook/sip-router/branch/master/modules_s/ctl/ctl.html#fifo kamctl implements that kind of communication proto. Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ From miconda at gmail.com Mon Aug 24 15:37:55 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Mon, 24 Aug 2009 16:37:55 +0300 Subject: [sr-dev] [Kamailio-Users] [SR-Users] kamailio 3.0 - the time before freezing In-Reply-To: <4A9295B7.6080208@evaristesys.com> References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> <19090.29262.195063.958231@tutpro.com> <4A927491.5030600@gmail.com> <4A927603.8050209@evaristesys.com> <4A92820E.50301@gmail.com> <4A9282C7.5020101@evaristesys.com> <4A928D87.6030008@gmail.com> <4A9295B7.6080208@evaristesys.com> Message-ID: <4A9297B3.1020903@gmail.com> On 24.08.2009 16:29 Uhr, Alex Balashov wrote: > Daniel-Constantin Mierla wrote: > >> Just as a different example, sqlops plus some scripting could >> obsolete most of db-connected modules - auth_db, alias_db, speeddial, >> uri_db, a.s.o, but doing so is not at all a good decision. > > In the case of my implementations, I have to do this quite frequently > because I do custom integration projects that incorporate specific > providers' sometimes very esoteric business logic. The sqlops module > was one of the best things to ever have happened to Kamailio, and I am > very thankful for it. > > My understanding is that the argument for using a native DB-connected > module boils down to the fact that most of these modules do some sort > of in-memory caching and/or buffering of large data sets, and use data > structures and search algorithms that are appropriate to the nature of > that data. So, this results in much faster processing with less > overhead and, of course, less database load. No, no caching for above mentioned modules. They simply hide a db query in most of the cases. They are supposed to deal with quite large volume of records where caching makes no sense. So you do not loose any performance by using sqlops. You can check with benchmark module. Cheers, Daniel > > I try to use them whenever possible. But sometimes it is not, which > is why I am very grateful for the thought that went into creating > parameters like this: > > http://www.kamailio.org/docs/modules/1.5.x/auth.html#id2505013 > > -- Alex > -- Daniel-Constantin Mierla * http://www.asipto.com/ From abalashov at evaristesys.com Mon Aug 24 15:47:41 2009 From: abalashov at evaristesys.com (Alex Balashov) Date: Mon, 24 Aug 2009 09:47:41 -0400 Subject: [sr-dev] [Kamailio-Users] [SR-Users] kamailio 3.0 - the time before freezing In-Reply-To: <4A9297B3.1020903@gmail.com> References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> <19090.29262.195063.958231@tutpro.com> <4A927491.5030600@gmail.com> <4A927603.8050209@evaristesys.com> <4A92820E.50301@gmail.com> <4A9282C7.5020101@evaristesys.com> <4A928D87.6030008@gmail.com> <4A9295B7.6080208@evaristesys.com> <4A9297B3.1020903@gmail.com> Message-ID: <4A9299FD.3060900@evaristesys.com> Daniel-Constantin Mierla wrote: > No, no caching for above mentioned modules. They simply hide a db query > in most of the cases. They are supposed to deal with quite large volume > of records where caching makes no sense. So you do not loose any > performance by using sqlops. You can check with benchmark module. Well, maybe not the above-mentioned modules, but certainly some. Otherwise, why all the db_mode parameters? I am thinking here of: http://www.kamailio.org/docs/modules/1.5.x/dialog.html#id2491994 http://www.kamailio.org/docs/modules/1.5.x/carrierroute.html#id2511124 http://www.kamailio.org/docs/modules/1.5.x/usrloc.html#id2508613 Unless I am misunderstanding these parameters, it seems to me that there is some performance benefit to using a module with database backing versus beyond just a wrapper for the queries? -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 From miconda at gmail.com Mon Aug 24 15:53:56 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Mon, 24 Aug 2009 16:53:56 +0300 Subject: [sr-dev] [Kamailio-Users] [SR-Users] kamailio 3.0 - the time before freezing In-Reply-To: <4A9299FD.3060900@evaristesys.com> References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> <19090.29262.195063.958231@tutpro.com> <4A927491.5030600@gmail.com> <4A927603.8050209@evaristesys.com> <4A92820E.50301@gmail.com> <4A9282C7.5020101@evaristesys.com> <4A928D87.6030008@gmail.com> <4A9295B7.6080208@evaristesys.com> <4A9297B3.1020903@gmail.com> <4A9299FD.3060900@evaristesys.com> Message-ID: <4A929B74.3020607@gmail.com> On 24.08.2009 16:47 Uhr, Alex Balashov wrote: > Daniel-Constantin Mierla wrote: > >> No, no caching for above mentioned modules. They simply hide a db >> query in most of the cases. They are supposed to deal with quite >> large volume of records where caching makes no sense. So you do not >> loose any performance by using sqlops. You can check with benchmark >> module. > > Well, maybe not the above-mentioned modules, but certainly some. definitely, yes! Cheers, Daniel > Otherwise, why all the db_mode parameters? > > I am thinking here of: > > http://www.kamailio.org/docs/modules/1.5.x/dialog.html#id2491994 > http://www.kamailio.org/docs/modules/1.5.x/carrierroute.html#id2511124 > http://www.kamailio.org/docs/modules/1.5.x/usrloc.html#id2508613 > > Unless I am misunderstanding these parameters, it seems to me that > there is some performance benefit to using a module with database > backing versus beyond just a wrapper for the queries? > -- Daniel-Constantin Mierla * http://www.asipto.com/ From klaus.mailinglists at pernau.at Mon Aug 24 16:26:30 2009 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Mon, 24 Aug 2009 16:26:30 +0200 Subject: [sr-dev] [SR-Users] [Kamailio-Users] kamailio 3.0 - the time before freezing In-Reply-To: References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> <19090.29262.195063.958231@tutpro.com> <4A927491.5030600@gmail.com> <4A927603.8050209@evaristesys.com> <4A92820E.50301@gmail.com> Message-ID: <4A92A316.8030407@pernau.at> I?aki Baz Castillo schrieb: > 2009/8/24 Daniel-Constantin Mierla : > >> I am personally aware of companies using Kamailio with several millions of >> subscribers, using kamailio database schema. Also, I am aware of companies >> having more or less same level of subscriber base using SER database schema. >> All have additional tools for management, integration with third-party >> application, a.s.o. Do you think that saying "hey, you were the unlucky >> bastard because we are going to drop tomorrow the database schema you are >> using" is the solution? > > That's right, but I don't expect that migration to SR is a priority > for those companies already using OpenSER/Kamailio. For example, I > know some companies still using OpenSer 1.2. > > However, it seems that the idea is that Kamailio/SER will use SR as > core, but the fact is that SR core uses current Kamailio and SER > modules/features as separate (modules_k, modules_s...). Wouldn't make > sense to unify SR code instead of having it splited in K and S? I always is a matter of viewpoint (If A sits next to B, B also sits next to A). Of course you could have it in 3 repositories: 1xSR, 1xser and 1xKamailio. But the decision was to use a single repository for easier developing (e.g. core API changes require module changes too). So, at the moment SR is the common repository for Kamailio (modules_k+modules+core) and ser (modules_s+modules+core). So, I think the next Kamailio release (source ball) might have just modules_k and modules. And ser does not need to distribute modules_k. However, if somebody wants to make fine selection, modules_s and modules_k can be mixed too. regards Klaus AFAIK > this is the idea for a future, but in the meanwhile I don't fully > understand why SR requires to run right now as it is. > > >>> What I don't understand is the reasons to make current SR working with >>> K and S features/modules compatibility. We don't need a SR working >>> solution right now (since Kamailio and SER do exist), do we? >> Maybe not you, but there are others. I am facing many troubles because of >> TCP (also TLS) layer in K which do not happen with SR core - asynchronous >> TCP helps a lot. > > Sure that's a good reason :) > But again you are speaking about Kamailio using SR as core (new and > improved TM module) while I meant SR code itself (which for now is a > mostly separate mix between K and S code instead of an unified > technology). > > >> All (but seas) are ported. > > Perhaps I understand it wrongly, but IMHO the modules will be really > ported when there is a unique MI interface for all of them (instead of > having to use K MI for K modules and S MI for S modules), when there > are just an unique class of pseudovariables (instead of having K and S > pvs)... > > > Regards. > > From admin at sip-router.org Mon Aug 24 17:01:28 2009 From: admin at sip-router.org (sip-router) Date: Mon, 24 Aug 2009 17:01:28 +0200 Subject: [sr-dev] [tracker] Assignee added: TLS modul problem In-Reply-To: References: Message-ID: <20090824150129.13646.844875011.swift@sip-router.org> THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A user has added themself to the list of users assigned to this task. FS#14 - TLS modul problem User who did this - Anonymous user () http://sip-router.org/tracker/index.php?do=details&task_id=14 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From admin at sip-router.org Mon Aug 24 17:01:29 2009 From: admin at sip-router.org (sip-router) Date: Mon, 24 Aug 2009 17:01:29 +0200 Subject: [sr-dev] [tracker] Task opened: TLS modul problem In-Reply-To: References: Message-ID: <20090824150129.13646.563251852.swift@sip-router.org> THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Anonymous user () Attached to Project - sip-router Summary - TLS modul problem Task Type - Bug Report Category - tls Status - Assigned Assigned To - Andrei Pelinescu-Onciul Operating System - Linux Severity - Critical Priority - Normal Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - I am experiencing problem "Invalid connection state (bug in TCP code)"in tls_server.c in function


static int tls_complete_init(struct tcp_connection* c)


if (c->state == S_CONN_ACCEPT) {
               dom = tls_lookup_cfg(cfg, TLS_DOMAIN_SRV, &c->rcv.dst_ip, c->rcv.dst_port);
       } else if (c->state == S_CONN_CONNECT) {
               dom = tls_lookup_cfg(cfg, TLS_DOMAIN_CLI, &c->rcv.dst_ip, c->rcv.dst_port);
       } else {
               BUG("Invalid connection state (bug in TCP code)\n");
               goto error;
       }

Incoming tls connection is working fine. The problem only occurs if a worker received a new invite and want forward and open a new TLS connection by

int tls_h_blocking_write(struct tcp_connection *c, int fd, const char *buf, unsigned int len)

I am debugged with gdb and i catch that c->state is S_CONN_OK So it seems it TCP is already connected. My TCP config in ser.cfg


#TLS
enable_tls=yes

#TCP settings
disable_tcp=no 
tcp_async=no
tcp_send_timeout=2
#tcp_accept_aliases=yes # accepts the tcp alias via option (see NEWS)
tcp_delayed_ack=no
tcp_fd_cache=no

More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=14 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From misi at niif.hu Mon Aug 24 17:25:09 2009 From: misi at niif.hu (=?UTF-8?B?TcOJU1rDgVJPUyBNaWjDoWx5?=) Date: Mon, 24 Aug 2009 17:25:09 +0200 Subject: [sr-dev] [SR-Users] [Kamailio-Users] kamailio 3.0 - the time before freezing In-Reply-To: <4A92A316.8030407@pernau.at> References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> <19090.29262.195063.958231@tutpro.com> <4A927491.5030600@gmail.com> <4A927603.8050209@evaristesys.com> <4A92820E.50301@gmail.com> <4A92A316.8030407@pernau.at> Message-ID: <4A92B0D5.2030809@niif.hu> Klaus Darilion wrote: > > > I?aki Baz Castillo schrieb: >> 2009/8/24 Daniel-Constantin Mierla : >> >>> I am personally aware of companies using Kamailio with several >>> millions of >>> subscribers, using kamailio database schema. Also, I am aware of >>> companies >>> having more or less same level of subscriber base using SER database >>> schema. >>> All have additional tools for management, integration with third-party >>> application, a.s.o. Do you think that saying "hey, you were the unlucky >>> bastard because we are going to drop tomorrow the database schema >>> you are >>> using" is the solution? >> >> That's right, but I don't expect that migration to SR is a priority >> for those companies already using OpenSER/Kamailio. For example, I >> know some companies still using OpenSer 1.2. >> >> However, it seems that the idea is that Kamailio/SER will use SR as >> core, but the fact is that SR core uses current Kamailio and SER >> modules/features as separate (modules_k, modules_s...). Wouldn't make >> sense to unify SR code instead of having it splited in K and S? > > I always is a matter of viewpoint (If A sits next to B, B also sits > next to A). Of course you could have it in 3 repositories: 1xSR, 1xser > and 1xKamailio. But the decision was to use a single repository for > easier developing (e.g. core API changes require module changes too). > > So, at the moment SR is the common repository for Kamailio > (modules_k+modules+core) and ser (modules_s+modules+core). So, I think > the next Kamailio release (source ball) might have just modules_k and > modules. And ser does not need to distribute modules_k. However, if > somebody wants to make fine selection, modules_s and modules_k can be > mixed too. > Hi! I want only mention my experience. (I am pretty new using sip-router.) I tried to mix the modules but it didn't work for me. So I want some modules from modules_s (xlog,auth_identiy ...) and other from modules_p (presence etc.) But i have failed. :( I must choose from the two repository. I can't use it together. The key problem was that SL modul is not merged. Many modules depends on this modul. Misi > regards > Klaus > > > AFAIK >> this is the idea for a future, but in the meanwhile I don't fully >> understand why SR requires to run right now as it is. >> >> >>>> What I don't understand is the reasons to make current SR working with >>>> K and S features/modules compatibility. We don't need a SR working >>>> solution right now (since Kamailio and SER do exist), do we? >>> Maybe not you, but there are others. I am facing many troubles >>> because of >>> TCP (also TLS) layer in K which do not happen with SR core - >>> asynchronous >>> TCP helps a lot. >> >> Sure that's a good reason :) >> But again you are speaking about Kamailio using SR as core (new and >> improved TM module) while I meant SR code itself (which for now is a >> mostly separate mix between K and S code instead of an unified >> technology). >> >> >>> All (but seas) are ported. >> >> Perhaps I understand it wrongly, but IMHO the modules will be really >> ported when there is a unique MI interface for all of them (instead of >> having to use K MI for K modules and S MI for S modules), when there >> are just an unique class of pseudovariables (instead of having K and S >> pvs)... >> >> >> Regards. >> >> > > _______________________________________________ > sr-dev mailing list > sr-dev at lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev From klaus.mailinglists at pernau.at Mon Aug 24 17:38:11 2009 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Mon, 24 Aug 2009 17:38:11 +0200 Subject: [sr-dev] [SR-Users] [Kamailio-Users] kamailio 3.0 - the time before freezing In-Reply-To: <4A92B0D5.2030809@niif.hu> References: <4A926529.5030307@gmail.com> <19090.28590.281902.881662@tutpro.com> <4A9270E0.6080905@gmail.com> <19090.29262.195063.958231@tutpro.com> <4A927491.5030600@gmail.com> <4A927603.8050209@evaristesys.com> <4A92820E.50301@gmail.com> <4A92A316.8030407@pernau.at> <4A92B0D5.2030809@niif.hu> Message-ID: <4A92B3E3.1070404@pernau.at> M?SZ?ROS Mih?ly schrieb: > Klaus Darilion wrote: >> >> >> I?aki Baz Castillo schrieb: >>> 2009/8/24 Daniel-Constantin Mierla : >>> >>>> I am personally aware of companies using Kamailio with several >>>> millions of >>>> subscribers, using kamailio database schema. Also, I am aware of >>>> companies >>>> having more or less same level of subscriber base using SER database >>>> schema. >>>> All have additional tools for management, integration with third-party >>>> application, a.s.o. Do you think that saying "hey, you were the unlucky >>>> bastard because we are going to drop tomorrow the database schema >>>> you are >>>> using" is the solution? >>> >>> That's right, but I don't expect that migration to SR is a priority >>> for those companies already using OpenSER/Kamailio. For example, I >>> know some companies still using OpenSer 1.2. >>> >>> However, it seems that the idea is that Kamailio/SER will use SR as >>> core, but the fact is that SR core uses current Kamailio and SER >>> modules/features as separate (modules_k, modules_s...). Wouldn't make >>> sense to unify SR code instead of having it splited in K and S? >> >> I always is a matter of viewpoint (If A sits next to B, B also sits >> next to A). Of course you could have it in 3 repositories: 1xSR, 1xser >> and 1xKamailio. But the decision was to use a single repository for >> easier developing (e.g. core API changes require module changes too). >> >> So, at the moment SR is the common repository for Kamailio >> (modules_k+modules+core) and ser (modules_s+modules+core). So, I think >> the next Kamailio release (source ball) might have just modules_k and >> modules. And ser does not need to distribute modules_k. However, if >> somebody wants to make fine selection, modules_s and modules_k can be >> mixed too. >> > Hi! > > I want only mention my experience. (I am pretty new using sip-router.) > I tried to mix the modules but it didn't work for me. > So I want some modules from modules_s (xlog,auth_identiy ...) and other > from modules_p (presence etc.) > But i have failed. :( > I must choose from the two repository. I can't use it together. > The key problem was that SL modul is not merged. Many modules depends on > this modul. Yes, that's true. That's why Daniel said he tries to merge the sl modules regards klaus From ramona at rosdev.ro Tue Aug 25 10:38:45 2009 From: ramona at rosdev.ro (Elena-Ramona Modroiu) Date: Tue, 25 Aug 2009 10:38:45 +0200 (CEST) Subject: [sr-dev] git:master: rls: fixed supported header name Message-ID: <20090825083845.C9F1AEF8072@rimmer> Module: sip-router Branch: master Commit: a3b0f700d10d0b310766a34ec6e7390455e5ba64 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=a3b0f700d10d0b310766a34ec6e7390455e5ba64 Author: Elena-Ramona Modroiu Committer: Elena-Ramona Modroiu Date: Tue Aug 25 11:16:53 2009 +0300 rls: fixed supported header name - port of K #5908 --- modules_k/rls/subscribe.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/modules_k/rls/subscribe.c b/modules_k/rls/subscribe.c index eada0c6..7f1c365 100644 --- a/modules_k/rls/subscribe.c +++ b/modules_k/rls/subscribe.c @@ -476,7 +476,7 @@ int rls_handle_subscribe(struct sip_msg* msg, char* s1, char* s2) lock_release(&rls_table[hash_code].lock); } -/*** verify if it contains the 'Support: eventlist' header +/*** verify if it contains the 'Supported: eventlist' header * and if not - reply with '421 (Extension Required)' */ /* @@ -490,7 +490,7 @@ int rls_handle_subscribe(struct sip_msg* msg, char* s1, char* s2) hdr= msg->headers; while(hdr) { - if(cmp_hdrname_strzn(&hdr->name, "Support", 7)== 0) + if(cmp_hdrname_strzn(&hdr->name, "Supported", 9)== 0) break; hdr= hdr->next; } From ramona at rosdev.ro Tue Aug 25 10:38:45 2009 From: ramona at rosdev.ro (Elena-Ramona Modroiu) Date: Tue, 25 Aug 2009 10:38:45 +0200 (CEST) Subject: [sr-dev] git:master: rls: memory leak fix Message-ID: <20090825083845.E493EEF8064@rimmer> Module: sip-router Branch: master Commit: 778c4352f2cbbc572a001e7ef9f2bf18d453a302 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=778c4352f2cbbc572a001e7ef9f2bf18d453a302 Author: Elena-Ramona Modroiu Committer: Elena-Ramona Modroiu Date: Tue Aug 25 11:36:59 2009 +0300 rls: memory leak fix - port of K #5909 --- modules_k/rls/notify.c | 19 +++++++++++-------- modules_k/rls/resource_notify.c | 34 +++++++++++++++++++--------------- modules_k/rls/subscribe.c | 25 ++++++++++++++++--------- 3 files changed, 46 insertions(+), 32 deletions(-) diff --git a/modules_k/rls/notify.c b/modules_k/rls/notify.c index eaefad1..9734d6c 100644 --- a/modules_k/rls/notify.c +++ b/modules_k/rls/notify.c @@ -216,13 +216,13 @@ int agg_body_sendn_update(str* rl_uri, char* boundary_string, str* rlmi_body, cid= generate_cid(rl_uri->s, rl_uri->len); - len= 2*strlen(boundary_string)+ 4+ 102+ strlen(cid)+ 2+ rlmi_body->len+50; + len= 2*strlen(boundary_string)+4+102+strlen(cid)+2+rlmi_body->len+50; if(multipart_body) len+= multipart_body->len; init_len= len; - body.s= (char*)pkg_malloc(len* sizeof(char)); + body.s= (char*)pkg_malloc((len+1)* sizeof(char)); if(body.s== NULL) { ERR_MEM(PKG_MEM_STR); @@ -469,6 +469,7 @@ str* constr_multipart_body(db1_res_t* result, char** cid_array, db_val_t *row_vals; char* content_id= NULL; str body= {0, 0}; + str ctype= {0, 0}; int antet_len; str* multi_body= NULL; @@ -489,6 +490,11 @@ str* constr_multipart_body(db1_res_t* result, char** cid_array, if(row_vals[auth_state_col].val.int_val!= ACTIVE_STATE) continue; + body.s= (char*)row_vals[pres_state_col].val.string_val; + body.len= strlen(body.s); + ctype.s = (char*)row_vals[content_type_col].val.string_val; + ctype.len = strlen(ctype.s); + if(length+ antet_len+ body.len+ 4 > size) { REALLOC_BUF @@ -505,13 +511,10 @@ str* constr_multipart_body(db1_res_t* result, char** cid_array, } length+= sprintf(buf+ length, "Content-ID: <%s>\r\n",content_id); - length+= sprintf(buf+ length, "Content-Type: %s\r\n\r\n", - row_vals[content_type_col].val.string_val); + length+= sprintf(buf+ length, "Content-Type: %.*s\r\n\r\n", + ctype.len, ctype.s); - body.s= (char*)row_vals[pres_state_col].val.string_val; - body.len= strlen(body.s); - - length+= sprintf(buf+length,"%s\r\n\r\n", body.s); + length+= sprintf(buf+length,"%.*s\r\n\r\n", body.len, body.s); } if(length+ strlen( boundary_string)+ 7> size ) diff --git a/modules_k/rls/resource_notify.c b/modules_k/rls/resource_notify.c index 3afc2d7..ff9a037 100644 --- a/modules_k/rls/resource_notify.c +++ b/modules_k/rls/resource_notify.c @@ -406,9 +406,17 @@ done: goto error; } + pkg_free(res_id->s); + pkg_free(res_id); + return 1; error: + if(res_id!=NULL) + { + pkg_free(res_id->s); + pkg_free(res_id); + } return -1; } /* callid, from_tag, to_tag parameters must be allocated */ @@ -563,11 +571,6 @@ void timer_send_notify(unsigned int ticks,void *param) goto error; } xmlFree(rlmi_cont.s); - if(buf_len) - { - pkg_free(buf); - buf= NULL; - } xmlFreeDoc(rlmi_doc); rlmi_doc= NULL; pkg_free(rl_uri); @@ -576,14 +579,16 @@ void timer_send_notify(unsigned int ticks,void *param) dialog= NULL; } - if(prev_did== NULL || strcmp(prev_did, curr_did)) /*if first or different*/ + /*if first or different*/ + if(prev_did==NULL || strcmp(prev_did, curr_did)!=0) { /* search the subscription in rlsubs_table*/ if( parse_rlsubs_did(curr_did, &callid, &from_tag, &to_tag)< 0) { LM_ERR("bad format for " "resource list Subscribe dialog indentifier(rlsubs did)\n"); - goto done; + prev_did = NULL; + continue; } hash_code= core_hash(&callid, &to_tag, hash_size); @@ -598,6 +603,7 @@ void timer_send_notify(unsigned int ticks,void *param) callid.len, callid.s,from_tag.len,from_tag.s, to_tag.len,to_tag.s); lock_release(&rls_table[hash_code].lock); + prev_did = NULL; continue; } LM_DBG("Found rl-subs record in hash table\n"); @@ -634,8 +640,10 @@ void timer_send_notify(unsigned int ticks,void *param) rl_uri[dialog->pres_uri.len]= '\0'; xmlNewProp(list_node, BAD_CAST "uri", BAD_CAST rl_uri); - xmlNewProp(list_node, BAD_CAST "xmlns", BAD_CAST "urn:ietf:params:xml:ns:rlmi"); - xmlNewProp(list_node, BAD_CAST "version", BAD_CAST int2str(dialog->version, &len)); + xmlNewProp(list_node, BAD_CAST "xmlns", + BAD_CAST "urn:ietf:params:xml:ns:rlmi"); + xmlNewProp(list_node, BAD_CAST "version", + BAD_CAST int2str(dialog->version, &len)); xmlNewProp(list_node, BAD_CAST "fullState", BAD_CAST "false"); xmlDocSetRootElement(rlmi_doc, list_node); @@ -702,7 +710,8 @@ void timer_send_notify(unsigned int ticks,void *param) REALLOC_BUF } buf_len+= sprintf(buf+ buf_len, "--%s\r\n\r\n", bstr.s); - buf_len+= sprintf(buf+ buf_len, "Content-Transfer-Encoding: binary\r\n"); + buf_len+= sprintf(buf+ buf_len, + "Content-Transfer-Encoding: binary\r\n"); buf_len+= sprintf(buf+ buf_len, "Content-ID: <%s>\r\n", cid); buf_len+= sprintf(buf+ buf_len, "Content-Type: %s\r\n\r\n", row_vals[content_type_col].val.string_val); @@ -750,11 +759,6 @@ void timer_send_notify(unsigned int ticks,void *param) goto error; } xmlFree(rlmi_cont.s); - if(buf_len) - { - pkg_free(buf); - buf= NULL; - } pkg_free(rl_uri); rl_uri= NULL; pkg_free(dialog); diff --git a/modules_k/rls/subscribe.c b/modules_k/rls/subscribe.c index 7f1c365..bdf311f 100644 --- a/modules_k/rls/subscribe.c +++ b/modules_k/rls/subscribe.c @@ -688,6 +688,21 @@ int update_rlsubs( subs_t* subs, unsigned int hash_code) memcpy(subs->pres_uri.s, s->pres_uri.s, s->pres_uri.len); subs->pres_uri.len= s->pres_uri.len; + if(s->record_route.s!=NULL && s->record_route.len>0) + { + subs->record_route.s = + (char*)pkg_malloc(s->record_route.len* sizeof(char)); + if(subs->record_route.s==NULL) + { + ERR_MEM(PKG_MEM_STR); + } + memcpy(subs->record_route.s, s->record_route.s, s->record_route.len); + subs->record_route.len= s->record_route.len; + } + + subs->local_cseq= s->local_cseq; + subs->version= s->version; + if(subs->expires== 0) { /* delete record from hash table */ @@ -710,15 +725,7 @@ int update_rlsubs( subs_t* subs, unsigned int hash_code) ps->next= s->next; shm_free(s); } - else - { - s->remote_cseq= subs->remote_cseq; - s->expires= subs->expires+ (int)time(NULL); - } - subs->local_cseq= s->local_cseq; - subs->version= s->version; - lock_release(&rls_table[hash_code].lock); return 0; @@ -745,7 +752,7 @@ int resource_subscriptions(subs_t* subs, xmlNodePtr rl_node) char* uri= NULL; subs_info_t s; str wuri= {0, 0}; - static char buf[64]; + static char buf[256]; str extra_headers; str did_str= {0, 0}; From miconda at gmail.com Tue Aug 25 18:41:52 2009 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Tue, 25 Aug 2009 18:41:52 +0200 (CEST) Subject: [sr-dev] git:master: core: support for include file in cfg Message-ID: <20090825164153.0130AEF8070@rimmer> Module: sip-router Branch: master Commit: d20565193c1176312a29d75710d494707abdf6a5 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=d20565193c1176312a29d75710d494707abdf6a5 Author: Daniel-Constantin Mierla Committer: Daniel-Constantin Mierla Date: Tue Aug 25 19:27:01 2009 +0300 core: support for include file in cfg - syntax: include path/to/file - example: include checks.cfg - path can be absolute or relative - if path is relative: - first attempt is to open the file relative to current directory - second attempt is to open the file relative to the directory of the file including it - if include file fails, then print error and exit - cfg syntax error messages print file name - there is no restriction where 'include' can be used, can have global parameters, module configs or entire/parts of route blocks --- cfg.lex | 159 +++++++++++++++++++++++++++++++++++++++++++++++++++++++- cfg.y | 29 ++++++----- route_struct.h | 1 + 3 files changed, 174 insertions(+), 15 deletions(-) diff --git a/cfg.lex b/cfg.lex index ebe2b6d..079613d 100644 --- a/cfg.lex +++ b/cfg.lex @@ -122,6 +122,7 @@ int column=1; int startcolumn=1; int startline=1; + char *finame = 0; static int ign_lines=0; static int ign_columns=0; char* yy_number_str=0; /* str correspondent for the current NUMBER token */ @@ -132,12 +133,30 @@ static void count_more(); static void count_ignore(); + #define MAX_INCLUDE_DEPTH 10 + static struct sr_yy_state { + YY_BUFFER_STATE state; + int line; + int column; + int startcolumn; + int startline; + char *finame; + } include_stack[MAX_INCLUDE_DEPTH]; + static int include_stack_ptr = 0; + + static int sr_push_yy_state(char *fin); + static int sr_pop_yy_state(); + + static struct sr_yy_fname { + char *fname; + struct sr_yy_fname *next; + } *sr_yy_fname_list = 0; %} /* start conditions */ %x STRING1 STRING2 STR_BETWEEN COMMENT COMMENT_LN ATTR SELECT AVP_PVAR PVAR_P -%x PVARID +%x PVARID INCL /* config script types : #!SER or #!KAMAILIO or #!MAX_COMPAT */ SER_CFG SER @@ -201,6 +220,8 @@ CASE "case" DEFAULT "default" WHILE "while" +INCLUDE "include" + /*ACTION LVALUES*/ URIHOST "uri:host" URIPORT "uri:port" @@ -556,6 +577,8 @@ EAT_ABLE [\ \t\b\r] {DEFAULT} { count(); yylval.strval=yytext; return DEFAULT; } {WHILE} { count(); yylval.strval=yytext; return WHILE; } +{INCLUDE} { BEGIN(INCL); } + {URIHOST} { count(); yylval.strval=yytext; return URIHOST; } {URIPORT} { count(); yylval.strval=yytext; return URIPORT; } @@ -1097,6 +1120,13 @@ EAT_ABLE [\ \t\b\r]