2-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 Lis
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-I
act: .
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:
he
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 p
}}, 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@"
,
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
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
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",
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
u 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 a
s() 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
> exe
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
ico...@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
>
>
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 gettin
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)
_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 direct
his 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 happe
17 matches
Mail list logo
