[Serusers] PSTN gateway failover

List overview All Threads
Download

newer

older

[Serusers] Can someone (Jan, Jiri,...

[Serusers] Session Disconnection!!!

Andreas Granig

20 Oct 2004 20 Oct '04

2:33 p.m.

Hi all, Since SER does not provide DNS SRV failover capability, how do you perform failover for your PSTN gateways? I currently think about some sort of load balancing with exec_dset() which looks up a gateway in a mysql db and give it 10 tries to find a gateway (SER is running on my.domain:5060) route { if (!mf_process_maxfwd_header("10")) { sl_send_reply("483", "Too many hops"); break; } <snip> exec_dset("/my/sipgw-balancing-script"); # returns a random GW t_on_failure("1"); t_relay(); <snip> } failure_route[1] { if(t_check_status("503") { rewritehostport("my.domain:5060"); # peform loop append_branch(); t_relay(); } } Is this good practice? Any other ideas/optimizations? Cheers, Andy

Show replies by date

Jan Janak

26 Oct 26 Oct

11:37 p.m.

On 20-10 14:33, Andreas Granig wrote:

...

I would probably try to avoid mysql, because the scripts needs to connect to the mysql server and perform authentication/authorization each time -- that can be slow. Jan.

g.billoudet＠arwen-tech.fr

2 Nov 2 Nov

3:01 p.m.

New subject: [Serusers] receive_msg: no mem for sip_msg

g.billoudet＠arwen-tech.fr

9 Nov 9 Nov

2:18 p.m.

New subject: [Serusers] receive_msg: no mem for sip_msg

Hi, When I put these lines in ser.cfg : modparam("usrloc", "db_mode", 1) modparam("usrloc", "db_url", "mysql://ser:heslo@localhost/ser") Then I get this error each time my ser gets a sip message : ERROR: receive_msg: no mem for sip_msg (and ser doesn't work and I can't have phone call) The probleme comes from the script ser.cfg or from mysql ? Thanks Gwen # ----------- global configuration parameters ------------------------ debug=1 fork=yes log_stderror=yes memlog=0 sip_warning=yes listen=10.0.1.139 listen=127.0.0.1 check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) fifo="/tmp/ser_fifo" port=5060 children=4 alias="arwen-tech.fr" alias="10.0.1.139" # ------------------ module loading ---------------------------------- loadmodule "/usr/local/lib/ser/modules/mysql.so" loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so" # ----------------- setting module-specific parameters --------------- # -- usrloc params -- modparam("usrloc", "db_mode", 1) modparam("usrloc", "db_url", "mysql://ser:heslo@localhost/ser") # -- rr params -- modparam("rr", "enable_full_lr", 1) # ------------------------- request routing logic ------------------- route{ if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); break; }; if ( msg:len > max_len ) { sl_send_reply("513", "Message too big"); break; }; record_route(); if (loose_route()) { t_relay(); break; }; if (uri == myself) { if (method=="REGISTER") { save("location"); sl_send_reply("200","REGISTER OK"); break; }; if (!lookup("aliases")) { log(1, "ALIASES FAILED\n"); }; if (lookup("location")) { log(1, "USER FOUND\n"); if (!t_relay()) { sl_reply_error(); }; } else { log(1, "USER NOT FOUND\n"); sl_send_reply("404", "User not found"); break; }; } else { log(1, "OUT REALM\n"); t_relay(); break; }; }

E. Versaevel

2:26 p.m.

New subject: [Serusers] receive_msg: no mem for sip_msg

First of all put a linebreak between them, they should not be on the same line, and if I'm not mistaken the sql url should be sql://user:password@server/database not mysql:// Kind regards, E. Versaevel -----Oorspronkelijk bericht----- Van: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] Namens g.billoudet(a)arwen-tech.fr Verzonden: dinsdag 9 november 2004 14:18 Aan: serusers(a)lists.iptel.org Onderwerp: [Serusers] receive_msg: no mem for sip_msg Hi, When I put these lines in ser.cfg : modparam("usrloc", "db_mode", 1) modparam("usrloc", "db_url", "mysql://ser:heslo@localhost/ser") Then I get this error each time my ser gets a sip message : ERROR: receive_msg: no mem for sip_msg (and ser doesn't work and I can't have phone call) The probleme comes from the script ser.cfg or from mysql ? Thanks Gwen # ----------- global configuration parameters ------------------------ debug=1 fork=yes log_stderror=yes memlog=0 sip_warning=yes listen=10.0.1.139 listen=127.0.0.1 check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) fifo="/tmp/ser_fifo" port=5060 children=4 alias="arwen-tech.fr" alias="10.0.1.139" # ------------------ module loading ---------------------------------- loadmodule "/usr/local/lib/ser/modules/mysql.so" loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so" # ----------------- setting module-specific parameters --------------- # -- usrloc params -- modparam("usrloc", "db_mode", 1) modparam("usrloc", "db_url", "mysql://ser:heslo@localhost/ser") # -- rr params -- modparam("rr", "enable_full_lr", 1) # ------------------------- request routing logic ------------------- route{ if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); break; }; if ( msg:len > max_len ) { sl_send_reply("513", "Message too big"); break; }; record_route(); if (loose_route()) { t_relay(); break; }; if (uri == myself) { if (method=="REGISTER") { save("location"); sl_send_reply("200","REGISTER OK"); break; }; if (!lookup("aliases")) { log(1, "ALIASES FAILED\n"); }; if (lookup("location")) { log(1, "USER FOUND\n"); if (!t_relay()) { sl_reply_error(); }; } else { log(1, "USER NOT FOUND\n"); sl_send_reply("404", "User not found"); break; }; } else { log(1, "OUT REALM\n"); t_relay(); break; }; } _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

Jan Janak

2:36 p.m.

New subject: [Serusers] receive_msg: no mem for sip_msg

On 09-11 14:26, E. Versaevel wrote:

...

First of all put a linebreak between them, they should not be on the same line, and if I'm not mistaken the sql url should be sql://user:password@server/database not mysql://

It depends on SER version, 0.8.99-xx uses "mysql:" (or the name of the database driver, to be more precise), 0.8.14 uses "sql:" Jan.

...

-----Oorspronkelijk bericht----- Van: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] Namens g.billoudet(a)arwen-tech.fr Verzonden: dinsdag 9 november 2004 14:18 Aan: serusers(a)lists.iptel.org Onderwerp: [Serusers] receive_msg: no mem for sip_msg Hi, When I put these lines in ser.cfg : modparam("usrloc", "db_mode", 1) modparam("usrloc", "db_url", "mysql://ser:heslo@localhost/ser") Then I get this error each time my ser gets a sip message : ERROR: receive_msg: no mem for sip_msg (and ser doesn't work and I can't have phone call) The probleme comes from the script ser.cfg or from mysql ? Thanks Gwen # ----------- global configuration parameters ------------------------ debug=1 fork=yes log_stderror=yes memlog=0 sip_warning=yes listen=10.0.1.139 listen=127.0.0.1 check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) fifo="/tmp/ser_fifo" port=5060 children=4 alias="arwen-tech.fr" alias="10.0.1.139" # ------------------ module loading ---------------------------------- loadmodule "/usr/local/lib/ser/modules/mysql.so" loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so" # ----------------- setting module-specific parameters --------------- # -- usrloc params -- modparam("usrloc", "db_mode", 1) modparam("usrloc", "db_url", "mysql://ser:heslo@localhost/ser") # -- rr params -- modparam("rr", "enable_full_lr", 1) # ------------------------- request routing logic ------------------- route{ if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); break; }; if ( msg:len > max_len ) { sl_send_reply("513", "Message too big"); break; }; record_route(); if (loose_route()) { t_relay(); break; }; if (uri == myself) { if (method=="REGISTER") { save("location"); sl_send_reply("200","REGISTER OK"); break; }; if (!lookup("aliases")) { log(1, "ALIASES FAILED\n"); }; if (lookup("location")) { log(1, "USER FOUND\n"); if (!t_relay()) { sl_reply_error(); }; } else { log(1, "USER NOT FOUND\n"); sl_send_reply("404", "User not found"); break; }; } else { log(1, "OUT REALM\n"); t_relay(); break; }; } _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

g.billoudet＠arwen-tech.fr

5:56 p.m.

New subject: [Serusers] receive_msg: no mem for sip_msg

Hi, I tried with sql:// instead of mysql:// and I get the same error... Anyway, I still get the error when I put that : modparam("usrloc", "db_mode", 1) #modparam("usrloc", "db_url", "sql://ser:heslo@localhost/ser") Help :-( Gwen

...

On 09-11 14:26, E. Versaevel wrote:

First of all put a linebreak between them, they should not be on the same line, and if I'm not mistaken the sql url should be sql://user:password@server/database not mysql://

It depends on SER version, 0.8.99-xx uses "mysql:" (or the name of the database driver, to be more precise), 0.8.14 uses "sql:" Jan.

Bogdan-Andrei IANCU

6 p.m.

New subject: [Serusers] receive_msg: no mem for sip_msg

can you send the whole ser output? don't forget to set debug=9, to get as much as possible. bogdan g.billoudet(a)arwen-tech.fr wrote:

...

On 09-11 14:26, E. Versaevel wrote:

First of all put a linebreak between them, they should not be on the same line, and if I'm not mistaken the sql url should be sql://user:password@server/database not mysql://

It depends on SER version, 0.8.99-xx uses "mysql:" (or the name of the database driver, to be more precise), 0.8.14 uses "sql:" Jan. >-----Oorspronkelijk bericht----- >Van: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] >Namens >g.billoudet(a)arwen-tech.fr >Verzonden: dinsdag 9 november 2004 14:18 >Aan: serusers(a)lists.iptel.org >Onderwerp: [Serusers] receive_msg: no mem for sip_msg > > >Hi, > >When I put these lines in ser.cfg : >modparam("usrloc", "db_mode", 1) >modparam("usrloc", "db_url", "mysql://ser:heslo@localhost/ser") > >Then I get this error each time my ser gets a sip message : > ERROR: receive_msg: no mem for sip_msg > >(and ser doesn't work and I can't have phone call) > > >The probleme comes from the script ser.cfg or from mysql ? > > >Thanks > > Gwen > ># ----------- global configuration parameters ------------------------ >debug=1 >fork=yes >log_stderror=yes >memlog=0 >sip_warning=yes >listen=10.0.1.139 >listen=127.0.0.1 > >check_via=no # (cmd. line: -v) >dns=no # (cmd. line: -r) >rev_dns=no # (cmd. line: -R) >fifo="/tmp/ser_fifo" >port=5060 >children=4 >alias="arwen-tech.fr" >alias="10.0.1.139" > ># ------------------ module loading ---------------------------------- >loadmodule "/usr/local/lib/ser/modules/mysql.so" >loadmodule "/usr/local/lib/ser/modules/sl.so" >loadmodule "/usr/local/lib/ser/modules/tm.so" >loadmodule "/usr/local/lib/ser/modules/rr.so" >loadmodule "/usr/local/lib/ser/modules/maxfwd.so" >loadmodule "/usr/local/lib/ser/modules/usrloc.so" >loadmodule "/usr/local/lib/ser/modules/registrar.so" > ># ----------------- setting module-specific parameters --------------- ># -- usrloc params -- >modparam("usrloc", "db_mode", 1) >modparam("usrloc", "db_url", "mysql://ser:heslo@localhost/ser") > ># -- rr params -- >modparam("rr", "enable_full_lr", 1) > ># ------------------------- request routing logic ------------------- >route{ > if (!mf_process_maxfwd_header("10")) { > sl_send_reply("483","Too Many Hops"); > break; > }; > if ( msg:len > max_len ) { > sl_send_reply("513", "Message too big"); > break; > }; > record_route(); > if (loose_route()) { > t_relay(); > break; > }; > > if (uri == myself) { > if (method=="REGISTER") { > save("location"); > sl_send_reply("200","REGISTER OK"); > break; > }; > if (!lookup("aliases")) { > log(1, "ALIASES FAILED\n"); > }; > if (lookup("location")) { > log(1, "USER FOUND\n"); > if (!t_relay()) { > sl_reply_error(); > }; > } else { > log(1, "USER NOT FOUND\n"); > sl_send_reply("404", "User not found"); > break; > }; > } else { > log(1, "OUT REALM\n"); > t_relay(); > break; > }; >} > > >_______________________________________________ >Serusers mailing list >serusers(a)lists.iptel.org >http://lists.iptel.org/mailman/listinfo/serusers > >_______________________________________________ >Serusers mailing list >serusers(a)lists.iptel.org >http://lists.iptel.org/mailman/listinfo/serusers > >

_______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

g.billoudet＠arwen-tech.fr

10 Nov 10 Nov

9:36 a.m.

New subject: [Serusers] receive_msg: no mem for sip_msg

Hi, Thanks for help I put this in ser.cfg : modparam("usrloc", "db_mode", 1) modparam("usrloc", "db_url", "sql://ser:heslo@localhost/ser") Here is the output : (see the last lines : the error "receive_msg: no mem for sip_msg" (none of my phone can have a phone call, but X-Lite seems to register...) (2826) loading module /usr/local/lib/ser/modules/mysql.so 0(2826) loading module /usr/local/lib/ser/modules/sl.so 0(2826) loading module /usr/local/lib/ser/modules/tm.so 0(2826) loading module /usr/local/lib/ser/modules/rr.so 0(2826) loading module /usr/local/lib/ser/modules/maxfwd.so 0(2826) loading module /usr/local/lib/ser/modules/usrloc.so 0(2826) loading module /usr/local/lib/ser/modules/registrar.so 0(2826) set_mod_param_regex: usrloc matches module usrloc 0(2826) set_mod_param_regex: found <db_mode> in module usrloc [/usr/local/lib/ser/modules/usrloc.so] 0(2826) set_mod_param_regex: usrloc matches module usrloc 0(2826) set_mod_param_regex: found <db_url> in module usrloc [/usr/local/lib/ser/modules/usrloc.so] 0(2826) set_mod_param_regex: rr matches module rr 0(2826) set_mod_param_regex: found <enable_full_lr> in module rr [/usr/local/lib/ser/modules/rr.so] 0(2826) find_export: found <mf_process_maxfwd_header> in module maxfwd_module [/usr/local/lib/ser/modules/maxfwd.so] 0(2826) find_export: found <sl_send_reply> in module sl_module [/usr/local/lib/ser/modules/sl.so] 0(2826) find_export: found <sl_send_reply> in module sl_module [/usr/local/lib/ser/modules/sl.so] 0(2826) find_export: found <record_route> in module rr [/usr/local/lib/ser/modules/rr.so] 0(2826) find_export: found <loose_route> in module rr [/usr/local/lib/ser/modules/rr.so] 0(2826) find_export: found <t_relay> in module tm [/usr/local/lib/ser/modules/tm.so] 0(2826) find_export: found <save> in module registrar [/usr/local/lib/ser/modules/registrar.so] 0(2826) find_export: found <sl_send_reply> in module sl_module [/usr/local/lib/ser/modules/sl.so] 0(2826) find_export: found <lookup> in module registrar [/usr/local/lib/ser/modules/registrar.so] 0(2826) find_export: found <lookup> in module registrar [/usr/local/lib/ser/modules/registrar.so] 0(2826) find_export: found <t_relay> in module tm [/usr/local/lib/ser/modules/tm.so] 0(2826) find_export: found <sl_reply_error> in module sl_module [/usr/local/lib/ser/modules/sl.so] 0(2826) find_export: found <sl_send_reply> in module sl_module [/usr/local/lib/ser/modules/sl.so] 0(2826) find_export: found <t_relay> in module tm [/usr/local/lib/ser/modules/tm.so] 0(2826) routing table 0: 0(2826) if ( 0(2826) NOT( 0(2826) external_module_call( 0(2826) f_ptr<0x4229fe20> 0(2826) , "10" 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x4229fe20> 0(2826) , "10" 0(2826) ); 0(2826) ) 0(2826) ) { 0(2826) log( 0(2826) 1 0(2826) , "TROP DE SAUTS " 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x4219e790> 0(2826) , "483" 0(2826) , "Too Many Hops" 0(2826) ); 0(2826) drop( 0(2826) type<0> 0(2826) ); 0(2826) } else { 0(2826) }; 0(2826) if ( 0(2826) UNKNOWN 0(2826) <UNKNOWN> 0(2826) 65535 0(2826) ) { 0(2826) log( 0(2826) 1 0(2826) , "MESSAGE TROP LONG " 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x4219e790> 0(2826) , "513" 0(2826) , "Message too big" 0(2826) ); 0(2826) drop( 0(2826) type<0> 0(2826) ); 0(2826) } else { 0(2826) }; 0(2826) external_module_call( 0(2826) f_ptr<0x422991f0> 0(2826) ); 0(2826) if ( 0(2826) external_module_call( 0(2826) f_ptr<0x42296e60> 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x42296e60> 0(2826) ); 0(2826) ) { 0(2826) external_module_call( 0(2826) f_ptr<0x42270830> 0(2826) ); 0(2826) drop( 0(2826) type<0> 0(2826) ); 0(2826) } else { 0(2826) }; 0(2826) if ( 0(2826) uri 0(2826) == 0(2826) _myself_ 0(2826) ) { 0(2826) if ( 0(2826) method 0(2826) == 0(2826) "REGISTER" 0(2826) ) { 0(2826) external_module_call( 0(2826) f_ptr<0x422b6620> 0(2826) , "location" 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x4219e790> 0(2826) , "200" 0(2826) , "Enregistrement OK" 0(2826) ); 0(2826) drop( 0(2826) type<0> 0(2826) ); 0(2826) } else { 0(2826) }; 0(2826) log( 0(2826) 2 0(2826) , "NON REGISTER " 0(2826) ); 0(2826) if ( 0(2826) NOT( 0(2826) external_module_call( 0(2826) f_ptr<0x422b5a30> 0(2826) , "aliases" 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x422b5a30> 0(2826) , "aliases" 0(2826) ); 0(2826) ) 0(2826) ) { 0(2826) log( 0(2826) 1 0(2826) , "ALIASES2 FAILED " 0(2826) ); 0(2826) } else { 0(2826) }; 0(2826) if ( 0(2826) external_module_call( 0(2826) f_ptr<0x422b5a30> 0(2826) , "location" 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x422b5a30> 0(2826) , "location" 0(2826) ); 0(2826) ) { 0(2826) log( 0(2826) 1 0(2826) , "USER FOUND " 0(2826) ); 0(2826) if ( 0(2826) NOT( 0(2826) external_module_call( 0(2826) f_ptr<0x42270830> 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x42270830> 0(2826) ); 0(2826) ) 0(2826) ) { 0(2826) external_module_call( 0(2826) f_ptr<0x4219e7c0> 0(2826) ); 0(2826) } else { 0(2826) }; 0(2826) } else { 0(2826) log( 0(2826) 1 0(2826) , "USER NOT FOUND " 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x4219e790> 0(2826) , "404" 0(2826) , "User not found" 0(2826) ); 0(2826) drop( 0(2826) type<0> 0(2826) ); 0(2826) }; 0(2826) } else { 0(2826) log( 0(2826) 1 0(2826) , "OUT REALM " 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x42270830> 0(2826) ); 0(2826) drop( 0(2826) type<0> 0(2826) ); 0(2826) }; 0(2826) if ( 0(2826) UNKNOWN 0(2826) <UNKNOWN> 0(2826) 65535 0(2826) ) { 0(2826) log( 0(2826) 1 0(2826) , "MESSAGE TROP LONG " 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x4219e790> 0(2826) , "513" 0(2826) , "Message too big" 0(2826) ); 0(2826) drop( 0(2826) type<0> 0(2826) ); 0(2826) } else { 0(2826) }; 0(2826) external_module_call( 0(2826) f_ptr<0x422991f0> 0(2826) ); 0(2826) if ( 0(2826) external_module_call( 0(2826) f_ptr<0x42296e60> 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x42296e60> 0(2826) ); 0(2826) ) { 0(2826) external_module_call( 0(2826) f_ptr<0x42270830> 0(2826) ); 0(2826) drop( 0(2826) type<0> 0(2826) ); 0(2826) } else { 0(2826) }; 0(2826) if ( 0(2826) uri 0(2826) == 0(2826) _myself_ 0(2826) ) { 0(2826) if ( 0(2826) method 0(2826) == 0(2826) "REGISTER" 0(2826) ) { 0(2826) external_module_call( 0(2826) f_ptr<0x422b6620> 0(2826) , "location" 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x4219e790> 0(2826) , "200" 0(2826) , "Enregistrement OK" 0(2826) ); 0(2826) drop( 0(2826) type<0> 0(2826) ); 0(2826) } else { 0(2826) }; 0(2826) log( 0(2826) 2 0(2826) , "NON REGISTER " 0(2826) ); 0(2826) if ( 0(2826) NOT( 0(2826) external_module_call( 0(2826) f_ptr<0x422b5a30> 0(2826) , "aliases" 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x422b5a30> 0(2826) , "aliases" 0(2826) ); 0(2826) ) 0(2826) ) { 0(2826) log( 0(2826) 1 0(2826) , "ALIASES2 FAILED " 0(2826) ); 0(2826) } else { 0(2826) }; 0(2826) if ( 0(2826) external_module_call( 0(2826) f_ptr<0x422b5a30> 0(2826) , "location" 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x422b5a30> 0(2826) , "location" 0(2826) ); 0(2826) ) { 0(2826) log( 0(2826) 1 0(2826) , "USER FOUND " 0(2826) ); 0(2826) if ( 0(2826) NOT( 0(2826) external_module_call( 0(2826) f_ptr<0x42270830> 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x42270830> 0(2826) ); 0(2826) ) 0(2826) ) { 0(2826) external_module_call( 0(2826) f_ptr<0x4219e7c0> 0(2826) ); 0(2826) } else { 0(2826) }; 0(2826) } else { 0(2826) log( 0(2826) 1 0(2826) , "USER NOT FOUND " 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x4219e790> 0(2826) , "404" 0(2826) , "User not found" 0(2826) ); 0(2826) drop( 0(2826) type<0> 0(2826) ); 0(2826) }; 0(2826) } else { 0(2826) log( 0(2826) 1 0(2826) , "OUT REALM " 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x42270830> 0(2826) ); 0(2826) drop( 0(2826) type<0> 0(2826) ); 0(2826) }; 0(2826) external_module_call( 0(2826) f_ptr<0x422991f0> 0(2826) ); 0(2826) if ( 0(2826) external_module_call( 0(2826) f_ptr<0x42296e60> 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x42296e60> 0(2826) ); 0(2826) ) { 0(2826) external_module_call( 0(2826) f_ptr<0x42270830> 0(2826) ); 0(2826) drop( 0(2826) type<0> 0(2826) ); 0(2826) } else { 0(2826) }; 0(2826) if ( 0(2826) uri 0(2826) == 0(2826) _myself_ 0(2826) ) { 0(2826) if ( 0(2826) method 0(2826) == 0(2826) "REGISTER" 0(2826) ) { 0(2826) external_module_call( 0(2826) f_ptr<0x422b6620> 0(2826) , "location" 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x4219e790> 0(2826) , "200" 0(2826) , "Enregistrement OK" 0(2826) ); 0(2826) drop( 0(2826) type<0> 0(2826) ); 0(2826) } else { 0(2826) }; 0(2826) log( 0(2826) 2 0(2826) , "NON REGISTER " 0(2826) ); 0(2826) if ( 0(2826) NOT( 0(2826) external_module_call( 0(2826) f_ptr<0x422b5a30> 0(2826) , "aliases" 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x422b5a30> 0(2826) , "aliases" 0(2826) ); 0(2826) ) 0(2826) ) { 0(2826) log( 0(2826) 1 0(2826) , "ALIASES2 FAILED " 0(2826) ); 0(2826) } else { 0(2826) }; 0(2826) if ( 0(2826) external_module_call( 0(2826) f_ptr<0x422b5a30> 0(2826) , "location" 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x422b5a30> 0(2826) , "location" 0(2826) ); 0(2826) ) { 0(2826) log( 0(2826) 1 0(2826) , "USER FOUND " 0(2826) ); 0(2826) if ( 0(2826) NOT( 0(2826) external_module_call( 0(2826) f_ptr<0x42270830> 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x42270830> 0(2826) ); 0(2826) ) 0(2826) ) { 0(2826) external_module_call( 0(2826) f_ptr<0x4219e7c0> 0(2826) ); 0(2826) } else { 0(2826) }; 0(2826) } else { 0(2826) log( 0(2826) 1 0(2826) , "USER NOT FOUND " 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x4219e790> 0(2826) , "404" 0(2826) , "User not found" 0(2826) ); 0(2826) drop( 0(2826) type<0> 0(2826) ); 0(2826) }; 0(2826) } else { 0(2826) log( 0(2826) 1 0(2826) , "OUT REALM " 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x42270830> 0(2826) ); 0(2826) drop( 0(2826) type<0> 0(2826) ); 0(2826) }; 0(2826) if ( 0(2826) external_module_call( 0(2826) f_ptr<0x42296e60> 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x42296e60> 0(2826) ); 0(2826) ) { 0(2826) external_module_call( 0(2826) f_ptr<0x42270830> 0(2826) ); 0(2826) drop( 0(2826) type<0> 0(2826) ); 0(2826) } else { 0(2826) }; 0(2826) if ( 0(2826) uri 0(2826) == 0(2826) _myself_ 0(2826) ) { 0(2826) if ( 0(2826) method 0(2826) == 0(2826) "REGISTER" 0(2826) ) { 0(2826) external_module_call( 0(2826) f_ptr<0x422b6620> 0(2826) , "location" 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x4219e790> 0(2826) , "200" 0(2826) , "Enregistrement OK" 0(2826) ); 0(2826) drop( 0(2826) type<0> 0(2826) ); 0(2826) } else { 0(2826) }; 0(2826) log( 0(2826) 2 0(2826) , "NON REGISTER " 0(2826) ); 0(2826) if ( 0(2826) NOT( 0(2826) external_module_call( 0(2826) f_ptr<0x422b5a30> 0(2826) , "aliases" 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x422b5a30> 0(2826) , "aliases" 0(2826) ); 0(2826) ) 0(2826) ) { 0(2826) log( 0(2826) 1 0(2826) , "ALIASES2 FAILED " 0(2826) ); 0(2826) } else { 0(2826) }; 0(2826) if ( 0(2826) external_module_call( 0(2826) f_ptr<0x422b5a30> 0(2826) , "location" 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x422b5a30> 0(2826) , "location" 0(2826) ); 0(2826) ) { 0(2826) log( 0(2826) 1 0(2826) , "USER FOUND " 0(2826) ); 0(2826) if ( 0(2826) NOT( 0(2826) external_module_call( 0(2826) f_ptr<0x42270830> 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x42270830> 0(2826) ); 0(2826) ) 0(2826) ) { 0(2826) external_module_call( 0(2826) f_ptr<0x4219e7c0> 0(2826) ); 0(2826) } else { 0(2826) }; 0(2826) } else { 0(2826) log( 0(2826) 1 0(2826) , "USER NOT FOUND " 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x4219e790> 0(2826) , "404" 0(2826) , "User not found" 0(2826) ); 0(2826) drop( 0(2826) type<0> 0(2826) ); 0(2826) }; 0(2826) } else { 0(2826) log( 0(2826) 1 0(2826) , "OUT REALM " 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x42270830> 0(2826) ); 0(2826) drop( 0(2826) type<0> 0(2826) ); 0(2826) }; 0(2826) if ( 0(2826) uri 0(2826) == 0(2826) _myself_ 0(2826) ) { 0(2826) if ( 0(2826) method 0(2826) == 0(2826) "REGISTER" 0(2826) ) { 0(2826) external_module_call( 0(2826) f_ptr<0x422b6620> 0(2826) , "location" 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x4219e790> 0(2826) , "200" 0(2826) , "Enregistrement OK" 0(2826) ); 0(2826) drop( 0(2826) type<0> 0(2826) ); 0(2826) } else { 0(2826) }; 0(2826) log( 0(2826) 2 0(2826) , "NON REGISTER " 0(2826) ); 0(2826) if ( 0(2826) NOT( 0(2826) external_module_call( 0(2826) f_ptr<0x422b5a30> 0(2826) , "aliases" 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x422b5a30> 0(2826) , "aliases" 0(2826) ); 0(2826) ) 0(2826) ) { 0(2826) log( 0(2826) 1 0(2826) , "ALIASES2 FAILED " 0(2826) ); 0(2826) } else { 0(2826) }; 0(2826) if ( 0(2826) external_module_call( 0(2826) f_ptr<0x422b5a30> 0(2826) , "location" 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x422b5a30> 0(2826) , "location" 0(2826) ); 0(2826) ) { 0(2826) log( 0(2826) 1 0(2826) , "USER FOUND " 0(2826) ); 0(2826) if ( 0(2826) NOT( 0(2826) external_module_call( 0(2826) f_ptr<0x42270830> 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x42270830> 0(2826) ); 0(2826) ) 0(2826) ) { 0(2826) external_module_call( 0(2826) f_ptr<0x4219e7c0> 0(2826) ); 0(2826) } else { 0(2826) }; 0(2826) } else { 0(2826) log( 0(2826) 1 0(2826) , "USER NOT FOUND " 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x4219e790> 0(2826) , "404" 0(2826) , "User not found" 0(2826) ); 0(2826) drop( 0(2826) type<0> 0(2826) ); 0(2826) }; 0(2826) } else { 0(2826) log( 0(2826) 1 0(2826) , "OUT REALM " 0(2826) ); 0(2826) external_module_call( 0(2826) f_ptr<0x42270830> 0(2826) ); 0(2826) drop( 0(2826) type<0> 0(2826) ); 0(2826) }; 0(2826) Listening on 10.0.1.139 [10.0.1.139]:5060 127.0.0.1 [127.0.0.1]:5060 Aliases: localhost:5060 Linux:5060 10.0.1.139:* arwen-tech.fr:* 0(2828) DEBUG: init_mod: mysql 0(2828) mysql - initializing 0(2828) DEBUG: init_mod: sl_module stateless - initializing 0(2828) DEBUG: register_fifo_cmd: new command (sl_stats) registered 0(2828) DEBUG: MD5 calculated: 3cc4c29c50fe423c689136c8ae913ec2 0(2828) DEBUG: init_mod: tm 0(2828) TM - initializing... 0(2828) Call-ID initialization: '6bb7bddf' 0(2828) DEBUG: register_fifo_cmd: new command (t_uac_dlg) registered 0(2828) DEBUG: register_fifo_cmd: new command (t_hash) registered 0(2828) DEBUG: lock_initialize: lock initialization started 0(2828) DEBUG: register_fifo_cmd: new command (t_stats) registered 0(2828) DEBUG: MD5 calculated: a98ea5369af7c62803785160b9215111 0(2828) DEBUG: MD5 calculated: a532a1b878db1254fb2a69d48f1933d6 0(2828) DEBUG: init_mod: rr 0(2828) rr - initializing 0(2828) DEBUG: init_mod: maxfwd_module Maxfwd module- initializing 0(2828) DEBUG: init_mod: usrloc 0(2828) usrloc - initializing 0(2828) DEBUG: register_fifo_cmd: new command (ul_stats) registered 0(2828) DEBUG: register_fifo_cmd: new command (ul_rm) registered 0(2828) DEBUG: register_fifo_cmd: new command (ul_rm_contact) registered 0(2828) DEBUG: register_fifo_cmd: new command (ul_dump) registered 0(2828) DEBUG: register_fifo_cmd: new command (ul_flush) registered 0(2828) DEBUG: register_fifo_cmd: new command (ul_add) registered 0(2828) DEBUG: register_fifo_cmd: new command (ul_show_contact) registered 0(2828) find_export: found <db_use_table> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(2828) find_export: found <db_init> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(2828) find_export: found <db_close> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(2828) find_export: found <db_query> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(2828) find_export: found <db_raw_query> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(2828) find_export: found <db_free_query> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(2828) find_export: found <db_insert> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(2828) find_export: found <db_delete> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(2828) find_export: found <db_update> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(2828) mod_init(): Database connection opened successfuly 0(2828) DEBUG: init_mod: registrar 0(2828) registrar - initializing 0(2828) find_export: found <sl_send_reply> in module sl_module [/usr/local/lib/ser/modules/sl.so] 0(2828) find_export: found <ul_bind_usrloc> in module usrloc [/usr/local/lib/ser/modules/usrloc.so] 0(2828) find_export: found <ul_register_udomain> in module usrloc [/usr/local/lib/ser/modules/usrloc.so] 0(2828) find_export: found <ul_get_all_ucontacts> in module usrloc [/usr/local/lib/ser/modules/usrloc.so] 0(2828) find_export: found <ul_insert_urecord> in module usrloc [/usr/local/lib/ser/modules/usrloc.so] 0(2828) find_export: found <ul_delete_urecord> in module usrloc [/usr/local/lib/ser/modules/usrloc.so] 0(2828) find_export: found <ul_get_urecord> in module usrloc [/usr/local/lib/ser/modules/usrloc.so] 0(2828) find_export: found <ul_lock_udomain> in module usrloc [/usr/local/lib/ser/modules/usrloc.so] 0(2828) find_export: found <ul_unlock_udomain> in module usrloc [/usr/local/lib/ser/modules/usrloc.so] 0(2828) find_export: found <ul_release_urecord> in module usrloc [/usr/local/lib/ser/modules/usrloc.so] 0(2828) find_export: found <ul_insert_ucontact> in module usrloc [/usr/local/lib/ser/modules/usrloc.so] 0(2828) find_export: found <ul_delete_ucontact> in module usrloc [/usr/local/lib/ser/modules/usrloc.so] 0(2828) find_export: found <ul_get_ucontact> in module usrloc [/usr/local/lib/ser/modules/usrloc.so] 0(2828) find_export: found <ul_update_ucontact> in module usrloc [/usr/local/lib/ser/modules/usrloc.so] 0(0) fixing /usr/local/lib/ser/modules/maxfwd.so mf_process_maxfwd_header 0(0) fixing /usr/local/lib/ser/modules/sl.so sl_send_reply 0(0) fixing /usr/local/lib/ser/modules/sl.so sl_send_reply 0(0) fixing /usr/local/lib/ser/modules/rr.so record_route 0(0) fixing /usr/local/lib/ser/modules/rr.so loose_route 0(0) fixing /usr/local/lib/ser/modules/tm.so t_relay 0(0) fixing /usr/local/lib/ser/modules/registrar.so save 0(0) preload_udomain(): Table is empty 0(0) fixing /usr/local/lib/ser/modules/sl.so sl_send_reply 0(0) fixing /usr/local/lib/ser/modules/registrar.so lookup 0(0) preload_udomain(): Table is empty 0(0) fixing /usr/local/lib/ser/modules/registrar.so lookup 0(0) fixing /usr/local/lib/ser/modules/tm.so t_relay 0(0) fixing /usr/local/lib/ser/modules/sl.so sl_reply_error 0(0) fixing /usr/local/lib/ser/modules/sl.so sl_send_reply 0(0) fixing /usr/local/lib/ser/modules/tm.so t_relay 0(0) INFO: udp_init: SO_RCVBUF is initially 65535 0(0) DEBUG: udp_init: trying SO_RCVBUF: 131070 0(0) DEBUG: setting SO_RCVBUF; set=131070,verify=131070 0(0) DEBUG: udp_init: trying SO_RCVBUF: 262140 0(0) DEBUG: setting SO_RCVBUF; set=262140,verify=131070 0(0) DEBUG: setting SO_RCVBUF has no effect 0(0) DEBUG: udp_init: trying SO_RCVBUF: 133118 0(0) DEBUG: setting SO_RCVBUF; set=133118,verify=131070 0(0) DEBUG: setting SO_RCVBUF has no effect 0(0) INFO: udp_init: SO_RCVBUF is finally 131070 0(0) INFO: udp_init: SO_RCVBUF is initially 65535 0(0) DEBUG: udp_init: trying SO_RCVBUF: 131070 0(0) DEBUG: setting SO_RCVBUF; set=131070,verify=131070 0(0) DEBUG: udp_init: trying SO_RCVBUF: 262140 0(0) DEBUG: setting SO_RCVBUF; set=262140,verify=131070 0(0) DEBUG: setting SO_RCVBUF has no effect 0(0) DEBUG: udp_init: trying SO_RCVBUF: 133118 0(0) DEBUG: setting SO_RCVBUF; set=133118,verify=131070 0(0) DEBUG: setting SO_RCVBUF has no effect 0(0) INFO: udp_init: SO_RCVBUF is finally 131070 1(0) DEBUG: init_mod_child (1): tm 1(0) DEBUG: callid: '6bb7bddf-0(a)10.0.1.139' 1(0) DEBUG: init_mod_child (1): usrloc 2(0) DEBUG: init_mod_child (2): tm 2(0) DEBUG: callid: '6bb7bddf-0(a)10.0.1.139' 2(0) DEBUG: init_mod_child (2): usrloc 3(0) DEBUG: init_mod_child (3): tm 3(0) DEBUG: callid: '6bb7bddf-0(a)10.0.1.139' 3(0) DEBUG: init_mod_child (3): usrloc 4(0) DEBUG: init_mod_child (4): tm 4(0) DEBUG: callid: '6bb7bddf-0(a)10.0.1.139' 4(0) DEBUG: init_mod_child (4): usrloc 5(0) DEBUG: init_mod_child (1): tm 5(0) DEBUG: callid: '6bb7bddf-0(a)127.0.0.1' 5(0) DEBUG: init_mod_child (1): usrloc 7(0) DEBUG: init_mod_child (3): tm 7(0) DEBUG: callid: '6bb7bddf-0(a)127.0.0.1' 7(0) DEBUG: init_mod_child (3): usrloc 8(0) DEBUG: init_mod_child (4): tm 8(0) DEBUG: callid: '6bb7bddf-0(a)127.0.0.1' 8(0) DEBUG: init_mod_child (4): usrloc 8(2844) DBG: open_uac_fifo: opening fifo... 8(2844) DEBUG: open_fifo_server: FIFO stat failed: Success 8(2844) DEBUG: FIFO created @ /tmp/ser_fifo 8(2844) DEBUG: fifo /tmp/ser_fifo opened, mode=432 9(0) INFO: fifo process starting: 2846 9(0) DEBUG: init_mod_child (-2): tm 9(0) DEBUG: callid: '6bb7bddf-0(a)10.0.1.139' 9(0) DEBUG: init_mod_child (-2): usrloc 10(0) DEBUG: init_mod_child (-1): tm 10(0) DEBUG: callid: '6bb7bddf-0(a)10.0.1.139' 10(0) DEBUG: init_mod_child (-1): usrloc 11(0) DEBUG: init_mod_child (5): tm 11(0) DEBUG: callid: '6bb7bddf-0(a)10.0.1.139' 11(0) DEBUG: init_mod_child (5): usrloc 9(2846) SER: open_uac_fifo: fifo server up at /tmp/ser_fifo... 6(0) DEBUG: init_mod_child (2): tm 6(2841) DEBUG: callid: '6bb7bddf-2841(a)127.0.0.1' 6(2841) DEBUG: init_mod_child (2): usrloc 12(0) DEBUG: init_mod_child (6): tm 12(0) DEBUG: callid: '6bb7bddf-0(a)10.0.1.139' 12(0) DEBUG: init_mod_child (6): usrloc 13(0) DEBUG: init_mod_child (7): tm 13(0) DEBUG: callid: '6bb7bddf-0(a)10.0.1.139' 13(0) DEBUG: init_mod_child (7): usrloc 14(0) DEBUG: init_mod_child (8): tm 14(0) DEBUG: callid: '6bb7bddf-0(a)10.0.1.139' 14(0) DEBUG: init_mod_child (8): usrloc 15(0) DEBUG: init_mod_child (-4): tm 15(0) DEBUG: callid: '6bb7bddf-0(a)10.0.1.139' 15(0) DEBUG: init_mod_child (-4): usrloc 0(2828) DEBUG: init_mod_child (0): tm 0(2828) DEBUG: callid: '6bb7bddf-2828(a)10.0.1.139' 0(2828) DEBUG: init_mod_child (0): usrloc sip:gwenael@arwen-tech.fr 200 Added to table ('1234','sip:gwenael@arwen-tech.fr') to 'aliases' sip:boris@arwen-tech.fr 200 Added to table ('5678','sip:boris@arwen-tech.fr') to 'aliases' [root@Linux local]# 1(2831) ERROR: receive_msg: no mem for sip_msg 2(2833) ERROR: receive_msg: no mem for sip_msg 3(2835) ERROR: receive_msg: no mem for sip_msg 4(2837) ERROR: receive_msg: no mem for sip_msg 1(2831) ERROR: receive_msg: no mem for sip_msg 2(2833) ERROR: receive_msg: no mem for sip_msg 3(2835) DEBUG: probing packet received 4(2837) ERROR: receive_msg: no mem for sip_msg 1(2831) ERROR: receive_msg: no mem for sip_msg 2(2833) ERROR: receive_msg: no mem for sip_msg 3(2835) ERROR: receive_msg: no mem for sip_msg 4(2837) ERROR: receive_msg: no mem for sip_msg 1(2831) ERROR: receive_msg: no mem for sip_msg 2(2833) ERROR: receive_msg: no mem for sip_msg 3(2835) ERROR: receive_msg: no mem for sip_msg 4(2837) ERROR: receive_msg: no mem for sip_msg 1(2831) ERROR: receive_msg: no mem for sip_msg 10(2848) Binding '1234','sip:gwenael@arwen-tech.fr' has expired 10(2848) Binding '5678','sip:boris@arwen-tech.fr' has expired 2(2833) ERROR: receive_msg: no mem for sip_msg 3(2835) ERROR: receive_msg: no mem for sip_msg 4(2837) ERROR: receive_msg: no mem for sip_msg 1(2831) ERROR: receive_msg: no mem for sip_msg 2(2833) ERROR: receive_msg: no mem for sip_msg 3(2835) ERROR: receive_msg: no mem for sip_msg 4(2837) ERROR: receive_msg: no mem for sip_msg 1(2831) ERROR: receive_msg: no mem for sip_msg

...

can you send the whole ser output? don't forget to set debug=9, to get as much as possible. bogdan g.billoudet(a)arwen-tech.fr wrote:

On 09-11 14:26, E. Versaevel wrote:

First of all put a linebreak between them, they should not be on the same line, and if I'm not mistaken the sql url should be sql://user:password@server/database not mysql://

_______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

Bogdan-Andrei IANCU

10:01 a.m.

New subject: [Serusers] receive_msg: no mem for sip_msg

my first guess is that use at start-up time you have an intensive private memory consumer which gets into conflict with the SIP messages receiver. Judging after the error (in receive loop) I'm sure you have some SIP traffic at start-up - please check with tcpdump or ngrep - it can be a REGISTER, SUBSCRIBE, etc Looking into your script, I would say only usrloc can be the intensive private memory consumer - if you have a lot of entries in DB (usrloc and aliases). To check this theory, try to start ser with DB disabled in usrloc; set: modparam("usrloc", "db_mode", 0) please see if you still get the error and also please confirm if you have or not sip traffic. bogdan g.billoudet(a)arwen-tech.fr wrote:

...

Jan Janak

11:31 a.m.

New subject: [Serusers] receive_msg: no mem for sip_msg

On 10-11 10:01, Bogdan-Andrei IANCU wrote:

...

I don't think this is the problem. usrloc consumes private memory before SER forks (and at that stage it does not process SIP messages), when re-loading data from the database. It would fail to start if this was the problem, so I think there must be some other memory problem. What version fo ser are you using (ser -V) ? Jan.

...

g.billoudet(a)arwen-tech.fr wrote:

Bogdan-Andrei IANCU

11:41 a.m.

New subject: [Serusers] receive_msg: no mem for sip_msg

Jan Janak wrote:

...

On 10-11 10:01, Bogdan-Andrei IANCU wrote:

I was considering the possibility of memory fragmentation. If there are a lot of usrloc/aliases records to be loaded, memory can get to fragmented to be able later to alloced a bigger size chunk. bogdan

...

What version fo ser are you using (ser -V) ? Jan.

Jan Janak

11:54 a.m.

New subject: [Serusers] receive_msg: no mem for sip_msg

On 10-11 11:41, Bogdan-Andrei IANCU wrote:

...

Jan Janak wrote:

On 10-11 10:01, Bogdan-Andrei IANCU wrote:

I was considering the possibility of memory fragmentation. If there are a lot of usrloc/aliases records to be loaded, memory can get to fragmented to be able later to alloced a bigger size chunk.

Bot tables (aliases, location) are empty: 0(0) preload_udomain(): Table is empty 0(0) fixing /usr/local/lib/ser/modules/sl.so sl_send_reply 0(0) fixing /usr/local/lib/ser/modules/registrar.so lookup 0(0) preload_udomain(): Table is empty Jan.

g.billoudet＠arwen-tech.fr

1:25 p.m.

New subject: [Serusers] receive_msg: no mem for sip_msg

Hi, thanks for help I used serctl alias add 1234 sip:gwenael@arwen-tech.fr just after starting ser : - When I set modparam("usrloc", "db_mode", 0), ser works fine and I can have phone calls but I can't use this alias of course... - When I ser modparam("usrloc", "db_mode", 1), ser just doesn't work at all. My aliases table is empty when I start ser. I am using ser 0.8.12. Gwen

...

On 10-11 11:41, Bogdan-Andrei IANCU wrote:

Jan Janak wrote:

On 10-11 10:01, Bogdan-Andrei IANCU wrote: >my first guess is that use at start-up time you have an intensive >private memory consumer which gets into conflict with the SIP messages >receiver. > >Judging after the error (in receive loop) I'm sure you have some SIP >traffic at start-up - please check with tcpdump or ngrep - it can be

>REGISTER, SUBSCRIBE, etc > >Looking into your script, I would say only usrloc can be the intensive >private memory consumer - if you have a lot of entries in DB (usrloc

and

aliases). To check this theory, try to start ser with DB disabled in usrloc; set: modparam("usrloc", "db_mode", 0) please see if you still get the error and also please confirm if you have or not sip traffic.

I don't think this is the problem. usrloc consumes private memory before SER forks (and at that stage it does not process SIP

messages),

when re-loading data from the database. It would fail to start if

this

was the problem, so I think there must be some other memory problem.

I was considering the possibility of memory fragmentation. If there are a lot of usrloc/aliases records to be loaded, memory can get to fragmented to be able later to alloced a bigger size chunk.

Bogdan-Andrei IANCU

2:27 p.m.

New subject: [Serusers] receive_msg: no mem for sip_msg

Hi Gwen, try to set back db_mode to 1 or 2 but without adding the aliases via serctl. I'm trying to figure out if it's a problem in DB part or in fifo part of usrloc. bogdan g.billoudet(a)arwen-tech.fr wrote:

...

On 10-11 11:41, Bogdan-Andrei IANCU wrote:

Jan Janak wrote:

>REGISTER, SUBSCRIBE, etc > >Looking into your script, I would say only usrloc can be the intensive >private memory consumer - if you have a lot of entries in DB (usrloc

and

>aliases). To check this theory, try to start ser with DB disabled in >usrloc; set: > modparam("usrloc", "db_mode", 0) > >please see if you still get the error and also please confirm if you >have or not sip traffic. I don't think this is the problem. usrloc consumes private memory before SER forks (and at that stage it does not process SIP

messages),

when re-loading data from the database. It would fail to start if

this

was the problem, so I think there must be some other memory problem.

I was considering the possibility of memory fragmentation. If there are a lot of usrloc/aliases records to be loaded, memory can get to fragmented to be able later to alloced a bigger size chunk.

Jan Janak

2:34 p.m.

New subject: [Serusers] receive_msg: no mem for sip_msg

Try to install 0.8.14. Jan. On 10-11 14:27, Bogdan-Andrei IANCU wrote:

...

On 10-11 11:41, Bogdan-Andrei IANCU wrote:

Jan Janak wrote: >On 10-11 10:01, Bogdan-Andrei IANCU wrote: > > >>my first guess is that use at start-up time you have an intensive >>private memory consumer which gets into conflict with the SIP messages >>receiver. >> >>Judging after the error (in receive loop) I'm sure you have some SIP >>traffic at start-up - please check with tcpdump or ngrep - it can be a >>REGISTER, SUBSCRIBE, etc >> >>Looking into your script, I would say only usrloc can be the intensive >>private memory consumer - if you have a lot of entries in DB (usrloc and >>aliases). To check this theory, try to start ser with DB disabled in >>usrloc; set: >> modparam("usrloc", "db_mode", 0) >> >>please see if you still get the error and also please confirm if you >>have or not sip traffic. > > >I don't think this is the problem. usrloc consumes private memory >before SER forks (and at that stage it does not process SIP messages), >when re-loading data from the database. It would fail to start if this >was the problem, so I think there must be some other memory problem. I was considering the possibility of memory fragmentation. If there are a lot of usrloc/aliases records to be loaded, memory can get to fragmented to be able later to alloced a bigger size chunk.

g.billoudet＠arwen-tech.fr

4:32 p.m.

New subject: [Serusers] receive_msg: no mem for sip_msg

...

Try to install 0.8.14. Jan. On 10-11 14:27, Bogdan-Andrei IANCU wrote:

Hi, thanks for help I used serctl alias add 1234 sip:gwenael@arwen-tech.fr just after

starting

ser : - When I set modparam("usrloc", "db_mode", 0), ser works fine and I can have phone calls but I can't use this alias of course... - When I ser modparam("usrloc", "db_mode", 1), ser just doesn't work at all. My aliases table is empty when I start ser. I am using ser 0.8.12. Gwen >On 10-11 11:41, Bogdan-Andrei IANCU wrote: > >>Jan Janak wrote: >> >>>On 10-11 10:01, Bogdan-Andrei IANCU wrote: >>> >>> >>>>my first guess is that use at start-up time you have an intensive >>>>private memory consumer which gets into conflict with the SIP

messages

>>>>receiver. >>>> >>>>Judging after the error (in receive loop) I'm sure you have some

SIP

>>>>traffic at start-up - please check with tcpdump or ngrep - it can

>> >>a >> >>>>REGISTER, SUBSCRIBE, etc >>>> >>>>Looking into your script, I would say only usrloc can be the

intensive

>>>>private memory consumer - if you have a lot of entries in DB

(usrloc

>> >>and >> >>>>aliases). To check this theory, try to start ser with DB disabled

>>>>usrloc; set: >>>> modparam("usrloc", "db_mode", 0) >>>> >>>>please see if you still get the error and also please confirm if

you

>>>>have or not sip traffic. >>> >>> >>>I don't think this is the problem. usrloc consumes private memory >>>before SER forks (and at that stage it does not process SIP >> >>messages), >> >>>when re-loading data from the database. It would fail to start if >> >>this >> >>>was the problem, so I think there must be some other memory problem. >> >>I was considering the possibility of memory fragmentation. If there

are

>a lot of usrloc/aliases records to be loaded, memory can get to >fragmented to be able later to alloced a bigger size chunk. Bot tables (aliases, location) are empty: 0(0) preload_udomain(): Table is empty 0(0) fixing /usr/local/lib/ser/modules/sl.so sl_send_reply 0(0) fixing /usr/local/lib/ser/modules/registrar.so lookup 0(0) preload_udomain(): Table is empty Jan.

Bogdan-Andrei IANCU

4:36 p.m.

New subject: [Serusers] receive_msg: no mem for sip_msg

Hi Gwen, it will be safer to uninstall first the 0.8.12 version. out of curiosity, since the problem you reported is quite strange, have you tried db_mod 2? bogdan g.billoudet(a)arwen-tech.fr wrote:

...

Try to install 0.8.14. Jan. On 10-11 14:27, Bogdan-Andrei IANCU wrote: >Hi Gwen, > >try to set back db_mode to 1 or 2 but without adding the aliases via >serctl. I'm trying to figure out if it's a problem in DB part or in fifo >part of usrloc. > >bogdan > >g.billoudet(a)arwen-tech.fr wrote: > > >>Hi, thanks for help >> >>I used serctl alias add 1234 sip:gwenael@arwen-tech.fr just after >> >> >starting > > >>ser : >>- When I set modparam("usrloc", "db_mode", 0), ser works fine and I can >>have phone calls but I can't use this alias of course... >>- When I ser modparam("usrloc", "db_mode", 1), ser just doesn't work at >>all. >> >>My aliases table is empty when I start ser. I am using ser 0.8.12. >> >> Gwen >> >> >> >> >> >>>On 10-11 11:41, Bogdan-Andrei IANCU wrote: >>> >>> >>> >>>>Jan Janak wrote: >>>> >>>> >>>> >>>>>On 10-11 10:01, Bogdan-Andrei IANCU wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>my first guess is that use at start-up time you have an intensive >>>>>>private memory consumer which gets into conflict with the SIP >>>>>> >>>>>> >messages > > >>>>>>receiver. >>>>>> >>>>>>Judging after the error (in receive loop) I'm sure you have some >>>>>> >>>>>> >SIP > > >>>>>>traffic at start-up - please check with tcpdump or ngrep - it can >>>>>> >>>>>> >be > > >>>>a >>>> >>>> >>>> >>>>>>REGISTER, SUBSCRIBE, etc >>>>>> >>>>>>Looking into your script, I would say only usrloc can be the >>>>>> >>>>>> >intensive > > >>>>>>private memory consumer - if you have a lot of entries in DB >>>>>> >>>>>> >(usrloc > > >>>>and >>>> >>>> >>>> >>>>>>aliases). To check this theory, try to start ser with DB disabled >>>>>> >>>>>> >in > > >>>>>>usrloc; set: >>>>>> modparam("usrloc", "db_mode", 0) >>>>>> >>>>>>please see if you still get the error and also please confirm if >>>>>> >>>>>> >you > > >>>>>>have or not sip traffic. >>>>>> >>>>>> >>>>>I don't think this is the problem. usrloc consumes private memory >>>>>before SER forks (and at that stage it does not process SIP >>>>> >>>>> >>>>messages), >>>> >>>> >>>> >>>>>when re-loading data from the database. It would fail to start if >>>>> >>>>> >>>>this >>>> >>>> >>>> >>>>>was the problem, so I think there must be some other memory problem. >>>>> >>>>> >>>>I was considering the possibility of memory fragmentation. If there >>>> >>>> >are > > >>>>a lot of usrloc/aliases records to be loaded, memory can get to >>>>fragmented to be able later to alloced a bigger size chunk. >>>> >>>> >>>Bot tables (aliases, location) are empty: >>> >>> 0(0) preload_udomain(): Table is empty >>> 0(0) fixing /usr/local/lib/ser/modules/sl.so sl_send_reply >>> 0(0) fixing /usr/local/lib/ser/modules/registrar.so lookup >>> 0(0) preload_udomain(): Table is empty >>> >>> Jan. >>> >>> >>> >> >>

g.billoudet＠arwen-tech.fr

5:15 p.m.

New subject: [Serusers] receive_msg: no mem for sip_msg

Yes, I have the same problem with db_mode 2 I always get these lines : ERROR: receive_msg: no mem for sip_msg DEBUG: probing packet received I will upgrade to 0.8.14... Thank you Gwen

...

Hi Gwen, it will be safer to uninstall first the 0.8.12 version. out of curiosity, since the problem you reported is quite strange, have you tried db_mod 2? bogdan g.billoudet(a)arwen-tech.fr wrote:

Try to install 0.8.14. Jan. On 10-11 14:27, Bogdan-Andrei IANCU wrote: >Hi Gwen, > >try to set back db_mode to 1 or 2 but without adding the aliases via >serctl. I'm trying to figure out if it's a problem in DB part or in > fifo >part of usrloc. > >bogdan > >g.billoudet(a)arwen-tech.fr wrote: > > >>Hi, thanks for help >> >>I used serctl alias add 1234 sip:gwenael@arwen-tech.fr just after >> >> >starting > > >>ser : >>- When I set modparam("usrloc", "db_mode", 0), ser works fine and I >> can >>have phone calls but I can't use this alias of course... >>- When I ser modparam("usrloc", "db_mode", 1), ser just doesn't work >> at >>all. >> >>My aliases table is empty when I start ser. I am using ser 0.8.12. >> >> Gwen >> >> >> >> >> >>>On 10-11 11:41, Bogdan-Andrei IANCU wrote: >>> >>> >>> >>>>Jan Janak wrote: >>>> >>>> >>>> >>>>>On 10-11 10:01, Bogdan-Andrei IANCU wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>my first guess is that use at start-up time you have an intensive >>>>>>private memory consumer which gets into conflict with the SIP >>>>>> >>>>>> >messages > > >>>>>>receiver. >>>>>> >>>>>>Judging after the error (in receive loop) I'm sure you have some >>>>>> >>>>>> >SIP > > >>>>>>traffic at start-up - please check with tcpdump or ngrep - it can >>>>>> >>>>>> >be > > >>>>a >>>> >>>> >>>> >>>>>>REGISTER, SUBSCRIBE, etc >>>>>> >>>>>>Looking into your script, I would say only usrloc can be the >>>>>> >>>>>> >intensive > > >>>>>>private memory consumer - if you have a lot of entries in DB >>>>>> >>>>>> >(usrloc > > >>>>and >>>> >>>> >>>> >>>>>>aliases). To check this theory, try to start ser with DB disabled >>>>>> >>>>>> >in > > >>>>>>usrloc; set: >>>>>> modparam("usrloc", "db_mode", 0) >>>>>> >>>>>>please see if you still get the error and also please confirm if >>>>>> >>>>>> >you > > >>>>>>have or not sip traffic. >>>>>> >>>>>> >>>>>I don't think this is the problem. usrloc consumes private memory >>>>>before SER forks (and at that stage it does not process SIP >>>>> >>>>> >>>>messages), >>>> >>>> >>>> >>>>>when re-loading data from the database. It would fail to start if >>>>> >>>>> >>>>this >>>> >>>> >>>> >>>>>was the problem, so I think there must be some other memory >>>>> problem. >>>>> >>>>> >>>>I was considering the possibility of memory fragmentation. If there >>>> >>>> >are > > >>>>a lot of usrloc/aliases records to be loaded, memory can get to >>>>fragmented to be able later to alloced a bigger size chunk. >>>> >>>> >>>Bot tables (aliases, location) are empty: >>> >>> 0(0) preload_udomain(): Table is empty >>> 0(0) fixing /usr/local/lib/ser/modules/sl.so sl_send_reply >>> 0(0) fixing /usr/local/lib/ser/modules/registrar.so lookup >>> 0(0) preload_udomain(): Table is empty >>> >>> Jan. >>> >>> >>> >> >>

g.billoudet＠arwen-tech.fr

17 Nov 17 Nov

1:51 p.m.

New subject: [Serusers] receive_msg: no mem for sip_msg

Hi, I am back with my problem... I installed ser 0.8.14 on another computer (I bought it last week) but I still have the same problem : ERROR: receive_msg: no mem for sip_msg Is it a bug of ser ? Does it come from mysql 4.0.18 ? Gwen

...

Yes, I have the same problem with db_mode 2 I always get these lines : ERROR: receive_msg: no mem for sip_msg DEBUG: probing packet received I will upgrade to 0.8.14... Thank you Gwen

Hi Gwen, it will be safer to uninstall first the 0.8.12 version. out of curiosity, since the problem you reported is quite strange, have you tried db_mod 2? bogdan g.billoudet(a)arwen-tech.fr wrote:

Try to install 0.8.14. Jan. On 10-11 14:27, Bogdan-Andrei IANCU wrote: >Hi Gwen, > >try to set back db_mode to 1 or 2 but without adding the aliases via >serctl. I'm trying to figure out if it's a problem in DB part or in > fifo >part of usrloc. > >bogdan > >g.billoudet(a)arwen-tech.fr wrote: > > >>Hi, thanks for help >> >>I used serctl alias add 1234 sip:gwenael@arwen-tech.fr just after >> >> >starting > > >>ser : >>- When I set modparam("usrloc", "db_mode", 0), ser works fine and I >> can >>have phone calls but I can't use this alias of course... >>- When I ser modparam("usrloc", "db_mode", 1), ser just doesn't work >> at >>all. >> >>My aliases table is empty when I start ser. I am using ser 0.8.12. >> >> Gwen >> >> >> >> >> >>>On 10-11 11:41, Bogdan-Andrei IANCU wrote: >>> >>> >>> >>>>Jan Janak wrote: >>>> >>>> >>>> >>>>>On 10-11 10:01, Bogdan-Andrei IANCU wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>my first guess is that use at start-up time you have an intensive >>>>>>private memory consumer which gets into conflict with the SIP >>>>>> >>>>>> >messages > > >>>>>>receiver. >>>>>> >>>>>>Judging after the error (in receive loop) I'm sure you have some >>>>>> >>>>>> >SIP > > >>>>>>traffic at start-up - please check with tcpdump or ngrep - it >>>>>> can >>>>>> >>>>>> >be > > >>>>a >>>> >>>> >>>> >>>>>>REGISTER, SUBSCRIBE, etc >>>>>> >>>>>>Looking into your script, I would say only usrloc can be the >>>>>> >>>>>> >intensive > > >>>>>>private memory consumer - if you have a lot of entries in DB >>>>>> >>>>>> >(usrloc > > >>>>and >>>> >>>> >>>> >>>>>>aliases). To check this theory, try to start ser with DB disabled >>>>>> >>>>>> >in > > >>>>>>usrloc; set: >>>>>> modparam("usrloc", "db_mode", 0) >>>>>> >>>>>>please see if you still get the error and also please confirm if >>>>>> >>>>>> >you > > >>>>>>have or not sip traffic. >>>>>> >>>>>> >>>>>I don't think this is the problem. usrloc consumes private memory >>>>>before SER forks (and at that stage it does not process SIP >>>>> >>>>> >>>>messages), >>>> >>>> >>>> >>>>>when re-loading data from the database. It would fail to start if >>>>> >>>>> >>>>this >>>> >>>> >>>> >>>>>was the problem, so I think there must be some other memory >>>>> problem. >>>>> >>>>> >>>>I was considering the possibility of memory fragmentation. If there >>>> >>>> >are > > >>>>a lot of usrloc/aliases records to be loaded, memory can get to >>>>fragmented to be able later to alloced a bigger size chunk. >>>> >>>> >>>Bot tables (aliases, location) are empty: >>> >>> 0(0) preload_udomain(): Table is empty >>> 0(0) fixing /usr/local/lib/ser/modules/sl.so sl_send_reply >>> 0(0) fixing /usr/local/lib/ser/modules/registrar.so lookup >>> 0(0) preload_udomain(): Table is empty >>> >>> Jan. >>> >>> >>> >> >>

g.billoudet＠arwen-tech.fr

5:34 p.m.

New subject: [Serusers] receive_msg: no mem for sip_msg

Hi, I worked all day on this error. Maybe the following information of my ser could be useful : [root@localhost sbin]# ser -V version: 0.8.14 (i386/linux) flags: STATS:Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 @(#) $Id: main.c,v 1.168.4.3 2004/06/28 15:41:21 andrei Exp $ main.c compiled on 12:28:01 Jul 27 2004 with gcc 2.95 [root@localhost sbin]# ser -d -d -d -d 0(3271) WARNING: could not rev. resolve 10.0.1.99 Listening on 10.0.1.99 [10.0.1.99]:5060 127.0.0.1 [127.0.0.1]:5060 Aliases: localhost:5060 10.0.1.99:* mairie-grigny69.fr:* stateless - initializing [root@localhost sbin]# Maxfwd module- initializing 0(3273) mod_init(): Database connection opened successfuly 0(0) INFO: udp_init: SO_RCVBUF is initially 65535 0(0) INFO: udp_init: SO_RCVBUF is finally 131070 0(0) INFO: udp_init: SO_RCVBUF is initially 65535 0(0) INFO: udp_init: SO_RCVBUF is finally 131070 9(0) INFO: fifo process starting: 3289 9(3289) SER: open_uac_fifo: fifo server up at /tmp/ser_fifo... 1(3275) ERROR: receive_msg: no mem for sip_msg 2(3277) ERROR: receive_msg: no mem for sip_msg 4(3281) ERROR: receive_msg: no mem for sip_msg 1(3275) ERROR: receive_msg: no mem for sip_msg Here, only one of my X-Lite client tried to log in. After those 4 errors, X-Lite said "logging time-out"... Thanks for your help (in advance) :-) Gwen

...

Yes, I have the same problem with db_mode 2 I always get these lines : ERROR: receive_msg: no mem for sip_msg DEBUG: probing packet received I will upgrade to 0.8.14... Thank you Gwen

Hi Gwen, it will be safer to uninstall first the 0.8.12 version. out of curiosity, since the problem you reported is quite strange, have you tried db_mod 2? bogdan g.billoudet(a)arwen-tech.fr wrote:

Hi, If I don't use "serctl alias add", I still get the same error message... I will try to upgrade ser: - Should I uninstall ser 0.8.12 and then install 0.8.14 - Or should I install 0.8.14 directly ? Thanks Gwen >Try to install 0.8.14. > > Jan. > >On 10-11 14:27, Bogdan-Andrei IANCU wrote: > > >>Hi Gwen, >> >>try to set back db_mode to 1 or 2 but without adding the aliases via >>serctl. I'm trying to figure out if it's a problem in DB part or in >> fifo >>part of usrloc. >> >>bogdan >> >>g.billoudet(a)arwen-tech.fr wrote: >> >> >>>Hi, thanks for help >>> >>>I used serctl alias add 1234 sip:gwenael@arwen-tech.fr just after >>> >>> >>starting >> >> >>>ser : >>>- When I set modparam("usrloc", "db_mode", 0), ser works fine and I >>> can >>>have phone calls but I can't use this alias of course... >>>- When I ser modparam("usrloc", "db_mode", 1), ser just doesn't work >>> at >>>all. >>> >>>My aliases table is empty when I start ser. I am using ser 0.8.12. >>> >>> Gwen >>> >>> >>> >>> >>> >>>>On 10-11 11:41, Bogdan-Andrei IANCU wrote: >>>> >>>> >>>> >>>>>Jan Janak wrote: >>>>> >>>>> >>>>> >>>>>>On 10-11 10:01, Bogdan-Andrei IANCU wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>my first guess is that use at start-up time you have an >>>>>>> intensive >>>>>>>private memory consumer which gets into conflict with the SIP >>>>>>> >>>>>>> >>messages >> >> >>>>>>>receiver. >>>>>>> >>>>>>>Judging after the error (in receive loop) I'm sure you have some >>>>>>> >>>>>>> >>SIP >> >> >>>>>>>traffic at start-up - please check with tcpdump or ngrep - it >>>>>>> can >>>>>>> >>>>>>> >>be >> >> >>>>>a >>>>> >>>>> >>>>> >>>>>>>REGISTER, SUBSCRIBE, etc >>>>>>> >>>>>>>Looking into your script, I would say only usrloc can be the >>>>>>> >>>>>>> >>intensive >> >> >>>>>>>private memory consumer - if you have a lot of entries in DB >>>>>>> >>>>>>> >>(usrloc >> >> >>>>>and >>>>> >>>>> >>>>> >>>>>>>aliases). To check this theory, try to start ser with DB >>>>>>> disabled >>>>>>> >>>>>>> >>in >> >> >>>>>>>usrloc; set: >>>>>>> modparam("usrloc", "db_mode", 0) >>>>>>> >>>>>>>please see if you still get the error and also please confirm if >>>>>>> >>>>>>> >>you >> >> >>>>>>>have or not sip traffic. >>>>>>> >>>>>>> >>>>>>I don't think this is the problem. usrloc consumes private memory >>>>>>before SER forks (and at that stage it does not process SIP >>>>>> >>>>>> >>>>>messages), >>>>> >>>>> >>>>> >>>>>>when re-loading data from the database. It would fail to start if >>>>>> >>>>>> >>>>>this >>>>> >>>>> >>>>> >>>>>>was the problem, so I think there must be some other memory >>>>>> problem. >>>>>> >>>>>> >>>>>I was considering the possibility of memory fragmentation. If >>>>> there >>>>> >>>>> >>are >> >> >>>>>a lot of usrloc/aliases records to be loaded, memory can get to >>>>>fragmented to be able later to alloced a bigger size chunk. >>>>> >>>>> >>>>Bot tables (aliases, location) are empty: >>>> >>>> 0(0) preload_udomain(): Table is empty >>>> 0(0) fixing /usr/local/lib/ser/modules/sl.so sl_send_reply >>>> 0(0) fixing /usr/local/lib/ser/modules/registrar.so lookup >>>> 0(0) preload_udomain(): Table is empty >>>> >>>> Jan. >>>> >>>> >>>> >>> >>>

Andrei Pelinescu-Onciul

6:47 p.m.

New subject: [Serusers] receive_msg: no mem for sip_msg

On Nov 17, 2004 at 17:34, g.billoudet(a)arwen-tech.fr <g.billoudet(a)arwen-tech.fr> wrote:

...

You could try to increase PKG_MEM_POOL_SIZE to 4096*1024 in config.h, recompile and see if it works. What's very strange is you don't seem to have anything consuming all this memory (empty db). Anyway, whether the above fix works or not, please try also compiling in malloc debug support. Set PKG_MEM_POOL_SIZE back to 1024*1024, edit Makefile.defs, remove -DF_MALLOC, add instead -DDBG_QM_MALLOC and recompile (make proper; make all). Set a high debuging level (e.g.: ser -dddddd), send a SIGUSR1 to one of the ser processes (it would be better if it won't be the first one), try to reproduce your out of memory condition and send another SIGUSR1 to the pid listed in the error message in the log. Stop ser (killall -TERM ser) and send me the log. Thanks, Andrei

g.billoudet＠arwen-tech.fr

18 Nov 18 Nov

10:34 a.m.

New subject: [Serusers] receive_msg: no mem for sip_msg

...

On Nov 17, 2004 at 17:34, g.billoudet(a)arwen-tech.fr <g.billoudet(a)arwen-tech.fr> wrote:

Daniel-Constantin Mierla

10:43 a.m.

New subject: [Serusers] receive_msg: no mem for sip_msg

Looks like you didn't compile the modules with new flags. Do: make proper include_modules="mysql"; make; make modules include_modules="mysql"; make install include_modules="mysql". Then try again. Daniel On 11/18/04 10:34, g.billoudet(a)arwen-tech.fr wrote:

...

Hi, thanks for your help Andrei I set PKG_MEM_POOL_SIZE to 4096*1024 and I still had the same error. So I set back PKG_MEM_POOL_SIZE to 1024*1024, edit Makefile.defs, remove -DF_MALLOC and add instead -DDBG_QM_MALLOC. Unfortunately, the modules can't be loaded (undefined symbol: fm_malloc). It's so strange that I got the same error with two different computers... as I installed both ser (0.8.12 and 0.8.14) the same way with same mysql 4.0.18, there might be something wrong there... On the other hand, the installation of ser is so easy, I'm not really sure the error comes from there... Does this error really nether happened to anybody else ? Thanks Gwen [root@localhost ser-0.8.14]# ser -V version: 0.8.14 (i386/linux) flags: STATS:Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 @(#) $Id: main.c,v 1.168.4.3 2004/06/28 15:41:21 andrei Exp $ main.c compiled on 10:15:39 Nov 18 2004 with gcc 3.3 [root@localhost ser-0.8.14]# [root@localhost ser-0.8.14]# [root@localhost ser-0.8.14]# ser -dddddd 0(11966) ERROR: load_module: could not open module </usr/local/lib/ser/modules/mysql.so>: /usr/local/lib/ser/modules/mysql.so: undefined symbol: fm_malloc 0(11966) parse error (23,13-49): failed to load module 0(11966) ERROR: load_module: could not open module </usr/local/lib/ser/modules/sl.so>: /usr/local/lib/ser/modules/sl.so: undefined symbol: fm_malloc 0(11966) parse error (24,13-46): failed to load module 0(11966) ERROR: load_module: could not open module </usr/local/lib/ser/modules/tm.so>: /usr/local/lib/ser/modules/tm.so: undefined symbol: fm_malloc 0(11966) parse error (25,13-46): failed to load module 0(11966) ERROR: load_module: could not open module </usr/local/lib/ser/modules/rr.so>: /usr/local/lib/ser/modules/rr.so: undefined symbol: fm_malloc 0(11966) parse error (26,13-46): failed to load module 0(11966) ERROR: load_module: could not open module </usr/local/lib/ser/modules/maxfwd.so>: /usr/local/lib/ser/modules/maxfwd.so: undefined symbol: fm_malloc 0(11966) parse error (27,13-50): failed to load module 0(11966) ERROR: load_module: could not open module </usr/local/lib/ser/modules/usrloc.so>: /usr/local/lib/ser/modules/usrloc.so: undefined symbol: fm_malloc 0(11966) parse error (28,13-50): failed to load module 0(11966) ERROR: load_module: could not open module </usr/local/lib/ser/modules/registrar.so>: /usr/local/lib/ser/modules/registrar.so: undefined symbol: fm_malloc 0(11966) parse error (29,13-53): failed to load module 0(11966) set_mod_param_regex: No module matching usrloc found | 0(11966) parse error (36,32-33): Can't set module parameter 0(11966) set_mod_param_regex: No module matching usrloc found | 0(11966) parse error (37,61-62): Can't set module parameter 0(11966) set_mod_param_regex: No module matching rr found | 0(11966) parse error (45,35-36): Can't set module parameter 0(11966) parse error (51,36-37): unknown command, missing loadmodule? 0(11966) parse error (53,38-39): unknown command, missing loadmodule? 0(11966) parse error (58,41-42): unknown command, missing loadmodule? 0(11966) parse error (62,15-16): unknown command, missing loadmodule? 0(11966) parse error (63,18-19): unknown command, missing loadmodule? 0(11966) parse error (64,11-12): unknown command, missing loadmodule? 0(11966) parse error (75,19-20): unknown command, missing loadmodule? 0(11966) parse error (78,24-25): unknown command, missing loadmodule? 0(11966) parse error (81,25-26): unknown command, missing loadmodule? 0(11966) parse error (83,36-37): unknown command, missing loadmodule? 0(11966) parse error (87,15-16): unknown command, missing loadmodule? 0(11966) parse error (89,18-19): unknown command, missing loadmodule? ERROR: bad config file (22 errors) >On Nov 17, 2004 at 17:34, g.billoudet(a)arwen-tech.fr ><g.billoudet(a)arwen-tech.fr> wrote: > > >>Hi, >> >>I worked all day on this error. Maybe the following information of my >>ser >>could be useful : >> >>[root@localhost sbin]# ser -V >>version: 0.8.14 (i386/linux) >>flags: STATS:Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, DNS_IP_HACK, >>SHM_MEM, >>SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT >>ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, >>MAX_URI_SIZE 1024, BUF_SIZE 65535 >>@(#) $Id: main.c,v 1.168.4.3 2004/06/28 15:41:21 andrei Exp $ >>main.c compiled on 12:28:01 Jul 27 2004 with gcc 2.95 >> >> >You could try to increase PKG_MEM_POOL_SIZE to 4096*1024 in config.h, >recompile and see if it works. >What's very strange is you don't seem to have anything consuming all >this memory (empty db). > >Anyway, whether the above fix works or not, please try also compiling in >malloc debug support. Set PKG_MEM_POOL_SIZE back to 1024*1024, > edit Makefile.defs, remove -DF_MALLOC, add instead -DDBG_QM_MALLOC and > recompile (make proper; make all). > >Set a high debuging level (e.g.: ser -dddddd), send a SIGUSR1 to > one of the ser processes (it would be better if it won't be the first > one), try to reproduce your out of memory condition and send another > SIGUSR1 to the pid listed in the error message in the log. Stop ser > (killall -TERM ser) and send me the log. > >Thanks, >Andrei > > > >------------------------------------------------------------------------ > >_______________________________________________ >Serusers mailing list >serusers(a)lists.iptel.org >http://lists.iptel.org/mailman/listinfo/serusers > >

g.billoudet＠arwen-tech.fr

11:52 a.m.

New subject: [Serusers] receive_msg: no mem for sip_msg

Hi Daniel, Hi Andrei, Thanks you so much !!!! It works now !! :-D I followed your instructions and now my phones can register and call... I also can use aliases... Great ! Thanks ! :-) Gwen

...

Andrei Pelinescu-Onciul

11:23 p.m.

New subject: [Serusers] receive_msg: no mem for sip_msg

On Nov 18, 2004 at 11:52, g.billoudet(a)arwen-tech.fr <g.billoudet(a)arwen-tech.fr> wrote:

...

Hi Daniel, Hi Andrei, Thanks you so much !!!! It works now !! :-D I followed your instructions and now my phones can register and call... I also can use aliases... Great !

Well, don't be so happy, we still haven't found out why it didn't work. In fact what you did is just compile with malloc debugging. This shouldn't have changed anything, apart form more log messages :-) This is really getting very strange... Andrei

Andrei Pelinescu-Onciul

9:10 p.m.

New subject: [Serusers] receive_msg: no mem for sip_msg

On Nov 18, 2004 at 10:34, g.billoudet(a)arwen-tech.fr <g.billoudet(a)arwen-tech.fr> wrote:

...

They are still trying to use fm_malloc. You've either not recompiled all of them (make proper; make all include_modules=mysql) or you forgot make install and you have some old modules in /usr/local/lib/ser/modules.

...

It's so strange that I got the same error with two different computers... as I installed both ser (0.8.12 and 0.8.14) the same way with same mysql 4.0.18, there might be something wrong there... On the other hand, the installation of ser is so easy, I'm not really sure the error comes from there... Does this error really nether happened to anybody else ?

No, or at least it was not reported before. It really looks very strange. Andrei

g.billoudet＠arwen-tech.fr

2 Nov 2 Nov

3:14 p.m.

New subject: [Serusers] lookup("aliases") doesn't work

Hi, I use lookup("aliases") in my ser.cfg file. I read the Admin Guide about 'User Aliases' but I can't make it work. I use lookup("aliases") just after (method=="REGISTER") as demonstrate in the Guide. I use serctl alias add 1234 sip:gwenael@arwen-tech.fr for a new alias. I have modparam("usrloc", "db_mode", 0), so I add the alias each time I reboot ser. (I can't use modparam("usrloc", "db_mode", 1)... see my previous post :-( Anyone has an idea about my lookup("aliases") problem ? Thanks Gwen # ----------- global configuration parameters ------------------------ debug=1 fork=yes log_stderror=yes memlog=0 sip_warning=yes listen=10.0.1.139 listen=127.0.0.1 check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) fifo="/tmp/ser_fifo" port=5060 children=4 alias="arwen-tech.fr" alias="10.0.1.139" # ------------------ module loading ---------------------------------- loadmodule "/usr/local/lib/ser/modules/mysql.so" loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so" # ----------------- setting module-specific parameters --------------- # -- usrloc params -- modparam("usrloc", "db_mode", 0) #modparam("usrloc", "db_url", "mysql://ser:heslo@localhost/ser") # -- rr params -- modparam("rr", "enable_full_lr", 1) # ------------------------- request routing logic ------------------- route{ if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); break; }; if ( msg:len > max_len ) { sl_send_reply("513", "Message too big"); break; }; record_route(); if (loose_route()) { t_relay(); break; }; if (uri == myself) { if (method=="REGISTER") { save("location"); sl_send_reply("200","REGISTER OK"); break; }; if (!lookup("aliases")) { log(1, "ALIASES FAILED\n"); }; if (lookup("location")) { log(1, "USER FOUND\n"); if (!t_relay()) { sl_reply_error(); }; } else { log(1, "USER NOT FOUND\n"); sl_send_reply("404", "User not found"); break; }; } else { log(1, "OUT REALM\n"); t_relay(); break; }; }

Marian Dumitru

7:23 p.m.

...

-- Voice Sistem http://www.voice-sistem.ro

Jiri Kuthan

3 Nov 3 Nov

9:32 a.m.

Nice. I'm wondering how the following line is supposed to be executed: if (!(avp_db_load($ruri/domain,"s:t_ips/ips") I mean -- how is $uri/domain interpreted? Or is it just missing " in the documented script version that confuses me? Thanks, -jiri At 07:23 PM 11/2/2004, Marian Dumitru wrote:

...

-- Voice Sistem http://www.voice-sistem.ro _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

-- Jiri Kuthan http://iptel.org/~jiri/

Marian Dumitru

8:50 p.m.

Hi Jiri, thanks for you documentation overview. Yes indeed, there is a small typing error. All module functions takes the parameters as quoted string. AFAIK only couple of core function breaks this rule. I will add the " as soon as possible and regenerate the documentation. Again, thanks for the report. Best regards, Marian Dumitru Jiri Kuthan wrote:

...

-- Voice Sistem http://www.voice-sistem.ro _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

-- Jiri Kuthan http://iptel.org/~jiri/

-- Voice Sistem http://www.voice-sistem.ro

Jan Janak

4 Nov 4 Nov

2:14 p.m.

When you are updating the documentation, I would suggest to mention one more thing: Using $to for any AVP operations might be a security hole, because To header field it not used in message processing and might not be related to the the real callee whose SIP URI is in the Request-URI. For example in the following message: INVITE sip:george.w.bush@whitehouse.gov SIP/2.0 To: sip:john.kerry@whitehouse.gov $to based avp_db_load would load AVPs for someone else than the message recipient. Jan. On 03-11 20:50, Marian Dumitru wrote:

...

-- Voice Sistem http://www.voice-sistem.ro _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

-- Jiri Kuthan http://iptel.org/~jiri/

-- Voice Sistem http://www.voice-sistem.ro _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

Marian Dumitru

5:17 p.m.

Hi Jan, Thank you for the advice. I am aware and totally agree with your suggestion. The may reason for allowing $to as source for avp_db_load() was to make its use possible for REGISTER requests also - if I'm not wrong, for REGISTER reqs, the TO hdr is used since the RURI contains only domain name. More liberty, means also more risks :-). But people should know what they are doing. Best regards, Marian Dumitru Jan Janak wrote:

...

Hi Andreas, you can implement GW failover by doing serial fork using AVPOPS module. Pleas take a look at example number 4 - Serial forking: http://www.voice-system.ro/docs/avpops/ You can store all GW IPs in database and load them via avp_db_load(). If you don't want to hardcode even your first GW IP and to rely only on the IP list from AVPs, be sure to push the fist AVP value into RURI in main route before first sending to GW. Unfortunately, this approach doesn't offer load-balancing Best regards, Marian Dumitru Andreas Granig wrote: >Hi all, >Since SER does not provide DNS SRV failover capability, how do you >perform failover for your PSTN gateways? >I currently think about some sort of load balancing with exec_dset() >which looks up a gateway in a mysql db and give it 10 tries to find a >gateway (SER is running on my.domain:5060) >route >{ >if (!mf_process_maxfwd_header("10")) >{ > sl_send_reply("483", "Too many hops"); > break; >} ><snip> >exec_dset("/my/sipgw-balancing-script"); # returns a random GW >t_on_failure("1"); >t_relay(); ><snip> >} >failure_route[1] >{ >if(t_check_status("503") >{ > rewritehostport("my.domain:5060"); # peform loop > append_branch(); > t_relay(); >} >} >Is this good practice? Any other ideas/optimizations? > >Cheers, >Andy >_______________________________________________ >Serusers mailing list >serusers(a)lists.iptel.org >http://lists.iptel.org/mailman/listinfo/serusers -- Voice Sistem http://www.voice-sistem.ro _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

-- Jiri Kuthan http://iptel.org/~jiri/

-- Voice Sistem http://www.voice-sistem.ro _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

-- Voice Sistem http://www.voice-sistem.ro

7111

days inactive

7140

days old

sr-users@lists.kamailio.org

Manage subscription

32 comments

9 participants

tags (0)

participants (9)

Andreas Granig
Andrei Pelinescu-Onciul
Bogdan-Andrei IANCU
Daniel-Constantin Mierla
E. Versaevel
g.billoudet＠arwen-tech.fr
Jan Janak
Jiri Kuthan
Marian Dumitru