Re: [SR-Users] issues using evapi module
Dear all, Daniel
we have been testing this module with the following setup
kamailio 5.3.2
evapi params
modparam("evapi", "workers", 4)
modparam("evapi", "netstring_format", 0)
modparam("evapi", "bind_addr", "127.0.0.1:8448")
modparam("evapi", "max_clients", 32)
then in the configuration we do evapi_relay of avp including a json data
(which can be quite long), like this
{"key" : "aarp2q0tcpqhs0cpucuhukjs2ah2j00q@10.18.5.64" , "msg" :
{"rg_in":"701","ani_init":{"ani_source":"pai", ... }}}
We have an application listening on the tcp socket and writing those
messages to a kafka cluster, and this works ok, and in the previous manual
tests we have done no issue was found.
But when making some load tests, and passing some live traffic we see some
issues
seems like some times, when there are messages to be sent to the tcp socket
at the same time, they are sent in the same message, when normally each
data sent using evapi_relay is sent in 1 message
We do sometimes see something like this on the application consuming from
the tcp socket
2020-11-25 15:20:01.744 UTC [error]
<0.706.0>@evapi_kafka_listener:handle_info:167 body "{\"key\" : \"
6142651aa63616c6c04a783cd@72.21.24.130\" , \"msg\" :
{\"rg_in\":\"677\",\"ani_init\":{\"ani_source\":\"fro\",...}}}{\"key\"
: \"isbc7caT4001915251VabcGhEfHdNiF0i@172.16.120.1\" , \"msg\" :
{\"rg_in\":\"22\",\"ani_init\":{\"ani_source\":\"pai\", ...
,\"translate" not valid json; error = {691,invalid_trailing_data}
2020-11-25 15:20:01.745 UTC [error]
<0.706.0>@evapi_kafka_listener:handle_info:167 body
"dPartition\":\"-1\",..}}}" not valid json; error = {1,invalid_json}
and we do see that the application cannot parse the json message fine,
because we have like 2 json objects together
..{\"ani_source\":\"fro\",...}}}{\"key\" :
\"isbc7caT4001915251Vabc
This happens with 2 different UDP receivers processing messages and calling
evapi_relay at the same time. But i don't think this happens all the time.
Seems like some issue when several processes try to use evapi workers at
the same time.
We tried to increase evapi workers and it's the same
We also saw another issue I think. Seems when the avp sent to evapi socket
is bigger than ~1680 char, the json is also truncated, and also happens
when we use the socket in Lo interface which has an MTU of 65535.
Could you please take a look to see if there is any problem or limitation,
or if we are using something wrong?
thanks and best regards
david
El mar, 29 sept 2020 a las 13:40, David Escartin ()
escribió:
> hello Daniel
>
> thanks, finally i could do that, i was struggling with this because in
> kamailio 5.4 there was not being created a socket on the bindaddr param
> when starting kamailio. (that's why i even tried to start to listen on a
> regular tcp socket to connect there an application)
> But in 5.5 and 5.3 it does, so i could move forward and send the events to
> an external application
>
> best regards
> david
>
> El lun., 21 sept. 2020 a las 9:45, Daniel-Constantin Mierla (<
> mico...@gmail.com>) escribió:
>
>> Hello,
>>
>> you must have a different socket in modparam("evapi", "bind_addr", "...")
>> than the core listen parameter for sip tcp traffic. The connect with your
>> evapi app to the socket specified in modparam.
>>
>> Cheers,
>> Daniel
>> On 15.09.20 09:29, David Escartin wrote:
>>
>> hello Daniel
>>
>> i have tried the directive
>> listen=127.0.0.1:8448 and listen=tcp:127.0.0.1:8448
>> and i tried now for example to connect with a tcp client from port 48583
>> (randomly selected when i made the tcp connect i guess)
>>
>> tcp0 0 127.0.0.1:8448 127.0.0.1:48583
>> ESTABLISHED 4508/kamailiokeepalive (2.24/0/0)
>>
>> i configured the kernel to send keep alives 30secs after the tcp
>> connection
>>
>> should this be ok?
>>
>> best regards
>> david
>>
>> El lun., 14 sept. 2020 a las 18:50, Daniel-Constantin Mierla (<
>> mico...@gmail.com>) escribió:
>>
>>> Hello,
>>>
>>> to what port do you connect for evapi?
>>>
>>> The logs indicate connection to sip tcp port.
>>>
>>> Cheers,
>>> Daniel
>>> On 14.09.20 18:06, David Escartin wrote:
>>>
>>> Dear all
>>>
>>> We are tr
Re: [SR-Users] issues using evapi module
hello Daniel
thanks, finally i could do that, i was struggling with this because in
kamailio 5.4 there was not being created a socket on the bindaddr param
when starting kamailio. (that's why i even tried to start to listen on a
regular tcp socket to connect there an application)
But in 5.5 and 5.3 it does, so i could move forward and send the events to
an external application
best regards
david
El lun., 21 sept. 2020 a las 9:45, Daniel-Constantin Mierla (<
mico...@gmail.com>) escribió:
> Hello,
>
> you must have a different socket in modparam("evapi", "bind_addr", "...")
> than the core listen parameter for sip tcp traffic. The connect with your
> evapi app to the socket specified in modparam.
>
> Cheers,
> Daniel
> On 15.09.20 09:29, David Escartin wrote:
>
> hello Daniel
>
> i have tried the directive
> listen=127.0.0.1:8448 and listen=tcp:127.0.0.1:8448
> and i tried now for example to connect with a tcp client from port 48583
> (randomly selected when i made the tcp connect i guess)
>
> tcp0 0 127.0.0.1:8448 127.0.0.1:48583
> ESTABLISHED 4508/kamailiokeepalive (2.24/0/0)
>
> i configured the kernel to send keep alives 30secs after the tcp connection
>
> should this be ok?
>
> best regards
> david
>
> El lun., 14 sept. 2020 a las 18:50, Daniel-Constantin Mierla (<
> mico...@gmail.com>) escribió:
>
>> Hello,
>>
>> to what port do you connect for evapi?
>>
>> The logs indicate connection to sip tcp port.
>>
>> Cheers,
>> Daniel
>> On 14.09.20 18:06, David Escartin wrote:
>>
>> Dear all
>>
>> We are trying to use the evapi module to send some data to an external
>> application but I'm having problems getting the clients connected.
>>
>> I have the kamailio (version 5.3) running with a tcp socket
>> 127.0.0.1:8228, and the evapi params are just
>> modparam("evapi", "workers", 4)
>> modparam("evapi", "netstring_format", 0)
>> modparam("evapi", "bind_addr", "127.0.0.1:8448")
>> modparam("evapi", "max_clients", 32)
>>
>> I tried a different number of workers and netstring_format 1 too.
>> When I start the kamailio i added some debug to the code, and seems when
>> doing the mod init of the evapi dispatcher
>> 38(4779) DEBUG: [core/sr_module.c:779]: init_mod_child(): idx 38
>> rank -2: evapi [EvAPI Dispatcher]
>> it reaches to
>> while(1) {
>> ev_loop (loop, 0);
>> }
>> at evapi_run_dispatcher function.
>> I guess if I connected to the tcp socket and sent some event, I would see
>> the client accepted and the event route evapi:connection-new would be
>> triggered. But i'm not able to do that.
>> I tried to use the prime option, a tcp input client connection from
>> logstash, so i could relay the data to the logstash using the evapi relay,
>> but i only see the tcp socket being created but no client accepted.
>> I also tried to connect with an erlang gen_tcp client, but it's the same
>> i only see
>>
>> 47(4798) DEBUG: [core/ip_addr.c:229]: print_ip(): tcpconn_new: new
>> tcp connection: 127.0.0.1
>> 47(4798) DEBUG: [core/tcp_main.c:1174]: tcpconn_new(): on port
>> 54537, type 2, socket 105
>> 47(4798) DEBUG: [core/tcp_main.c:1497]: tcpconn_add(): hashes:
>> 1117:1187:1505, 1
>> 47(4798) DEBUG: [core/io_wait.h:375]: io_watch_add(): DBG:
>> io_watch_add(0xad0880, 105, 2, 0x7fc211712d58), fd_no=53
>> and if i try to send any data
>>
>> 47(4798) DEBUG: [core/io_wait.h:600]: io_watch_del(): DBG:
>> io_watch_del (0xad0880, 105, -1, 0x0) fd_no=54 called
>> 47(4798) DEBUG: [core/tcp_main.c:4456]: handle_tcpconn_ev():
>> sending to child, events 1
>> 47(4798) DEBUG: [core/tcp_main.c:4129]: send2child(): selected tcp
>> worker idx:0 proc:43 pid:4791 for activity on [tcp:127.0.0.1:8448],
>> 0x7fc211712d58
>> 43(4791) DEBUG: [core/tcp_read.c:1749]: handle_io(): received n=8
>> con=0x7fc211712d58, fd=39
>> 43(4791) DEBUG: [core/io_wait.h:375]: io_watch_add(): DBG:
>> io_watch_add(0xb3c720, 39, 2, 0x7fc211712d58), fd_no=1
>> 43(4791) DEBUG: [core/io_wait.h:600]: io_watch_del(): DBG:
>> io_watch_del (0xb3c720, 39, -1, 0x10) fd_no=2 called
>> 43(4791) DEBUG: [core/tcp_read.c:1671]: release_tcpconn():
>> releasing con 0x7fc211712d58, state 1, fd=39, id=1 ([127.0.0.1]:54537 ->
>> [127.0.0.1]:8448)
>> 43(4791) DEBUG: [core/tcp_read.c:1672]: release_tcpconn():
>> extra_data (nil)
>> 47(4798) DEBUG: [core/tcp_main.c:
Re: [SR-Users] issues using evapi module
hello Daniel
i have tried the directive
listen=127.0.0.1:8448 and listen=tcp:127.0.0.1:8448
and i tried now for example to connect with a tcp client from port 48583
(randomly selected when i made the tcp connect i guess)
tcp0 0 127.0.0.1:8448 127.0.0.1:48583
ESTABLISHED 4508/kamailiokeepalive (2.24/0/0)
i configured the kernel to send keep alives 30secs after the tcp connection
should this be ok?
best regards
david
El lun., 14 sept. 2020 a las 18:50, Daniel-Constantin Mierla (<
mico...@gmail.com>) escribió:
> Hello,
>
> to what port do you connect for evapi?
>
> The logs indicate connection to sip tcp port.
>
> Cheers,
> Daniel
> On 14.09.20 18:06, David Escartin wrote:
>
> Dear all
>
> We are trying to use the evapi module to send some data to an external
> application but I'm having problems getting the clients connected.
>
> I have the kamailio (version 5.3) running with a tcp socket
> 127.0.0.1:8228, and the evapi params are just
> modparam("evapi", "workers", 4)
> modparam("evapi", "netstring_format", 0)
> modparam("evapi", "bind_addr", "127.0.0.1:8448")
> modparam("evapi", "max_clients", 32)
>
> I tried a different number of workers and netstring_format 1 too.
> When I start the kamailio i added some debug to the code, and seems when
> doing the mod init of the evapi dispatcher
> 38(4779) DEBUG: [core/sr_module.c:779]: init_mod_child(): idx 38
> rank -2: evapi [EvAPI Dispatcher]
> it reaches to
> while(1) {
> ev_loop (loop, 0);
> }
> at evapi_run_dispatcher function.
> I guess if I connected to the tcp socket and sent some event, I would see
> the client accepted and the event route evapi:connection-new would be
> triggered. But i'm not able to do that.
> I tried to use the prime option, a tcp input client connection from
> logstash, so i could relay the data to the logstash using the evapi relay,
> but i only see the tcp socket being created but no client accepted.
> I also tried to connect with an erlang gen_tcp client, but it's the same
> i only see
>
> 47(4798) DEBUG: [core/ip_addr.c:229]: print_ip(): tcpconn_new: new
> tcp connection: 127.0.0.1
> 47(4798) DEBUG: [core/tcp_main.c:1174]: tcpconn_new(): on port
> 54537, type 2, socket 105
> 47(4798) DEBUG: [core/tcp_main.c:1497]: tcpconn_add(): hashes:
> 1117:1187:1505, 1
> 47(4798) DEBUG: [core/io_wait.h:375]: io_watch_add(): DBG:
> io_watch_add(0xad0880, 105, 2, 0x7fc211712d58), fd_no=53
> and if i try to send any data
>
> 47(4798) DEBUG: [core/io_wait.h:600]: io_watch_del(): DBG:
> io_watch_del (0xad0880, 105, -1, 0x0) fd_no=54 called
> 47(4798) DEBUG: [core/tcp_main.c:4456]: handle_tcpconn_ev():
> sending to child, events 1
> 47(4798) DEBUG: [core/tcp_main.c:4129]: send2child(): selected tcp
> worker idx:0 proc:43 pid:4791 for activity on [tcp:127.0.0.1:8448],
> 0x7fc211712d58
> 43(4791) DEBUG: [core/tcp_read.c:1749]: handle_io(): received n=8
> con=0x7fc211712d58, fd=39
> 43(4791) DEBUG: [core/io_wait.h:375]: io_watch_add(): DBG:
> io_watch_add(0xb3c720, 39, 2, 0x7fc211712d58), fd_no=1
> 43(4791) DEBUG: [core/io_wait.h:600]: io_watch_del(): DBG:
> io_watch_del (0xb3c720, 39, -1, 0x10) fd_no=2 called
> 43(4791) DEBUG: [core/tcp_read.c:1671]: release_tcpconn():
> releasing con 0x7fc211712d58, state 1, fd=39, id=1 ([127.0.0.1]:54537 ->
> [127.0.0.1]:8448)
> 43(4791) DEBUG: [core/tcp_read.c:1672]: release_tcpconn():
> extra_data (nil)
> 47(4798) DEBUG: [core/tcp_main.c:3559]: handle_tcp_child(): reader
> response= 7fc211712d58, 1 from 0
> 47(4798) DEBUG: [core/io_wait.h:375]: io_watch_add(): DBG:
> io_watch_add(0xad0880, 105, 2, 0x7fc211712d58), fd_no=53
> 47(4798) DEBUG: [core/tcp_main.c:3686]: handle_tcp_child():
> CONN_RELEASE 0x7fc211712d58 refcnt= 1
>
> and when i try to send any data
> 38(10867) DEBUG: evapi [evapi_dispatch.c:610]: evapi_recv_notify():
> received [0x7f17d23fc628] [{"test" : "1.1.1.1", "uuid" : "1-31629@3.3.3.3"
> , "pdd" : "4"}] (75)
> 38(10867) DEBUG: evapi [evapi_dispatch.c:316]: evapi_dispatch_notify():
> the message was sent to 0 clients
>
> I don't know what i'm missing, or if i'm understanding the use of the
> module correctly
>
> could you please take a look?
> thanks a lot
> David
>
>
> --
> [image: Logo]
>
> David Escartín Almudévar
> VoIP/Switch Engineer
> descar...@sonoc.io
>
> *SONOC*
> C/ Josefa Amar y Borbón, 10, 4ª · 50001 Zaragoza, España
> Tlf: +34 917019888 · www.sonoc.io
>
> ___
[SR-Users] issues using evapi module
Dear all
We are trying to use the evapi module to send some data to an external
application but I'm having problems getting the clients connected.
I have the kamailio (version 5.3) running with a tcp socket 127.0.0.1:8228,
and the evapi params are just
modparam("evapi", "workers", 4)
modparam("evapi", "netstring_format", 0)
modparam("evapi", "bind_addr", "127.0.0.1:8448")
modparam("evapi", "max_clients", 32)
I tried a different number of workers and netstring_format 1 too.
When I start the kamailio i added some debug to the code, and seems when
doing the mod init of the evapi dispatcher
38(4779) DEBUG: [core/sr_module.c:779]: init_mod_child(): idx 38
rank -2: evapi [EvAPI Dispatcher]
it reaches to
while(1) {
ev_loop (loop, 0);
}
at evapi_run_dispatcher function.
I guess if I connected to the tcp socket and sent some event, I would see
the client accepted and the event route evapi:connection-new would be
triggered. But i'm not able to do that.
I tried to use the prime option, a tcp input client connection from
logstash, so i could relay the data to the logstash using the evapi relay,
but i only see the tcp socket being created but no client accepted.
I also tried to connect with an erlang gen_tcp client, but it's the same
i only see
47(4798) DEBUG: [core/ip_addr.c:229]: print_ip(): tcpconn_new: new
tcp connection: 127.0.0.1
47(4798) DEBUG: [core/tcp_main.c:1174]: tcpconn_new(): on port
54537, type 2, socket 105
47(4798) DEBUG: [core/tcp_main.c:1497]: tcpconn_add(): hashes:
1117:1187:1505, 1
47(4798) DEBUG: [core/io_wait.h:375]: io_watch_add(): DBG:
io_watch_add(0xad0880, 105, 2, 0x7fc211712d58), fd_no=53
and if i try to send any data
47(4798) DEBUG: [core/io_wait.h:600]: io_watch_del(): DBG:
io_watch_del (0xad0880, 105, -1, 0x0) fd_no=54 called
47(4798) DEBUG: [core/tcp_main.c:4456]: handle_tcpconn_ev(): sending
to child, events 1
47(4798) DEBUG: [core/tcp_main.c:4129]: send2child(): selected tcp
worker idx:0 proc:43 pid:4791 for activity on [tcp:127.0.0.1:8448],
0x7fc211712d58
43(4791) DEBUG: [core/tcp_read.c:1749]: handle_io(): received n=8
con=0x7fc211712d58, fd=39
43(4791) DEBUG: [core/io_wait.h:375]: io_watch_add(): DBG:
io_watch_add(0xb3c720, 39, 2, 0x7fc211712d58), fd_no=1
43(4791) DEBUG: [core/io_wait.h:600]: io_watch_del(): DBG:
io_watch_del (0xb3c720, 39, -1, 0x10) fd_no=2 called
43(4791) DEBUG: [core/tcp_read.c:1671]: release_tcpconn(): releasing
con 0x7fc211712d58, state 1, fd=39, id=1 ([127.0.0.1]:54537 ->
[127.0.0.1]:8448)
43(4791) DEBUG: [core/tcp_read.c:1672]: release_tcpconn():
extra_data (nil)
47(4798) DEBUG: [core/tcp_main.c:3559]: handle_tcp_child(): reader
response= 7fc211712d58, 1 from 0
47(4798) DEBUG: [core/io_wait.h:375]: io_watch_add(): DBG:
io_watch_add(0xad0880, 105, 2, 0x7fc211712d58), fd_no=53
47(4798) DEBUG: [core/tcp_main.c:3686]: handle_tcp_child():
CONN_RELEASE 0x7fc211712d58 refcnt= 1
and when i try to send any data
38(10867) DEBUG: evapi [evapi_dispatch.c:610]: evapi_recv_notify():
received [0x7f17d23fc628] [{"test" : "1.1.1.1", "uuid" : "1-31629@3.3.3.3"
, "pdd" : "4"}] (75)
38(10867) DEBUG: evapi [evapi_dispatch.c:316]: evapi_dispatch_notify(): the
message was sent to 0 clients
I don't know what i'm missing, or if i'm understanding the use of the
module correctly
could you please take a look?
thanks a lot
David
--
[image: Logo]
David Escartín Almudévar
VoIP/Switch Engineer
descar...@sonoc.io
*SONOC*
C/ Josefa Amar y Borbón, 10, 4ª · 50001 Zaragoza, España
Tlf: +34 917019888 · www.sonoc.io
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] doubt about xflags
hello Daniel sorry i was quite lost, but it's ok and actually i already have the fix on most of the live systems since they have a March 2nd commit of 5.3 version, which already includes it and it works fine thanks a lot david El lun., 6 abr. 2020 a las 14:10, Daniel-Constantin Mierla (< mico...@gmail.com>) escribió: > Hello, > > that change was pushed to 5.3 at that moment, as I wrote in the email. If > you still get the issue with branch 5.3, let me know. > > Cheers, > Daniel > On 06.04.20 10:48, David Escartin wrote: > > Dear Daniel > > hope everything is ok. > Sorry if i missed something, but this was changed already backported from > master to 5.3 yet? > > thanks alot and regards > david > > El vie., 21 feb. 2020 a las 11:20, Daniel-Constantin Mierla (< > mico...@gmail.com>) escribió: > >> Hello, >> >> ok, good to know works fine now! Thanks for troubleshooting and testing. >> >> Cheers, >> Daniel >> On 21.02.20 10:11, David Escartin wrote: >> >> hello Daniel >> >> I made a try on the latest master branch commit and seems ok now >> thanks a lot! >> >> david >> >> >> El vie., 21 feb. 2020 a las 8:45, Daniel-Constantin Mierla (< >> mico...@gmail.com>) escribió: >> >>> Hello, >>> >>> good catch, I pushed a patch to propagate xflags on msg_apply_changes() >>> in master and backported to 5.3 and 5.2. Give it a try with any of the >>> branches and let me know if works fine now. >>> >>> Cheers, >>> Daniel >>> On 21.02.20 08:29, David Escartin wrote: >>> >>> Hello Daniel >>> >>> i made some more tests and i could see that it's after >>> executing msg_apply_changes function that the xflag is lost. The original >>> message transaction flags remain activated after msg_apply_changes. >>> >>> i did an execution on debug but i saw no information more than >>> >>> 2(5231) INFO: Talos-Test Call 50 / Call-ID 1-25549@1.1.18.171: We >>> activate TEST_XFLAG!! >>> 2(5231) INFO: Talos-Test Call 50 / Call-ID 1-25549@1.1.18.171: >>> TEST_XFLAG TRUE >>> 2(5231) DEBUG: [core/msg_translator.c:3262]: >>> sip_msg_update_buffer(): SIP message content updated - reparsing >>> 2(5231) DEBUG: [core/parser/msg_parser.c:610]: parse_msg(): SIP >>> Request: >>> 2(5231) DEBUG: [core/parser/msg_parser.c:612]: parse_msg(): >>> method: >>> 2(5231) DEBUG: [core/parser/msg_parser.c:614]: parse_msg(): >>> uri: >>> 2(5231) DEBUG: [core/parser/msg_parser.c:616]: parse_msg(): >>> version: >>> 2(5231) DEBUG: [core/parser/parse_via.c:1303]: >>> parse_via_param(): Found param type 235, = ; state=6 >>> 2(5231) DEBUG: [core/parser/parse_via.c:1303]: >>> parse_via_param(): Found param type 232, = >>> ; state=6 >>> 2(5231) DEBUG: [core/parser/parse_via.c:1303]: >>> parse_via_param(): Found param type 253, = <74e198e2>; state=16 >>> 2(5231) DEBUG: [core/parser/parse_via.c:2639]: parse_via(): end >>> of header reached, state=5 >>> 2(5231) DEBUG: [core/parser/msg_parser.c:498]: parse_headers(): >>> Via found, flags=2 >>> 2(5231) DEBUG: [core/parser/msg_parser.c:500]: parse_headers(): >>> this is the first via >>> 2(5231) DEBUG: [core/parser/parse_addr_spec.c:864]: >>> parse_addr_spec(): end of header reached, state=10 >>> 2(5231) DEBUG: [core/parser/msg_parser.c:171]: get_hdr_field(): >>> [83]; uri=[sip:+9934355692006294@1.1.14.173 >>> ;transport=udp;user=phone] >>> 2(5231) DEBUG: [core/parser/msg_parser.c:174]: get_hdr_field(): >>> to body ["+0034355692006294">> ;transport=udp;user=phone> >>> ], to tag [] >>> 2(5231) INFO: Talos-Test Call 50 / Call-ID 1-25549@1.1.18.171: >>> TEST_XFLAG after msg_apply_changes FALSE >>> >>> >>> best regards >>> david >>> >>> El jue., 20 feb. 2020 a las 20:45, Daniel-Constantin Mierla (< >>> mico...@gmail.com>) escribió: >>> >>>> Hello, >>>> >>>> have you set the flags before creating the transaction? Can you test if >>>> you set a normal flag and an xflag at the same place in request route, is >>>> the first visible in onreply route and the xflag not? >>>> >>>> Cheers, >>>> Daniel >>>> On 20.02.20 18:05, David Escartin wrote: >>>> >
Re: [SR-Users] doubt about xflags
Dear Daniel hope everything is ok. Sorry if i missed something, but this was changed already backported from master to 5.3 yet? thanks alot and regards david El vie., 21 feb. 2020 a las 11:20, Daniel-Constantin Mierla (< mico...@gmail.com>) escribió: > Hello, > > ok, good to know works fine now! Thanks for troubleshooting and testing. > > Cheers, > Daniel > On 21.02.20 10:11, David Escartin wrote: > > hello Daniel > > I made a try on the latest master branch commit and seems ok now > thanks a lot! > > david > > > El vie., 21 feb. 2020 a las 8:45, Daniel-Constantin Mierla (< > mico...@gmail.com>) escribió: > >> Hello, >> >> good catch, I pushed a patch to propagate xflags on msg_apply_changes() >> in master and backported to 5.3 and 5.2. Give it a try with any of the >> branches and let me know if works fine now. >> >> Cheers, >> Daniel >> On 21.02.20 08:29, David Escartin wrote: >> >> Hello Daniel >> >> i made some more tests and i could see that it's after >> executing msg_apply_changes function that the xflag is lost. The original >> message transaction flags remain activated after msg_apply_changes. >> >> i did an execution on debug but i saw no information more than >> >> 2(5231) INFO: Talos-Test Call 50 / Call-ID 1-25549@1.1.18.171: We >> activate TEST_XFLAG!! >> 2(5231) INFO: Talos-Test Call 50 / Call-ID 1-25549@1.1.18.171: >> TEST_XFLAG TRUE >> 2(5231) DEBUG: [core/msg_translator.c:3262]: >> sip_msg_update_buffer(): SIP message content updated - reparsing >> 2(5231) DEBUG: [core/parser/msg_parser.c:610]: parse_msg(): SIP >> Request: >> 2(5231) DEBUG: [core/parser/msg_parser.c:612]: parse_msg(): >> method: >> 2(5231) DEBUG: [core/parser/msg_parser.c:614]: parse_msg(): uri: >> >> 2(5231) DEBUG: [core/parser/msg_parser.c:616]: parse_msg(): >> version: >> 2(5231) DEBUG: [core/parser/parse_via.c:1303]: parse_via_param(): >> Found param type 235, = ; state=6 >> 2(5231) DEBUG: [core/parser/parse_via.c:1303]: parse_via_param(): >> Found param type 232, = >> ; state=6 >> 2(5231) DEBUG: [core/parser/parse_via.c:1303]: parse_via_param(): >> Found param type 253, = <74e198e2>; state=16 >> 2(5231) DEBUG: [core/parser/parse_via.c:2639]: parse_via(): end >> of header reached, state=5 >> 2(5231) DEBUG: [core/parser/msg_parser.c:498]: parse_headers(): >> Via found, flags=2 >> 2(5231) DEBUG: [core/parser/msg_parser.c:500]: parse_headers(): >> this is the first via >> 2(5231) DEBUG: [core/parser/parse_addr_spec.c:864]: >> parse_addr_spec(): end of header reached, state=10 >> 2(5231) DEBUG: [core/parser/msg_parser.c:171]: get_hdr_field(): >> [83]; uri=[sip:+9934355692006294@1.1.14.173 >> ;transport=udp;user=phone] >> 2(5231) DEBUG: [core/parser/msg_parser.c:174]: get_hdr_field(): >> to body ["+0034355692006294"> ;transport=udp;user=phone> >> ], to tag [] >> 2(5231) INFO: Talos-Test Call 50 / Call-ID 1-25549@1.1.18.171: >> TEST_XFLAG after msg_apply_changes FALSE!!!! >> >> >> best regards >> david >> >> El jue., 20 feb. 2020 a las 20:45, Daniel-Constantin Mierla (< >> mico...@gmail.com>) escribió: >> >>> Hello, >>> >>> have you set the flags before creating the transaction? Can you test if >>> you set a normal flag and an xflag at the same place in request route, is >>> the first visible in onreply route and the xflag not? >>> >>> Cheers, >>> Daniel >>> On 20.02.20 18:05, David Escartin wrote: >>> >>> Dear all >>> >>> one quick question, reading the module corex doc, seems that xflag are >>> message(transaction) flags. But I made a test and seems for some reason the >>> flag is not seeing activated at the onreply_route, when it's activated on >>> the request route. Seemed more like a script flag behaviour. Maybe I'm >>> missing something? >>> >>> thanks a lot and regards >>> david >>> >>> ___ >>> Kamailio (SER) - Users Mailing >>> Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> >>> -- >>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- >>> www.linkedin.com/in/miconda >>> Kamailio Advanced Training - March 9-11, 2020, Berlin - www.asipto.com >>> Kamailio World Conference - April 27-29,
Re: [SR-Users] doubt about xflags
hello Daniel I made a try on the latest master branch commit and seems ok now thanks a lot! david El vie., 21 feb. 2020 a las 8:45, Daniel-Constantin Mierla (< mico...@gmail.com>) escribió: > Hello, > > good catch, I pushed a patch to propagate xflags on msg_apply_changes() in > master and backported to 5.3 and 5.2. Give it a try with any of the > branches and let me know if works fine now. > > Cheers, > Daniel > On 21.02.20 08:29, David Escartin wrote: > > Hello Daniel > > i made some more tests and i could see that it's after > executing msg_apply_changes function that the xflag is lost. The original > message transaction flags remain activated after msg_apply_changes. > > i did an execution on debug but i saw no information more than > > 2(5231) INFO: Talos-Test Call 50 / Call-ID 1-25549@1.1.18.171: We > activate TEST_XFLAG!! > 2(5231) INFO: Talos-Test Call 50 / Call-ID 1-25549@1.1.18.171: > TEST_XFLAG TRUE > 2(5231) DEBUG: [core/msg_translator.c:3262]: > sip_msg_update_buffer(): SIP message content updated - reparsing > 2(5231) DEBUG: [core/parser/msg_parser.c:610]: parse_msg(): SIP > Request: > 2(5231) DEBUG: [core/parser/msg_parser.c:612]: parse_msg(): > method: > 2(5231) DEBUG: [core/parser/msg_parser.c:614]: parse_msg(): uri: > > 2(5231) DEBUG: [core/parser/msg_parser.c:616]: parse_msg(): > version: > 2(5231) DEBUG: [core/parser/parse_via.c:1303]: parse_via_param(): > Found param type 235, = ; state=6 > 2(5231) DEBUG: [core/parser/parse_via.c:1303]: parse_via_param(): > Found param type 232, = > ; state=6 > 2(5231) DEBUG: [core/parser/parse_via.c:1303]: parse_via_param(): > Found param type 253, = <74e198e2>; state=16 > 2(5231) DEBUG: [core/parser/parse_via.c:2639]: parse_via(): end of > header reached, state=5 > 2(5231) DEBUG: [core/parser/msg_parser.c:498]: parse_headers(): > Via found, flags=2 > 2(5231) DEBUG: [core/parser/msg_parser.c:500]: parse_headers(): > this is the first via > 2(5231) DEBUG: [core/parser/parse_addr_spec.c:864]: > parse_addr_spec(): end of header reached, state=10 > 2(5231) DEBUG: [core/parser/msg_parser.c:171]: get_hdr_field(): > [83]; uri=[sip:+9934355692006294@1.1.14.173;transport=udp;user=phone] > 2(5231) DEBUG: [core/parser/msg_parser.c:174]: get_hdr_field(): to > body ["+0034355692006294" ;transport=udp;user=phone> > ], to tag [] > 2(5231) INFO: Talos-Test Call 50 / Call-ID 1-25549@1.1.18.171: > TEST_XFLAG after msg_apply_changes FALSE > > > best regards > david > > El jue., 20 feb. 2020 a las 20:45, Daniel-Constantin Mierla (< > mico...@gmail.com>) escribió: > >> Hello, >> >> have you set the flags before creating the transaction? Can you test if >> you set a normal flag and an xflag at the same place in request route, is >> the first visible in onreply route and the xflag not? >> >> Cheers, >> Daniel >> On 20.02.20 18:05, David Escartin wrote: >> >> Dear all >> >> one quick question, reading the module corex doc, seems that xflag are >> message(transaction) flags. But I made a test and seems for some reason the >> flag is not seeing activated at the onreply_route, when it's activated on >> the request route. Seemed more like a script flag behaviour. Maybe I'm >> missing something? >> >> thanks a lot and regards >> david >> >> ___ >> Kamailio (SER) - Users Mailing >> Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> -- >> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- >> www.linkedin.com/in/miconda >> Kamailio Advanced Training - March 9-11, 2020, Berlin - www.asipto.com >> Kamailio World Conference - April 27-29, 2020, in Berlin -- >> www.kamailioworld.com >> >> -- > Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- > www.linkedin.com/in/miconda > Kamailio Advanced Training - March 9-11, 2020, Berlin - www.asipto.com > Kamailio World Conference - April 27-29, 2020, in Berlin -- > 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] doubt about xflags
Hello Daniel i made some more tests and i could see that it's after executing msg_apply_changes function that the xflag is lost. The original message transaction flags remain activated after msg_apply_changes. i did an execution on debug but i saw no information more than 2(5231) INFO: Talos-Test Call 50 / Call-ID 1-25549@1.1.18.171: We activate TEST_XFLAG!! 2(5231) INFO: Talos-Test Call 50 / Call-ID 1-25549@1.1.18.171: TEST_XFLAG TRUE 2(5231) DEBUG: [core/msg_translator.c:3262]: sip_msg_update_buffer(): SIP message content updated - reparsing 2(5231) DEBUG: [core/parser/msg_parser.c:610]: parse_msg(): SIP Request: 2(5231) DEBUG: [core/parser/msg_parser.c:612]: parse_msg(): method: 2(5231) DEBUG: [core/parser/msg_parser.c:614]: parse_msg(): uri: 2(5231) DEBUG: [core/parser/msg_parser.c:616]: parse_msg(): version: 2(5231) DEBUG: [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 235, = ; state=6 2(5231) DEBUG: [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, = ; state=6 2(5231) DEBUG: [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 253, = <74e198e2>; state=16 2(5231) DEBUG: [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 2(5231) DEBUG: [core/parser/msg_parser.c:498]: parse_headers(): Via found, flags=2 2(5231) DEBUG: [core/parser/msg_parser.c:500]: parse_headers(): this is the first via 2(5231) DEBUG: [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=10 2(5231) DEBUG: [core/parser/msg_parser.c:171]: get_hdr_field(): [83]; uri=[sip:+9934355692006294@1.1.14.173;transport=udp;user=phone] 2(5231) DEBUG: [core/parser/msg_parser.c:174]: get_hdr_field(): to body ["+0034355692006294" ], to tag [] 2(5231) INFO: Talos-Test Call 50 / Call-ID 1-25549@1.1.18.171: TEST_XFLAG after msg_apply_changes FALSE best regards david El jue., 20 feb. 2020 a las 20:45, Daniel-Constantin Mierla (< mico...@gmail.com>) escribió: > Hello, > > have you set the flags before creating the transaction? Can you test if > you set a normal flag and an xflag at the same place in request route, is > the first visible in onreply route and the xflag not? > > Cheers, > Daniel > On 20.02.20 18:05, David Escartin wrote: > > Dear all > > one quick question, reading the module corex doc, seems that xflag are > message(transaction) flags. But I made a test and seems for some reason the > flag is not seeing activated at the onreply_route, when it's activated on > the request route. Seemed more like a script flag behaviour. Maybe I'm > missing something? > > thanks a lot and regards > david > > ___ > Kamailio (SER) - Users Mailing > Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > -- > Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- > www.linkedin.com/in/miconda > Kamailio Advanced Training - March 9-11, 2020, Berlin - www.asipto.com > Kamailio World Conference - April 27-29, 2020, in Berlin -- > 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] doubt about xflags
Dear all one quick question, reading the module corex doc, seems that xflag are message(transaction) flags. But I made a test and seems for some reason the flag is not seeing activated at the onreply_route, when it's activated on the request route. Seemed more like a script flag behaviour. Maybe I'm missing something? thanks a lot and regards david ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio does not responde if an rtpengine is unreachable
hello Daniel
Thanks a lot for the update. We will also test it.
It has not 100% relation with this issue, but i only wanted to share the setup
we have for cases where a rtpengine fails having high traffic load, to minimize
the impact on the kamailio processes.
modparam("rtpengine", "queried_nodes_limit", 2)
modparam("rtpengine", "rtpengine_retr", 2)
modparam("rtpengine", "rtpengine_tout_ms", 350)
considering we don't use sets with more than 2 rtpengine instances, at least
for retry attempts. And your rtpengine instances are in the same network too.
this works quite fine for us, there are some few secs of impact while the
rtpengine is marked as disabled, but the system recovers quite ok.
best regards
david
-Original Message-
From: "Daniel-Constantin Mierla"
Sent: Friday, December 28, 2018 9:15am
To: "Juha Heinanen"
Cc: "Kamailio (SER) - Users Mailing List"
Subject: Re: [SR-Users] kamailio does not responde if an rtpengine is
unreachable
I just pushed a series of commits trying to rework how loading (and
reloading) of rtpegines list is done, to avoid that sync'ed probing,
which can take long if any of the rtpengines is down.
Now, building the local (per process) structures/sockets for rtpengines
during kamailio start up is done without locking. This is guarded by the
fact a reload command can be executed only after all children were
initialized (added also with these commits). Moreover, the probing of
rtpeningesis done only by child process 1, because the status is stored
in shared memory list, so it is visible in all children. Based on my
understanding there, doing probing from all processes is useless now,
that was probably kept from the time when the list was not stored in
shared memory, from the early rtpproxy times.
There is also a restriction on how often the rtpengine list can be
reloaded, now having a 10 seconds interval guard. I added this because
the reload is done over the old list, not building a new list to swap
with the old one. So it requires some time to walk through the existing
list and update based on the new records. I went this way for now, even
building a new list may be better/safer in long term, but it would
require more work. I also wanted to avoid being very intrusive right
now, given that those patches would need to be backported.
The last relevant change was to use a version number to discover when a
reload was done. So far, as I understood, it was relying on the number
of rtpengines, but one may trigger a reload with same rtpengines, but
different attributes (e.g., disabled or not). Having a version number is
better in detecting when each worker needs to rebuild its local list of
sockets, as well as for troubleshooting, because a value is increased
with each reload, so easier to track if it was done or now.
I didn't have time for any tests, so it would be good if you can test
and report if works as expected.
All related commits are in master, if they prove to work fine, we can
backport all those patches.
Cheers,
Daniel
On 26.12.18 12:46, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>> I pushed a quick fix for the case when db support is not enabled,
>> because these locks are useless in that case, so all children will do
>> the rtpengine init at the same time, without waiting for the others:
> Still took in rtpengine db mode about 2 minutes before kamailio became
> responsive after start.
>
> -- Juha
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in
Washington, DC, USA -- 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] problems to parse Cseq 0 value
hello Daniel :-[ alright, trying to duplicate the issue of the complain, i guess i changed that and since i finally got an error i missed the fact the Cseq was not ok. the strange thing is that they have timeout when they send an OPTIONS like U 79.170.68.171:5084 -> 10.100.10.67:5060 OPTIONS sip:52.88.180.226:5060 SIP/2.0. Via: SIP/2.0/UDP 79.170.68.171:5084;branch=z9hG4bKmfvstb108oednh05umi0.1. From: ;tag=5AEC0759-61E7D23-C613801C. To: . Call-ID: 1-10641@79.170.68.171. CSeq: 0 OPTIONS. Supported: timer. Max-Forwards: 69. Content-Length: 0. Maybe they have some issue receiving the response, because it's true we reply that # U 10.100.10.67:5060 -> 79.170.68.171:5084 SIP/2.0 200 OK. Via: SIP/2.0/UDP 79.170.68.171:5084;branch=z9hG4bKmfvstb108oednh05umi0.1. From: ;tag=5AEC0759-61E7D23-C613801C. To: ;tag=8925de184eefa723b9e77a8b63457539.c52c. Call-ID: 1-10641@79.170.68.171. CSeq: 0 OPTIONS. Server: kamailio (5.1.1 (x86_64/linux)). Content-Length: 0. i will tell them thanks and sorry david On 05/06/18 16:57, Daniel-Constantin Mierla wrote: Hello, well, obviously the method is missing in the CSeq -- it is: CSeq: 0. It should be: CSeq: 0 OPTIONS. Cheers, Daniel On 05.06.18 16:45, David Escartin wrote: hello Daniel here you have U 79.170.68.171:5084 -> 10.100.10.67:5060 OPTIONS sip:bts.io:0;transport=udp SIP/2.0. Via: SIP/2.0/UDP 79.170.68.171:5084;branch=z9hG4bK-4458-1-1. From: ;tag=127.0.0.1alUtKGp-01023+1+5613000a+7a506358. To: . Call-ID: 1-9191@79.170.68.171. CSeq: 0. Contact: . Supported: replaces, path, 100rel, timer. User-Agent: Alcatel-Lucent 5060 MGC-8 9.3.0.7.0.4. Accept: application/sdp. Content-Length: 0. On 04/06/18 12:38, Daniel-Constantin Mierla wrote: Hello, can you paste here such a sip message? Cheers, Daniel On 04.06.18 12:25, David Escartin wrote: hello all we have seen that when an OPTIONS is sent with CSep: 0 OPTIONS, message is not parsed. Jun 4 10:12:09 proxy-1-aws /usr/local/kamailio/sbin/kamailio[2205]: ERROR: [core/parser/parse_cseq.c:61]: parse_cseq(): no method found Jun 4 10:12:09 proxy-1-aws /usr/local/kamailio/sbin/kamailio[2205]: ERROR: [core/parser/parse_cseq.c:92]: parse_cseq(): bad cseq Jun 4 10:12:09 proxy-1-aws /usr/local/kamailio/sbin/kamailio[2205]: ERROR: [core/parser/msg_parser.c:144]: get_hdr_field(): bad cseq Jun 4 10:12:09 proxy-1-aws /usr/local/kamailio/sbin/kamailio[2205]: ERROR: [core/parser/msg_parser.c:331]: parse_headers(): bad header field [CSeq: 0 Jun 4 10:12:09 proxy-1-aws /usr/local/kamailio/sbin/kamailio[2205]: WARNING: [core/receive.c:198]: receive_msg(): parsing relevant headers failed as far i see in rfc3261 "The sequence number value MUST be expressible as a 32-bit unsigned integer and MUST be less than 2**31." i don't know if you already discussed about this, but do you think it would be something to fix? best regards and thanks a lot david escartin ___ 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] problems to parse Cseq 0 value
hello Daniel here you have U 79.170.68.171:5084 -> 10.100.10.67:5060 OPTIONS sip:bts.io:0;transport=udp SIP/2.0. Via: SIP/2.0/UDP 79.170.68.171:5084;branch=z9hG4bK-4458-1-1. From: ;tag=127.0.0.1alUtKGp-01023+1+5613000a+7a506358. To: . Call-ID: 1-9191@79.170.68.171. CSeq: 0. Contact: . Supported: replaces, path, 100rel, timer. User-Agent: Alcatel-Lucent 5060 MGC-8 9.3.0.7.0.4. Accept: application/sdp. Content-Length: 0. On 04/06/18 12:38, Daniel-Constantin Mierla wrote: Hello, can you paste here such a sip message? Cheers, Daniel On 04.06.18 12:25, David Escartin wrote: hello all we have seen that when an OPTIONS is sent with CSep: 0 OPTIONS, message is not parsed. Jun 4 10:12:09 proxy-1-aws /usr/local/kamailio/sbin/kamailio[2205]: ERROR: [core/parser/parse_cseq.c:61]: parse_cseq(): no method found Jun 4 10:12:09 proxy-1-aws /usr/local/kamailio/sbin/kamailio[2205]: ERROR: [core/parser/parse_cseq.c:92]: parse_cseq(): bad cseq Jun 4 10:12:09 proxy-1-aws /usr/local/kamailio/sbin/kamailio[2205]: ERROR: [core/parser/msg_parser.c:144]: get_hdr_field(): bad cseq Jun 4 10:12:09 proxy-1-aws /usr/local/kamailio/sbin/kamailio[2205]: ERROR: [core/parser/msg_parser.c:331]: parse_headers(): bad header field [CSeq: 0 Jun 4 10:12:09 proxy-1-aws /usr/local/kamailio/sbin/kamailio[2205]: WARNING: [core/receive.c:198]: receive_msg(): parsing relevant headers failed as far i see in rfc3261 "The sequence number value MUST be expressible as a 32-bit unsigned integer and MUST be less than 2**31." i don't know if you already discussed about this, but do you think it would be something to fix? best regards and thanks a lot david escartin ___ 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] problems to parse Cseq 0 value
hello all we have seen that when an OPTIONS is sent with CSep: 0 OPTIONS, message is not parsed. Jun 4 10:12:09 proxy-1-aws /usr/local/kamailio/sbin/kamailio[2205]: ERROR: [core/parser/parse_cseq.c:61]: parse_cseq(): no method found Jun 4 10:12:09 proxy-1-aws /usr/local/kamailio/sbin/kamailio[2205]: ERROR: [core/parser/parse_cseq.c:92]: parse_cseq(): bad cseq Jun 4 10:12:09 proxy-1-aws /usr/local/kamailio/sbin/kamailio[2205]: ERROR: [core/parser/msg_parser.c:144]: get_hdr_field(): bad cseq Jun 4 10:12:09 proxy-1-aws /usr/local/kamailio/sbin/kamailio[2205]: ERROR: [core/parser/msg_parser.c:331]: parse_headers(): bad header field [CSeq: 0 Jun 4 10:12:09 proxy-1-aws /usr/local/kamailio/sbin/kamailio[2205]: WARNING: [core/receive.c:198]: receive_msg(): parsing relevant headers failed as far i see in rfc3261 "The sequence number value MUST be expressible as a 32-bit unsigned integer and MUST be less than 2**31." i don't know if you already discussed about this, but do you think it would be something to fix? best regards and thanks a lot david escartin ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] rare crash at kamailio 5.0.1
hello Daniel
it was used using lua-http library, not really using a proper kamailio
function but a lua script, using
client = require("http.client")
stream = require("http.h1_stream")
and then
conn=client.connect method to establish the link to the app who received
the http requests
and then using functions
conn:write_request_line
conn:write_header
conn:write_body_chunk
to do the request.
It's not the best setup or the ideal we wanted, but we did this way to
reduce the number of tcp sockets created and destroyed, since this
library allowed us to create only one socket with the app.
And at the moment we did it was the setup which fit us the most.
best regards
david
On 26/04/18 09:04, Daniel-Constantin Mierla wrote:
Hello,
it should not crash in any conditions, I will try to analyze based on
your latest info and see if any delay in using http query can cause
any race there. Was the http request done with http_client or
http_async_client?
Cheers,
Daniel
On 25.04.18 18:48, David Escartin wrote:
hello Daniel
sorry for the delay
i'm afraid i couldn't, since the pcap were captured on the ISP link,
so only got the interface between the proxy and the carrier.
I also couldnt experience more crashes like those to active a better
trace debug to have the other side of the trace.
HOwever, i suspect (with no real basis :) ) that crashes maybe were
related with some http post request me made to an external app to
send some call data to be processed, and some nodes where the http
req were sent to, were down or missconfigured in the app, so maybe
that had relation. (we were using async relay involved for that too).
I have no basis for that, only guessing, but when kamailio run on a
server with remote nodes of the app well configured, no crash at all,
and all crashes started to happen when the kamailio instance was
running on a server which had those issue to send the http requests
anycase, if i have any more info about i will let you know
best regards
david
On 11/04/18 17:45, Daniel-Constantin Mierla wrote:
Hello,
the sip trace (pcap) I got has the sip traffic in one side only, can
you get both sides (what kamailio receives and also what it sends out)?
Cheers,
Daniel
On 30.03.18 09:14, David Escartin wrote:
Hello all
last March 26th we experienced a crash on a 5.0.1 kamailio server
and a core was generated.
Seems that the call involved in the core generated was doing
several retransmisions of a request (expected) and when it finally
forwarded the request upstream, seems fter receiving a 481 from
a-side, it crashed.
here you have the backtrace
<154>Mar 26 19:54:03 mad-proxy-inout-1
/usr/local/kamailio/sbin/kamailio[24992]: :
[core/mem/q_malloc.c:469]: qm_free(): BUG: qm_free: bad pointer
0x7f247acb5878 (out of memory block!) called from tm: h_table.c:
free_cell_helper(187) - aborting
(gdb) bt
#0 0x0036e8a32925 in raise () from /lib64/libc.so.6
#1 0x0036e8a34105 in abort () from /lib64/libc.so.6
#2 0x00654c24 in qm_free (qmp=0x7f23b9cba000,
p=0x7f247acb5878, file=0x7f2479e3cd86 "tm: h_table.c",
func=0x7f2479e3d070 "free_cell_helper", line=187,
mname=0x7f2479e3c780 "tm") at core/mem/q_malloc.c:471
#3 0x7f2479d6bf16 in free_cell_helper
(dead_cell=0x7f23c54fea50, silent=0, fname=0x7f2479e4da80
"timer.c", fline=651) at h_table.c:187
#4 0x7f2479db8148 in wait_handler (ti=1503818844,
wait_tl=0x7f23c54fead0, data=0x7f23c54fea50) at timer.c:651
#5 0x00629578 in timer_list_expire (t=1503818844,
h=0x7f23b9d38dc0, slow_l=0x7f23b9d3b0c8, slow_mark=43533) at
core/timer.c:874
#6 0x006299d4 in timer_handler () at core/timer.c:939
#7 0x00629e73 in timer_main () at core/timer.c:978
#8 0x00422d4e in main_loop () at main.c:1690
#9 0x00429732 in main (argc=13, argv=0x7fff2b9f8088) at
main.c:2639
(gdb) frame 4
#4 0x7f2479db8148 in wait_handler (ti=1503818844,
wait_tl=0x7f23c54fead0, data=0x7f23c54fea50) at timer.c:651
651 UNREF_FREE(p_cell);
(gdb) info locals
p_cell = 0x7f23c54fea50
ret = 1
(gdb) p *p_cell
$1 = {next_c = 0x0, prev_c = 0x0, hash_index = 28196, label =
341555146, flags = 4132, nr_of_outgoings = 2, ref_count = {val =
0}, from = {
s = 0x7f23c87c79ed "From:
<sip:932687220@100.100.100.177;user=phone;noa=national>;tag=50aa4a46-co11146-INS002\r\nCall-ID:
b8997821-2814-46d3-b8f7-cf690f50f640\r\nCSeq: 1114601
BYE\r\nUser-Agent: ENSR3.0.67.10-IS2-RMRG1119-RG2040"..., len =
89}, callid = {
s = 0x7f23c87c7a46 "Call-ID:
b8997821-2814-46d3-b8f7-cf690f50f640\r\nCSeq: 1114601
BYE\r\nUser-Agent:
ENSR3.0.67.10-IS2-RMRG1119-RG2040-CPI1-CPO2612\r\nContent-Length:
0\r\n\r\n", len = 47}, cseq_n = {
s = 0x7f23c87c7a75 "CSeq: 1114601 BYE\r\nUser-Agent:
ENSR3.0.67.10-IS2-RMRG1119-RG2040-CPI1-CPO2612\r\nContent-Length:
0\r\n\r\n", len = 13}, to = {
s = 0x7f23c87c799e "To:
\"3467
Re: [SR-Users] rare crash at kamailio 5.0.1
hello Daniel
sorry for the delay
i'm afraid i couldn't, since the pcap were captured on the ISP link, so
only got the interface between the proxy and the carrier.
I also couldnt experience more crashes like those to active a better
trace debug to have the other side of the trace.
HOwever, i suspect (with no real basis :) ) that crashes maybe were
related with some http post request me made to an external app to send
some call data to be processed, and some nodes where the http req were
sent to, were down or missconfigured in the app, so maybe that had
relation. (we were using async relay involved for that too).
I have no basis for that, only guessing, but when kamailio run on a
server with remote nodes of the app well configured, no crash at all,
and all crashes started to happen when the kamailio instance was running
on a server which had those issue to send the http requests
anycase, if i have any more info about i will let you know
best regards
david
On 11/04/18 17:45, Daniel-Constantin Mierla wrote:
Hello,
the sip trace (pcap) I got has the sip traffic in one side only, can
you get both sides (what kamailio receives and also what it sends out)?
Cheers,
Daniel
On 30.03.18 09:14, David Escartin wrote:
Hello all
last March 26th we experienced a crash on a 5.0.1 kamailio server and
a core was generated.
Seems that the call involved in the core generated was doing several
retransmisions of a request (expected) and when it finally forwarded
the request upstream, seems fter receiving a 481 from a-side, it crashed.
here you have the backtrace
<154>Mar 26 19:54:03 mad-proxy-inout-1
/usr/local/kamailio/sbin/kamailio[24992]: :
[core/mem/q_malloc.c:469]: qm_free(): BUG: qm_free: bad pointer
0x7f247acb5878 (out of memory block!) called from tm: h_table.c:
free_cell_helper(187) - aborting
(gdb) bt
#0 0x0036e8a32925 in raise () from /lib64/libc.so.6
#1 0x0036e8a34105 in abort () from /lib64/libc.so.6
#2 0x00654c24 in qm_free (qmp=0x7f23b9cba000,
p=0x7f247acb5878, file=0x7f2479e3cd86 "tm: h_table.c",
func=0x7f2479e3d070 "free_cell_helper", line=187,
mname=0x7f2479e3c780 "tm") at core/mem/q_malloc.c:471
#3 0x7f2479d6bf16 in free_cell_helper (dead_cell=0x7f23c54fea50,
silent=0, fname=0x7f2479e4da80 "timer.c", fline=651) at h_table.c:187
#4 0x7f2479db8148 in wait_handler (ti=1503818844,
wait_tl=0x7f23c54fead0, data=0x7f23c54fea50) at timer.c:651
#5 0x00629578 in timer_list_expire (t=1503818844,
h=0x7f23b9d38dc0, slow_l=0x7f23b9d3b0c8, slow_mark=43533) at
core/timer.c:874
#6 0x006299d4 in timer_handler () at core/timer.c:939
#7 0x00629e73 in timer_main () at core/timer.c:978
#8 0x00422d4e in main_loop () at main.c:1690
#9 0x00429732 in main (argc=13, argv=0x7fff2b9f8088) at
main.c:2639
(gdb) frame 4
#4 0x7f2479db8148 in wait_handler (ti=1503818844,
wait_tl=0x7f23c54fead0, data=0x7f23c54fea50) at timer.c:651
651 UNREF_FREE(p_cell);
(gdb) info locals
p_cell = 0x7f23c54fea50
ret = 1
(gdb) p *p_cell
$1 = {next_c = 0x0, prev_c = 0x0, hash_index = 28196, label =
341555146, flags = 4132, nr_of_outgoings = 2, ref_count = {val = 0},
from = {
s = 0x7f23c87c79ed "From:
<sip:932687220@100.100.100.177;user=phone;noa=national>;tag=50aa4a46-co11146-INS002\r\nCall-ID:
b8997821-2814-46d3-b8f7-cf690f50f640\r\nCSeq: 1114601
BYE\r\nUser-Agent: ENSR3.0.67.10-IS2-RMRG1119-RG2040"..., len = 89},
callid = {
s = 0x7f23c87c7a46 "Call-ID:
b8997821-2814-46d3-b8f7-cf690f50f640\r\nCSeq: 1114601
BYE\r\nUser-Agent:
ENSR3.0.67.10-IS2-RMRG1119-RG2040-CPI1-CPO2612\r\nContent-Length:
0\r\n\r\n", len = 47}, cseq_n = {
s = 0x7f23c87c7a75 "CSeq: 1114601 BYE\r\nUser-Agent:
ENSR3.0.67.10-IS2-RMRG1119-RG2040-CPI1-CPO2612\r\nContent-Length:
0\r\n\r\n", len = 13}, to = {
s = 0x7f23c87c799e "To:
\"34676893111\"<sip:34676893111@100.100.100.134;user=phone>;tag=64jNUpSZK8mSp\r\nFrom:
<sip:932687220@100.100.100.177;user=phone;noa=national>;tag=50aa4a46-co11146-INS002\r\nCall-ID:
b8997821-2814-46d3-b8f7"..., len = 79}, method = {
s = 0x7f23c87c78c8 "BYE sip:34676893111@100.100.100.134:5080
SIP/2.0\r\nVia: SIP/2.0/UDP
200.200.200.78:5060;branch=z9hG4bK2d5c0cb4e11bb1503BYE50aa466c2b8a\r\nMax-Forwards:
34\r\nRoute: <sip:100.100.100.177;lr;ftag=64jNUpSZK8mSp;d"..., len =
3}, tmcb_hl = {first = 0x7f23bd9f7818, reg_types = 131714},
wait_timer = {
next = 0x0, prev = 0x0, expire = 1503818844, initial_timeout = 80,
data = 0x7f23c54fea50, f = 0x7f2479db8097 , flags =
513, slow_idx = 0},
uas = {request = 0x7f23c87c71d8, end_request = 0x7f23c87c8288
"\300\300\300\300", response = {activ_type = 481, flags = 128,
t_active = 0 '\000', branch = 0,
buffer_len = 526,
buffer = 0x7f23bef07b18 "SIP/2.0 481 Call Does Not Exist\r\nVia:
SIP/2.0/UDP
200.200.200.78:5060;branch=z9hG4bK2d5c0cb4e11bb1
Re: [SR-Users] rare crash at kamailio 5.0.1
ba6
"rtpengine", len = 139},
lr = {s = 0xf0f0f0f0 , len =
-1019193672}, r2 = {s = 0x20 , len =
-1019194816}, gr = {s = 0x1 , len =
-1095956386}, transport_val = {
s = 0x2 , len = -1095956384}, ttl_val
= {s = 0x4 , len = 2}, user_param_val = {s =
0x0, len = -1019194792}, maddr_val = {s = 0x0, len = 0}, method_val = {
s = 0x7fabc3405538 "\001", len = 142942208}, lr_val = {s = 0x1
, len = -1095956380}, r2_val = {s = 0x2
, len = -1095956378}, gr_val = {
s = 0x7 , len = 2}}, add_rm = 0x0,
body_lumps = 0x7fabc3405258, reply_lump = 0x0,
add_to_branch_s =
"\000\000\000\000\000\000\000\000\230U@ë\177\000\000\000
\205\b\377\177\000\000\001\000\000\000\000\000\000\000m\b\255\276\253\177\000\000\003\000\000\000\000\000\000\000p\b\255\276\253\177\000\000\r",
add_to_branch_len = 0, hash_index = 2, msg_flags = 16, flags = 0,
set_global_address = {s = 0x7fabc3405258 "\004", len = 0},
set_global_port = {s = 0x0, len = -1019193864}, force_send_socket =
0x7fff08852000, path_vec = {
s = 0x1 , len = -1095956355}, instance =
{s = 0x2 , len = -1095956353}, reg_id = 4,
ruid = {s = 0x60002 , len = 0},
location_ua = {
s = 0x7fabc3405258 "\004", len = 0}, ldv = {flow = {decoded = 0,
rcv = {src_ip = {af = 3275773528, len = 32683, u = {addrl =
{14076330240, 2}, addr32 = {142942208, 32767, 2, 0}, addr16 = {8192,
2181, 32767, 0, 2, 0, 0,
0}, addr = "\000
\205\b\377\177\000\000\002\000\000\000\000\000\000"}}, dst_ip = {af =
3199010947, len = 32683, u = {addrl = {7, 0}, addr32 = {7, 0, 0, 0},
addr16 = {7, 0, 0, 0, 0, 0, 0, 0},
addr = "\a", '\000' }}, src_port = 0,
dst_port = 0, proto_reserved1 = 0, proto_reserved2 = 1, src_su = {s =
{sa_family = 7,
sa_data = "\000\000\273\203\000\000\000\000\000\000XR@",
}, sin = {sin_family = 7, sin_port = 0,
sin_addr = {s_addr = 33723}, sin_zero = "\000\000\000\000XR@",
},
sin6 = {sin6_family = 7, sin6_port = 0, sin6_flowinfo =
33723, sin6_addr = {__in6_u = {__u6_addr8 =
"\000\000\000\000XR@ë\177\000\000\000\000\000", __u6_addr16 = {0, 0,
21080, 49984, 32683, 0, 0, 0}, __u6_addr32 = {0,
3275772504, 32683, 0}}}, sin6_scope_id = 0}},
bind_address = 0x0, proto = 0 '\000'
best regards
david
On 02/04/18 09:33, David Escartin wrote:
hello Daniel
here you have
best regards
david
On 02/04/18 08:26, Daniel-Constantin Mierla wrote:
Hello,
do you have the pcap for such call?
Cheers,
Daniel
On 30.03.18 09:14, David Escartin wrote:
Hello all
last March 26th we experienced a crash on a 5.0.1 kamailio server
and a core was generated.
Seems that the call involved in the core generated was doing several
retransmisions of a request (expected) and when it finally forwarded
the request upstream, seems fter receiving a 481 from a-side, it
crashed.
here you have the backtrace
<154>Mar 26 19:54:03 mad-proxy-inout-1
/usr/local/kamailio/sbin/kamailio[24992]: :
[core/mem/q_malloc.c:469]: qm_free(): BUG: qm_free: bad pointer
0x7f247acb5878 (out of memory block!) called from tm: h_table.c:
free_cell_helper(187) - aborting
(gdb) bt
#0 0x0036e8a32925 in raise () from /lib64/libc.so.6
#1 0x0036e8a34105 in abort () from /lib64/libc.so.6
#2 0x00654c24 in qm_free (qmp=0x7f23b9cba000,
p=0x7f247acb5878, file=0x7f2479e3cd86 "tm: h_table.c",
func=0x7f2479e3d070 "free_cell_helper", line=187,
mname=0x7f2479e3c780 "tm") at core/mem/q_malloc.c:471
#3 0x7f2479d6bf16 in free_cell_helper (dead_cell=0x7f23c54fea50,
silent=0, fname=0x7f2479e4da80 "timer.c", fline=651) at h_table.c:187
#4 0x7f2479db8148 in wait_handler (ti=1503818844,
wait_tl=0x7f23c54fead0, data=0x7f23c54fea50) at timer.c:651
#5 0x00629578 in timer_list_expire (t=1503818844,
h=0x7f23b9d38dc0, slow_l=0x7f23b9d3b0c8, slow_mark=43533) at
core/timer.c:874
#6 0x006299d4 in timer_handler () at core/timer.c:939
#7 0x00629e73 in timer_main () at core/timer.c:978
#8 0x00422d4e in main_loop () at main.c:1690
#9 0x00429732 in main (argc=13, argv=0x7fff2b9f8088) at
main.c:2639
(gdb) frame 4
#4 0x7f2479db8148 in wait_handler (ti=1503818844,
wait_tl=0x7f23c54fead0, data=0x7f23c54fea50) at timer.c:651
651 UNREF_FREE(p_cell);
(gdb) info locals
p_cell = 0x7f23c54fea50
ret = 1
(gdb) p *p_cell
$1 = {next_c = 0x0, prev_c = 0x0, hash_index = 28196, label =
341555146, flags = 4132, nr_of_outgoings = 2, ref_count = {val = 0},
from = {
s = 0x7f23c87c79ed "From:
<sip:932687220@100.100.100.177;user=phone;noa=national>;tag=50aa4a46-co11146-INS002\r\nCall-ID:
b8997821-2814-46d3-b8f7-cf690f50f640\r\nCSeq: 1114601
BYE\r\nUser-Agent: ENSR3.0.67.10-IS2-RMRG1119-RG2040"..., len = 89},
callid = {
s = 0x7f23c87c7a46 "Call-ID:
b8997821-2814-46d3-b8f7-cf690f50f640\r\nCSeq: 1114601
BY
[SR-Users] rare crash at kamailio 5.0.1
Hello all
last March 26th we experienced a crash on a 5.0.1 kamailio server and a core
was generated.
Seems that the call involved in the core generated was doing several
retransmisions of a request (expected) and when it finally forwarded the
request upstream, seems fter receiving a 481 from a-side, it crashed.
here you have the backtrace
<154>Mar 26 19:54:03 mad-proxy-inout-1
/usr/local/kamailio/sbin/kamailio[24992]: : [core/mem/q_malloc.c:469]:
qm_free(): BUG: qm_free: bad pointer 0x7f247acb5878 (out of memory block!)
called from tm: h_table.c: free_cell_helper(187) - aborting
(gdb) bt
#0 0x0036e8a32925 in raise () from /lib64/libc.so.6
#1 0x0036e8a34105 in abort () from /lib64/libc.so.6
#2 0x00654c24 in qm_free (qmp=0x7f23b9cba000, p=0x7f247acb5878,
file=0x7f2479e3cd86 "tm: h_table.c", func=0x7f2479e3d070 "free_cell_helper",
line=187,
mname=0x7f2479e3c780 "tm") at core/mem/q_malloc.c:471
#3 0x7f2479d6bf16 in free_cell_helper (dead_cell=0x7f23c54fea50, silent=0,
fname=0x7f2479e4da80 "timer.c", fline=651) at h_table.c:187
#4 0x7f2479db8148 in wait_handler (ti=1503818844, wait_tl=0x7f23c54fead0,
data=0x7f23c54fea50) at timer.c:651
#5 0x00629578 in timer_list_expire (t=1503818844, h=0x7f23b9d38dc0,
slow_l=0x7f23b9d3b0c8, slow_mark=43533) at core/timer.c:874
#6 0x006299d4 in timer_handler () at core/timer.c:939
#7 0x00629e73 in timer_main () at core/timer.c:978
#8 0x00422d4e in main_loop () at main.c:1690
#9 0x00429732 in main (argc=13, argv=0x7fff2b9f8088) at main.c:2639
(gdb) frame 4
#4 0x7f2479db8148 in wait_handler (ti=1503818844, wait_tl=0x7f23c54fead0,
data=0x7f23c54fea50) at timer.c:651
651 UNREF_FREE(p_cell);
(gdb) info locals
p_cell = 0x7f23c54fea50
ret = 1
(gdb) p *p_cell
$1 = {next_c = 0x0, prev_c = 0x0, hash_index = 28196, label = 341555146, flags
= 4132, nr_of_outgoings = 2, ref_count = {val = 0}, from = {
s = 0x7f23c87c79ed "From:
;tag=50aa4a46-co11146-INS002\r\nCall-ID:
b8997821-2814-46d3-b8f7-cf690f50f640\r\nCSeq: 1114601 BYE\r\nUser-Agent:
ENSR3.0.67.10-IS2-RMRG1119-RG2040"..., len = 89}, callid = {
s = 0x7f23c87c7a46 "Call-ID: b8997821-2814-46d3-b8f7-cf690f50f640\r\nCSeq:
1114601 BYE\r\nUser-Agent:
ENSR3.0.67.10-IS2-RMRG1119-RG2040-CPI1-CPO2612\r\nContent-Length: 0\r\n\r\n",
len = 47}, cseq_n = {
s = 0x7f23c87c7a75 "CSeq: 1114601 BYE\r\nUser-Agent:
ENSR3.0.67.10-IS2-RMRG1119-RG2040-CPI1-CPO2612\r\nContent-Length: 0\r\n\r\n",
len = 13}, to = {
s = 0x7f23c87c799e "To:
\"34676893111\";tag=64jNUpSZK8mSp\r\nFrom:
;tag=50aa4a46-co11146-INS002\r\nCall-ID:
b8997821-2814-46d3-b8f7"..., len = 79}, method = {
s = 0x7f23c87c78c8 "BYE sip:34676893111@100.100.100.134:5080 SIP/2.0\r\nVia:
SIP/2.0/UDP
200.200.200.78:5060;branch=z9hG4bK2d5c0cb4e11bb1503BYE50aa466c2b8a\r\nMax-Forwards:
34\r\nRoute: ;tag=50aa4a46-co11146-I"...,
my_T = 0x7f23c54fea50, timer = {next = 0x0, prev = 0x0, expire = 0,
initial_timeout = 0, data = 0x0, f = 0x7f2479db7b4b , flags =
0, slow_idx = 0}, dst = {send_sock = 0x7f247a95be78, to = {s = {
sa_family = 2, sa_data = "\023\304\325\300\313N\000\000\000\000\000\000\000"},
sin = {sin_family = 2, sin_port = 50195, sin_addr = {
s_addr = 1321976021}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 =
{sin6_family = 2, sin6_port = 50195, sin6_flowinfo = 1321976021,
sin6_addr = {__in6_u = {__u6_addr8 = '\000' , __u6_addr16 =
{0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}},
sin6_scope_id = 0}}, id = 0, proto = 1 '\001', send_flags = {f = 0 '\000',
blst_imask = 0 '\000'}}, retr_expire = 0, fr_expire = 0}, local_totag = {
s = 0x0, len = 0}, cancel_reas = 0x0, status = 481}, uac = 0x7f23c54fec58,
async_backup = {backup_route = 1, backup_branch = 4294967295, blind_uac = 0,
ruri_new = 1}, fwded_totags = 0x0, uri_avps_from = 0x0, uri_avps_to = 0x0,
user_avps_from = 0x0, user_avps_to = 0x0, domain_avps_from = 0x0,
domain_avps_to = 0x0, xavps_list = 0x0, reply_mutex = {val = 0},
reply_locker_pid = {val = 0}, reply_rec_lock_level = 0, fr_timeout = 480,
fr_inv_timeout = 1920, rt_t1_timeout_ms = 650, rt_t2_timeout_ms = 4000,
end_of_life = 1503819200,
