Re: [SR-Users] set_advertised_address with variable

[Patrick Wakano]

Thanks for the replies Daniel and Henning!
The problem with the listen address is that it can't be set at run time per
call, for example, after reading the value from the DB And also it is
way too dirty to use the set_advertised_address with a static string
value
Long story short, we have a weird telco setup which only allows the SIP
trunk to terminate in their own network, which then puts my Kamailio behind
a NAT box only for them.  And because they are the biggest carrier in that
country, we will have to workaround the issue.
Kamailio itself has only one network interface to communicate with everyone
(other provider and extensions), so I was trying to actually only set the
advertise address before sending call to this specific telco. For calls to
anyone else I would not set the advertise address. Looks simple, but seems
not that easy to implement.

Cheers,
Patrick Wakano

On Tue, 2 Oct 2018 at 15:39, Daniel-Constantin Mierla 
wrote:

> Hello,
>
> the pseudo-variable is read only.
>
> The recommended way would be to use listen with advertise, like:
>
> listen=udp:1.2.3.4:5060 advertise 5.6.7.8:5060
>
> That will take care of both Via and Record-Route headers as well as
> matching myself, no need to do other stuff in route blocks. Doesn't work
> for you?
>
> Cheers,
> Daniel
>
>
> On 01.10.18 22:16, Henning Westerholt wrote:
> > Am Freitag, 28. September 2018, 07:16:18 CEST schrieb Patrick Wakano:
> >> Sorry to annoy again, but I did find a couple of more emails asking
> around
> >> about the possibility to pass a variable to the set_advertised_address,
> but
> >> no one was replied
> >> How is the status of these old core functions that don't accept
> variables
> >> as parameters? Is it something being worked on?
> > Hi Patrick,
> >
> > about the old core function - I think that indeed some of them are still
> > missing PV support. Regarding your question, have you already tried to
> use
> > this PV:
> >
> >
> https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables#rai_-_received_advertised_ip_address
> >
> > Best regards,
> >
> > Henning
> >
>
> --
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio World Conference -- www.kamailioworld.com
> Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com
>
>
> ___
> 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

Re: [SR-Users] rr module not detecting nat=ws route param

[Jon Bonilla (Manwe)]

El Tue, 2 Oct 2018 22:15:48 +0200
Daniel-Constantin Mierla  escribió:

> Even with client on the same host as the server, the port should be
> different. R-URI of ACK has port 5060, like on of the Route headers, so
> I assume only kamailio is using that port.
> 
> R-URI for ACK has to be the contact URI from 200ok and if it is kamailio
> ip:port, then that is what loose_route() is considering to be the Route
> hop based on strict routing rules. The R-URI must be different than
> kamailio ip:port (and transport) to actually consume from Route headers
> via loose processing.
> 
> Try to figure out why ACK has the address of Kamailio in R-URI and not
> the address of the callee.
> 
> 


understood. Thank you. I will check another capture tomorrow in the lab server.




-- 
https://pekepbx.com
https://www.issabel.com/multitenant

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

Re: [SR-Users] rr module not detecting nat=ws route param

[Daniel-Constantin Mierla]

Even with client on the same host as the server, the port should be
different. R-URI of ACK has port 5060, like on of the Route headers, so
I assume only kamailio is using that port.

R-URI for ACK has to be the contact URI from 200ok and if it is kamailio
ip:port, then that is what loose_route() is considering to be the Route
hop based on strict routing rules. The R-URI must be different than
kamailio ip:port (and transport) to actually consume from Route headers
via loose processing.

Try to figure out why ACK has the address of Kamailio in R-URI and not
the address of the callee.

Daniel


On 02.10.18 22:03, Jon Bonilla (Manwe) wrote:
> El Tue, 2 Oct 2018 21:34:12 +0200
> Daniel-Constantin Mierla  escribió:
>
>> Hello,
>>
>> I see MYIP in R-URI and then just MY in the Route headers. Are they
>> different or the same value? 
> Sorry, it's the same value. 
>
>> If the same value, is the sip server
>> address? if yes, then R-URI is matching local address (myself) and that
>> means it is a strict routing and the R-URI is the route processed at
>> that step. Likely the contact address from 200ok gets replaced with
>> server address somewhere in the path of signaling.
>
> The subscriber is in the same IP as the proxy. It's a lab version of a webrtc
> client. client using port 42088, nginx using port 3002 and kamailio using port
> 5060 internally
>
>
> asterisk (OUT) --> 5060 kamailio nginx 2443 --> ua 42088
>
>
>
> Anyway, after loose route I don't know why nat=ws isn't detected. $route_uri
> printed in xlogs shows this:
>
>  $route_uri=sip:MYIP;r2=on;lr=on;did=1d1.7702;nat=ws
>
> According to the doc:
>
> "The function checks if the URI parameters of the local Route header
> (corresponding to the local server) matches the given regular expression. It
> must be call after loose_route()"
>
>  Example 1.15. check_route_param usage
> if (check_route_param("nat=yes"))
>
>
>
>
>
>> Cheers,
>> Daniel
>>
>> On 02.10.18 17:27, Jon Bonilla (Manwe) wrote:
>>> El Mon, 1 Oct 2018 12:16:28 +0300
>>> Igor Olhovskiy  escribió:
>>>  
 Hi!

 What is your original packet, before calling loose_route?
  
>>> 2018/10/02 17:12:41.007053 OUT:5060 -> MYIP:5060
>>>
>>> ACK sip:86to7j7i@MYIP:5060;alias=MY~42088~6;transport=ws;ob SIP/2.0 
>>>
>>> Via: SIP/2.0/UDP OUT;branch=z9hG4bK9658.2fd077002f564d6398951beb959c7708.0 
>>>
>>> Via:SIP/2.0/UDP OUT:5060;rport=5060;branch=z9hG4bK72288d3e 
>>>
>>> Route:
>>> ,
>>>
>>> Max-Forwards: 69 
>>>
>>> From: ;tag=as7bbb1aa3 
>>>
>>> To: ;tag=d04lulkvk7
>>>
>>> Contact:  
>>>
>>> Call-ID: ocuh443d3c0l3mccpujr
>>>
>>> CSeq: 102 ACK
>>>
>>> Content-Length: 0
>>>
>>>  
 Regards, Igor
 On Sep 28, 2018, 1:54 PM +0300, Jon Bonilla (Manwe) ,
 wrote:  
> Hi all. I'm having problems with an indialog ACK request which is not
> being routed correctly.
>
> I call loose_route and print:
>
> $du=sip:MYIP:2443;transport=ws;r2=on;lr=on;did=1d1.7702;nat=ws
> $route_uri=sip:MYIP;r2=on;lr=on;did=1d1.7702;nat=ws
>
> But when I call
>
> check_route_param("nat=ws") I get false result.
>
> version: kamailio 5.1.4
>
> any hints?
>
>
>
> cheers,
>
> Jon
>
>
>
>
> --
> https://pekepbx.com
> https://www.issabel.com/multitenant
>
> ___
> 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 World Conference -- www.kamailioworld.com
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com


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

Re: [SR-Users] rr module not detecting nat=ws route param

[Jon Bonilla (Manwe)]

El Tue, 2 Oct 2018 21:34:12 +0200
Daniel-Constantin Mierla  escribió:

> Hello,
> 
> I see MYIP in R-URI and then just MY in the Route headers. Are they
> different or the same value? 

Sorry, it's the same value. 

>If the same value, is the sip server
> address? if yes, then R-URI is matching local address (myself) and that
> means it is a strict routing and the R-URI is the route processed at
> that step. Likely the contact address from 200ok gets replaced with
> server address somewhere in the path of signaling.


The subscriber is in the same IP as the proxy. It's a lab version of a webrtc
client. client using port 42088, nginx using port 3002 and kamailio using port
5060 internally


asterisk (OUT) --> 5060 kamailio nginx 2443 --> ua 42088



Anyway, after loose route I don't know why nat=ws isn't detected. $route_uri
printed in xlogs shows this:

 $route_uri=sip:MYIP;r2=on;lr=on;did=1d1.7702;nat=ws

According to the doc:

"The function checks if the URI parameters of the local Route header
(corresponding to the local server) matches the given regular expression. It
must be call after loose_route()"

 Example 1.15. check_route_param usage
if (check_route_param("nat=yes"))





> 
> Cheers,
> Daniel
> 
> On 02.10.18 17:27, Jon Bonilla (Manwe) wrote:
> > El Mon, 1 Oct 2018 12:16:28 +0300
> > Igor Olhovskiy  escribió:
> >  
> >> Hi!
> >>
> >> What is your original packet, before calling loose_route?
> >>  
> > 2018/10/02 17:12:41.007053 OUT:5060 -> MYIP:5060
> >
> > ACK sip:86to7j7i@MYIP:5060;alias=MY~42088~6;transport=ws;ob SIP/2.0 
> >
> > Via: SIP/2.0/UDP OUT;branch=z9hG4bK9658.2fd077002f564d6398951beb959c7708.0 
> >
> > Via:SIP/2.0/UDP OUT:5060;rport=5060;branch=z9hG4bK72288d3e 
> >
> > Route:
> > ,
> >
> > Max-Forwards: 69 
> >
> > From: ;tag=as7bbb1aa3 
> >
> > To: ;tag=d04lulkvk7
> >
> > Contact:  
> >
> > Call-ID: ocuh443d3c0l3mccpujr
> >
> > CSeq: 102 ACK
> >
> > Content-Length: 0
> >
> >  
> >> Regards, Igor
> >> On Sep 28, 2018, 1:54 PM +0300, Jon Bonilla (Manwe) ,
> >> wrote:  
> >>> Hi all. I'm having problems with an indialog ACK request which is not
> >>> being routed correctly.
> >>>
> >>> I call loose_route and print:
> >>>
> >>> $du=sip:MYIP:2443;transport=ws;r2=on;lr=on;did=1d1.7702;nat=ws
> >>> $route_uri=sip:MYIP;r2=on;lr=on;did=1d1.7702;nat=ws
> >>>
> >>> But when I call
> >>>
> >>> check_route_param("nat=ws") I get false result.
> >>>
> >>> version: kamailio 5.1.4
> >>>
> >>> any hints?
> >>>
> >>>
> >>>
> >>> cheers,
> >>>
> >>> Jon
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> https://pekepbx.com
> >>> https://www.issabel.com/multitenant
> >>>
> >>> ___
> >>> Kamailio (SER) - Users Mailing List
> >>> sr-users@lists.kamailio.org
> >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >  
> 


-- 
https://pekepbx.com
https://www.issabel.com/multitenant

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

Re: [SR-Users] Kamailio memory manager

[Daniel-Constantin Mierla]

Hello,

pkg is out of free size, not shm. See the output for:

kamctl rpc pkg.stats

You may need to increase the pkg allocated pool with -M command line
parameter.

Cheers,
Daniel


On 02.10.18 20:02, Igor Olhovskiy wrote:
> Hi!
>
> What is the best way to debug messages like...
>
> 29(42) ERROR: [core/mem/q_malloc.c:290]: qm_find_free():
> qm_find_free(0x7fad301cf010, 56); Free fragment not found!
> 29(42) ERROR: [core/mem/q_malloc.c:423]: qm_malloc():
> qm_malloc(0x7fad301cf010, 56) called from core: core/data_lump.c:
> dup_lump_list_r(537), module: core; Free fragment not found!
> 29(42) ERROR: [core/data_lump.c:573]: dup_lump_list_r(): out of mem
> 29(42) ERROR: [core/data_lump.c:573]: dup_lump_list_r(): out of mem
> 29(42) ERROR: [core/data_lump.c:573]: dup_lump_list_r(): out of mem
> 29(42) ERROR: [core/data_lump.c:573]: dup_lump_list_r(): out of mem
> 29(42) ERROR: [core/data_lump.c:573]: dup_lump_list_r(): out of mem
> 29(42) ERROR: [core/data_lump.c:573]: dup_lump_list_r(): out of mem
> 29(42) ERROR: [core/data_lump.c:573]: dup_lump_list_r(): out of mem
> 29(42) ERROR: [core/data_lump.c:573]: dup_lump_list_r(): out of mem
> 29(42) ERROR: tm [t_fwd.c:1735]: t_forward_nonack(): failure to add
> branches
>
> Cause core.shmmem shows
>  total: 536870912
> free: 522859104
> used: 12224144
> real_used: 14011808
> max_used: 14479048
> fragments: 10560
>
>
> Also 
>
> mod.stats all pkg
> Module: core
> {
> init_io_wait(475): 6960
> init_io_wait(524): 6312
> new_db_id(272): 512
> dupl_string_name(72): 32
> db_do_init2(298): 488
> mk_switch_cond_table(43): 144
> sr_wtimer_add(330): 48
> as_asciiz(161): 24
> init_modules(1026): 16
> rpc_hash_add(146): 2048
> db_allocate_columns(150): 32
> db_new_result(114): 56
> get_hdr_field(116): 1160
> db_allocate_columns(160): 16
> cnt_hash_add(383): 1024
> register_select_table(458): 48
> add_callback(59): 320
> sr_wtimer_init(308): 136
> cfg_new_group(79): 704
> cfg_declare(50): 3360
> fix_sock_str(420): 480
> init_dst_set(83): 32208
> grp_hash_add(234): 808
> fix_hostname(1301): 152
> add_alias(91): 464
> add_alias(93): 256
> dupl_string(48): 176
> parse_headers(325): 432
> subst_parser(291): 144
> subst_parser(274): 64
> exp_optimize_right(411): 24
> fix_expr(541): 600
> mk_case_stm(3775): 400
> fixup_regexp_null(213): 72
> mk_elem(90): 560
> route_new_list(200): 1344
> fix_param(1196): 1336
> parse_select(204): 1488
> fix_param(1257): 536
> fix_match_rve(3028): 320
> mk_rval_expr1(2616): 142656
> tr_new(1646): 1464
> fixup_pvar_all(279): 1624
> fix_param(1162): 16144
> mk_action(118): 350168
> mk_rval_expr2(2674): 489552
> mk_rval_expr_v(2537): 1475600
> yyparse(2757): 8792
> pv_parse_format(1150): 89064
> pv_cache_add(347): 31456
> parse_params2(585): 1400
> set_mod_param_regex(110): 376
> set_mod_param_regex(121): 832
> tr_table_add(1875): 400
> sr_cmd_exports_convert(235): 36288
> register_module(280): 6624
> load_module(496): 2640
> new_sock_info(235): 224
> fix_socket_list(1509): 48
> new_sock_info(230): 3920
> add_alias(93): 56
> add_alias(91): 96
> yyparse(1774): 64
> yyparse(667): 152
> yyparse(2306): 128
> yyparse(648): 144
> sr_push_yy_state(1666): 32
> sr_push_yy_state(1656): 104
> sr_push_yy_state(1596): 184
> addstr(1413): 415752
> rpc_hash_add(100): 25656
> str_hash_alloc(59): 512
> pv_table_add(236): 17864
> pv_init_buffer(2055): 327680
> pv_init_buffer(2045): 320
> init_nonsip_hooks(43): 24
> init_rlist(146): 8
> mk_rval_expr_v(2548): 1264
> route_add(124): 5872
> str_hash_alloc(59): 768
> rval_get_str(1256): 56632
> pp_define(1788): 2248
> init_counters(122): 128
> cnt_hash_add(332): 20608
> str_hash_alloc(59): 1280
> Total: 3602152
> }
>
> Module: rtpengine
> {
> child_init(1812): 256
> Total: 256
> }
>
> Module: db_mysql
> {
> db_mysql_new_connection(65): 96
> db_mysql_new_connection(75): 3040
> Total: 3136
> }
>
> Module: siptrace
> {
> mod_init(344): 384
> Total: 384
> }
>
> Module: sl
> {
> sl_register_callback(460): 88
> Total: 88
> }
>
> Module: acc
> {
> parse_acc_extra(116): 1512
> Total: 1512
> }
>
> Module: dialog
> {
> dlg_bridge_init_hdrs(66): 80
> Total: 80
> }
>
> Module: rr
> {
> register_rrcb(61): 80
> Total: 80
> }
>
> Module: db_text
> {
> dbt_get_columns(67): 64
> Total: 64
> }
>
> Module: permissions
> {
> get_pathname(242): 64
> Total: 64
> }
>
> Module: auth
> {
> generate_random_secret(239): 32
> generate_random_secret(238): 32
> Total: 64
> }
>
> Module: xlog
> {
> mod_init(214): 4104
> xdbg_fixup_helper(500): 6032
> xlog_fixup_helper(535): 26992
> Total: 37128
> }
>
> Module: dmq
> {
> make_socket_str_from_uri(149): 24
> Total: 24
> }
>
> Module: sqlops
> {
> sqlops_tr_buffer_init(46): 2048
> sql_init_con(83): 240
> Total: 2288
> }
>
> Module: textops
> {
> tr_txt_parse_re(212): 32
> hname_fixup(3217): 768
> fixup_method(3287): 1384
> Total: 2184
> }
>
> Module: pv
> {
> tr_parse_string(2343): 120
> tr_parse_string(2332): 32
> tr_parse_string(2378): 96
> tr_parse_string(2368): 184
> tr_parse_string(2544): 576
> 

Re: [SR-Users] rr module not detecting nat=ws route param

[Daniel-Constantin Mierla]

Hello,

I see MYIP in R-URI and then just MY in the Route headers. Are they
different or the same value? If the same value, is the sip server
address? if yes, then R-URI is matching local address (myself) and that
means it is a strict routing and the R-URI is the route processed at
that step. Likely the contact address from 200ok gets replaced with
server address somewhere in the path of signaling.

Cheers,
Daniel

On 02.10.18 17:27, Jon Bonilla (Manwe) wrote:
> El Mon, 1 Oct 2018 12:16:28 +0300
> Igor Olhovskiy  escribió:
>
>> Hi!
>>
>> What is your original packet, before calling loose_route?
>>
> 2018/10/02 17:12:41.007053 OUT:5060 -> MYIP:5060
>
> ACK sip:86to7j7i@MYIP:5060;alias=MY~42088~6;transport=ws;ob SIP/2.0 
>
> Via: SIP/2.0/UDP OUT;branch=z9hG4bK9658.2fd077002f564d6398951beb959c7708.0 
>
> Via:SIP/2.0/UDP OUT:5060;rport=5060;branch=z9hG4bK72288d3e 
>
> Route:
> ,
>
> Max-Forwards: 69 
>
> From: ;tag=as7bbb1aa3 
>
> To: ;tag=d04lulkvk7
>
> Contact:  
>
> Call-ID: ocuh443d3c0l3mccpujr
>
> CSeq: 102 ACK
>
> Content-Length: 0
>
>
>> Regards, Igor
>> On Sep 28, 2018, 1:54 PM +0300, Jon Bonilla (Manwe) ,
>> wrote:
>>> Hi all. I'm having problems with an indialog ACK request which is not being
>>> routed correctly.
>>>
>>> I call loose_route and print:
>>>
>>> $du=sip:MYIP:2443;transport=ws;r2=on;lr=on;did=1d1.7702;nat=ws
>>> $route_uri=sip:MYIP;r2=on;lr=on;did=1d1.7702;nat=ws
>>>
>>> But when I call
>>>
>>> check_route_param("nat=ws") I get false result.
>>>
>>> version: kamailio 5.1.4
>>>
>>> any hints?
>>>
>>>
>>>
>>> cheers,
>>>
>>> Jon
>>>
>>>
>>>
>>>
>>> --
>>> https://pekepbx.com
>>> https://www.issabel.com/multitenant
>>>
>>> ___
>>> 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 World Conference -- www.kamailioworld.com
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com


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

[SR-Users] Kamailio memory manager

[Igor Olhovskiy]

Hi!

What is the best way to debug messages like...

29(42) ERROR: [core/mem/q_malloc.c:290]: qm_find_free(): 
qm_find_free(0x7fad301cf010, 56); Free fragment not found!
29(42) ERROR: [core/mem/q_malloc.c:423]: qm_malloc(): qm_malloc(0x7fad301cf010, 
56) called from core: core/data_lump.c: dup_lump_list_r(537), module: core; 
Free fragment not found!
29(42) ERROR: [core/data_lump.c:573]: dup_lump_list_r(): out of mem
29(42) ERROR: [core/data_lump.c:573]: dup_lump_list_r(): out of mem
29(42) ERROR: [core/data_lump.c:573]: dup_lump_list_r(): out of mem
29(42) ERROR: [core/data_lump.c:573]: dup_lump_list_r(): out of mem
29(42) ERROR: [core/data_lump.c:573]: dup_lump_list_r(): out of mem
29(42) ERROR: [core/data_lump.c:573]: dup_lump_list_r(): out of mem
29(42) ERROR: [core/data_lump.c:573]: dup_lump_list_r(): out of mem
29(42) ERROR: [core/data_lump.c:573]: dup_lump_list_r(): out of mem
29(42) ERROR: tm [t_fwd.c:1735]: t_forward_nonack(): failure to add branches

Cause core.shmmem shows
 total: 536870912
free: 522859104
used: 12224144
real_used: 14011808
max_used: 14479048
fragments: 10560


Also

mod.stats all pkg
Module: core
{
init_io_wait(475): 6960
init_io_wait(524): 6312
new_db_id(272): 512
dupl_string_name(72): 32
db_do_init2(298): 488
mk_switch_cond_table(43): 144
sr_wtimer_add(330): 48
as_asciiz(161): 24
init_modules(1026): 16
rpc_hash_add(146): 2048
db_allocate_columns(150): 32
db_new_result(114): 56
get_hdr_field(116): 1160
db_allocate_columns(160): 16
cnt_hash_add(383): 1024
register_select_table(458): 48
add_callback(59): 320
sr_wtimer_init(308): 136
cfg_new_group(79): 704
cfg_declare(50): 3360
fix_sock_str(420): 480
init_dst_set(83): 32208
grp_hash_add(234): 808
fix_hostname(1301): 152
add_alias(91): 464
add_alias(93): 256
dupl_string(48): 176
parse_headers(325): 432
subst_parser(291): 144
subst_parser(274): 64
exp_optimize_right(411): 24
fix_expr(541): 600
mk_case_stm(3775): 400
fixup_regexp_null(213): 72
mk_elem(90): 560
route_new_list(200): 1344
fix_param(1196): 1336
parse_select(204): 1488
fix_param(1257): 536
fix_match_rve(3028): 320
mk_rval_expr1(2616): 142656
tr_new(1646): 1464
fixup_pvar_all(279): 1624
fix_param(1162): 16144
mk_action(118): 350168
mk_rval_expr2(2674): 489552
mk_rval_expr_v(2537): 1475600
yyparse(2757): 8792
pv_parse_format(1150): 89064
pv_cache_add(347): 31456
parse_params2(585): 1400
set_mod_param_regex(110): 376
set_mod_param_regex(121): 832
tr_table_add(1875): 400
sr_cmd_exports_convert(235): 36288
register_module(280): 6624
load_module(496): 2640
new_sock_info(235): 224
fix_socket_list(1509): 48
new_sock_info(230): 3920
add_alias(93): 56
add_alias(91): 96
yyparse(1774): 64
yyparse(667): 152
yyparse(2306): 128
yyparse(648): 144
sr_push_yy_state(1666): 32
sr_push_yy_state(1656): 104
sr_push_yy_state(1596): 184
addstr(1413): 415752
rpc_hash_add(100): 25656
str_hash_alloc(59): 512
pv_table_add(236): 17864
pv_init_buffer(2055): 327680
pv_init_buffer(2045): 320
init_nonsip_hooks(43): 24
init_rlist(146): 8
mk_rval_expr_v(2548): 1264
route_add(124): 5872
str_hash_alloc(59): 768
rval_get_str(1256): 56632
pp_define(1788): 2248
init_counters(122): 128
cnt_hash_add(332): 20608
str_hash_alloc(59): 1280
Total: 3602152
}

Module: rtpengine
{
child_init(1812): 256
Total: 256
}

Module: db_mysql
{
db_mysql_new_connection(65): 96
db_mysql_new_connection(75): 3040
Total: 3136
}

Module: siptrace
{
mod_init(344): 384
Total: 384
}

Module: sl
{
sl_register_callback(460): 88
Total: 88
}

Module: acc
{
parse_acc_extra(116): 1512
Total: 1512
}

Module: dialog
{
dlg_bridge_init_hdrs(66): 80
Total: 80
}

Module: rr
{
register_rrcb(61): 80
Total: 80
}

Module: db_text
{
dbt_get_columns(67): 64
Total: 64
}

Module: permissions
{
get_pathname(242): 64
Total: 64
}

Module: auth
{
generate_random_secret(239): 32
generate_random_secret(238): 32
Total: 64
}

Module: xlog
{
mod_init(214): 4104
xdbg_fixup_helper(500): 6032
xlog_fixup_helper(535): 26992
Total: 37128
}

Module: dmq
{
make_socket_str_from_uri(149): 24
Total: 24
}

Module: sqlops
{
sqlops_tr_buffer_init(46): 2048
sql_init_con(83): 240
Total: 2288
}

Module: textops
{
tr_txt_parse_re(212): 32
hname_fixup(3217): 768
fixup_method(3287): 1384
Total: 2184
}

Module: pv
{
tr_parse_string(2343): 120
tr_parse_string(2332): 32
tr_parse_string(2378): 96
tr_parse_string(2368): 184
tr_parse_string(2544): 576
add_var(58): 3616
add_var(65): 1112
Total: 5736
}

Module: textopsx
{
fixup_hname_param(598): 352
Total: 352
}

Module: avpops
{
avpops_parse_pvar(57): 416
Total: 416
}

Module: userblacklist
{
check_blacklist_fixup(522): 16
Total: 16
}

Module: htable
{
fixup_ht_key(348): 176
pv_parse_ht_name(158): 520
Total: 696
}

Module: dialplan
{
dp_trans_fixup(396): 296
Total: 296
}

Module: dispatcher
{
Total: 0
}

Module: tmx
{
Total: 0
}

Module: tm
{
Total: 0
}

Module: kex
{
Total: 0
}

Module: usrloc
{
Total: 0
}

Module: topos
{
Total: 0
}

Module: utils
{
Total: 0
}

Module: app_python
{
Total: 0
}

Module: cfgutils
{
Total: 0
}

Module: nathelper

Re: [SR-Users] rr module not detecting nat=ws route param

[Jon Bonilla (Manwe)]

El Mon, 1 Oct 2018 12:16:28 +0300
Igor Olhovskiy  escribió:

> Hi!
> 
> What is your original packet, before calling loose_route?
> 

2018/10/02 17:12:41.007053 OUT:5060 -> MYIP:5060

ACK sip:86to7j7i@MYIP:5060;alias=MY~42088~6;transport=ws;ob SIP/2.0 

Via: SIP/2.0/UDP OUT;branch=z9hG4bK9658.2fd077002f564d6398951beb959c7708.0 

Via:SIP/2.0/UDP OUT:5060;rport=5060;branch=z9hG4bK72288d3e 

Route:
,

Max-Forwards: 69 

From: ;tag=as7bbb1aa3 

To: ;tag=d04lulkvk7

Contact:  

Call-ID: ocuh443d3c0l3mccpujr

CSeq: 102 ACK

Content-Length: 0


> Regards, Igor
> On Sep 28, 2018, 1:54 PM +0300, Jon Bonilla (Manwe) ,
> wrote:
> > Hi all. I'm having problems with an indialog ACK request which is not being
> > routed correctly.
> >
> > I call loose_route and print:
> >
> > $du=sip:MYIP:2443;transport=ws;r2=on;lr=on;did=1d1.7702;nat=ws
> > $route_uri=sip:MYIP;r2=on;lr=on;did=1d1.7702;nat=ws
> >
> > But when I call
> >
> > check_route_param("nat=ws") I get false result.
> >
> > version: kamailio 5.1.4
> >
> > any hints?
> >
> >
> >
> > cheers,
> >
> > Jon
> >
> >
> >
> >
> > --
> > https://pekepbx.com
> > https://www.issabel.com/multitenant
> >
> > ___
> > Kamailio (SER) - Users Mailing List
> > sr-users@lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users  


-- 
https://pekepbx.com
https://www.issabel.com/multitenant

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

Re: [SR-Users] clang compiler warnings

[Juha Heinanen]

Floimair Florian writes:

> I think your mail was intended for the baresip mailing list.
> There is no baresip.c in Kamailio

I just wanted to check if it is really so that clang doesn't generate
unused compiler warnings.  Any C source is OK for that test and I just
happened to have baresip.c around.

clang does not produce unused var warnings without -Wunused-variable,
which means that that flag needs to be added to K Makefile.

-- Juha

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

Re: [SR-Users] clang compiler warnings

[Floimair Florian]

Juha

I think your mail was intended for the baresip mailing list.
There is no baresip.c in Kamailio

 
 
With best regards

Florian Floimair
Innovation - Software-Development

COMMEND INTERNATIONAL GMBH
A-5020 Salzburg, Saalachstraße 51
http://www.commend.com 

Security and Communication by Commend

FN 178618z | LG Salzburg

Am 02.10.18, 12:39 schrieb "sr-users im Auftrag von Juha Heinanen" 
:

I just made a test and, for sure, clang warns about unused variables:

$ clang -Wunused-variable -I/usr/include/re -I/usr/include/baresip 
-lbaresip -lrem -lre baresip.c 
baresip.c:48:6: warning: unused variable 'unused' [-Wunused-variable]
int unused;
^
1 warning generated.

-- Juha

___
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] clang compiler warnings

[Juha Heinanen]

I just made a test and, for sure, clang warns about unused variables:

$ clang -Wunused-variable -I/usr/include/re -I/usr/include/baresip -lbaresip 
-lrem -lre baresip.c 
baresip.c:48:6: warning: unused variable 'unused' [-Wunused-variable]
int unused;
^
1 warning generated.

-- Juha

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

Re: [SR-Users] Using TLS on a load-balancing cluster behind DNS-SRV

[Sergey Basov]

Hi Kevin

You need TLS certificate for domain which you will setup on SIP clients to
connect to.

So if your SIP domain is pbx.example.com and you will provide DNS-SRV
record for it - then you need TLS certificate for pbx.example.com
--
Best regards,
Sergey Basov e-mail: sergey.v.ba...@gmail.com


вт, 2 окт. 2018 г. в 12:44, Kevin Olbrich :

> Hi!
>
> Which hostname do I need to request for the certificate when the
> servers are load-balanced using DNS-SRV?
> Do I need to get the cert for the DNS-SRV subdomain (without
> _sip._tls) or for the servers, eg. server0{1,2,3}.pbx.example.com ?
>
> Thank you!
>
> Kevin
>
> ___
> 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] Using TLS on a load-balancing cluster behind DNS-SRV

[Kevin Olbrich]

Hi!

Which hostname do I need to request for the certificate when the
servers are load-balanced using DNS-SRV?
Do I need to get the cert for the DNS-SRV subdomain (without
_sip._tls) or for the servers, eg. server0{1,2,3}.pbx.example.com ?

Thank you!

Kevin

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

Re: [SR-Users] Dialog lifetime for dialogs synced with DMQ

[Charles Chance]

Hi Jan,

I am not completely familiar with the dialog-dmq integration so will need
to take a closer look to understand if this is expected behaviour given its
current implementation.

I should be able to take a look later today or tomorrow morning but in the
meantime, maybe someone else has experience with it and can comment on
whether they see the same.

Cheers,

Charles

On Mon, 1 Oct 2018 at 10:14,  wrote:

> Hello,
>
> I'm using DMQ to sync dialogs between a active and standby kamailio
> node. I noticed that when the standby takes over dialog's they do not
> expire after the lifetime i set on the other node.
>
> Is there a way to make sure that calls are terminated after the dialog
> lifetime expires? I see that the timer is replicated to the other node,
> but nothing happens after the dialog expires. The event routes aren't
> executed as well.
>
> Thanks,
>
> Jan
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-- 
*Charles Chance*
Managing Director

t. 0330 120 1200m. 07932 063 891

-- 
Sipcentric Ltd.
Company registered in England & Wales no. 
7365592. Registered
office: Faraday Wharf, Innovation 
Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Fwd: kamailio with evapi crashing on high volume

[Jayesh Nambiar]

Thanks Daniel.
I'll upgrade to the latest stable version once it is out.

- Jayesh

On Tue, Oct 2, 2018 at 10:55 AM Daniel-Constantin Mierla 
wrote:

> Hello,
>
> I looked at the core files when you reported, but due to busy times
> traveling, I didn't get the chance to follow up. However, the core files
> are truncated, so no useful details there.
>
> We will release 5.1.6 these days, it has few more bits that might help
> troubleshooting here, if there will be another good core dump file.
>
> Cheers,
> Daniel
>
> On 26.09.18 09:25, Jayesh Nambiar wrote:
>
> Hello Daniel,
>
> Just a quick update on this. After running from the 5.1 branch twice it
> happened that Server became unresponsive. It never crashed and on forceful
> shutdown it only generated a core with shutdown routine. Here is what the
> syslog contained off while the calls were being sent to kamailio but
> kamailio was not processing any calls:
>
> Sep 22 16:09:04 triviamedia /usr/local/kamailio/sbin/kamailio[16006]:
> CRITICAL:  [core/mem/q_malloc.c:502]: qm_free(): BUG: freeing already
> freed pointer (0x7fcd23ce5648), called from tm: h_table.c:
> free_cell_helper(235), first free tm: h_table.c: free_cell_helper(235) -
> aborting
> Sep 22 16:09:04 triviamedia /usr/local/kamailio/sbin/kamailio[16006]:
> CRITICAL:  [core/mem/q_malloc.c:502]: qm_free(): BUG: freeing already
> freed pointer (0x7fcd24a38ea8), called from tm: h_table.c:
> free_cell_helper(234), first free tm: h_table.c: free_cell_helper(234) -
> aborting
> Sep 22 16:09:04 triviamedia /usr/local/kamailio/sbin/kamailio[16006]:
> CRITICAL:  [core/mem/q_malloc.c:502]: qm_free(): BUG: freeing already
> freed pointer (0x7fcd23ce5648), called from tm: h_table.c:
> free_cell_helper(235), first free tm: h_table.c: free_cell_helper(235) -
> aborting
> Sep 22 16:09:04 triviamedia /usr/local/kamailio/sbin/kamailio[16006]:
> CRITICAL:  [core/mem/q_malloc.c:502]: qm_free(): BUG: freeing already
> freed pointer (0x7fcd24a38ea8), called from tm: h_table.c:
> free_cell_helper(234), first free tm: h_table.c: free_cell_helper(234) -
> aborting
> Sep 22 16:09:04 triviamedia /usr/local/kamailio/sbin/kamailio[16006]:
> CRITICAL:  [core/mem/q_malloc.c:502]: qm_free(): BUG: freeing already
> freed pointer (0x7fcd23ce5648), called from tm: h_table.c:
> free_cell_helper(235), first free tm: h_table.c: free_cell_helper(235) -
> aborting
> Sep 22 16:09:04 triviamedia /usr/local/kamailio/sbin/kamailio[16006]:
> CRITICAL:  [core/mem/q_malloc.c:502]: qm_free(): BUG: freeing already
> freed pointer (0x7fcd24a38ea8), called from tm: h_table.c:
> free_cell_helper(234), first free tm: h_table.c: free_cell_helper(234) -
> aborting
> Sep 22 16:09:04 triviamedia /usr/local/kamailio/sbin/kamailio[16006]:
> CRITICAL:  [core/mem/q_malloc.c:502]: qm_free(): BUG: freeing already
> freed pointer (0x7fcd23ce5648), called from tm: h_table.c:
> free_cell_helper(235), first fre
>
> And here's the "bt full" of the core file:
> [New LWP 16003]
> Cannot access memory at address 0x7fcd64e1a148
> Cannot access memory at address 0x7fcd64e1a140
> Failed to read a valid object file image from memory.
> Core was generated by `/usr/local/kamailio/sbin/kamailio -P
> /var/run/siptrunk.pid -f /usr/local/carrie'.
> Program terminated with signal SIGABRT, Aborted.
> #0  0x7fcd6443f428 in ?? ()
> (gdb) bt full
> #0  0x7fcd6443f428 in ?? ()
> No symbol table info available.
> Backtrace stopped: Cannot access memory at address 0x7ffed40e9e68
>
> Thanks,
>
> - Jayesh
>
> On Sat, Sep 15, 2018 at 7:09 PM Jayesh Nambiar 
> wrote:
>
>> Hello Daniel,
>> I have now git cloned from 5.1 branch and restarted kamailio today. Also
>> an observation; that when one particular customer with around 40-50cps
>> capacity starts his dialing is when the kamailio kept crashing. I will
>> observe in the coming week and report of any crashes accordingly.
>>
>> Thanks,
>>
>> - Jayesh
>>
>> On Wed, Sep 12, 2018 at 3:11 AM Jayesh Nambiar 
>> wrote:
>>
>>> Thank you Daniel. I will deploy from 5.1 branch. I will be able to
>>> update it in next two days. Since this is a production system, I will have
>>> to have find a proper time slot to get this updated. Will let you know once
>>> that is done.
>>> Thanks again.
>>>
>>> - Jayesh
>>>
>>> On Tue, Sep 11, 2018 at 2:16 PM Daniel-Constantin Mierla <
>>> mico...@gmail.com> wrote:
>>>
 Hi Jayesh,

 I looked over the weekend and seems like a race or a double free. I
 backported some patches to tm module from master to 5.1 branch (a counter
 to see if there is more than one free). Would you be able to deploy from
 branch 5.1 or nightly builds for 5.1? With the next crash I can evaluate
 (rule out or go for it) if it is double free or not.

 I haven't written you yet, because I planned to dig more into libev
 (which is used by evapi), to see if it creates some threads that can mess
 up with some kamailio globals, although I expect it is event loop in a
 single thread. Other 

Re: [SR-Users] [DMQ] dmq_send_message function usage.

[José Seabra]

Thank you Charles.
As soon as i can i will try it.

Once again thanks for your great job.

Regards


Denys Pozniak  escreveu no dia quinta, 27/09/2018
à(s) 08:39:

> Thank you for the information!
>
> 2018-09-27 10:20 GMT+03:00 Charles Chance :
>
>> Hello,
>>
>> You could certainly construct the message using dmq_send_message()
>> function, however, you would not be able to access the reply. DMQ is
>> designed primarily for one-way replication of information to other nodes,
>> without caring much about the response other than that it is success or
>> failure.
>>
>> You could probably achieve what you’re looking for using http and/or
>> jsonrpc modules quite easily.
>>
>> Cheers,
>>
>> Charles
>>
>>
>> On Thu, 27 Sep 2018 at 09:12, Denys Pozniak 
>> wrote:
>>
>>> Hello!
>>>
>>> I have set of Kamailios which distributed location via dmq_usrloc.
>>> Could I construct synthetic DMQ message from separate Kamailio node to
>>> this cluster to get location info for the specific user?
>>>
>>> If yes, please explain how to do it.
>>>
>>> --
>>>
>>> BR,
>>> Denys Pozniak
>>> ___
>>> Kamailio (SER) - Users Mailing List
>>> sr-users@lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>> --
>> *Charles Chance*
>> Managing Director
>>
>> t. 0330 120 1200m. 07932 063 891
>>
>> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
>> office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
>> Birmingham Science Park, Birmingham B7 4BB.
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>
>
> --
>
> BR,
> Denys Pozniak
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


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

Re: [SR-Users] Forcing outbound transport to TCP

[Daniel-Constantin Mierla]

Hello,

in KEMI you can do:

KSR.setdsturi("sip:_IP_OR_DOMAIN_:_PORT_;transport=tcp");

KSR.tm.t_relay()

I will review what tm functions are not exported yet and add those that
are still relevant. In Kamailio we had the t_relay_to(...), which allow
setting the transport in the parameter, the variants for
t_relay_to_tcp/tls/... were retrieve via tm branch and I haven't use them.

Cheers,
Daniel

On 28.09.18 12:07, Ivan Ribakov wrote:
> How would one achieve the same using KEMI? I can see there is a KSR.tm
> module
> - 
> https://kamailio.org/docs/tutorials/devel/kamailio-kemi-framework/modules/#tm 
> which
> has “t_relay()” function but it has no “t_relay_to_tcp()”.
>
>> On 28 Sep 2018, at 11:22, Ivan Ribakov > > wrote:
>>
>> Thanks Daniel!
>>
>> route[RELAY] section is what I’ve been looking for!
>> I knew about t_relay_to_tcp() function but placing it directly in the
>> end of “request_route” block lead to undesirable behaviour which made
>> me think it’s not what I needed.
>>
>>> On 28 Sep 2018, at 10:40, Daniel Tryba >> > wrote:
>>>
>>> On Fri, Sep 28, 2018 at 10:07:09AM +0200, Ivan Ribakov wrote:
 In a basic scenario of one2one call, I was able to make Kamailio to
 forward INVITE to callee over TCP by issuing a REGISTER request
 with ???transport=tcp??? parameter. Although it worked, as far as I
 understand that means all communication with the callee will be
 happening over TCP. I would like to be able to change transport
 dynamically so looking for a way to do that from config file.
>>> ...
 Any pointers as to how can I modify the outbound message transport?
 Do I need to use some extra modules or can it be achieved with a
 basic setup?
>>>
>>> You can do this by explicitly calling t_relay_to_tcp() instead of
>>> t_relay().
>>>
>>> For example I modified route[RELAY] for a specific destination that
>>> wants TCP for large INVITEs.
>>>
>>> if($avp(dispatcherid)=="1" && $ml>1249)
>>> {
>>> if(!t_relay_to_tcp())
>>> {
>>> if(!t_relay())
>>> {
>>> sl_reply_error();
>>> }
>>> }
>>> }
>>> else
>>> {
>>> if(!t_relay())
>>> {
>>> sl_reply_error();
>>> }
>>> }
>>>
>>>
>>> ___
>>> 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

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

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