Hi Thibault,
I'm not sure I understand the scenario of your crash. Is the branch
rejecting the call a branch added with ts_append? What are you doing upon
receiving the 603 (supposing that's how the application is rejecting the
call)? Are you appending other branches?
In the bt it looks like the tr
ok -- try gain with latest master branch.
Cheers,
Daniel
On 15/09/15 15:38, Juha Heinanen wrote:
> one more:
>
> CC (gcc) [sip-proxy] mem/shm.o
> In file included from mem/../mem/shm_mem.h:34:0,
> from mem/../ut.h:45,
> from mem/../ip_addr.h:40,
>
Hi list!
We use Kamailio 4.2 for presence BLF with DB_TEXT.
And i want to make cluster with a few Kamailio's presences, to load
balance.
Can you please tell me - is that possible to use same shared DB_TEXT
database with 2 or more Kamailio servers ?
modparam("presence", "subs_db_mode", 3)
mo
Hello Federico,
I have built from 4.3 branch.
I got a crash again... However it seems different than previous one:
Issue seems located in tm module.
It appears if the remote denied the incoming call, then quit application .
thibault
Core was generated by `sbin/kamailio -f /etc/kamailio/kam
one more:
CC (gcc) [sip-proxy]mem/shm.o
In file included from mem/../mem/shm_mem.h:34:0,
from mem/../ut.h:45,
from mem/../ip_addr.h:40,
from mem/../globals.h:36,
from mem/shm.c:22:
mem/shm.c: In function 'shm_core_lock
Hello,
I will look if there are options in libev to buffer data or try to
implement a buffering mechanism locally for such cases.
Cheers,
Daniel
On 14/09/15 23:00, Jayesh Nambiar wrote:
> Hello Daniel,
> After further testing with evapi module, I figured that when
> Netstrings are used, an event
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
#!/bin/bash
# Compiling Kamailio for Cubie/RaspberryPi/others ARM arch from main repos:
echo 'deb-src http://deb.kamailio.org/kamailio43 jessie main' >
/etc/apt/sources.list.d/kamailio.list
wget -O- http://deb.kamailio.org/kamailiodebkey.gpg | sudo ap
Should be fixed now.
Cheers,
Daniel
On 15/09/15 14:35, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>> I pushed a patch to master for it -- check to see if the result is what
>> you expect.
> thanks. didn't get that far though:
>
> CC (gcc) [sip-proxy] mem/q_malloc.o
> mem/
Daniel-Constantin Mierla writes:
> I pushed a patch to master for it -- check to see if the result is what
> you expect.
thanks. didn't get that far though:
CC (gcc) [sip-proxy]mem/q_malloc.o
mem/q_malloc.c:919:6: error: conflicting types for 'qm_sums'
void qm_sums(struct qm_block*
I pushed a patch to master for it -- check to see if the result is what
you expect.
Cheers,
Daniel
On 15/09/15 13:11, Juha Heinanen wrote:
> looks like htable.dump does not tell what is the type of the value, e.g.
>
> {
> entry: 53
> size: 1
> slot: {
> item: {
>
Juha Heinanen writes:
> looks like htable.dump does not tell what is the type of the value,
actually, it is possible to get the type of the value using htable.get
rpc command.
-- juha
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mail
Hello,
indeed was a regression to a fixup function in textopsx due to a fix
that tried to avoid going beyond the buffer boundaries. I pushed a
commit to handle it, you can fetch latest kamailio branch 4.3.
Cheers,
Daniel
On 15/09/15 11:44, Björn Bylander wrote:
> Hello,
>
> 4.3.1 works well for
looks like htable.dump does not tell what is the type of the value, e.g.
{
entry: 53
size: 1
slot: {
item: {
name: foo::bar
value: 0
}
}
}
-- juha
_
Do let me know if I should run some specific tests for you all to get a
little more clarity and information and I'd be happy to do those test and
update you with results. I eagerly want to take a positive decision on
going ahead with evapi module as it looks very promising. Only if we can
solve the
Hello,
4.3.1 works well for us apart from the issue fixed by
93b297e16134b0e74cf83e3604da01355a52e700. Since
93b297e16134b0e74cf83e3604da01355a52e700 is included in 4.3.2 I tried upgrading
one of our servers and now Kamailio won't even start as it apparently finds the
way assign_hf_value, hf_v
Hi Thibault,
I have not been able to get the crash reproducing the scenario you
described.
Could you try the last 4.3.x code? Are you still seeing the crash?
Regards,
Federico
On Fri, Sep 11, 2015 at 11:34 PM, Thibault Gueslin <
thibault.gues...@gmail.com> wrote:
> Hi Federico,
>
> I will try l
Hello,
if you use default kamailio.cfg auth part, then besides checking the
auth response, the functions checks that From/To username are the same
as authentiaction username (to prevent caller id spoofing) -- see the
parameters of auth_check() to adjust this behaviour in case you need
that those
Hello,
good to know that you found the issue and it was in the config file.
Would be appreciated if you can report the results on testing maxload,
to know if there is anything to fix there.
Cheers,
Daniel
On 14/09/15 21:52, Ding Ma wrote:
> Hi,
>
> Figured this out. Seems I had made a mistake in
I am trying to register with Kamailio server from my custom endpoint.
I have below call flows
Register -> 401
Register -> 401
When I saw Kamailio log, I do not see any error.
Looks auth response is fine. Then why 401 repeatedly.
Log is given blow.
Please guide to fix this issue.
Sep 14 18:41:0
I took SBC *out* from my test scenario.
So it is just endpoint -> Kamailio.
Then I found same issue, Kamalio challanges repeatedly.
One of the reason I suspect is, in my case for REGISTER message to uri and
from uri are different.
Can that cause Kamailio to challenge it repeatedly.
On Mon, Sep 1
20 matches
Mail list logo
