Re: [SR-Users] out of memory Error

[ycaner]

  

  
  
Hello Daniel; 
      i got summary on "kamailio -E -m 256 -M 8". as you said i did
  children 2. after 3000 calls i get this errors. 
  
  in additon , i saw some logs about loops some packets. 
  Thanks 
  
  0(11969) NOTICE:  [main.c:555]: cleanup(): Memory
  still-in-use summary (pkg): 
   0(11969) NOTICE: fm_status: summarizing all alloc'ed. fragments: 
   0(11969) NOTICE: fm_status:  count= 1 size=    56 bytes
  from textops: textops.c: hname_fixup(2208) 
   0(11969) NOTICE: fm_status:  count= 1 size=   128 bytes
  from : mod_fix.c: fixup_pvar_all(270) 
   0(11969) NOTICE: fm_status:  count= 1 size=   128 bytes
  from : switch.c: mk_switch_cond_table(43) 
   0(11969) NOTICE: fm_status:  count= 1 size=   232 bytes
  from : parser/msg_parser.c: get_hdr_field(116) 
   0(11969) NOTICE: fm_status:  count= 1 size=    64 bytes
  from : parser/msg_parser.c: parse_headers(326) 
   0(11969) NOTICE: fm_status:  count= 1 size=    56 bytes
  from acc: acc_mod.c: acc_register_engine(844) 
   0(11969) NOTICE: fm_status:  count=    19 size=  2128 bytes
  from acc: acc_extra.c: parse_acc_extra(127) 
   0(11969) NOTICE: fm_status:  count= 1 size=   112 bytes
  from misc_radius: extra.c: parse_extra_str(83) 
   0(11969) NOTICE: fm_status:  count= 2 size=    32 bytes
  from : select.c: register_select_table(448) 
   0(11969) NOTICE: fm_status:  count= 1 size=    24 bytes
  from kex: mi_core.c: init_mi_uptime(82) 
   0(11969) NOTICE: fm_status:  count= 1 size=    80 bytes
  from : socket_info.c: fix_sock_str(419) 
   0(11969) NOTICE: fm_status:  count= 1 size=    16 bytes
  from : name_alias.h: add_alias(93) 
   0(11969) NOTICE: fm_status:  count= 1 size=    32 bytes
  from : name_alias.h: add_alias(91) 
   0(11969) NOTICE: fm_status:  count= 1 size= 32208 bytes
  from : dset.c: init_dst_set(83) 
   0(11969) NOTICE: fm_status:  count= 1 size=    40 bytes
  from : socket_info.c: fix_hostname(1357) 
   0(11969) NOTICE: fm_status:  count= 1 size=    64 bytes
  from : route.c: fix_expr(541) 
   0(11969) NOTICE: fm_status:  count=    10 size=   656 bytes
  from : cfg.y: mk_case_stm(3718) 
   0(11969) NOTICE: fm_status:  count= 1 size=   256 bytes
  from : switch.c: mk_match_cond_table(94) 
   0(11969) NOTICE: fm_status:  count= 1 size=   168 bytes
  from : mod_fix.c: fixup_regexp_null(213) 
   0(11969) NOTICE: fm_status:  count= 5 size=   560 bytes
  from : sr_module.c: fix_param(1211) 
   0(11969) NOTICE: fm_status:  count= 3 size=   232 bytes
  from : route_struct.c: mk_elem(90) 
   0(11969) NOTICE: fm_status:  count= 1 size=    32 bytes
  from : socket_info.c: fix_socket_list(1559) 
   0(11969) NOTICE: fm_status:  count=    24 size=   632 bytes
  from textops: textops.c: fixup_method(2278) 
   0(11969) NOTICE: fm_status:  count= 1 size=    72 bytes
  from htable: ht_var.c: pv_parse_ht_name(135) 
   0(11969) NOTICE: fm_status:  count= 2 size=    64 bytes
  from pv: pv_trans.c: tr_parse_string(2120) 
   0(11969) NOTICE: fm_status:  count= 3 size=   152 bytes
  from pv: pv_trans.c: tr_parse_string(2109) 
   0(11969) NOTICE: fm_status:  count= 2 size=    16 bytes
  from : re.c: subst_parser(300) 
   0(11969) NOTICE: fm_status:  count= 3 size=   432 bytes
  from : re.c: subst_parser(290) 
   0(11969) NOTICE: fm_status:  count= 3 size=   192 bytes
  from : re.c: subst_parser(273) 
   0(11969) NOTICE: fm_status:  count= 3 size=    96 bytes
  from textops: txt_var.c: tr_txt_parse_re(212) 
   0(11969) NOTICE: fm_status:  count= 9 size=   432 bytes
  from pv: pv_svar.c: add_var(58) 
   0(11969) NOTICE: fm_status:  count= 1 size=    32 bytes
  from pv: pv_trans.c: tr_parse_string(2245) 
   0(11969) NOTICE: fm_status:  count= 8 size=   384 bytes
  from : pvapi.c: tr_new(1542) 
   0(11969) NOTICE: fm_status:  count= 1 size=   128 bytes
  from : rvalue.c: fix_match_rve(3018) 
   0(11969) NOTICE: fm_status:  count= 9 size=   112 bytes
  from pv: pv_svar.c: add_var(65) 
   0(11969) NOTICE: fm_status:  count=    48 size= 83328 bytes
  from : rvalue.c: mk_rval_expr1(2611) 
   0(11969) NOTICE: fm_status:  count=   211 size=  7624 bytes
  from : pvapi.c: pv_parse_format(1057) 
   0(11969) NOTICE: fm_status:  count=   147 size= 14440 bytes
  from : sr_module.c: fix

Re: [SR-Users] out of memory Error

[Daniel-Constantin Mierla]

Hello,

so these logs are only from main kamailio process, which doesn't handle
sip, so it looks like it has still a lot of pkg.

Is there another group of logs for "fm_status: summarizing all alloc'ed.
fragments" but for another PID than 11969?

If not, then do the test again. When you get out memory logs, identify
the PID of the process that wrote the log message, then run:

kamcmd cfg.set_now_int core mem_dump_pkg 

Replace  with actual value for PID.

Then send some traffic so the process with PID is doing some work. It
should print the summary when it receives the first packet.

Cheers,
Daniel

On 29/09/15 10:34, ycaner wrote:
> Hello Daniel;
> i got summary on "kamailio -E -m 256 -M 8". as you said i did
> children 2. after 3000 calls i get this errors.
>
> in additon , i saw some logs about loops some packets.
> Thanks
>
> 0(11969) NOTICE:  [main.c:555]: cleanup(): Memory still-in-use
> summary (pkg):
>  0(11969) NOTICE: fm_status: summarizing all alloc'ed. fragments:
>  0(11969) NOTICE: fm_status:  count= 1 size=56 bytes from
> textops: textops.c: hname_fixup(2208)
>  0(11969) NOTICE: fm_status:  count= 1 size=   128 bytes from
> : mod_fix.c: fixup_pvar_all(270)
>  0(11969) NOTICE: fm_status:  count= 1 size=   128 bytes from
> : switch.c: mk_switch_cond_table(43)
>  0(11969) NOTICE: fm_status:  count= 1 size=   232 bytes from
> : parser/msg_parser.c: get_hdr_field(116)
>  0(11969) NOTICE: fm_status:  count= 1 size=64 bytes from
> : parser/msg_parser.c: parse_headers(326)
>  0(11969) NOTICE: fm_status:  count= 1 size=56 bytes from
> acc: acc_mod.c: acc_register_engine(844)
>  0(11969) NOTICE: fm_status:  count=19 size=  2128 bytes from
> acc: acc_extra.c: parse_acc_extra(127)
>  0(11969) NOTICE: fm_status:  count= 1 size=   112 bytes from
> misc_radius: extra.c: parse_extra_str(83)
>  0(11969) NOTICE: fm_status:  count= 2 size=32 bytes from
> : select.c: register_select_table(448)
>  0(11969) NOTICE: fm_status:  count= 1 size=24 bytes from
> kex: mi_core.c: init_mi_uptime(82)
>  0(11969) NOTICE: fm_status:  count= 1 size=80 bytes from
> : socket_info.c: fix_sock_str(419)
>  0(11969) NOTICE: fm_status:  count= 1 size=16 bytes from
> : name_alias.h: add_alias(93)
>  0(11969) NOTICE: fm_status:  count= 1 size=32 bytes from
> : name_alias.h: add_alias(91)
>  0(11969) NOTICE: fm_status:  count= 1 size= 32208 bytes from
> : dset.c: init_dst_set(83)
>  0(11969) NOTICE: fm_status:  count= 1 size=40 bytes from
> : socket_info.c: fix_hostname(1357)
>  0(11969) NOTICE: fm_status:  count= 1 size=64 bytes from
> : route.c: fix_expr(541)
>  0(11969) NOTICE: fm_status:  count=10 size=   656 bytes from
> : cfg.y: mk_case_stm(3718)
>  0(11969) NOTICE: fm_status:  count= 1 size=   256 bytes from
> : switch.c: mk_match_cond_table(94)
>  0(11969) NOTICE: fm_status:  count= 1 size=   168 bytes from
> : mod_fix.c: fixup_regexp_null(213)
>  0(11969) NOTICE: fm_status:  count= 5 size=   560 bytes from
> : sr_module.c: fix_param(1211)
>  0(11969) NOTICE: fm_status:  count= 3 size=   232 bytes from
> : route_struct.c: mk_elem(90)
>  0(11969) NOTICE: fm_status:  count= 1 size=32 bytes from
> : socket_info.c: fix_socket_list(1559)
>  0(11969) NOTICE: fm_status:  count=24 size=   632 bytes from
> textops: textops.c: fixup_method(2278)
>  0(11969) NOTICE: fm_status:  count= 1 size=72 bytes from
> htable: ht_var.c: pv_parse_ht_name(135)
>  0(11969) NOTICE: fm_status:  count= 2 size=64 bytes from
> pv: pv_trans.c: tr_parse_string(2120)
>  0(11969) NOTICE: fm_status:  count= 3 size=   152 bytes from
> pv: pv_trans.c: tr_parse_string(2109)
>  0(11969) NOTICE: fm_status:  count= 2 size=16 bytes from
> : re.c: subst_parser(300)
>  0(11969) NOTICE: fm_status:  count= 3 size=   432 bytes from
> : re.c: subst_parser(290)
>  0(11969) NOTICE: fm_status:  count= 3 size=   192 bytes from
> : re.c: subst_parser(273)
>  0(11969) NOTICE: fm_status:  count= 3 size=96 bytes from
> textops: txt_var.c: tr_txt_parse_re(212)
>  0(11969) NOTICE: fm_status:  count= 9 size=   432 bytes from
> pv: pv_svar.c: add_var(58)
>  0(11969) NOTICE: fm_status:  count= 1 size=32 bytes from
> pv: pv_trans.c: tr_parse_string(2245)
>  0(11969) NOTICE: fm_status:  count= 8 size=   384 bytes from
> : pvapi.c: tr_new(1542)
>  0(11969) NOTICE: fm_status:  count= 1 size=   128 bytes from
> : rvalue.c: fix_match_rve(3018)
>  0(11969) NOTICE: fm_status:  count= 9 size=   112 bytes from
> pv: pv_svar.c: add_var(65)
>  0(11969) NOTICE: fm_status:  count=48 size= 83328 bytes from
> : rvalue.c: mk_rval_expr1(2611)
>  0(11969) NOTICE: fm_status:  count=   211 size=  7624 bytes from
> : pvapi.c: pv_parse_format(1057)
>  0(11969

Re: [SR-Users] out of memory Error

[ycaner]

  

  
  

  Hello; 
  
  There is no changes after changin .cfg and ports. here is second
  summary. 
  
  0(15002) NOTICE:  [main.c:555]: cleanup(): Memory
  still-in-use summary (pkg): 
   0(15002) NOTICE: fm_status: summarizing all alloc'ed. fragments: 
   0(15002) NOTICE: fm_status:  count= 1 size=    56 bytes
  from textops: textops.c: hname_fixup(2208) 
   0(15002) NOTICE: fm_status:  count= 1 size=   128 bytes
  from : mod_fix.c: fixup_pvar_all(270) 
   0(15002) NOTICE: fm_status:  count= 1 size=   128 bytes
  from : switch.c: mk_switch_cond_table(43) 
   0(15002) NOTICE: fm_status:  count= 1 size=   232 bytes
  from : parser/msg_parser.c: get_hdr_field(116) 
   0(15002) NOTICE: fm_status:  count= 1 size=    64 bytes
  from : parser/msg_parser.c: parse_headers(326) 
   0(15002) NOTICE: fm_status:  count= 1 size=    56 bytes
  from acc: acc_mod.c: acc_register_engine(844) 
   0(15002) NOTICE: fm_status:  count=    19 size=  2128 bytes
  from acc: acc_extra.c: parse_acc_extra(127) 
   0(15002) NOTICE: fm_status:  count= 1 size=   112 bytes
  from misc_radius: extra.c: parse_extra_str(83) 
   0(15002) NOTICE: fm_status:  count= 2 size=    32 bytes
  from : select.c: register_select_table(448) 
   0(15002) NOTICE: fm_status:  count= 1 size=    24 bytes
  from kex: mi_core.c: init_mi_uptime(82) 
   0(15002) NOTICE: fm_status:  count= 1 size=    80 bytes
  from : socket_info.c: fix_sock_str(419) 
   0(15002) NOTICE: fm_status:  count= 1 size=    16 bytes
  from : name_alias.h: add_alias(93) 
   0(15002) NOTICE: fm_status:  count= 1 size=    32 bytes
  from : name_alias.h: add_alias(91) 
   0(15002) NOTICE: fm_status:  count= 1 size= 32208 bytes
  from : dset.c: init_dst_set(83) 
   0(15002) NOTICE: fm_status:  count= 1 size=    40 bytes
  from : socket_info.c: fix_hostname(1357) 
   0(15002) NOTICE: fm_status:  count= 1 size=    64 bytes
  from : route.c: fix_expr(541) 
   0(15002) NOTICE: fm_status:  count= 1 size=    72 bytes
  from : mod_fix.c: fixup_regexp_null(213) 
   0(15002) NOTICE: fm_status:  count=    10 size=   656 bytes
  from : cfg.y: mk_case_stm(3718) 
   0(15002) NOTICE: fm_status:  count= 1 size=   256 bytes
  from : switch.c: mk_match_cond_table(94) 
   0(15002) NOTICE: fm_status:  count= 5 size=   560 bytes
  from : sr_module.c: fix_param(1211) 
   0(15002) NOTICE: fm_status:  count= 3 size=   232 bytes
  from : route_struct.c: mk_elem(90) 
   0(15002) NOTICE: fm_status:  count= 1 size=    32 bytes
  from : socket_info.c: fix_socket_list(1559) 
   0(15002) NOTICE: fm_status:  count=    24 size=   632 bytes
  from textops: textops.c: fixup_method(2278) 
   0(15002) NOTICE: fm_status:  count= 1 size=    72 bytes
  from htable: ht_var.c: pv_parse_ht_name(135) 
   0(15002) NOTICE: fm_status:  count= 2 size=    64 bytes
  from pv: pv_trans.c: tr_parse_string(2120) 
   0(15002) NOTICE: fm_status:  count= 3 size=   152 bytes
  from pv: pv_trans.c: tr_parse_string(2109) 
   0(15002) NOTICE: fm_status:  count= 2 size=    16 bytes
  from : re.c: subst_parser(300) 
   0(15002) NOTICE: fm_status:  count= 3 size=   432 bytes
  from : re.c: subst_parser(290) 
   0(15002) NOTICE: fm_status:  count= 3 size=   192 bytes
  from : re.c: subst_parser(273) 
   0(15002) NOTICE: fm_status:  count= 3 size=    96 bytes
  from textops: txt_var.c: tr_txt_parse_re(212) 
   0(15002) NOTICE: fm_status:  count=   147 size= 14392 bytes
  from : sr_module.c: fix_param(1116) 
   0(15002) NOTICE: fm_status:  count= 9 size=   432 bytes
  from pv: pv_svar.c: add_var(58) 
   0(15002) NOTICE: fm_status:  count= 1 size=    32 bytes
  from pv: pv_trans.c: tr_parse_string(2245) 
   0(15002) NOTICE: fm_status:  count= 8 size=   384 bytes
  from : pvapi.c: tr_new(1542) 
   0(15002) NOTICE: fm_status:  count= 9 size=   112 bytes
  from pv: pv_svar.c: add_var(65) 
   0(15002) NOTICE: fm_status:  count= 1 size=   128 bytes
  from : rvalue.c: fix_match_rve(3018) 
   0(15002) NOTICE: fm_status:  count=    48 size= 83328 bytes
  from : rvalue.c: mk_rval_expr1(2611) 
   0(15002) NOTICE: fm_status:  count=   213 size=  7688 bytes
  from : pvapi.c: pv_parse_format(1057) 
   0(15002) NOTICE: fm_status:  count=   262 size=  5472 bytes
  from : rvalue.c: rv

Re: [SR-Users] out of memory Error

[Daniel-Constantin Mierla]

Hello,

still look like only mem summary from main process, which is not
relevant for a worker process.

Use the suggestions from my previous email to get the pkg mem summary
for a sip worker process.

Cheers,
Daniel

On 29/09/15 10:52, ycaner wrote:
>
> Hello;
>
> There is no changes after changin .cfg and ports. here is second summary.
>
> 0(15002) NOTICE:  [main.c:555]: cleanup(): Memory still-in-use
> summary (pkg):
>  0(15002) NOTICE: fm_status: summarizing all alloc'ed. fragments:
>  0(15002) NOTICE: fm_status:  count= 1 size=56 bytes from
> textops: textops.c: hname_fixup(2208)
>  0(15002) NOTICE: fm_status:  count= 1 size=   128 bytes from
> : mod_fix.c: fixup_pvar_all(270)
>  0(15002) NOTICE: fm_status:  count= 1 size=   128 bytes from
> : switch.c: mk_switch_cond_table(43)
>  0(15002) NOTICE: fm_status:  count= 1 size=   232 bytes from
> : parser/msg_parser.c: get_hdr_field(116)
>  0(15002) NOTICE: fm_status:  count= 1 size=64 bytes from
> : parser/msg_parser.c: parse_headers(326)
>  0(15002) NOTICE: fm_status:  count= 1 size=56 bytes from
> acc: acc_mod.c: acc_register_engine(844)
>  0(15002) NOTICE: fm_status:  count=19 size=  2128 bytes from
> acc: acc_extra.c: parse_acc_extra(127)
>  0(15002) NOTICE: fm_status:  count= 1 size=   112 bytes from
> misc_radius: extra.c: parse_extra_str(83)
>  0(15002) NOTICE: fm_status:  count= 2 size=32 bytes from
> : select.c: register_select_table(448)
>  0(15002) NOTICE: fm_status:  count= 1 size=24 bytes from
> kex: mi_core.c: init_mi_uptime(82)
>  0(15002) NOTICE: fm_status:  count= 1 size=80 bytes from
> : socket_info.c: fix_sock_str(419)
>  0(15002) NOTICE: fm_status:  count= 1 size=16 bytes from
> : name_alias.h: add_alias(93)
>  0(15002) NOTICE: fm_status:  count= 1 size=32 bytes from
> : name_alias.h: add_alias(91)
>  0(15002) NOTICE: fm_status:  count= 1 size= 32208 bytes from
> : dset.c: init_dst_set(83)
>  0(15002) NOTICE: fm_status:  count= 1 size=40 bytes from
> : socket_info.c: fix_hostname(1357)
>  0(15002) NOTICE: fm_status:  count= 1 size=64 bytes from
> : route.c: fix_expr(541)
>  0(15002) NOTICE: fm_status:  count= 1 size=72 bytes from
> : mod_fix.c: fixup_regexp_null(213)
>  0(15002) NOTICE: fm_status:  count=10 size=   656 bytes from
> : cfg.y: mk_case_stm(3718)
>  0(15002) NOTICE: fm_status:  count= 1 size=   256 bytes from
> : switch.c: mk_match_cond_table(94)
>  0(15002) NOTICE: fm_status:  count= 5 size=   560 bytes from
> : sr_module.c: fix_param(1211)
>  0(15002) NOTICE: fm_status:  count= 3 size=   232 bytes from
> : route_struct.c: mk_elem(90)
>  0(15002) NOTICE: fm_status:  count= 1 size=32 bytes from
> : socket_info.c: fix_socket_list(1559)
>  0(15002) NOTICE: fm_status:  count=24 size=   632 bytes from
> textops: textops.c: fixup_method(2278)
>  0(15002) NOTICE: fm_status:  count= 1 size=72 bytes from
> htable: ht_var.c: pv_parse_ht_name(135)
>  0(15002) NOTICE: fm_status:  count= 2 size=64 bytes from
> pv: pv_trans.c: tr_parse_string(2120)
>  0(15002) NOTICE: fm_status:  count= 3 size=   152 bytes from
> pv: pv_trans.c: tr_parse_string(2109)
>  0(15002) NOTICE: fm_status:  count= 2 size=16 bytes from
> : re.c: subst_parser(300)
>  0(15002) NOTICE: fm_status:  count= 3 size=   432 bytes from
> : re.c: subst_parser(290)
>  0(15002) NOTICE: fm_status:  count= 3 size=   192 bytes from
> : re.c: subst_parser(273)
>  0(15002) NOTICE: fm_status:  count= 3 size=96 bytes from
> textops: txt_var.c: tr_txt_parse_re(212)
>  0(15002) NOTICE: fm_status:  count=   147 size= 14392 bytes from
> : sr_module.c: fix_param(1116)
>  0(15002) NOTICE: fm_status:  count= 9 size=   432 bytes from
> pv: pv_svar.c: add_var(58)
>  0(15002) NOTICE: fm_status:  count= 1 size=32 bytes from
> pv: pv_trans.c: tr_parse_string(2245)
>  0(15002) NOTICE: fm_status:  count= 8 size=   384 bytes from
> : pvapi.c: tr_new(1542)
>  0(15002) NOTICE: fm_status:  count= 9 size=   112 bytes from
> pv: pv_svar.c: add_var(65)
>  0(15002) NOTICE: fm_status:  count= 1 size=   128 bytes from
> : rvalue.c: fix_match_rve(3018)
>  0(15002) NOTICE: fm_status:  count=48 size= 83328 bytes from
> : rvalue.c: mk_rval_expr1(2611)
>  0(15002) NOTICE: fm_status:  count=   213 size=  7688 bytes from
> : pvapi.c: pv_parse_format(1057)
>  0(15002) NOTICE: fm_status:  count=   262 size=  5472 bytes from
> : rvalue.c: rval_get_str(1252)
>  0(15002) NOTICE: fm_status:  count=52 size= 90272 bytes from
> : rvalue.c: mk_rval_expr2(2669)
>  0(15002) NOTICE: fm_status:  count=54 size=  6504 bytes from
> xlog: xlog.c: xlog_fixup_helper(449)
>  0(15002) NOTICE: fm_status:  count=   544 size=136208 bytes from
> : route_str

Re: [SR-Users] evapi tcp parsing??

[Jayesh Nambiar]

Hi Daniel:
I did a new test where I stopped as soon as I saw one message that got
discarded. Basically the following message got discarded:
{"event":"REGISTER","tindex":"52171","tlabel":"748030241","PhoneNumber":"11161","DeviceId":"abcd1234abcd1234","CallId":"
10943-15480@198.24.63.39"}
The CallId parameter in the above json is auto incremented, so I tried
gathering logs for messages with following CallIds:
"CallId":"10940-15480@198.24.63.39"
"CallId":"10941-15480@198.24.63.39"
"CallId":"10942-15480@198.24.63.39"
"CallId":"10943-15480@198.24.63.39"
"CallId":"10944-15480@198.24.63.39"
"CallId":"10945-15480@198.24.63.39"

And the message with CallID "CallId":"10943-15480@198.24.63.39" got
discarded.

Here's the bunch of kamailio logs printed by the evapi module:
*Logs for processed messages just before the discarded message:*
DEBUG: evapi [evapi_dispatch.c:492]: evapi_recv_notify(): received
[0x7f43da494ad0]
[146:{"event":"REGISTER","tindex":"61133","tlabel":"450961398","PhoneNumber":"11158","DeviceId":"abcd1234abcd1234","CallId":"
10940-15480@198.24.63.39"},] (151)

NOTICE: evapi_recv_client(): {0} [198.24.63.45:48905] - received
[147:{"event":"REGISTER","tindex":"25291","tlabel":"2047024302","PhoneNumber":"11132","DeviceId":"abcd1234abcd1234","CallId":"
10914-15480@198.24.63.39
"},146:{"event":"REGISTER","tindex":"61136","tlabel":"839735223","PhoneNumber":"11148","DeviceId":"abcd1234abcd1234","CallId":"
10930-15480@198.24.63.39
"},143:{"event":"REGISTER","tindex":"4562","tlabel":"6586867","PhoneNumber":"11149","DeviceId":"abcd1234abcd1234","CallId":"
10931-15480@198.24.63.39
"},146:{"event":"REGISTER","tindex":"43213","tlabel":"220429340","PhoneNumber":"11151","DeviceId":"abcd1234abcd1234","CallId":"
10932-15480@198.24.63.39
"},146:{"event":"REGISTER","tindex":"52174","tlabel":"708781916","PhoneNumber":"11150","DeviceId":"abcd1234abcd1234","CallId":"
10933-15480@198.24.63.39
"},147:{"event":"REGISTER","tindex":"34251","tlabel":"1354642017","PhoneNumber":"11153","DeviceId":"abcd1234abcd1234","CallId":"
10935-15480@198.24.63.39
"},146:{"event":"REGISTER","tindex":"7366","tlabel":"1368396808","PhoneNumber":"11154","DeviceId":"abcd1234abcd1234","CallId":"
10936-15480@198.24.63.39
"},146:{"event":"REGISTER","tindex":"25289","tlabel":"11971","PhoneNumber":"11152","DeviceId":"abcd1234abcd1234","CallId":"
10934-15480@198.24.63.39
"},146:{"event":"REGISTER","tindex":"16327","tlabel":"971937029","PhoneNumber":"11155","DeviceId":"abcd1234abcd1234","CallId":"
10937-15480@198.24.63.39
"},146:{"event":"REGISTER","tindex":"22242","tlabel":"609737074","PhoneNumber":"11156","DeviceId":"abcd1234abcd1234","CallId":"
10938-15480@198.24.63.39
"},146:{"event":"REGISTER","tindex":"10720","tlabel":"930036340","PhoneNumber":"11157","DeviceId":"abcd1234abcd1234","CallId":"
10939-15480@198.24.63.39
"},146:{"event":"REGISTER","tindex":"61133","tlabel":"450961398","PhoneNumber":"11158","DeviceId":"abcd1234abcd1234","CallId":"
10940-15480@198.24.63.39"},146:{"event":"REGISTER","tindex":"43210","tlabel":"639090568","PhoneNumber":"11160","Dev]
(1899) (0)


evapi_recv_client(): executing event route for frame:
[{"event":"REGISTER","tindex":"61133","tlabel":"450961398","PhoneNumber":"11158","DeviceId":"abcd1234abcd1234","CallId":"
10940-15480@198.24.63.39"}] (146)

Sep 29 05:35:14 v39 /usr/local/kamailio-dev/sbin/kamailio[15387]: DEBUG:
evapi [evapi_dispatch.c:492]: evapi_recv_notify(): received
[0x7f43da4b67e0]
[146:{"event":"REGISTER","tindex":"4559","tlabel":"1701553747","PhoneNumber":"11159","DeviceId":"abcd1234abcd1234","CallId":"
10941-15480@198.24.63.39"},] (151)

NOTICE: evapi [evapi_dispatch.c:290]: evapi_recv_client(): {0} [
198.24.63.45:48905] - received [iceId":"abcd1234abcd1234","CallId":"
10942-15480@198.24.63.39
"},146:{"event":"REGISTER","tindex":"4559","tlabel":"1701553747","PhoneNumber":"11159","DeviceId":"abcd1234abcd1234","CallId":"
10941-15480@198.24.63.39"},] (214) (88)

DEBUG: evapi [evapi_dispatch.c:370]: evapi_recv_client(): executing event
route for frame:
[{"event":"REGISTER","tindex":"4559","tlabel":"1701553747","PhoneNumber":"11159","DeviceId":"abcd1234abcd1234","CallId":"
10941-15480@198.24.63.39"}] (146)

DEBUG: evapi [evapi_dispatch.c:492]: evapi_recv_notify(): received
[0x7f43d93c2a70]
[146:{"event":"REGISTER","tindex":"43210","tlabel":"639090568","PhoneNumber":"11160","DeviceId":"abcd1234abcd1234","CallId":"
10942-15480@198.24.63.39"},] (151)

DEBUG: evapi [evapi_dispatch.c:370]: evapi_recv_client(): executing event
route for frame:
[{"event":"REGISTER","tindex":"43210","tlabel":"639090568","PhoneNumber":"11160","DeviceId":"abcd1234abcd1234","CallId":"
10942-15480@198.24.63.39"}] (146)

DEBUG: evapi [evapi_dispatch.c:353]: evapi_recv_client(): residual data
[146:{"event":"REGISTER","tindex":"43210","tlabel":"639090568","PhoneNumber":"11160","Dev]
(88)

DEBUG: evapi [evapi_dispatch.c:361]: evapi_recv_client(): frame size
mismatch the ending char ("):
[{"event":"REGISTER","tindex":"43210","tlabel":"63909

Re: [SR-Users] Kazoo db_url required?

[Asgaroth]

I ended up looking at the source for Kazoo, and there appears to be a 
"pua_mode" parameter which defaults to 1, I added


modparam("kazoo", "pua_mode", 0)

And I am now able to start kamailio without kazoo connecting to the 
presence tables.


This parameter is not documented in the Kazoo module docs.

Is this the correct way of disabling the presence db connection for the 
kazoo module?


I am not a C developer by any stretch, so any tips would be appreciated.

Thanks

On 28/09/2015 13:20, Asgaroth wrote:

Hi,

I am doing some tests with the kazoo module, I only want to use it for 
some amqp related tasks.


In our particular case, we do not require kazoo to hook into the 
presence tables, however, if I do *not* set the db_url parameter for 
kazoo, then kamailio fails to start with the following error:


/usr/sbin/kamailio[11557]: CRITICAL: kazoo [kazoo.c:361]: 
mod_child_init(): child_init: database not bound
/usr/sbin/kamailio[11557]: ERROR:  [sr_module.c:900]: 
init_mod_child(): Error while initializing module kazoo 
(/usr/lib64/kamailio/modules/kazoo.so)


Is it possible to run the kazoo module without specifying the db_url 
parameter, we only need it for sending/recieving amqp messages.


Additionally, I noticed that the amqp_connection parameter has a max 
limit of 50 characters, is it possible to increase this at all? I had 
a case where my url was 64 characters long and kazoo would fail with 
max character limit exceeded for the module parameter.


Any tips much appreciated.

Thanks




___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kazoo db_url required?

[Asgaroth]

oh, i forgot to mention I'm on version kamailio v4.3.2

On 29/09/2015 12:55, Asgaroth wrote:
I ended up looking at the source for Kazoo, and there appears to be a 
"pua_mode" parameter which defaults to 1, I added


modparam("kazoo", "pua_mode", 0)

And I am now able to start kamailio without kazoo connecting to the 
presence tables.


This parameter is not documented in the Kazoo module docs.

Is this the correct way of disabling the presence db connection for 
the kazoo module?


I am not a C developer by any stretch, so any tips would be appreciated.

Thanks

On 28/09/2015 13:20, Asgaroth wrote:

Hi,

I am doing some tests with the kazoo module, I only want to use it 
for some amqp related tasks.


In our particular case, we do not require kazoo to hook into the 
presence tables, however, if I do *not* set the db_url parameter for 
kazoo, then kamailio fails to start with the following error:


/usr/sbin/kamailio[11557]: CRITICAL: kazoo [kazoo.c:361]: 
mod_child_init(): child_init: database not bound
/usr/sbin/kamailio[11557]: ERROR:  [sr_module.c:900]: 
init_mod_child(): Error while initializing module kazoo 
(/usr/lib64/kamailio/modules/kazoo.so)


Is it possible to run the kazoo module without specifying the db_url 
parameter, we only need it for sending/recieving amqp messages.


Additionally, I noticed that the amqp_connection parameter has a max 
limit of 50 characters, is it possible to increase this at all? I had 
a case where my url was 64 characters long and kazoo would fail with 
max character limit exceeded for the module parameter.


Any tips much appreciated.

Thanks






___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] db_text and caching/reloading

[Asgaroth]

Hi,

Friendly "bump", any thoughts on this one?

I'm using kamailio v4.3.2

Thanks

On 28/09/2015 13:11, Asgaroth wrote:

Hi,

I am busy testing the db_text module for some modules who's 
configuration does not change that often.


If I set the db_mode for db_text to 0 (caching), it appears that if I 
modify the file directly (in this case the address dbtext file) and 
then issue a "kamctl address reload" the updated contents are *not* 
reloaded. However, if I set db_mode to 1, then the contents of the 
db_text file automatically reload when I change it on the file system.


Is it possible to run db_text in caching mode but to also force a 
reload if I manually update the underlying database file?


Additionally, in kamctlrc, I had to add the following variable:

DBTEXT_PATH="/etc/kamailio/db_text"

Whereas the original example for db_text path in kamctlrc is as follows:

# database path used by dbtext, db_berkeley or sqlite
#DB_PATH="/etc/kamailio/db_text"

Is this just a typo in the kamctlrc distribution or is the variable 
meant to be DB_PATH or DBTEXT_PATH?


Thanks




___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] evapi tcp parsing??

[Jayesh Nambiar]

Hi Daniel,
Taking a second look at the NGREP Trace I think I can see what is going
wrong. The message in the third packet was discarded by Evapi module. If
you look at the first two packets carefully, the first packet ends at Dev
and the second packet is the continuation of first packet which starts with
"iceId". The first two packets are processed perfectly fine.
Now the third packet is a new message, but Kamailio is trying to continue
the third packet again with the first packet. So even when the third packet
starts with '146:' Kamailio considers it to be starting with 'Dev146'. This
causes the evapi to discard this message since it does not remain a valid
netstring then. Here the three packets that I'm talking about:

T 198.24.63.45:48905 -> 198.24.63.39:3927 [A]
  
146:{"event":"REGISTER","tindex":"43213","tlabel":"220429340","PhoneNumber":"11151","DeviceId":"abcd1234abcd1234","CallId":"10932-15480@198.24.63.39"},146:{"event":"REGISTER","tindex":"52174","tlabel":"708781916","PhoneNumber":"11150","DeviceId":"abcd1234abcd1234","CallId":"10933-15480@198.24.63.39"},147:{"event":"REGISTER","tindex":"34251","tlabel":"1354642017","PhoneNumber":"11153","DeviceId":"abcd1234abcd1234","CallId":"10935-15480@198.24.63.39"},146:{"event":"REGISTER","tindex":"7366","tlabel":"1368396808","PhoneNumber":"11154","DeviceId":"abcd1234abcd1234","CallId":"10936-15480@198.24.63.39"},146:{"event":"REGISTER","tindex":"25289","tlabel":"11971","PhoneNumber":"11152","DeviceId":"abcd1234abcd1234","CallId":"10934-15480@198.24.63.39"},146:{"event":"REGISTER","tindex":"16327","tlabel":"971937029","PhoneNumber":"11155","DeviceId":"abcd1234abcd1234","CallId":"10937-15480@198.24.63.39"},146:{"event":"REGISTER","tindex":"22242","tlabel":"609737074","PhoneNumber":"11156","DeviceId":"abcd1234abcd1234","CallId":"10938-15480@198.24.63.39"},146:{"event":"REGISTER","tindex":"10720","tlabel":"930036340","PhoneNumber":"11157","DeviceId":"abcd1234abcd1234","CallId":"10939-15480@198.24.63.39"},146:{"event":"REGISTER","tindex":"61133","tlabel":"450961398","PhoneNumber":"11158","DeviceId":"abcd1234abcd1234","CallId":"10940-15480@198.24.63.39"},146:{"event":"REGISTER","tindex":"43210","tlabel":"639090568","PhoneNumber":"11160","Dev

T 198.24.63.45:48905 -> 198.24.63.39:3927 [AP]
  
iceId":"abcd1234abcd1234","CallId":"10942-15480@198.24.63.39"},146:{"event":"REGISTER","tindex":"4559","tlabel":"1701553747","PhoneNumber":"11159","DeviceId":"abcd1234abcd1234","CallId":"10941-15480@198.24.63.39"},

T 198.24.63.45:48905 -> 198.24.63.39:3927 [AP]
  
146:{"event":"REGISTER","tindex":"52171","tlabel":"748030241","PhoneNumber":"11161","DeviceId":"abcd1234abcd1234","CallId":"10943-15480@198.24.63.39"},


On Tue, Sep 29, 2015 at 4:43 PM Jayesh Nambiar  wrote:

> Hi Daniel:
> I did a new test where I stopped as soon as I saw one message that got
> discarded. Basically the following message got discarded:
>
> {"event":"REGISTER","tindex":"52171","tlabel":"748030241","PhoneNumber":"11161","DeviceId":"abcd1234abcd1234","CallId":"
> 10943-15480@198.24.63.39"}
> The CallId parameter in the above json is auto incremented, so I tried
> gathering logs for messages with following CallIds:
> "CallId":"10940-15480@198.24.63.39"
> "CallId":"10941-15480@198.24.63.39"
> "CallId":"10942-15480@198.24.63.39"
> "CallId":"10943-15480@198.24.63.39"
> "CallId":"10944-15480@198.24.63.39"
> "CallId":"10945-15480@198.24.63.39"
>
> And the message with CallID "CallId":"10943-15480@198.24.63.39" got
> discarded.
>
> Here's the bunch of kamailio logs printed by the evapi module:
> *Logs for processed messages just before the discarded message:*
> DEBUG: evapi [evapi_dispatch.c:492]: evapi_recv_notify(): received
> [0x7f43da494ad0]
> [146:{"event":"REGISTER","tindex":"61133","tlabel":"450961398","PhoneNumber":"11158","DeviceId":"abcd1234abcd1234","CallId":"
> 10940-15480@198.24.63.39"},] (151)
>
> NOTICE: evapi_recv_client(): {0} [198.24.63.45:48905] - received
> [147:{"event":"REGISTER","tindex":"25291","tlabel":"2047024302","PhoneNumber":"11132","DeviceId":"abcd1234abcd1234","CallId":"
> 10914-15480@198.24.63.39
> "},146:{"event":"REGISTER","tindex":"61136","tlabel":"839735223","PhoneNumber":"11148","DeviceId":"abcd1234abcd1234","CallId":"
> 10930-15480@198.24.63.39
> "},143:{"event":"REGISTER","tindex":"4562","tlabel":"6586867","PhoneNumber":"11149","DeviceId":"abcd1234abcd1234","CallId":"
> 10931-15480@198.24.63.39
> "},146:{"event":"REGISTER","tindex":"43213","tlabel":"220429340","PhoneNumber":"11151","DeviceId":"abcd1234abcd1234","CallId":"
> 10932-15480@198.24.63.39
> "},146:{"event":"REGISTER","tindex":"52174","tlabel":"708781916","PhoneNumber":"11150","DeviceId":"abcd1234abcd1234","CallId":"
> 10933-15480@198.24.63.39
> "},147:{"event":"REGISTER","tindex":"34251","tlabel":"1354642017","PhoneNumber":"11153","DeviceId":"abcd1234abcd1234","CallId":"
> 10935-15480@198.24.63.39
> "},146:{"event":"REGISTER","tindex":"7366","tlabel":"1368396808","PhoneNumber":"11154","DeviceId":"abcd123

Re: [SR-Users] db_text and caching/reloading

[Asgaroth]

Some more investigation here and it looks like the kamctlrc value to set 
for db_text path is DBTEXT_PATH and not DB_PATH as listed in the default 
kamctlrc file.


[1] When I have DB_PATH set to the location of the db text files, the 
following happens (I cannot show the contents of the address table, but 
the memory dump works):


DB_PATH="/etc/kamailio/db_text"

# kamctl address dump
   0 <1, 10.7.0.0, 24, 0> []
   1 <10002, 10.7.0.0, 24, 0> []
# kamctl address show
#

[2] When I have DBTEXT_PATH set to the location of the db text files, 
the following happens (I cannot reload contents of the address table, 
but the memory dump and table show works):


# kamctl address dump
   0 <1, 10.7.0.0, 24, 0> []
   1 <10002, 10.7.0.0, 24, 0> []
# kamctl address show
[1, 1, '10.7.0.0', 24, 0, '']
# kamctl address reload
# kamctl address dump
   0 <1, 10.7.0.0, 24, 0> []
   1 <10002, 10.7.0.0, 24, 0> []
# kamctl address show
[1, 1, '10.7.0.0', 24, 0, '']

It also appears that the equivilent RPC commands dont work correctly too 
for the permissions module, the addressDump does not show in-memory 
values, and reload says it completed, but dump shows nothing too:


kamcmd> permissions.addressDump
{
}
kamcmd> permissions.addressReload
Reload OK
kamcmd> permissions.addressDump
{
}

Am I missing something with my configuration, or have I come accross a bug?

Thanks for reading this far :)

Thanks

On 29/09/2015 13:07, Asgaroth wrote:

Hi,

Friendly "bump", any thoughts on this one?

I'm using kamailio v4.3.2

Thanks

On 28/09/2015 13:11, Asgaroth wrote:

Hi,

I am busy testing the db_text module for some modules who's 
configuration does not change that often.


If I set the db_mode for db_text to 0 (caching), it appears that if I 
modify the file directly (in this case the address dbtext file) and 
then issue a "kamctl address reload" the updated contents are *not* 
reloaded. However, if I set db_mode to 1, then the contents of the 
db_text file automatically reload when I change it on the file system.


Is it possible to run db_text in caching mode but to also force a 
reload if I manually update the underlying database file?


Additionally, in kamctlrc, I had to add the following variable:

DBTEXT_PATH="/etc/kamailio/db_text"

Whereas the original example for db_text path in kamctlrc is as follows:

# database path used by dbtext, db_berkeley or sqlite
#DB_PATH="/etc/kamailio/db_text"

Is this just a typo in the kamctlrc distribution or is the variable 
meant to be DB_PATH or DBTEXT_PATH?


Thanks






___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Best practices for troubleshooting deadlocks?

[Alex Balashov]

Hi,

Thanks very much to you and Ovidiu for the responses. I didn't mean to 
leave this thread hanging. See inline:


On 09/28/2015 05:51 PM, Daniel-Constantin Mierla wrote:


Were you pulling the backtraces based on the script you pasted in your
previous email? That should be good source of information to analyze if
what kamailio was doing.


Yes, although as yet I have not been able to actually get the operator 
to run a backtrace at the time of the deadlock. It's a psychological and 
political problem: they are so eager to restore service that they do not 
have the discipline to run my debug script, and jump straight to 
restarting Kamailio.


However, the biggest problem that I see is that if the backtraces reveal 
something interesting, it may invite follow-up, e.g. examination of 
other frames and values. That would require a core dump. Dumping core 
for all 8-12 child processes would take several minutes, as the shm pool 
is quite large (4 GB). This is a very high-volume installation. The 
operator would never go for that.


So, if I do get an intriguing backtrace, I don't really know what else 
to do to elaborate.



I already said, if the is a mutex deadlock, it will be also noticed by
high cpu usage. Was it the case, or you don't have any access to cpu
usage history?


I don't have CPU usage history, but I will try to get one next time this 
happens.



If it is just no more sip message routing, but no high cpu usage, then:

- maybe processed were blocked in a lengthily I/O operation (e.g., query
to database)


That's certainly possible. The backtrace will surely reveal that.


- maybe someone/something was resetting the network interface (the
sockets were bound to previous address) -- e.g., it can be done by some
upgrades of OS or dhcp


No, that definitely is not the case.


- maybe some limits of OS were reached, the packets were filtered by
kernel (if you have centos with selinux, be sure it is properly configured)


I am aware of CentOS's ridiculous default ulimits in CentOS 6.6, and all 
of these have been appropriately set to infinity. SELinux is disabled.


I'll let you know what I find. Thanks for the input!

-- Alex

--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States

Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Best practices for troubleshooting deadlocks?

[Ovidiu Sas]

A backtrace should provide enough information to know where to look
for issues and that should not take a long time.
Maybe you can use monit to monitor the cpu and on failure run 'kamctl
trap' to get the backtrace.
 if cpu is greater than 50% for 5 cycles then exec "/usr/sbin/kamctl trap"
Make sure that you have the debug rpm installed.

-ovidiu

On Tue, Sep 29, 2015 at 1:40 PM, Alex Balashov
 wrote:
> Hi,
>
> Thanks very much to you and Ovidiu for the responses. I didn't mean to leave
> this thread hanging. See inline:
>
> On 09/28/2015 05:51 PM, Daniel-Constantin Mierla wrote:
>
>> Were you pulling the backtraces based on the script you pasted in your
>> previous email? That should be good source of information to analyze if
>> what kamailio was doing.
>
>
> Yes, although as yet I have not been able to actually get the operator to
> run a backtrace at the time of the deadlock. It's a psychological and
> political problem: they are so eager to restore service that they do not
> have the discipline to run my debug script, and jump straight to restarting
> Kamailio.
>
> However, the biggest problem that I see is that if the backtraces reveal
> something interesting, it may invite follow-up, e.g. examination of other
> frames and values. That would require a core dump. Dumping core for all 8-12
> child processes would take several minutes, as the shm pool is quite large
> (4 GB). This is a very high-volume installation. The operator would never go
> for that.
>
> So, if I do get an intriguing backtrace, I don't really know what else to do
> to elaborate.
>
>> I already said, if the is a mutex deadlock, it will be also noticed by
>> high cpu usage. Was it the case, or you don't have any access to cpu
>> usage history?
>
>
> I don't have CPU usage history, but I will try to get one next time this
> happens.
>
>> If it is just no more sip message routing, but no high cpu usage, then:
>>
>> - maybe processed were blocked in a lengthily I/O operation (e.g., query
>> to database)
>
>
> That's certainly possible. The backtrace will surely reveal that.
>
>> - maybe someone/something was resetting the network interface (the
>> sockets were bound to previous address) -- e.g., it can be done by some
>> upgrades of OS or dhcp
>
>
> No, that definitely is not the case.
>
>> - maybe some limits of OS were reached, the packets were filtered by
>> kernel (if you have centos with selinux, be sure it is properly
>> configured)
>
>
> I am aware of CentOS's ridiculous default ulimits in CentOS 6.6, and all of
> these have been appropriately set to infinity. SELinux is disabled.
>
> I'll let you know what I find. Thanks for the input!
>
> -- Alex
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
> 303 Perimeter Center North, Suite 300
> Atlanta, GA 30346
> United States
>
> Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] blf problem

[huseyin kalyoncu]

Hello Daniel,

I have been having some strange crashes after upgrade to 4.3.2

i did not configure for core dump but when i check the kern.log after crash
i see this:

Sep 29 22:47:19 km1 kernel: [1815465.204612] kamailio[4211]: segfault at 60
ip 7f64319df2e4 sp 7ffe99c703b8 error 4 in libc-2.19.so
[7f643194a000+19f000]
Sep 29 22:47:19 km1 kernel: [1815465.413074] kamailio[4201]: segfault at
f0f0f100 ip 7f64287c7915 sp 7ffe99c72600 error 4 in
pua_dialoginfo.so[7f64287be000+13000]


On Mon, Sep 28, 2015 at 1:15 PM, huseyin kalyoncu 
wrote:

>
> Hello Daniel
>
> Sorry for the late response. Yes,  when i change subs_db_mode to 3 i see
> lots of error messages as below.
> 5678*002 is the subscriber for 5678*012 and 5678*011. When all phones
> idle, everything is fine all lamps are green.
> But when i make a call i see error messages and nothing changes with the
> lamps.
> Sorry for inconvenience but I had to mask public IP addresses in the logs.
> I am using Kamailio version 4.3.2 and Postgresql-server 9.4.3 as DB.
> root@km1:~# uname -a
> Linux km1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04)
> x86_64 GNU/Linux
>
> Btw i tried to separate presence server from proxy but nothing changes and
> i saw the same errors as below.
>
> Thanks
>
> Huseyin
>
>
>
> 1:45:45 km1 kamailio_presence[10037]: WARNING: db_postgres
> [km_dbase.c:277]: db_postgres_submit_query(): postgres result check failed
> with code 7 (PGRES_FATAL_ERROR)
> Sep 28 11:45:45 km1 kamailio_presence[10037]: WARNING: db_postgres
> [km_dbase.c:281]: db_postgres_submit_query(): postgres query command
> failed, connection status 0, error [ERROR:  duplicate key value violates
> unique constraint "presentity_presentity_idx"#012DETAIL:  Key (username,
> domain, event, etag)=(5678*002, XXX.XXX.XX.XXX, dialog, *#-OFFLINE-#*)
> already exists.#012]
> Sep 28 11:45:45 km1 kamailio_presence[10037]: ERROR: db_postgres
> [km_dbase.c:290]: db_postgres_submit_query(): 0x7f0dd4497060 PQsendQuery
> Error: ERROR:  duplicate key value violates unique constraint
> "presentity_presentity_idx"#012DETAIL:  Key (username, domain, event,
> etag)=(5678*002, XXX.XXX.XX.XXX, dialog, *#-OFFLINE-#*) already exists.#012
> Query: update presentity set
> etag='*#-OFFLINE-#*',expires=1443433545,body=' version="1.0"?>#012 version="000" state="full" entity="sip:5678*0...@xxx.xxx.xx.xxx">#012
>  #012
>  terminated#012#012
>  sip:5678*0...@xxx.xxx.xx.xxx#012   uri="sip:5678*0...@xxx.xxx.xx.xxx:5060"/>#012#012
>  #012  sip:5678*0...@xxx.xxx.xx.xxx:5060#012
>  #012#012
>  #012#012' where username='5678*002' AND
> domain='XXX.XXX.XX.XXX' AND event='dialog' AND
> etag='a.1442821424.10032.187.0'
> Sep 28 11:45:45 km1 kamailio_presence[10037]: ERROR: 
> [db_query.c:339]: db_do_update(): error while submitting query
> Sep 28 11:45:45 km1 kamailio_presence[10037]: ERROR: db_postgres
> [km_dbase.c:580]: db_postgres_store_result(): invalid query, execution
> aborted
> Sep 28 11:45:45 km1 kamailio_presence[10037]: ERROR: db_postgres
> [km_dbase.c:581]: db_postgres_store_result(): driver error:
> PGRES_FATAL_ERROR, ERROR:  duplicate key value violates unique constraint
> "presentity_presentity_idx"#012DETAIL:  Key (username, domain, event,
> etag)=(5678*002, XXX.XXX.XX.XXX, dialog, *#-OFFLINE-#*) already exists.
> Sep 28 11:45:45 km1 kamailio_presence[10037]: WARNING: db_postgres
> [km_dbase.c:690]: db_postgres_update(): unexpected result returned
> Sep 28 11:45:45 km1 kamailio_presence[10037]: ERROR: presence
> [presentity.c:1324]: mark_presentity_for_delete(): unsuccessful sql update
> operation
> Sep 28 11:45:45 km1 kamailio_presence[10037]: ERROR: presence
> [publish.c:169]: msg_presentity_clean(): Marking presentity
> Sep 28 11:45:47 km1 kamailio_presence[10036]: INFO: presence
> [subscribe.c:1601]: get_database_info(): No matching subscription dialog
> found in database
> Sep 28 11:45:47 km1 kamailio_presence[10036]: INFO: presence
> [subscribe.c:949]: handle_subscribe(): getting stored info
> Sep 28 11:45:55 km1 kamailio_presence[10035]: ERROR: presence
> [subscribe.c:1617]: get_database_info(): wrong sequence number received: 22
> - stored: 22
> Sep 28 11:45:55 km1 kamailio_presence[10035]: INFO: presence
> [subscribe.c:949]: handle_subscribe(): getting stored info
> Sep 28 11:45:55 km1 kamailio_presence[10036]: INFO: presence
> [subscribe.c:1601]: get_database_info(): No matching subscription dialog
> found in database
> Sep 28 11:45:55 km1 kamailio_presence[10036]: INFO: presence
> [subscribe.c:949]: handle_subscribe(): getting stored info
> Sep 28 11:46:03 km1 kamailio_presence[10031]: ERROR: presence
> [subscribe.c:1617]: get_database_info(): wrong sequence number received: 22
> - stored: 22
> Sep 28 11:46:03 km1 kamailio_presence[10031]: INFO: presence
> [subscribe.c:949]: handle_subscribe(): getting stored info
> Sep 28 11:46:03 km1 kamailio_presence[10033]: INFO: presence
> [subscribe.c:1601]: get_database_info(): No mat

[SR-Users] Anybody in Beijing interested in Kamailio related project cooperation ?

[Thierry Luo]

很报歉通过这个邮件列表打扰大家。

 

我们是一个创业团队，刚刚拿到投资，正在组建核心团队，现需要一位在OpenIMSCore
（或Kamailio/OpenSIPS）方面有经验的C/C++开发工程师加盟，待遇优厚，期权可谈，
职位在北京。请有意者速与 luoyongh...@nane.cn  联
系。谢谢！

 

打扰见谅！

 

罗

 

 

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] ACK and BYE are forwarded statelessly (failed to parse Route HF)

[Miroslav Dunaev]

Hello everyone,
I have a setup where ​kamailio acts as UAC to a SIP provider.
Kamailio is also configured to pass all incoming calls to an Asterisk.
Here is a diagram:

Phone<-->Asterisk(10.10.11.232)<--->(PRIV:10.10.11.238)Kamailio(PUB:44.44.44.148)<--->(194.213.29.92)SIP-provider.

When a call comes in from the SIP-provider, it gets all the way to the
phone.
But when the SIP-provider sends BYE or ACK (during hungup event or
 200OK/SDP asterisk response.).
I get this errors in my kamailio log:


 siputils [checks.c:100]: has_totag(): totag found
 [parser/parse_rr.c:49]: do_parse_rr_body(): parse_rr_body(): No body
for record-route
rr [loose.c:106]: find_first_route(): failed to parse Route HF
rr [loose.c:929]: loose_route(): There is no Route HF
tm [t_lookup.c:648]: t_lookup_request(): DEBUG: t_lookup_request: no
transaction found
tm [t_lookup.c:1011]: t_check_msg(): DEBUG: t_check_msg: msg id=1 global
id=0 T start=0x
tm [t_lookup.c:466]: t_lookup_request(): t_lookup_request: start searching:
hash=10101, isACK=1
tm [t_lookup.c:424]: matching_3261(): DEBUG: RFC3261 transaction matching
failed
.


siputils [checks.c:100]: has_totag(): totag found
tm [t_lookup.c:1312]: t_newtran(): DEBUG: t_newtran: msg id=2 , global msg
id=1 , T on entrance=0x
tm [t_lookup.c:466]: t_lookup_request(): t_lookup_request: start searching:
hash=10101, isACK=1
tm [t_lookup.c:424]: matching_3261(): DEBUG: RFC3261 transaction matching
failed
tm [t_lookup.c:648]: t_lookup_request(): DEBUG: t_lookup_request: no
transaction found
tm [t_funcs.c:279]: t_relay_to(): SER: forwarding ACK  statelessly

here is the link to: kamailio.cfg, ngrep -i any capture, debug_level6 log:
http://labmir.com/kamailio/


Looking at the SIP ACK that comes from SIP provider I can see that they use
strict routing.
(i.e. TO field is set to kamailio's  public IP that is next hop to them).
Maybe I am wrong to judge that its not loose routing just because of the TO
field.

Anyways, because of (failed to parse Route HF) error, ACKs and BYEs are
forwarded by kamailio statelessly, as a result kamailio uses wrong
interface to forward them (SIP_dailog.txt line:233) and therefore asterisk
never sees ACKs or BYEs.

How can I make kamailio recognize ACKs and BYEs belonging to a dialog and
pass them statefully through the right interface?

It is worth to mention that I use exactly the same config with a different
SIP-provider (which is peered to our PUB IP not registered through UAC like
in this case) and it works flawlessly.

Thank you,
Mir
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] ERROR: mediaproxy [mediaproxy.c:1978] #347

[Ngoc]

Hello supporter,

I took a look kamailio and get the error: Sep 29 11:28:37 lvps46-163-74-198
/usr/local/sbin/kamailio[1738]: ERROR: mediaproxy [mediaproxy.c:1978]:
EngageMediaProxy(): engage_media_proxy requires the dialog module to be loaded
and configured.

How to resolved this problem, please help me.

Regards,
 
---
Dinh Hong Ngoc
Technical Lead
Edge-works Software Co.,ltd

Hall 5, Quang Trung Software City, Tan Chanh Hiep Ward, Dist. 12, Ho Chi Minh
City, Vietnam.
Email: ngoc.d...@edge-works.net
Phone: +84 8 54371075 | Mobile: +84 909 911 406
Site: http://www.edge-works.net___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] out of memory Error

[ycaner]

  

  
  
Hello Daniel; 
  
      i got logs from kamailio. there is 10 pid about kamailio and
  don't give dumps for all kamailio pids expects somes. Here is
  results; 
  
  root 18323  0.0  0.0 454628 12968 ?    S    12:12   0:00
  /usr/local/sbin/kamailio -P /var/run/kamailio.pid -m 256 -M 8 -u
  root -g root 
  root 18333  0.0  0.1 454628 16632 ?    S    12:12   0:03
  /usr/local/sbin/kamailio -P /var/run/kamailio.pid -m 256 -M 8 -u
  root -g root 
  root 18334  0.0  0.1 454628 16504 ?    S    12:12   0:03
  /usr/local/sbin/kamailio -P /var/run/kamailio.pid -m 256 -M 8 -u
  root -g root 
  root 18335  0.0  0.0 454628  7132 ?    S    12:12   0:00
  /usr/local/sbin/kamailio -P /var/run/kamailio.pid -m 256 -M 8 -u
  root -g root 
  root 18337  0.0  0.0 454628 10232 ?    S    12:12   0:02
  /usr/local/sbin/kamailio -P /var/run/kamailio.pid -m 256 -M 8 -u
  root -g root 
  root 18339  0.0  0.0 454632  5332 ?    S    12:12   0:00
  /usr/local/sbin/kamailio -P /var/run/kamailio.pid -m 256 -M 8 -u
  root -g root 
  root 18341  0.0  0.0 454628  6012 ?    S    12:12   0:00
  /usr/local/sbin/kamailio -P /var/run/kamailio.pid -m 256 -M 8 -u
  root -g root 
  root 18344  0.0  0.0 454628  5776 ?    S    12:12   0:00
  /usr/local/sbin/kamailio -P /var/run/kamailio.pid -m 256 -M 8 -u
  root -g root 
  root 18346  0.0  0.0 454628  6716 ?    S    12:12   0:00
  /usr/local/sbin/kamailio -P /var/run/kamailio.pid -m 256 -M 8 -u
  root -g root 
  root 18348  0.0  0.0 454628  5680 ?    S    12:12   0:00
  /usr/local/sbin/kamailio -P /var/run/kamailio.pid -m 256 -M 8 -u
  root -g root 
  
  Sep 29 13:59:21 localhost /usr/local/sbin/kamailio[18334]: ALERT:
   [pt.c:531]: mem_dump_pkg_cb(): Memory status (pkg) of
  process 18334: 
  Sep 29 13:59:21 localhost /usr/local/sbin/kamailio[18334]: ALERT:
  fm_status: fm_status (0x7f4b67aa8010): 
  Sep 29 13:59:21 localhost /usr/local/sbin/kamailio[18334]: ALERT:
  fm_status:  heap size= 8388608 
  Sep 29 13:59:21 localhost /usr/local/sbin/kamailio[18334]: ALERT:
  fm_status:  used= 3949448, used+overhead=8384064, free=4544 
  Sep 29 13:59:21 localhost /usr/local/sbin/kamailio[18334]: ALERT:
  fm_status:  max used (+overhead)= 8388608 
  Sep 29 13:59:21 localhost /usr/local/sbin/kamailio[18334]: ALERT:
  fm_status: dumping free list: 
  Sep 29 13:59:21 localhost /usr/local/sbin/kamailio[18334]: ALERT:
  fm_status: hash =   6 fragments no.: 2, unused:
  0#012#011#011 bucket size:    48 -    48 (first    48) 
  Sep 29 13:59:21 localhost /usr/local/sbin/kamailio[18334]: ALERT:
  fm_status: hash =   7 fragments no.: 1, unused:
  0#012#011#011 bucket size:    56 -    56 (first    56) 
  Sep 29 13:59:21 localhost /usr/local/sbin/kamailio[18334]: ALERT:
  fm_status: hash =   8 fragments no.:    15, unused:
  0#012#011#011 bucket size:    64 -    64 (first    64) 
  Sep 29 13:59:21 localhost /usr/local/sbin/kamailio[18334]: ALERT:
  fm_status: hash =  14 fragments no.: 1, unused:
  0#012#011#011 bucket size:   112 -   112 (first   112) 
  Sep 29 13:59:21 localhost /usr/local/sbin/kamailio[18334]: ALERT:
  fm_status: hash =  29 fragments no.: 1, unused:
  0#012#011#011 bucket size:   232 -   232 (first   232) 
  Sep 29 13:59:21 localhost /usr/local/sbin/kamailio[18334]: ALERT:
  fm_status: hash =  59 fragments no.: 1, unused:
  0#012#011#011 bucket size:   472 -   472 (first   472) 
  Sep 29 13:59:21 localhost /usr/local/sbin/kamailio[18334]: ALERT:
  fm_status: hash = 106 fragments no.: 1, unused:
  0#012#011#011 bucket size:   848 -   848 (first   848) 
  Sep 29 13:59:21 localhost /usr/local/sbin/kamailio[18334]: ALERT:
  fm_status: hash = 221 fragments no.: 1, unused:
  0#012#011#011 bucket size:  1768 -  1768 (first  1768) 
  Sep 29 13:59:21 localhost /usr/local/sbin/kamailio[18334]: ALERT:
  fm_status: TOTAL: 23 free fragments =   4544 free bytes 
  Sep 29 13:59:21 localhost /usr/local/sbin/kamailio[18334]: ALERT:
  fm_status: - 
  
  Sep 29 13:59:23 localhost /usr/local/sbin/kamailio[18335]: ALERT:
   [pt.c:531]: mem_dump_pkg_cb(): Memory status (pkg) of
  process 18335: 
  Sep 29 13:59:23 localhost /usr/local/sbin/kamailio[18335]: ALERT:
  fm_status: fm_status (0x7f4b67aa8010): 
  Sep 29 13:59:23 localhost /usr/local/sbin/kamailio[18335]: ALERT:
  fm_status:  heap size= 8388608 
  Sep 29 13:59:23 localhost /usr/local/sbin/kamailio[18335]: ALERT:
  fm_status:  us

Re: [SR-Users] evapi tcp parsing??

[Daniel-Constantin Mierla]

Hello,

thanks for troubleshooting further and pointing to the issue. I pushed a
patch last night, hopefully fixes it. Try with latest master branch and
let me know the results.

Cheers,
Daniel

On 29/09/15 14:15, Jayesh Nambiar wrote:
> Hi Daniel,
> Taking a second look at the NGREP Trace I think I can see what is
> going wrong. The message in the third packet was discarded by Evapi
> module. If you look at the first two packets carefully, the first
> packet ends at Dev and the second packet is the continuation of first
> packet which starts with "iceId". The first two packets are processed
> perfectly fine.
> Now the third packet is a new message, but Kamailio is trying to
> continue the third packet again with the first packet. So even when
> the third packet starts with '146:' Kamailio considers it to be
> starting with 'Dev146'. This causes the evapi to discard this message
> since it does not remain a valid netstring then. Here the three
> packets that I'm talking about:
>
> T 198.24.63.45:48905  -> 198.24.63.39:3927 
>  [A]
>   
> 146:{"event":"REGISTER","tindex":"43213","tlabel":"220429340","PhoneNumber":"11151","DeviceId":"abcd1234abcd1234","CallId":"10932-15480@198.24.63.39
>  
> "},146:{"event":"REGISTER","tindex":"52174","tlabel":"708781916","PhoneNumber":"11150","DeviceId":"abcd1234abcd1234","CallId":"10933-15480@198.24.63.39
>  
> "},147:{"event":"REGISTER","tindex":"34251","tlabel":"1354642017","PhoneNumber":"11153","DeviceId":"abcd1234abcd1234","CallId":"10935-15480@198.24.63.39
>  
> "},146:{"event":"REGISTER","tindex":"7366","tlabel":"1368396808","PhoneNumber":"11154","DeviceId":"abcd1234abcd1234","CallId":"10936-15480@198.24.63.39
>  
> "},146:{"event":"REGISTER","tindex":"25289","tlabel":"11971","PhoneNumber":"11152","DeviceId":"abcd1234abcd1234","CallId":"10934-15480@198.24.63.39
>  
> "},146:{"event":"REGISTER","tindex":"16327","tlabel":"971937029","PhoneNumber":"11155","DeviceId":"abcd1234abcd1234","CallId":"10937-15480@198.24.63.39
>  
> "},146:{"event":"REGISTER","tindex":"22242","tlabel":"609737074","PhoneNumber":"11156","DeviceId":"abcd1234abcd1234","CallId":"10938-15480@198.24.63.39
>  
> "},146:{"event":"REGISTER","tindex":"10720","tlabel":"930036340","PhoneNumber":"11157","DeviceId":"abcd1234abcd1234","CallId":"10939-15480@198.24.63.39
>  
> "},146:{"event":"REGISTER","tindex":"61133","tlabel":"450961398","PhoneNumber":"11158","DeviceId":"abcd1234abcd1234","CallId":"10940-15480@198.24.63.39
>  
> "},146:{"event":"REGISTER","tindex":"43210","tlabel":"639090568","PhoneNumber":"11160","Dev
>   
>
>
> T 198.24.63.45:48905  -> 198.24.63.39:3927 
>  [AP]
>   iceId":"abcd1234abcd1234","CallId":"10942-15480@198.24.63.39 
> "},146:{"event":"REGISTER","tindex":"4559","tlabel":"1701553747","PhoneNumber":"11159","DeviceId":"abcd1234abcd1234","CallId":"10941-15480@198.24.63.39
>  "},
>   
>   
>
> T 198.24.63.45:48905  -> 198.24.63.39:3927 
>  [AP]
>   
> 146:{"event":"REGISTER","tindex":"52171","tlabel":"748030241","PhoneNumber":"11161","DeviceId":"abcd1234abcd1234","CallId":"10943-15480@198.24.63.39
>  "},
>
> On Tue, Sep 29, 2015 at 4:43 PM Jayesh Nambiar  > wrote:
>
> Hi Daniel:
> I did a new test where I stopped as soon as I saw one message that
> got discarded. Basically the following message got discarded:
> 
> {"event":"REGISTER","tindex":"52171","tlabel":"748030241","PhoneNumber":"11161","DeviceId":"abcd1234abcd1234","CallId":"10943-15480@198.24.63.39
> "}
> The CallId parameter in the above json is auto incremented, so I
> tried gathering logs for messages with following CallIds:
> "CallId":"10940-15480@198.24.63.39 "
> "CallId":"10941-15480@198.24.63.39 "
> "CallId":"10942-15480@198.24.63.39 "
> "CallId":"10943-15480@198.24.63.39 "
> "CallId":"10944-15480@198.24.63.39 "
> "CallId":"10945-15480@198.24.63.39 "
>
> And the message with C

Re: [SR-Users] out of memory Error

[Daniel-Constantin Mierla]

Hello,

hmm, even these logs were not catching the relevant information, the
main process is the one logging the used packets, from the others I saw
only the free chunks summary.

Let's do it again with stopping kamailio when you get out of memory
errors. Set children=2 and mem_summary=15 to get all possible logs
related to the memory.

You can send directly to me all the log messages with memory status and
summary printed when kamailio is stopped, because the size can be quite
big and the mailing list won't accept it.

Cheers,
Daniel

On 29/09/15 13:10, ycaner wrote:
> Hello Daniel;
>
> i got logs from kamailio. there is 10 pid about kamailio and don't
> give dumps for all kamailio pids expects somes. Here is results;
>

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] blf problem

[Daniel-Constantin Mierla]

Hello,

are you running the last kamailio branch 4.3 or is from packages?

Do you get a core dump file? If yes, can you send the backtrace?

Daniel

On 29/09/15 23:07, huseyin kalyoncu wrote:
> Hello Daniel,
>
> I have been having some strange crashes after upgrade to 4.3.2
>
> i did not configure for core dump but when i check the kern.log after
> crash i see this:
>
> Sep 29 22:47:19 km1 kernel: [1815465.204612] kamailio[4211]: segfault
> at 60 ip 7f64319df2e4 sp 7ffe99c703b8 error 4 in libc-2.19.so
> [7f643194a000+19f000]
> Sep 29 22:47:19 km1 kernel: [1815465.413074] kamailio[4201]: segfault
> at f0f0f100 ip 7f64287c7915 sp 7ffe99c72600 error 4 in
> pua_dialoginfo.so[7f64287be000+13000]
>
>
> On Mon, Sep 28, 2015 at 1:15 PM, huseyin kalyoncu  > wrote:
>
>
> Hello Daniel
>
> Sorry for the late response. Yes,  when i change subs_db_mode to 3
> i see lots of error messages as below.
> 5678*002 is the subscriber for 5678*012 and 5678*011. When all
> phones idle, everything is fine all lamps are green. 
> But when i make a call i see error messages and nothing changes
> with the lamps.
> Sorry for inconvenience but I had to mask public IP addresses in
> the logs. 
> I am using Kamailio version 4.3.2 and Postgresql-server 9.4.3 as DB.
> root@km1:~# uname -a
> Linux km1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u3
> (2015-08-04) x86_64 GNU/Linux
>  
> Btw i tried to separate presence server from proxy but nothing
> changes and i saw the same errors as below.
>
> Thanks
>
> Huseyin 
>
>
>
> 1:45:45 km1 kamailio_presence[10037]: WARNING: db_postgres
> [km_dbase.c:277]: db_postgres_submit_query(): postgres result
> check failed with code 7 (PGRES_FATAL_ERROR)
> Sep 28 11:45:45 km1 kamailio_presence[10037]: WARNING: db_postgres
> [km_dbase.c:281]: db_postgres_submit_query(): postgres query
> command failed, connection status 0, error [ERROR:  duplicate key
> value violates unique constraint
> "presentity_presentity_idx"#012DETAIL:  Key (username, domain,
> event, etag)=(5678*002, XXX.XXX.XX.XXX, dialog, *#-OFFLINE-#*)
> already exists.#012]
> Sep 28 11:45:45 km1 kamailio_presence[10037]: ERROR: db_postgres
> [km_dbase.c:290]: db_postgres_submit_query(): 0x7f0dd4497060
> PQsendQuery Error: ERROR:  duplicate key value violates unique
> constraint "presentity_presentity_idx"#012DETAIL:  Key (username,
> domain, event, etag)=(5678*002, XXX.XXX.XX.XXX, dialog,
> *#-OFFLINE-#*) already exists.#012 Query: update presentity set
> etag='*#-OFFLINE-#*',expires=1443433545,body=' version="1.0"?>#012 xmlns="urn:ietf:params:xml:ns:dialog-info" version="000"
> state="full" entity="sip:5678*0...@xxx.xxx.xx.xxx">#012   id="1074899713" call-id="1074899713" direction="recipient">#012  
>  terminated#012#012
>  sip:5678*0...@xxx.xxx.xx.xxx#012   uri="sip:5678*0...@xxx.xxx.xx.xxx:5060"/>#012#012  
>  #012
>  sip:5678*0...@xxx.xxx.xx.xxx:5060#012
>  #012  
>  #012  #012#012' where
> username='5678*002' AND domain='XXX.XXX.XX.XXX' AND event='dialog'
> AND etag='a.1442821424.10032.187.0'
> Sep 28 11:45:45 km1 kamailio_presence[10037]: ERROR: 
> [db_query.c:339]: db_do_update(): error while submitting query
> Sep 28 11:45:45 km1 kamailio_presence[10037]: ERROR: db_postgres
> [km_dbase.c:580]: db_postgres_store_result(): invalid query,
> execution aborted
> Sep 28 11:45:45 km1 kamailio_presence[10037]: ERROR: db_postgres
> [km_dbase.c:581]: db_postgres_store_result(): driver error:
> PGRES_FATAL_ERROR, ERROR:  duplicate key value violates unique
> constraint "presentity_presentity_idx"#012DETAIL:  Key (username,
> domain, event, etag)=(5678*002, XXX.XXX.XX.XXX, dialog,
> *#-OFFLINE-#*) already exists.
> Sep 28 11:45:45 km1 kamailio_presence[10037]: WARNING: db_postgres
> [km_dbase.c:690]: db_postgres_update(): unexpected result returned
> Sep 28 11:45:45 km1 kamailio_presence[10037]: ERROR: presence
> [presentity.c:1324]: mark_presentity_for_delete(): unsuccessful
> sql update operation
> Sep 28 11:45:45 km1 kamailio_presence[10037]: ERROR: presence
> [publish.c:169]: msg_presentity_clean(): Marking presentity
> Sep 28 11:45:47 km1 kamailio_presence[10036]: INFO: presence
> [subscribe.c:1601]: get_database_info(): No matching subscription
> dialog found in database
> Sep 28 11:45:47 km1 kamailio_presence[10036]: INFO: presence
> [subscribe.c:949]: handle_subscribe(): getting stored info
> Sep 28 11:45:55 km1 kamailio_presence[10035]: ERROR: presence
> [subscribe.c:1617]: get_database_info(): wrong sequence number
> received: 22 - stored: 22
> Sep 28 11:45:55 km1 kamailio_presence[10035]: INFO: presence
> [subscribe.c:949]: handle_subscribe