[SR-Users] Multi crashes in the same day

[igor.potjevlesch]

Hello !

 

I have multi crashes on a Kamailio 4.2.8 instance.

Already 6 coredump today, same time with the same scenario. Below the output
of the last coredump:

 

(gdb) where

#0  0x003d6f6328a5 in raise () from /lib64/libc.so.6

#1  0x003d6f634085 in abort () from /lib64/libc.so.6

#2  0x0061aad2 in qm_debug_frag (qm=0x7f9a8a7aa010,
f=0x7f9a8aca5968) at mem/q_malloc.c:161

#3  0x0061bf1c in qm_malloc (qm=0x7f9a8a7aa010, size=24,
file=0x7131d0 ": re.c", func=0x71483e "subst_run", line=440) at
mem/q_malloc.c:388

#4  0x00505e2c in subst_run (se=0x7f9a8ac08b78, input=0x7f9a8aca5918
"sip:0123456789@customer.local", msg=0x7f9a8abfef38, count=0x0) at re.c:440

#5  0x00506fff in subst_str (input=0x7f9a8aca5918
"sip:0123456789@customer.local", msg=0x7f9a8abfef38, se=0x7f9a8ac08b78,
count=0x0) at re.c:515

#6  0x7f9a87ff629d in subst_uri_f (msg=0x7f9a8abfef38,
subst=0x7f9a8ac08b78 "X\215\300\212\232\177", ignored=0x0) at textops.c:744

#7  0x0041d51b in do_action (h=0x7fffed0800d0, a=0x7f9a8ab64cc8,
msg=0x7f9a8abfef38) at action.c:1094

#8  0x00429ba3 in run_actions (h=0x7fffed0800d0, a=0x7f9a8ab64cc8,
msg=0x7f9a8abfef38) at action.c:1583

#9  0x0042a208 in run_actions_safe (h=0x7fffed081380,
a=0x7f9a8ab64cc8, msg=0x7f9a8abfef38) at action.c:1648

#10 0x00542994 in rval_get_int (h=0x7fffed081380,
msg=0x7f9a8abfef38, i=0x7fffed080890, rv=0x7f9a8ab64ef8, cache=0x0) at
rvalue.c:924

#11 0x00546bcc in rval_expr_eval_int (h=0x7fffed081380,
msg=0x7f9a8abfef38, res=0x7fffed080890, rve=0x7f9a8ab64ef0) at rvalue.c:1918

#12 0x0041cf77 in do_action (h=0x7fffed081380, a=0x7f9a8ab66a30,
msg=0x7f9a8abfef38) at action.c:1064

#13 0x00429ba3 in run_actions (h=0x7fffed081380, a=0x7f9a8ab66a30,
msg=0x7f9a8abfef38) at action.c:1583

#14 0x0041d3f6 in do_action (h=0x7fffed081380, a=0x7f9a8ab6b070,
msg=0x7f9a8abfef38) at action.c:1079

#15 0x00429ba3 in run_actions (h=0x7fffed081380, a=0x7f9a8ab607b8,
msg=0x7f9a8abfef38) at action.c:1583

#16 0x0042a2d0 in run_top_route (a=0x7f9a8ab607b8,
msg=0x7f9a8abfef38, c=0x7fffed081380) at action.c:1669

#17 0x7f9a891f6d0f in prepare_new_uac (t=0x7f9a6de86518,
i_req=0x7f9a8abfef38, branch=0, uri=0x7fffed0814d0, path=0x7fffed0814b0,
next_hop=0x7f9a8abff1a8, fsocket=0x0, 

snd_flags=..., fproto=0, flags=2, instance=0x7fffed0814a0,
ruid=0x7fffed081490, location_ua=0x7fffed081480) at t_fwd.c:410

#18 0x7f9a891faded in add_uac (t=0x7f9a6de86518, request=0x7f9a8abfef38,
uri=0x7f9a8abff1a8, next_hop=0x7f9a8abff1a8, path=0x7f9a8abff568, proxy=0x0,
fsocket=0x0, 

snd_flags=..., proto=0, flags=2, instance=0x7f9a8abff578,
ruid=0x7f9a8abff590, location_ua=0x7f9a8abff5a0) at t_fwd.c:855

#19 0x7f9a89201ddd in t_forward_nonack (t=0x7f9a6de86518,
p_msg=0x7f9a8abfef38, proxy=0x0, proto=0) at t_fwd.c:1723

#20 0x7f9a891ee374 in t_relay_to (p_msg=0x7f9a8abfef38, proxy=0x0,
proto=0, replicate=0) at t_funcs.c:355

#21 0x7f9a8922bd89 in _w_t_relay_to (p_msg=0x7f9a8abfef38, proxy=0x0,
force_proto=0) at tm.c:1517

#22 0x7f9a8922ceee in w_t_relay (p_msg=0x7f9a8abfef38, _foo=0x0,
_bar=0x0) at tm.c:1718

#23 0x0041d48d in do_action (h=0x7fffed082190, a=0x7f9a8a83e878,
msg=0x7f9a8abfef38) at action.c:1088

#24 0x00429ba3 in run_actions (h=0x7fffed082190, a=0x7f9a8a83e878,
msg=0x7f9a8abfef38) at action.c:1583

#25 0x0042a208 in run_actions_safe (h=0x7fffed0848f0,
a=0x7f9a8a83e878, msg=0x7f9a8abfef38) at action.c:1648

#26 0x00542994 in rval_get_int (h=0x7fffed0848f0,
msg=0x7f9a8abfef38, i=0x7fffed082668, rv=0x7f9a8a83eb60, cache=0x0) at
rvalue.c:924

#27 0x00546bcc in rval_expr_eval_int (h=0x7fffed0848f0,
msg=0x7f9a8abfef38, res=0x7fffed082668, rve=0x7f9a8a83eb58) at rvalue.c:1918

#28 0x00546fc2 in rval_expr_eval_int (h=0x7fffed0848f0,
msg=0x7f9a8abfef38, res=0x7fffed082af0, rve=0x7f9a8a83f280) at rvalue.c:1926

#29 0x0041cf77 in do_action (h=0x7fffed0848f0, a=0x7f9a8a83fbd0,
msg=0x7f9a8abfef38) at action.c:1064

#30 0x00429ba3 in run_actions (h=0x7fffed0848f0, a=0x7f9a8a838c88,
msg=0x7f9a8abfef38) at action.c:1583

#31 0x00419f13 in do_action (h=0x7fffed0848f0, a=0x7f9a8a996598,
msg=0x7f9a8abfef38) at action.c:712

#32 0x00429ba3 in run_actions (h=0x7fffed0848f0, a=0x7f9a8a9955b8,
msg=0x7f9a8abfef38) at action.c:1583

#33 0x0041d3f6 in do_action (h=0x7fffed0848f0, a=0x7f9a8a996a50,
msg=0x7f9a8abfef38) at action.c:1079

#34 0x00429ba3 in run_actions (h=0x7fffed0848f0, a=0x7f9a8a8fa068,
msg=0x7f9a8abfef38) at action.c:1583

#35 0x00419f13 in do_action (h=0x7fffed0848f0, a=0x7f9a8a830c70,
msg=0x7f9a8abfef38) at action.c:712

#36 0x00429ba3 in run_actions (h=0x7fffed0848f0, a=0x7f9a8a830c70,
msg=0x7f9a8abfef38) at action.c:1583

#37 0x0041d3f6 in do_action (h=0x7fffed0848f0, a=0x7f9a8a830db8,
msg=0x7f9a8abfef38) at action.c:1079

#38 

Re: [SR-Users] Kamailio didn't start before increasing fork_delay

[igor.potjevlesch]

Hello Daniel,

 

Thank you. Do you know some OS counters (in /proc I guess?) I can look to in
order to diagnose deeper?

Anyway, I'm already sure that the CAPS was higher than during another period
of time.

 

Regards,

 

Igor.

 

De : Daniel-Constantin Mierla [mailto:mico...@gmail.com] 
Envoyé : vendredi 24 novembre 2017 12:28
À : igor.potjevle...@gmail.com; 'Kamailio (SER) - Users Mailing List'

Objet : Re: [SR-Users] Kamailio didn't start before increasing fork_delay

 

Hello,

it can be some other limits set in the system, I encountered also with
centos/redhat and couldn't figure out myself (well, not a sysadmin here). It
is the reason I added fork_delay and modinit_delay. You have to dig in the
settings of the system and try to tune them.

Happening can be somehow random, a matter of how busy the system is at that
moment.

Cheers,
Daniel

 

On 24.11.17 11:30, igor.potjevle...@gmail.com
  wrote:

Hello Daniel,

 

Both Kamailio and MySQL are running under RHEL. But SELinux is deactivated.

 

Regards,

 

Igor.

 

De : Daniel-Constantin Mierla [mailto:mico...@gmail.com] 
Envoyé : jeudi 23 novembre 2017 12:56
À : Kamailio (SER) - Users Mailing List
 ;
igor.potjevle...@gmail.com  
Objet : Re: [SR-Users] Kamailio didn't start before increasing fork_delay

 

Hello,

are you running on centos/redhat with selinux?

Cheers,
Daniel

 

On 23.11.17 10:45, igor.potjevle...@gmail.com
  wrote:

Hello,

 

We suddenly had an issue on one Kamailio instance: we were not able to
restart. Kamailio started to boot and fork and suddenly crashed.

The last logs reported a failure regarding the ability to connect to one
MySQL instance.

 

I finally succeed  to restart after increasing: fork_delay=5000 to
fork_delay=9000.

 

How this could happen suddenly? We already restarted Kamailio on this
server.

 

Regards,

 

Igor.







___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org  
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users






-- 
Daniel-Constantin Mierla
www.twitter.com/miconda   --
www.linkedin.com/in/miconda  
Kamailio Advanced Training - www.asipto.com  
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
 





-- 
Daniel-Constantin Mierla
www.twitter.com/miconda   --
www.linkedin.com/in/miconda  
Kamailio Advanced Training - www.asipto.com  
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
 
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio didn't start before increasing fork_delay

[igor.potjevlesch]

Hello Daniel,

 

Both Kamailio and MySQL are running under RHEL. But SELinux is deactivated.

 

Regards,

 

Igor.

 

De : Daniel-Constantin Mierla [mailto:mico...@gmail.com] 
Envoyé : jeudi 23 novembre 2017 12:56
À : Kamailio (SER) - Users Mailing List ;
igor.potjevle...@gmail.com
Objet : Re: [SR-Users] Kamailio didn't start before increasing fork_delay

 

Hello,

are you running on centos/redhat with selinux?

Cheers,
Daniel

 

On 23.11.17 10:45, igor.potjevle...@gmail.com
  wrote:

Hello,

 

We suddenly had an issue on one Kamailio instance: we were not able to
restart. Kamailio started to boot and fork and suddenly crashed.

The last logs reported a failure regarding the ability to connect to one
MySQL instance.

 

I finally succeed  to restart after increasing: fork_delay=5000 to
fork_delay=9000.

 

How this could happen suddenly? We already restarted Kamailio on this
server.

 

Regards,

 

Igor.






___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org  
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users





-- 
Daniel-Constantin Mierla
www.twitter.com/miconda   --
www.linkedin.com/in/miconda  
Kamailio Advanced Training - www.asipto.com  
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
 
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Kamailio didn't start before increasing fork_delay

[igor.potjevlesch]

Hello,

 

We suddenly had an issue on one Kamailio instance: we were not able to
restart. Kamailio started to boot and fork and suddenly crashed.

The last logs reported a failure regarding the ability to connect to one
MySQL instance.

 

I finally succeed  to restart after increasing: fork_delay=5000 to
fork_delay=9000.

 

How this could happen suddenly? We already restarted Kamailio on this
server.

 

Regards,

 

Igor.

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Serial forking

[igor.potjevlesch]

Thank you. I'm running 4.2.7 but I think both options are available too.

I'm not sure to understand the first thing about t_set_fr. Currently, when I do 
lookup(aliases), the default behaviour is to send both calls simultaneously if 
there is 2 entries in aliases table. So, first, I'm wondering how can I change 
this behaviour to do serial forking instead.

-Message d'origine-
De : sr-users  De la part de Daniel Tryba
Envoyé : lundi 28 mai 2018 17:13
À : Kamailio (SER) - Users Mailing List 
Objet : Re: [SR-Users] Serial forking

On Mon, May 28, 2018 at 04:55:30PM +0200, igor.potjevle...@gmail.com wrote:
> I know that the default behaviour of two aliases in kamailio.aliases 
> result in parallel forking.
> 
> I'm wondering if its possible to do serial forking instead? For 
> example, in case that the first INVITE has no 180/183, or neither 100 
> Trying, then send the INVITE to the second entry?

Offcourse, fiddle with t_set_fr on a per call basis or the
fr_inv_timer/fr_timer:
http://www.kamailio.org/docs/modules/5.2.x/modules/tm.html#tm.f.t_set_fr

SERIALRELAY is used in stead of the normal RELAY route, it loads available 
endpoints with t_load_contacts:
http://www.kamailio.org/docs/modules/5.2.x/modules/tm.html#tm.f.t_load_contacts
and fetches the first one with t_next_contacts.
In the failure route keep calling t_next_contacts till there are no more.

route[SERIALRELAY] {
if (is_method("INVITE|SUBSCRIBE")) {
t_on_branch("MANAGE_BRANCH");
t_on_reply("MANAGE_REPLY");
}
if (is_method("INVITE")) {
t_load_contacts();
t_next_contacts();

t_on_failure("SERIAL_FAILURE");
}

if (!t_relay()) {
sl_reply_error();
}

break;
}

failure_route[SERIAL_FAILURE] {
if (!t_next_contacts())
{
send_reply("408","Timeout or nobody available");

exit;
}

t_on_branch("MANAGE_BRANCH");
t_on_reply("MANAGE_REPLY");
t_on_failure("SERIAL_FAILURE");

t_relay();
}


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Serial forking

[igor.potjevlesch]

Hello,

 

I know that the default behaviour of two aliases in kamailio.aliases result
in parallel forking.

I'm wondering if its possible to do serial forking instead? For example, in
case that the first INVITE has no 180/183, or neither 100 Trying, then send
the INVITE to the second entry?

 

Regards,

 

Igor.

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Dialplan module for load balancing

[igor.potjevlesch]

Hello,

 

I'm maybe confused on how to use dialplan module.

I have a dialplan setup for a long time now and I'd like to add a new rule
with the same match_exp than an existing one but with a different repl_exp.


If I set the same priority, the latest entry is used systematically. If I
set priority +1, the new rule is never used.

 

The goal is having two rules and alternatively reply with one or the other
repl_exp. Is it possible?

 

Regards,

 

Igor.

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Multi crashes in the same day

[igor.potjevlesch]

Hello Daniel,

 

Thank you for pinpoint.

Is this commit into branch 5 only?

 

Regards,

 

Igor.

 

De : Daniel-Constantin Mierla [mailto:mico...@gmail.com] 
Envoyé : mardi 3 octobre 2017 20:23
À : Kamailio (SER) - Users Mailing List ;
igor.potjevle...@gmail.com
Objet : Re: [SR-Users] Multi crashes in the same day

 

Hello,

likely you got hit by the issue fixed by:

  -
https://github.com/kamailio/kamailio/commit/25f2180999dafb807068313c4a329a16
3dd99f92

4.2 series is old and I expect this commit was not backported there.

Cheers,
Daniel

 

On 03.10.17 18:49, igor.potjevle...@gmail.com
  wrote:

Hello !

 

I have multi crashes on a Kamailio 4.2.8 instance.

Already 6 coredump today, same time with the same scenario. Below the output
of the last coredump:

 

(gdb) where

#0  0x003d6f6328a5 in raise () from /lib64/libc.so.6

#1  0x003d6f634085 in abort () from /lib64/libc.so.6

#2  0x0061aad2 in qm_debug_frag (qm=0x7f9a8a7aa010,
f=0x7f9a8aca5968) at mem/q_malloc.c:161

#3  0x0061bf1c in qm_malloc (qm=0x7f9a8a7aa010, size=24,
file=0x7131d0 ": re.c", func=0x71483e "subst_run", line=440) at
mem/q_malloc.c:388

#4  0x00505e2c in subst_run (se=0x7f9a8ac08b78, input=0x7f9a8aca5918
 "sip:0123456789@customer.local",
msg=0x7f9a8abfef38, count=0x0) at re.c:440

#5  0x00506fff in subst_str (input=0x7f9a8aca5918
 "sip:0123456789@customer.local",
msg=0x7f9a8abfef38, se=0x7f9a8ac08b78, count=0x0) at re.c:515

#6  0x7f9a87ff629d in subst_uri_f (msg=0x7f9a8abfef38,
subst=0x7f9a8ac08b78 "X\215\300\212\232\177", ignored=0x0) at textops.c:744

#7  0x0041d51b in do_action (h=0x7fffed0800d0, a=0x7f9a8ab64cc8,
msg=0x7f9a8abfef38) at action.c:1094

#8  0x00429ba3 in run_actions (h=0x7fffed0800d0, a=0x7f9a8ab64cc8,
msg=0x7f9a8abfef38) at action.c:1583

#9  0x0042a208 in run_actions_safe (h=0x7fffed081380,
a=0x7f9a8ab64cc8, msg=0x7f9a8abfef38) at action.c:1648

#10 0x00542994 in rval_get_int (h=0x7fffed081380,
msg=0x7f9a8abfef38, i=0x7fffed080890, rv=0x7f9a8ab64ef8, cache=0x0) at
rvalue.c:924

#11 0x00546bcc in rval_expr_eval_int (h=0x7fffed081380,
msg=0x7f9a8abfef38, res=0x7fffed080890, rve=0x7f9a8ab64ef0) at rvalue.c:1918

#12 0x0041cf77 in do_action (h=0x7fffed081380, a=0x7f9a8ab66a30,
msg=0x7f9a8abfef38) at action.c:1064

#13 0x00429ba3 in run_actions (h=0x7fffed081380, a=0x7f9a8ab66a30,
msg=0x7f9a8abfef38) at action.c:1583

#14 0x0041d3f6 in do_action (h=0x7fffed081380, a=0x7f9a8ab6b070,
msg=0x7f9a8abfef38) at action.c:1079

#15 0x00429ba3 in run_actions (h=0x7fffed081380, a=0x7f9a8ab607b8,
msg=0x7f9a8abfef38) at action.c:1583

#16 0x0042a2d0 in run_top_route (a=0x7f9a8ab607b8,
msg=0x7f9a8abfef38, c=0x7fffed081380) at action.c:1669

#17 0x7f9a891f6d0f in prepare_new_uac (t=0x7f9a6de86518,
i_req=0x7f9a8abfef38, branch=0, uri=0x7fffed0814d0, path=0x7fffed0814b0,
next_hop=0x7f9a8abff1a8, fsocket=0x0, 

snd_flags=..., fproto=0, flags=2, instance=0x7fffed0814a0,
ruid=0x7fffed081490, location_ua=0x7fffed081480) at t_fwd.c:410

#18 0x7f9a891faded in add_uac (t=0x7f9a6de86518, request=0x7f9a8abfef38,
uri=0x7f9a8abff1a8, next_hop=0x7f9a8abff1a8, path=0x7f9a8abff568, proxy=0x0,
fsocket=0x0, 

snd_flags=..., proto=0, flags=2, instance=0x7f9a8abff578,
ruid=0x7f9a8abff590, location_ua=0x7f9a8abff5a0) at t_fwd.c:855

#19 0x7f9a89201ddd in t_forward_nonack (t=0x7f9a6de86518,
p_msg=0x7f9a8abfef38, proxy=0x0, proto=0) at t_fwd.c:1723

#20 0x7f9a891ee374 in t_relay_to (p_msg=0x7f9a8abfef38, proxy=0x0,
proto=0, replicate=0) at t_funcs.c:355

#21 0x7f9a8922bd89 in _w_t_relay_to (p_msg=0x7f9a8abfef38, proxy=0x0,
force_proto=0) at tm.c:1517

#22 0x7f9a8922ceee in w_t_relay (p_msg=0x7f9a8abfef38, _foo=0x0,
_bar=0x0) at tm.c:1718

#23 0x0041d48d in do_action (h=0x7fffed082190, a=0x7f9a8a83e878,
msg=0x7f9a8abfef38) at action.c:1088

#24 0x00429ba3 in run_actions (h=0x7fffed082190, a=0x7f9a8a83e878,
msg=0x7f9a8abfef38) at action.c:1583

#25 0x0042a208 in run_actions_safe (h=0x7fffed0848f0,
a=0x7f9a8a83e878, msg=0x7f9a8abfef38) at action.c:1648

#26 0x00542994 in rval_get_int (h=0x7fffed0848f0,
msg=0x7f9a8abfef38, i=0x7fffed082668, rv=0x7f9a8a83eb60, cache=0x0) at
rvalue.c:924

#27 0x00546bcc in rval_expr_eval_int (h=0x7fffed0848f0,
msg=0x7f9a8abfef38, res=0x7fffed082668, rve=0x7f9a8a83eb58) at rvalue.c:1918

#28 0x00546fc2 in rval_expr_eval_int (h=0x7fffed0848f0,
msg=0x7f9a8abfef38, res=0x7fffed082af0, rve=0x7f9a8a83f280) at rvalue.c:1926

#29 0x0041cf77 in do_action (h=0x7fffed0848f0, a=0x7f9a8a83fbd0,
msg=0x7f9a8abfef38) at action.c:1064

#30 0x00429ba3 in run_actions (h=0x7fffed0848f0, a=0x7f9a8a838c88,
msg=0x7f9a8abfef38) at action.c:1583

#31 0x00419f13 in do_action (h=0x7fffed0848f0, 

Re: [SR-Users] Dialplan priority

[igor.potjevlesch]

hi Dmitri,

 

Having 2 dpid and use rand_event() seems to work like a charm! Thank you for 
the suggestion.


Regards,

 

Igor.

 

De : sr-users  De la part de Dmitri 
Savolainen
Envoyé : lundi 20 août 2018 19:41
À : Kamailio (SER) - Users Mailing List 
Objet : Re: [SR-Users] Dialplan priority

 

hi, Igor

I'm not sure to understand in which situation "pr" value is used. 

assume you want send 200 to 200 and others to 100

1.  ^.*$ -> 100

2. ^200$->200

 

so you should set   more priority to second rule (for avoid 200 to 100 
translation) like

1.  ^.*$ -> 100; pr=2

2. ^200$->200; pr=1

 

The finality I'd like to accomplish is having some kind of load balacing 
between two values into "repl_exp" with the same inputs conditions.

For balancing you may look for another modules, like drouting or dispatcher

Or use different DPIDs within dialplan: DPID may be chosen by $RANDOM (from 
cfgutils module)

 

On 20 August 2018 at 17:56, mailto:igor.potjevle...@gmail.com> > wrote:

Hello,

 

I'm not sure to understand in which situation "pr" value is used. For example: 
if I have two identical rules except pr value: 1 with 1 and the second with 2, 
then the rule with pr 2 is never used.

 

Someone can help me to understand? Thank you.

 

The finality I'd like to accomplish is having some kind of load balacing 
between two values into "repl_exp" with the same inputs conditions.

 

Thank you.

Regards,

 

Igor.


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org  
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users





 

-- 

Savolainen Dmitri

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Dialplan priority

[igor.potjevlesch]

Hello,

 

I'm not sure to understand in which situation "pr" value is used. For
example: if I have two identical rules except pr value: 1 with 1 and the
second with 2, then the rule with pr 2 is never used.

 

Someone can help me to understand? Thank you.

 

The finality I'd like to accomplish is having some kind of load balacing
between two values into "repl_exp" with the same inputs conditions.

 

Thank you.

Regards,

 

Igor.

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Kamailio 4.2.8 has crashed

[igor.potjevlesch]

Hello,

 

I had a crash on one Kamailio instance with the following backtrace:

 

Core was generated by `/usr/local/sbin/kamailio -m 704 -M 128 -P
/run/kamailio/kamailio.pid'.

Program terminated with signal 6, Aborted.

#0  0x7f92366761f7 in raise () from /lib64/libc.so.6

Missing separate debuginfos, use: debuginfo-install
bzip2-libs-1.0.6-13.el7.x86_64 elfutils-libelf-0.168-8.el7.x86_64
glibc-2.17-196.el7_4.2.x86_64 keyutils-libs-1.5.8-3.el7.x86_64
krb5-libs-1.15.1-8.el7.x86_64 libacl-2.2.51-12.el7.x86_64
libattr-2.4.46-12.el7.x86_64 libcap-2.22-9.el7.x86_64
libcom_err-1.42.9-10.el7.x86_64 libdb-5.3.21-21.el7_4.x86_64
libgcc-4.8.5-16.el7_4.1.x86_64 libselinux-2.5-11.el7.x86_64
libstdc++-4.8.5-16.el7_4.1.x86_64
lm_sensors-libs-3.4.0-4.20160601gitf9185e5.el7.x86_64
lua-5.1.4-15.el7.x86_64 mariadb-libs-5.5.56-2.el7.x86_64
net-snmp-agent-libs-5.7.2-28.el7_4.1.x86_64
net-snmp-libs-5.7.2-28.el7_4.1.x86_64 nspr-4.13.1-1.0.el7_3.x86_64
nss-3.28.4-15.el7_4.x86_64 nss-softokn-freebl-3.28.3-8.el7_4.x86_64
nss-util-3.28.4-3.el7.x86_64 openssl-libs-1.0.2k-8.el7.x86_64
pcre-8.32-17.el7.x86_64 perl-libs-5.16.3-292.el7.x86_64
popt-1.13-16.el7.x86_64 rpm-libs-4.11.3-25.el7.x86_64
tcp_wrappers-libs-7.6-77.el7.x86_64 xz-libs-5.2.2-1.el7.x86_64
zlib-1.2.7-17.el7.x86_64

(gdb) backtrace

#0  0x7f92366761f7 in raise () from /lib64/libc.so.6

#1  0x7f92366778e8 in abort () from /lib64/libc.so.6

#2  0x0061fb2c in qm_free (qm=0x7f91f4eaf000, p=0x7f92110d0300,
file=0x7f9226dd7072 "dialog: dlg_hash.c", func=0x7f9226dd9aeb
<__FUNCTION__.12761> "destroy_dlg", line=381) at mem/q_malloc.c:474

#3  0x7f9226d6fb62 in destroy_dlg (dlg=0x7f920f775598) at dlg_hash.c:381

#4  0x7f9226d75681 in dlg_unref (dlg=0x7f920f775598, cnt=2) at
dlg_hash.c:874

#5  0x7f9226da14d5 in dlg_ontimeout (tl=0x7f920f7755f8) at
dlg_handlers.c:1488

#6  0x7f9226db1e67 in dlg_timer_routine (ticks=8621904, attr=0x0) at
dlg_timer.c:283

#7  0x004af537 in compat_old_handler (ti=137950479,
tl=0x7f91f7ad8cc8, data=0x7f91f7ad8cc8) at timer.c:1011

#8  0x004aff14 in slow_timer_main () at timer.c:1145

#9  0x0052a2af in main_loop () at main.c:1684

#10 0x0052fe71 in main (argc=7, argv=0x7fff51f21418) at main.c:2581

(gdb)

 

Is there enough information to understand the reason of the crash?

 

Regards,

 

Igor.

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio 4.2.8 has crashed

[igor.potjevlesch]

Hello Daniel,

 

Ok, thank you for your feedback. mem_safety is available in 4.2?

 

Regards,

 

Igor.

 

De : Daniel-Constantin Mierla  
Envoyé : mercredi 11 avril 2018 16:06
À : Kamailio (SER) - Users Mailing List ;
igor.potjevle...@gmail.com
Objet : Re: [SR-Users] Kamailio 4.2.8 has crashed

 

Hello,

the reason of the crash is a double free, but why it happened is not clear
-- if you want to avoid crashing on double free, you can set mem_safety=1 .

4.2 is rather old to start digging into its code with a very limited spare
time. Maybe you can try with a newer version and see if you can reproduce.

Cheers,
Daniel

 

On 11.04.18 14:32, igor.potjevle...@gmail.com
  wrote:

Hello,

 

I had a crash on one Kamailio instance with the following backtrace:

 

Core was generated by `/usr/local/sbin/kamailio -m 704 -M 128 -P
/run/kamailio/kamailio.pid'.

Program terminated with signal 6, Aborted.

#0  0x7f92366761f7 in raise () from /lib64/libc.so.6

Missing separate debuginfos, use: debuginfo-install
bzip2-libs-1.0.6-13.el7.x86_64 elfutils-libelf-0.168-8.el7.x86_64
glibc-2.17-196.el7_4.2.x86_64 keyutils-libs-1.5.8-3.el7.x86_64
krb5-libs-1.15.1-8.el7.x86_64 libacl-2.2.51-12.el7.x86_64
libattr-2.4.46-12.el7.x86_64 libcap-2.22-9.el7.x86_64
libcom_err-1.42.9-10.el7.x86_64 libdb-5.3.21-21.el7_4.x86_64
libgcc-4.8.5-16.el7_4.1.x86_64 libselinux-2.5-11.el7.x86_64
libstdc++-4.8.5-16.el7_4.1.x86_64
lm_sensors-libs-3.4.0-4.20160601gitf9185e5.el7.x86_64
lua-5.1.4-15.el7.x86_64 mariadb-libs-5.5.56-2.el7.x86_64
net-snmp-agent-libs-5.7.2-28.el7_4.1.x86_64
net-snmp-libs-5.7.2-28.el7_4.1.x86_64 nspr-4.13.1-1.0.el7_3.x86_64
nss-3.28.4-15.el7_4.x86_64 nss-softokn-freebl-3.28.3-8.el7_4.x86_64
nss-util-3.28.4-3.el7.x86_64 openssl-libs-1.0.2k-8.el7.x86_64
pcre-8.32-17.el7.x86_64 perl-libs-5.16.3-292.el7.x86_64
popt-1.13-16.el7.x86_64 rpm-libs-4.11.3-25.el7.x86_64
tcp_wrappers-libs-7.6-77.el7.x86_64 xz-libs-5.2.2-1.el7.x86_64
zlib-1.2.7-17.el7.x86_64

(gdb) backtrace

#0  0x7f92366761f7 in raise () from /lib64/libc.so.6

#1  0x7f92366778e8 in abort () from /lib64/libc.so.6

#2  0x0061fb2c in qm_free (qm=0x7f91f4eaf000, p=0x7f92110d0300,
file=0x7f9226dd7072 "dialog: dlg_hash.c", func=0x7f9226dd9aeb
<__FUNCTION__.12761> "destroy_dlg", line=381) at mem/q_malloc.c:474

#3  0x7f9226d6fb62 in destroy_dlg (dlg=0x7f920f775598) at dlg_hash.c:381

#4  0x7f9226d75681 in dlg_unref (dlg=0x7f920f775598, cnt=2) at
dlg_hash.c:874

#5  0x7f9226da14d5 in dlg_ontimeout (tl=0x7f920f7755f8) at
dlg_handlers.c:1488

#6  0x7f9226db1e67 in dlg_timer_routine (ticks=8621904, attr=0x0) at
dlg_timer.c:283

#7  0x004af537 in compat_old_handler (ti=137950479,
tl=0x7f91f7ad8cc8, data=0x7f91f7ad8cc8) at timer.c:1011

#8  0x004aff14 in slow_timer_main () at timer.c:1145

#9  0x0052a2af in main_loop () at main.c:1684

#10 0x0052fe71 in main (argc=7, argv=0x7fff51f21418) at main.c:2581

(gdb)

 

Is there enough information to understand the reason of the crash?

 

Regards,

 

Igor.






___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org  
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users





-- 
Daniel-Constantin Mierla
www.twitter.com/miconda   --
www.linkedin.com/in/miconda  
Kamailio Advanced Training - April 16-18, 2018, Berlin - www.asipto.com
 
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
 
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio logs in RHEL 7 environment

[igor.potjevlesch]

Hi Dmitri,

 

Nice, thank you. Sounds good for the moment!

 

Regards,

 

Igor.

 

De : sr-users  De la part de Dmitri 
Savolainen
Envoyé : mercredi 11 avril 2018 14:41
À : Kamailio (SER) - Users Mailing List 
Objet : Re: [SR-Users] Kamailio logs in RHEL 7 environment

 

Hi. i set for it in my centos7 env :

 

/etc/systemd/journald.conf

RateLimitBurst=100

 

/etc/rsyslog.conf 

$imjournalRatelimitInterval 1 $imjournalRatelimitBurst 50 

 

 

systemctl restart rsyslog.service 

systemctl restart systemd-journald

 

 

2018-04-11 15:12 GMT+03:00  >:

Hello !

 

Since I moved my OS to RHEL 7, the logs management has changed. I cannot have 
all logs in /var/log/messages as I used to have. Indeed, there is 
journald/rsyslog which blocked logs to be written after hundreds/thousands of 
messages.

 

I tried to set these values to 0:

vim /etc/systemd/journald.conf

[Journal]

[…]

RateLimitInterval=0

RateLimitBurst=0

 

But the problem is still present.

 

Anyone has already solved this problem?

 

Regards,

 

Igor.


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org  
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users





 

-- 

Savolainen Dmitri

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio 4.2.8 has crashed

[igor.potjevlesch]

Hello Daniel,

 

I got a new occurrence last night with the following backtrace, looks like
the same:

(gdb) backtrace

#0  0x7f92366761f7 in raise () from /lib64/libc.so.6

#1  0x7f92366778e8 in abort () from /lib64/libc.so.6

#2  0x0061fb2c in qm_free (qm=0x7f91f4eaf000, p=0x7f92110d0300,
file=0x7f9226dd7072 "dialog: dlg_hash.c", func=0x7f9226dd9aeb
<__FUNCTION__.12761> "destroy_dlg", line=381) at mem/q_malloc.c:474

#3  0x7f9226d6fb62 in destroy_dlg (dlg=0x7f920f775598) at dlg_hash.c:381

#4  0x7f9226d75681 in dlg_unref (dlg=0x7f920f775598, cnt=2) at
dlg_hash.c:874

#5  0x7f9226da14d5 in dlg_ontimeout (tl=0x7f920f7755f8) at
dlg_handlers.c:1488

#6  0x7f9226db1e67 in dlg_timer_routine (ticks=8621904, attr=0x0) at
dlg_timer.c:283

#7  0x004af537 in compat_old_handler (ti=137950479,
tl=0x7f91f7ad8cc8, data=0x7f91f7ad8cc8) at timer.c:1011

#8  0x004aff14 in slow_timer_main () at timer.c:1145

#9  0x0052a2af in main_loop () at main.c:1684

#10 0x0052fe71 in main (argc=7, argv=0x7fff51f21418) at main.c:2581

 

I start to analyse the gap to upgrade to the latest 4.3 or 4.4 or 5.1. And I
notice that the source code of PDB module has been changed. But, I didn't
found a release note for this changing. Do you know where can I find this?

 

Regards,

 

Igor.

 

De : igor.potjevle...@gmail.com  
Envoyé : mercredi 11 avril 2018 17:31
À : mico...@gmail.com; 'Kamailio (SER) - Users Mailing List'

Objet : RE: [SR-Users] Kamailio 4.2.8 has crashed

 

Hello Daniel,

 

Ok, thank you for your feedback. mem_safety is available in 4.2?

 

Regards,

 

Igor.

 

De : Daniel-Constantin Mierla 
> 
Envoyé : mercredi 11 avril 2018 16:06
À : Kamailio (SER) - Users Mailing List  >; igor.potjevle...@gmail.com
 
Objet : Re: [SR-Users] Kamailio 4.2.8 has crashed

 

Hello,

the reason of the crash is a double free, but why it happened is not clear
-- if you want to avoid crashing on double free, you can set mem_safety=1 .

4.2 is rather old to start digging into its code with a very limited spare
time. Maybe you can try with a newer version and see if you can reproduce.

Cheers,
Daniel

 

On 11.04.18 14:32, igor.potjevle...@gmail.com
  wrote:

Hello,

 

I had a crash on one Kamailio instance with the following backtrace:

 

Core was generated by `/usr/local/sbin/kamailio -m 704 -M 128 -P
/run/kamailio/kamailio.pid'.

Program terminated with signal 6, Aborted.

#0  0x7f92366761f7 in raise () from /lib64/libc.so.6

Missing separate debuginfos, use: debuginfo-install
bzip2-libs-1.0.6-13.el7.x86_64 elfutils-libelf-0.168-8.el7.x86_64
glibc-2.17-196.el7_4.2.x86_64 keyutils-libs-1.5.8-3.el7.x86_64
krb5-libs-1.15.1-8.el7.x86_64 libacl-2.2.51-12.el7.x86_64
libattr-2.4.46-12.el7.x86_64 libcap-2.22-9.el7.x86_64
libcom_err-1.42.9-10.el7.x86_64 libdb-5.3.21-21.el7_4.x86_64
libgcc-4.8.5-16.el7_4.1.x86_64 libselinux-2.5-11.el7.x86_64
libstdc++-4.8.5-16.el7_4.1.x86_64
lm_sensors-libs-3.4.0-4.20160601gitf9185e5.el7.x86_64
lua-5.1.4-15.el7.x86_64 mariadb-libs-5.5.56-2.el7.x86_64
net-snmp-agent-libs-5.7.2-28.el7_4.1.x86_64
net-snmp-libs-5.7.2-28.el7_4.1.x86_64 nspr-4.13.1-1.0.el7_3.x86_64
nss-3.28.4-15.el7_4.x86_64 nss-softokn-freebl-3.28.3-8.el7_4.x86_64
nss-util-3.28.4-3.el7.x86_64 openssl-libs-1.0.2k-8.el7.x86_64
pcre-8.32-17.el7.x86_64 perl-libs-5.16.3-292.el7.x86_64
popt-1.13-16.el7.x86_64 rpm-libs-4.11.3-25.el7.x86_64
tcp_wrappers-libs-7.6-77.el7.x86_64 xz-libs-5.2.2-1.el7.x86_64
zlib-1.2.7-17.el7.x86_64

(gdb) backtrace

#0  0x7f92366761f7 in raise () from /lib64/libc.so.6

#1  0x7f92366778e8 in abort () from /lib64/libc.so.6

#2  0x0061fb2c in qm_free (qm=0x7f91f4eaf000, p=0x7f92110d0300,
file=0x7f9226dd7072 "dialog: dlg_hash.c", func=0x7f9226dd9aeb
<__FUNCTION__.12761> "destroy_dlg", line=381) at mem/q_malloc.c:474

#3  0x7f9226d6fb62 in destroy_dlg (dlg=0x7f920f775598) at dlg_hash.c:381

#4  0x7f9226d75681 in dlg_unref (dlg=0x7f920f775598, cnt=2) at
dlg_hash.c:874

#5  0x7f9226da14d5 in dlg_ontimeout (tl=0x7f920f7755f8) at
dlg_handlers.c:1488

#6  0x7f9226db1e67 in dlg_timer_routine (ticks=8621904, attr=0x0) at
dlg_timer.c:283

#7  0x004af537 in compat_old_handler (ti=137950479,
tl=0x7f91f7ad8cc8, data=0x7f91f7ad8cc8) at timer.c:1011

#8  0x004aff14 in slow_timer_main () at timer.c:1145

#9  0x0052a2af in main_loop () at main.c:1684

#10 0x0052fe71 in main (argc=7, argv=0x7fff51f21418) at main.c:2581

(gdb)

 

Is there enough information to understand the reason of the crash?

 

Regards,

 

Igor.





___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org  

Re: [SR-Users] Kamailio 4.2.8 has crashed

[igor.potjevlesch]

Hello Henning,

Thank you !!

Regards,

Igor.

-Message d'origine-
De : Henning Westerholt  
Envoyé : vendredi 13 avril 2018 17:43
À : sr-users@lists.kamailio.org
Cc : igor.potjevle...@gmail.com; mico...@gmail.com
Objet : Re: [SR-Users] Kamailio 4.2.8 has crashed

On Friday, 13 April 2018 09:46:48 CEST igor.potjevle...@gmail.com wrote:
> [..]
> I start to analyse the gap to upgrade to the latest 4.3 or 4.4 or 5.1. 
> And I notice that the source code of PDB module has been changed. But, 
> I didn't found a release note for this changing. Do you know where can I
find this?
> [..]

Hello Igor,

you can find the changes with git log or on github (e.g. for 5.1):
https://github.com/kamailio/kamailio/commits/5.1/src/modules/pdb

Best regards,

Henning



___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] lookup(aliases) issues with 5.2

[igor.potjevlesch]

Hello Daniel,

 

Thank you for getting back to me.

We will update with 5.2.4 and I'll let you know if it's solved.

 

Regards,

 

Igor.

 

De : Daniel-Constantin Mierla  
Envoyé : mardi 27 août 2019 09:39
À : Kamailio (SER) - Users Mailing List ;
igor.potjevle...@gmail.com
Objet : Re: [SR-Users] lookup(aliases) issues with 5.2

 

Hello,

On 27.08.19 09:27, igor.potjevle...@gmail.com
  wrote:

Hello!

 

Any help on that matter? Sounds like the domain parsing have been updated.
Is it possible to back on the previous mode?

did you mean backporting to older branches? If yes, it was done to branch
5.2, have you tried with latest version in that branch?

Cheers,
Daniel

 

Regards,

 

Igor.

 

De : igor.potjevle...@gmail.com 
  
Envoyé : vendredi 23 août 2019 18:53
À : 'Kamailio (SER) - Users Mailing List'
 
Objet : lookup(aliases) issues with 5.2

 

Hello!

 

I have notice some issues with lookup(aliases) since I upgraded to 5.2 from
5.1:

First with kamctl: If this default command is executed:

 

ctl_cmd_run ul.add "$USRLOC_TABLE" "$OSERUSER@$OSERDOMAIN" "$2" \

"$UL_EXPIRES" "$DEFAULT_Q" "$UL_PATH" "$UL_FLAGS" "$BR_FLAGS" "$ALL_METHODS"

 

as $ALL_METHODS is not defined, there is a huge value in methods and then
lookup(aliases) fails with -2. 

 

I have to update kamctl script and put -1 ("-1") instead of the variable.
So, now, methods is a NULL value in DB and my alias is not ignored. But I
use to make my alias like this: sip:number@blabla_1.local

Which is no longer works: ERROR: registrar [common.c:62]: extract_aor():
failed to parse AoR [sip:number@blabla_1.local]

 

Any idea of the difference since 5.2 with this behaviour? Without the
underscore, the AoR seems to be valid but I need to support underscore as
before.

 

Regards,

 

Igor.





___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org  
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com  
www.twitter.com/miconda   --
www.linkedin.com/in/miconda  
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] lookup(aliases) issues with 5.2

[igor.potjevlesch]

Hello Daniel,

 

We moved to the latest 5.2.4 but hostname with underscore are still not
handle properly. 

Is it a real design choice or a mistake somewhere in the code that handle
domain name?

 

Regards,

 

Igor.

 

De : igor.potjevle...@gmail.com  
Envoyé : mardi 27 août 2019 11:53
À : mico...@gmail.com; 'Kamailio (SER) - Users Mailing List'

Objet : RE: [SR-Users] lookup(aliases) issues with 5.2

 

Hello Daniel,

 

Thank you for getting back to me.

We will update with 5.2.4 and I'll let you know if it's solved.

 

Regards,

 

Igor.

 

De : Daniel-Constantin Mierla mailto:mico...@gmail.com>
> 
Envoyé : mardi 27 août 2019 09:39
À : Kamailio (SER) - Users Mailing List mailto:sr-users@lists.kamailio.org> >; igor.potjevle...@gmail.com
 
Objet : Re: [SR-Users] lookup(aliases) issues with 5.2

 

Hello,

On 27.08.19 09:27, igor.potjevle...@gmail.com
  wrote:

Hello!

 

Any help on that matter? Sounds like the domain parsing have been updated.
Is it possible to back on the previous mode?

did you mean backporting to older branches? If yes, it was done to branch
5.2, have you tried with latest version in that branch?

Cheers,
Daniel

 

Regards,

 

Igor.

 

De : igor.potjevle...@gmail.com 
  
Envoyé : vendredi 23 août 2019 18:53
À : 'Kamailio (SER) - Users Mailing List'
 
Objet : lookup(aliases) issues with 5.2

 

Hello!

 

I have notice some issues with lookup(aliases) since I upgraded to 5.2 from
5.1:

First with kamctl: If this default command is executed:

 

ctl_cmd_run ul.add "$USRLOC_TABLE" "$OSERUSER@$OSERDOMAIN" "$2" \

"$UL_EXPIRES" "$DEFAULT_Q" "$UL_PATH" "$UL_FLAGS" "$BR_FLAGS" "$ALL_METHODS"

 

as $ALL_METHODS is not defined, there is a huge value in methods and then
lookup(aliases) fails with -2. 

 

I have to update kamctl script and put -1 ("-1") instead of the variable.
So, now, methods is a NULL value in DB and my alias is not ignored. But I
use to make my alias like this: sip:number@blabla_1.local

Which is no longer works: ERROR: registrar [common.c:62]: extract_aor():
failed to parse AoR [sip:number@blabla_1.local]

 

Any idea of the difference since 5.2 with this behaviour? Without the
underscore, the AoR seems to be valid but I need to support underscore as
before.

 

Regards,

 

Igor.

 

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org  
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com  
www.twitter.com/miconda   --
www.linkedin.com/in/miconda  
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] lookup(aliases) issues with 5.2

[igor.potjevlesch]

Hello Daniel, Henning,

 

I'd be interested, but if I'm the only one... Otherwise I can indeed remove
this patch as Henning suggests, but it embarrasses me to have a different
source code.

Tell me if it's possible to make it customizable. Otherwise I will consider
either removing the patch or finding another workaround.

 

Regards,

 

Igor.

 

De : Daniel-Constantin Mierla  
Envoyé : mercredi 28 août 2019 20:26
À : igor.potjevle...@gmail.com; 'Kamailio (SER) - Users Mailing List'

Objet : Re: [SR-Users] lookup(aliases) issues with 5.2

 

Hello,

I haven't authored that patch and also never needed an underscore in host
part of the URI, but also it didn't affect me before that change. I guess
Juha wanted o be compliant with the RFC.

If people need to allow an extended set of chars in the host part, I am fine
to add some parameter to control that.

Cheers,
Daniel

On 28.08.19 15:34, igor.potjevle...@gmail.com
  wrote:

Hello,

 

Hmm, ok. Saw it.

Is it possible to reconsider a less strict control?

 

Regards,

 

Igor.

 

De : Daniel-Constantin Mierla  
 
Envoyé : mercredi 28 août 2019 10:25
À : igor.potjevle...@gmail.com  ;
'Kamailio (SER) - Users Mailing List'  

Objet : Re: [SR-Users] lookup(aliases) issues with 5.2

 

Hello,

reading again I see that the error with the host uri is printed from the C
code. I thought of another issue that was reported related to IPv6 addresses
in the URI that kamctl rejected.

The problem is that the underscore is not allowed in hostname: the relevant
standard is RFC 1123, section 2.1 "Host Names and Numbers" which limits host
names to letters-digits-hyphen.

I checked the commits log and it seems this more strict verification was
added by next commit:

commit 4994960324d5353222b3de08515bed07802ab7bc
Author: Juha Heinanen   
Date:   Wed Jan 10 08:39:48 2018 +0200

core/parser: more strict parsing of sip uri host

Regarding the $ALL_METHODS not being defined, iirc, you should set it to .
(or maybe -1 in this case).

Cheers,
Daniel

On 28.08.19 10:12, igor.potjevle...@gmail.com
  wrote:

Hello Daniel,

 

We moved to the latest 5.2.4 but hostname with underscore are still not
handle properly. 

Is it a real design choice or a mistake somewhere in the code that handle
domain name?

 

Regards,

 

Igor.

 

De : igor.potjevle...@gmail.com 
  
Envoyé : mardi 27 août 2019 11:53
À : mico...@gmail.com  ; 'Kamailio (SER) - Users
Mailing List'  

Objet : RE: [SR-Users] lookup(aliases) issues with 5.2

 

Hello Daniel,

 

Thank you for getting back to me.

We will update with 5.2.4 and I'll let you know if it's solved.

 

Regards,

 

Igor.

 

De : Daniel-Constantin Mierla mailto:mico...@gmail.com>
> 
Envoyé : mardi 27 août 2019 09:39
À : Kamailio (SER) - Users Mailing List mailto:sr-users@lists.kamailio.org> >; igor.potjevle...@gmail.com
 
Objet : Re: [SR-Users] lookup(aliases) issues with 5.2

 

Hello,

On 27.08.19 09:27, igor.potjevle...@gmail.com
  wrote:

Hello!

 

Any help on that matter? Sounds like the domain parsing have been updated.
Is it possible to back on the previous mode?

did you mean backporting to older branches? If yes, it was done to branch
5.2, have you tried with latest version in that branch?

Cheers,
Daniel

 

Regards,

 

Igor.

 

De : igor.potjevle...@gmail.com 
  
Envoyé : vendredi 23 août 2019 18:53
À : 'Kamailio (SER) - Users Mailing List'
 
Objet : lookup(aliases) issues with 5.2

 

Hello!

 

I have notice some issues with lookup(aliases) since I upgraded to 5.2 from
5.1:

First with kamctl: If this default command is executed:

 

ctl_cmd_run ul.add "$USRLOC_TABLE" "$OSERUSER@$OSERDOMAIN" "$2" \

"$UL_EXPIRES" "$DEFAULT_Q" "$UL_PATH" "$UL_FLAGS" "$BR_FLAGS" "$ALL_METHODS"

 

as $ALL_METHODS is not defined, there is a huge value in methods and then
lookup(aliases) fails with -2. 

 

I have to update kamctl script and put -1 ("-1") instead of the variable.
So, now, methods is a NULL value in DB and my alias is not ignored. But I
use to make my alias like this: sip:number@blabla_1.local

Which is no longer works: ERROR: registrar [common.c:62]: extract_aor():
failed to parse AoR [sip:number@blabla_1.local]

 

Any idea of the difference since 5.2 with this behaviour? Without the
underscore, the AoR seems to be valid but I need to support underscore as
before.

 

Regards,

 

Igor.

 

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org  

Re: [SR-Users] lookup(aliases) issues with 5.2

[igor.potjevlesch]

Hello,

 

Hmm, ok. Saw it.

Is it possible to reconsider a less strict control?

 

Regards,

 

Igor.

 

De : Daniel-Constantin Mierla  
Envoyé : mercredi 28 août 2019 10:25
À : igor.potjevle...@gmail.com; 'Kamailio (SER) - Users Mailing List'

Objet : Re: [SR-Users] lookup(aliases) issues with 5.2

 

Hello,

reading again I see that the error with the host uri is printed from the C
code. I thought of another issue that was reported related to IPv6 addresses
in the URI that kamctl rejected.

The problem is that the underscore is not allowed in hostname: the relevant
standard is RFC 1123, section 2.1 "Host Names and Numbers" which limits host
names to letters-digits-hyphen.

I checked the commits log and it seems this more strict verification was
added by next commit:

commit 4994960324d5353222b3de08515bed07802ab7bc
Author: Juha Heinanen   
Date:   Wed Jan 10 08:39:48 2018 +0200

core/parser: more strict parsing of sip uri host

Regarding the $ALL_METHODS not being defined, iirc, you should set it to .
(or maybe -1 in this case).

Cheers,
Daniel

On 28.08.19 10:12, igor.potjevle...@gmail.com
  wrote:

Hello Daniel,

 

We moved to the latest 5.2.4 but hostname with underscore are still not
handle properly. 

Is it a real design choice or a mistake somewhere in the code that handle
domain name?

 

Regards,

 

Igor.

 

De : igor.potjevle...@gmail.com 
  
Envoyé : mardi 27 août 2019 11:53
À : mico...@gmail.com  ; 'Kamailio (SER) - Users
Mailing List'  

Objet : RE: [SR-Users] lookup(aliases) issues with 5.2

 

Hello Daniel,

 

Thank you for getting back to me.

We will update with 5.2.4 and I'll let you know if it's solved.

 

Regards,

 

Igor.

 

De : Daniel-Constantin Mierla mailto:mico...@gmail.com>
> 
Envoyé : mardi 27 août 2019 09:39
À : Kamailio (SER) - Users Mailing List mailto:sr-users@lists.kamailio.org> >; igor.potjevle...@gmail.com
 
Objet : Re: [SR-Users] lookup(aliases) issues with 5.2

 

Hello,

On 27.08.19 09:27, igor.potjevle...@gmail.com
  wrote:

Hello!

 

Any help on that matter? Sounds like the domain parsing have been updated.
Is it possible to back on the previous mode?

did you mean backporting to older branches? If yes, it was done to branch
5.2, have you tried with latest version in that branch?

Cheers,
Daniel

 

Regards,

 

Igor.

 

De : igor.potjevle...@gmail.com 
  
Envoyé : vendredi 23 août 2019 18:53
À : 'Kamailio (SER) - Users Mailing List'
 
Objet : lookup(aliases) issues with 5.2

 

Hello!

 

I have notice some issues with lookup(aliases) since I upgraded to 5.2 from
5.1:

First with kamctl: If this default command is executed:

 

ctl_cmd_run ul.add "$USRLOC_TABLE" "$OSERUSER@$OSERDOMAIN" "$2" \

"$UL_EXPIRES" "$DEFAULT_Q" "$UL_PATH" "$UL_FLAGS" "$BR_FLAGS" "$ALL_METHODS"

 

as $ALL_METHODS is not defined, there is a huge value in methods and then
lookup(aliases) fails with -2. 

 

I have to update kamctl script and put -1 ("-1") instead of the variable.
So, now, methods is a NULL value in DB and my alias is not ignored. But I
use to make my alias like this: sip:number@blabla_1.local

Which is no longer works: ERROR: registrar [common.c:62]: extract_aor():
failed to parse AoR [sip:number@blabla_1.local]

 

Any idea of the difference since 5.2 with this behaviour? Without the
underscore, the AoR seems to be valid but I need to support underscore as
before.

 

Regards,

 

Igor.

 

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org  
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com  
www.twitter.com/miconda   --
www.linkedin.com/in/miconda  

-- 
Daniel-Constantin Mierla -- www.asipto.com  
www.twitter.com/miconda   --
www.linkedin.com/in/miconda  
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] lookup(aliases) issues with 5.2

[igor.potjevlesch]

Hello!

 

I have notice some issues with lookup(aliases) since I upgraded to 5.2 from
5.1:

First with kamctl: If this default command is executed:

 

ctl_cmd_run ul.add "$USRLOC_TABLE" "$OSERUSER@$OSERDOMAIN" "$2" \

"$UL_EXPIRES" "$DEFAULT_Q" "$UL_PATH" "$UL_FLAGS" "$BR_FLAGS" "$ALL_METHODS"

 

as $ALL_METHODS is not defined, there is a huge value in methods and then
lookup(aliases) fails with -2. 

 

I have to update kamctl script and put -1 ("-1") instead of the variable.
So, now, methods is a NULL value in DB and my alias is not ignored. But I
use to make my alias like this: sip:number@blabla_1.local

Which is no longer works: ERROR: registrar [common.c:62]: extract_aor():
failed to parse AoR [sip:number@blabla_1.local]

 

Any idea of the difference since 5.2 with this behaviour? Without the
underscore, the AoR seems to be valid but I need to support underscore as
before.

 

Regards,

 

Igor.

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] lookup(aliases) issues with 5.2

[igor.potjevlesch]

Hello!

 

Any help on that matter? Sounds like the domain parsing have been updated.
Is it possible to back on the previous mode?

 

Regards,

 

Igor.

 

De : igor.potjevle...@gmail.com  
Envoyé : vendredi 23 août 2019 18:53
À : 'Kamailio (SER) - Users Mailing List' 
Objet : lookup(aliases) issues with 5.2

 

Hello!

 

I have notice some issues with lookup(aliases) since I upgraded to 5.2 from
5.1:

First with kamctl: If this default command is executed:

 

ctl_cmd_run ul.add "$USRLOC_TABLE" "$OSERUSER@$OSERDOMAIN" "$2" \

"$UL_EXPIRES" "$DEFAULT_Q" "$UL_PATH" "$UL_FLAGS" "$BR_FLAGS" "$ALL_METHODS"

 

as $ALL_METHODS is not defined, there is a huge value in methods and then
lookup(aliases) fails with -2. 

 

I have to update kamctl script and put -1 ("-1") instead of the variable.
So, now, methods is a NULL value in DB and my alias is not ignored. But I
use to make my alias like this: sip:number@blabla_1.local

Which is no longer works: ERROR: registrar [common.c:62]: extract_aor():
failed to parse AoR [sip:number@blabla_1.local]

 

Any idea of the difference since 5.2 with this behaviour? Without the
underscore, the AoR seems to be valid but I need to support underscore as
before.

 

Regards,

 

Igor.

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] lookup(aliases) issues with 5.2

[igor.potjevlesch]

Hello Henning,

 

Thank you!

 

Regards,

 

Igor.

 

De : Henning Westerholt  
Envoyé : vendredi 1 novembre 2019 18:32
À : Kamailio (SER) - Users Mailing List ;
igor.potjevle...@gmail.com; mico...@gmail.com
Objet : Re: [SR-Users] lookup(aliases) issues with 5.2

 

Hello Igor,

functional extensions like this will be usually not be backported to older
stable releases.

But you should be able to easily apply the patch to your local copy, if you
build from tar anyway.

This is the patch, you can apply with the command "patch":

https://github.com/kamailio/kamailio/commit/038158c99da96933c26b11a919ed1cbe
29af9fab.patch

Cheers,

Henning

Am 28.10.19 um 19:13 schrieb igor.potjevle...@gmail.com
 :

Hello Daniel,

 

Thank you!

Is it pushed in one of the latest release? Because we don't have a
connection to git on our server. We build from tar.


Regards,

 

Igor.

 

De : Daniel-Constantin Mierla  
 
Envoyé : jeudi 10 octobre 2019 14:40
À : igor.potjevle...@gmail.com  ;
'Kamailio (SER) - Users Mailing List'  

Objet : Re: [SR-Users] lookup(aliases) issues with 5.2

 

Hello,

I just pushed a commit adding a core parameter to allow specifying
additional character in the host part of URIs:

 -
https://github.com/kamailio/kamailio/commit/038158c99da96933c26b11a919ed1cbe
29af9fab

It is in the master branch. Can you test it and report if works as expected?

Cheers,
Daniel

On 04.10.19 10:08, igor.potjevle...@gmail.com
  wrote:

Hello Daniel,

 

I confirm that we did that indeed. Just added the support of "_" instead of
rollback on the whole code.

 

Thank you!

 

Regards,

 

Igor.

 

De : Daniel-Constantin Mierla  
 
Envoyé : mercredi 11 septembre 2019 09:51
À : igor.potjevle...@gmail.com  ;
'Kamailio (SER) - Users Mailing List'  

Objet : Re: [SR-Users] lookup(aliases) issues with 5.2

 

Hello,

I will think what would be good ways to optimizie.

If you want to change the code, probably doesn't make sense to revert the
entire patch locally, just allow '_' -- you should change:

if(!isalnum(*p) && (*p != '.') && (*p != '-')) {

to

if(!isalnum(*p) && (*p != '.') && (*p != '-') && (*p != '_')) {

in src/core/parser/parse_uri.c -- see function parse_uri() and case
URI_HOST_P.

Cheers,
Daniel

 

On 29.08.19 10:21, igor.potjevle...@gmail.com
  wrote:

Hello Daniel, Henning,

 

I'd be interested, but if I'm the only one... Otherwise I can indeed remove
this patch as Henning suggests, but it embarrasses me to have a different
source code.

Tell me if it's possible to make it customizable. Otherwise I will consider
either removing the patch or finding another workaround.

 

Regards,

 

Igor.

 

De : Daniel-Constantin Mierla  
 
Envoyé : mercredi 28 août 2019 20:26
À : igor.potjevle...@gmail.com  ;
'Kamailio (SER) - Users Mailing List'  

Objet : Re: [SR-Users] lookup(aliases) issues with 5.2

 

Hello,

I haven't authored that patch and also never needed an underscore in host
part of the URI, but also it didn't affect me before that change. I guess
Juha wanted o be compliant with the RFC.

If people need to allow an extended set of chars in the host part, I am fine
to add some parameter to control that.

Cheers,
Daniel

On 28.08.19 15:34, igor.potjevle...@gmail.com
  wrote:

Hello,

 

Hmm, ok. Saw it.

Is it possible to reconsider a less strict control?

 

Regards,

 

Igor.

 

De : Daniel-Constantin Mierla  
 
Envoyé : mercredi 28 août 2019 10:25
À : igor.potjevle...@gmail.com  ;
'Kamailio (SER) - Users Mailing List'  

Objet : Re: [SR-Users] lookup(aliases) issues with 5.2

 

Hello,

reading again I see that the error with the host uri is printed from the C
code. I thought of another issue that was reported related to IPv6 addresses
in the URI that kamctl rejected.

The problem is that the underscore is not allowed in hostname: the relevant
standard is RFC 1123, section 2.1 "Host Names and Numbers" which limits host
names to letters-digits-hyphen.

I checked the commits log and it seems this more strict verification was
added by next commit:

commit 4994960324d5353222b3de08515bed07802ab7bc
Author: Juha Heinanen   
Date:   Wed Jan 10 08:39:48 2018 +0200

core/parser: more strict parsing of sip uri host

Regarding the $ALL_METHODS not being defined, iirc, you should set it to .
(or maybe -1 in this case).

Cheers,
Daniel

On 28.08.19 10:12, igor.potjevle...@gmail.com
  wrote:

Hello Daniel,

 

We moved to the latest 

Re: [SR-Users] lookup(aliases) issues with 5.2

[igor.potjevlesch]

Hello Daniel,

 

Thank you!

Is it pushed in one of the latest release? Because we don't have a
connection to git on our server. We build from tar.


Regards,

 

Igor.

 

De : Daniel-Constantin Mierla  
Envoyé : jeudi 10 octobre 2019 14:40
À : igor.potjevle...@gmail.com; 'Kamailio (SER) - Users Mailing List'

Objet : Re: [SR-Users] lookup(aliases) issues with 5.2

 

Hello,

I just pushed a commit adding a core parameter to allow specifying
additional character in the host part of URIs:

 -
https://github.com/kamailio/kamailio/commit/038158c99da96933c26b11a919ed1cbe
29af9fab

It is in the master branch. Can you test it and report if works as expected?

Cheers,
Daniel

On 04.10.19 10:08, igor.potjevle...@gmail.com
  wrote:

Hello Daniel,

 

I confirm that we did that indeed. Just added the support of "_" instead of
rollback on the whole code.

 

Thank you!

 

Regards,

 

Igor.

 

De : Daniel-Constantin Mierla  
 
Envoyé : mercredi 11 septembre 2019 09:51
À : igor.potjevle...@gmail.com  ;
'Kamailio (SER) - Users Mailing List'  

Objet : Re: [SR-Users] lookup(aliases) issues with 5.2

 

Hello,

I will think what would be good ways to optimizie.

If you want to change the code, probably doesn't make sense to revert the
entire patch locally, just allow '_' -- you should change:

if(!isalnum(*p) && (*p != '.') && (*p != '-')) {

to

if(!isalnum(*p) && (*p != '.') && (*p != '-') && (*p != '_')) {

in src/core/parser/parse_uri.c -- see function parse_uri() and case
URI_HOST_P.

Cheers,
Daniel

 

On 29.08.19 10:21, igor.potjevle...@gmail.com
  wrote:

Hello Daniel, Henning,

 

I'd be interested, but if I'm the only one... Otherwise I can indeed remove
this patch as Henning suggests, but it embarrasses me to have a different
source code.

Tell me if it's possible to make it customizable. Otherwise I will consider
either removing the patch or finding another workaround.

 

Regards,

 

Igor.

 

De : Daniel-Constantin Mierla  
 
Envoyé : mercredi 28 août 2019 20:26
À : igor.potjevle...@gmail.com  ;
'Kamailio (SER) - Users Mailing List'  

Objet : Re: [SR-Users] lookup(aliases) issues with 5.2

 

Hello,

I haven't authored that patch and also never needed an underscore in host
part of the URI, but also it didn't affect me before that change. I guess
Juha wanted o be compliant with the RFC.

If people need to allow an extended set of chars in the host part, I am fine
to add some parameter to control that.

Cheers,
Daniel

On 28.08.19 15:34, igor.potjevle...@gmail.com
  wrote:

Hello,

 

Hmm, ok. Saw it.

Is it possible to reconsider a less strict control?

 

Regards,

 

Igor.

 

De : Daniel-Constantin Mierla  
 
Envoyé : mercredi 28 août 2019 10:25
À : igor.potjevle...@gmail.com  ;
'Kamailio (SER) - Users Mailing List'  

Objet : Re: [SR-Users] lookup(aliases) issues with 5.2

 

Hello,

reading again I see that the error with the host uri is printed from the C
code. I thought of another issue that was reported related to IPv6 addresses
in the URI that kamctl rejected.

The problem is that the underscore is not allowed in hostname: the relevant
standard is RFC 1123, section 2.1 "Host Names and Numbers" which limits host
names to letters-digits-hyphen.

I checked the commits log and it seems this more strict verification was
added by next commit:

commit 4994960324d5353222b3de08515bed07802ab7bc
Author: Juha Heinanen   
Date:   Wed Jan 10 08:39:48 2018 +0200

core/parser: more strict parsing of sip uri host

Regarding the $ALL_METHODS not being defined, iirc, you should set it to .
(or maybe -1 in this case).

Cheers,
Daniel

On 28.08.19 10:12, igor.potjevle...@gmail.com
  wrote:

Hello Daniel,

 

We moved to the latest 5.2.4 but hostname with underscore are still not
handle properly. 

Is it a real design choice or a mistake somewhere in the code that handle
domain name?

 

Regards,

 

Igor.

 

De : igor.potjevle...@gmail.com 
  
Envoyé : mardi 27 août 2019 11:53
À : mico...@gmail.com  ; 'Kamailio (SER) - Users
Mailing List'  

Objet : RE: [SR-Users] lookup(aliases) issues with 5.2

 

Hello Daniel,

 

Thank you for getting back to me.

We will update with 5.2.4 and I'll let you know if it's solved.

 

Regards,

 

Igor.

 

De : Daniel-Constantin Mierla mailto:mico...@gmail.com>
> 
Envoyé : mardi 27 août 2019 09:39
À : Kamailio (SER) - Users Mailing List mailto:sr-users@lists.kamailio.org> >; 

Re: [SR-Users] lookup(aliases) issues with 5.2

[igor.potjevlesch]

Hello Daniel,

 

I confirm that we did that indeed. Just added the support of "_" instead of
rollback on the whole code.

 

Thank you!

 

Regards,

 

Igor.

 

De : Daniel-Constantin Mierla  
Envoyé : mercredi 11 septembre 2019 09:51
À : igor.potjevle...@gmail.com; 'Kamailio (SER) - Users Mailing List'

Objet : Re: [SR-Users] lookup(aliases) issues with 5.2

 

Hello,

I will think what would be good ways to optimizie.

If you want to change the code, probably doesn't make sense to revert the
entire patch locally, just allow '_' -- you should change:

if(!isalnum(*p) && (*p != '.') && (*p != '-')) {

to

if(!isalnum(*p) && (*p != '.') && (*p != '-') && (*p != '_')) {

in src/core/parser/parse_uri.c -- see function parse_uri() and case
URI_HOST_P.

Cheers,
Daniel

 

On 29.08.19 10:21, igor.potjevle...@gmail.com
  wrote:

Hello Daniel, Henning,

 

I'd be interested, but if I'm the only one... Otherwise I can indeed remove
this patch as Henning suggests, but it embarrasses me to have a different
source code.

Tell me if it's possible to make it customizable. Otherwise I will consider
either removing the patch or finding another workaround.

 

Regards,

 

Igor.

 

De : Daniel-Constantin Mierla  
 
Envoyé : mercredi 28 août 2019 20:26
À : igor.potjevle...@gmail.com  ;
'Kamailio (SER) - Users Mailing List'  

Objet : Re: [SR-Users] lookup(aliases) issues with 5.2

 

Hello,

I haven't authored that patch and also never needed an underscore in host
part of the URI, but also it didn't affect me before that change. I guess
Juha wanted o be compliant with the RFC.

If people need to allow an extended set of chars in the host part, I am fine
to add some parameter to control that.

Cheers,
Daniel

On 28.08.19 15:34, igor.potjevle...@gmail.com
  wrote:

Hello,

 

Hmm, ok. Saw it.

Is it possible to reconsider a less strict control?

 

Regards,

 

Igor.

 

De : Daniel-Constantin Mierla  
 
Envoyé : mercredi 28 août 2019 10:25
À : igor.potjevle...@gmail.com  ;
'Kamailio (SER) - Users Mailing List'  

Objet : Re: [SR-Users] lookup(aliases) issues with 5.2

 

Hello,

reading again I see that the error with the host uri is printed from the C
code. I thought of another issue that was reported related to IPv6 addresses
in the URI that kamctl rejected.

The problem is that the underscore is not allowed in hostname: the relevant
standard is RFC 1123, section 2.1 "Host Names and Numbers" which limits host
names to letters-digits-hyphen.

I checked the commits log and it seems this more strict verification was
added by next commit:

commit 4994960324d5353222b3de08515bed07802ab7bc
Author: Juha Heinanen   
Date:   Wed Jan 10 08:39:48 2018 +0200

core/parser: more strict parsing of sip uri host

Regarding the $ALL_METHODS not being defined, iirc, you should set it to .
(or maybe -1 in this case).

Cheers,
Daniel

On 28.08.19 10:12, igor.potjevle...@gmail.com
  wrote:

Hello Daniel,

 

We moved to the latest 5.2.4 but hostname with underscore are still not
handle properly. 

Is it a real design choice or a mistake somewhere in the code that handle
domain name?

 

Regards,

 

Igor.

 

De : igor.potjevle...@gmail.com 
  
Envoyé : mardi 27 août 2019 11:53
À : mico...@gmail.com  ; 'Kamailio (SER) - Users
Mailing List'  

Objet : RE: [SR-Users] lookup(aliases) issues with 5.2

 

Hello Daniel,

 

Thank you for getting back to me.

We will update with 5.2.4 and I'll let you know if it's solved.

 

Regards,

 

Igor.

 

De : Daniel-Constantin Mierla mailto:mico...@gmail.com>
> 
Envoyé : mardi 27 août 2019 09:39
À : Kamailio (SER) - Users Mailing List mailto:sr-users@lists.kamailio.org> >; igor.potjevle...@gmail.com
 
Objet : Re: [SR-Users] lookup(aliases) issues with 5.2

 

Hello,

On 27.08.19 09:27, igor.potjevle...@gmail.com
  wrote:

Hello!

 

Any help on that matter? Sounds like the domain parsing have been updated.
Is it possible to back on the previous mode?

did you mean backporting to older branches? If yes, it was done to branch
5.2, have you tried with latest version in that branch?

Cheers,
Daniel

 

Regards,

 

Igor.

 

De : igor.potjevle...@gmail.com 
  
Envoyé : vendredi 23 août 2019 18:53
À : 'Kamailio (SER) - Users Mailing List'
 
Objet : lookup(aliases) issues with 5.2

 

Hello!

 

I have notice some issues with lookup(aliases) since I upgraded to 5.2 from
5.1:

First with