Kamailio running in Fedora 19 box. The client (Jitsi) can only connect
over TCP.
If connecting over UDP, the clients connect, but cannot send/receive
messages.
Cannot connect over TLS at all. Ultimately I will need to run with TLS
over 5065 port or higher.
Tried using different listen directives, different port directive, but
kamailio either does not start, or only listening on one TCP port.
I've set up two SRV records, one for _sip on port 5065 and another for
_sips on port 5066. Both pointing to the Fedora box.
In Jitsi I have to specify port # and when I set it to 5065 over TCP it
works, but 5066 over TLS never connects.
What am I doing wrong?
Thank you.
Hello,
I have a crash with the following scenario:
I try to route an INVITE to a remote host, it fails, I route to the second
suing the dispatcher module. It fails the second time and I stop the call.
It seems that I did not release the transaction in this case
93454 Feb 28 11:39:08 kamailio23 /usr/local/sbin/kamailio[20225]: WARNING:
tm [t_lookup.c:1536]: t_unref(): WARNING: script writer didn't release
transaction
And then, Kamailio receives BYE of other dialogs and it crashes
Here is core bt of 2 kamailio processes (4.1.1)
(gdb) bt full
#0 0x0000000000534e4e in timer_list_expire (t=1283469267,
h=0x7ff9219e99b8, slow_l=0x7ff9219e9c88, slow_mark=12) at timer.c:883
tl = 0x7ff921c6b8f0
ret = 32767
#1 0x00000000005351ba in timer_handler () at timer.c:959
saved_ticks = 1283469267
run_slow_timer = 0
i = 12
__FUNCTION__ = "timer_handler"
#2 0x0000000000535453 in timer_main () at timer.c:998
No locals.
#3 0x000000000046efa2 in main_loop () at main.c:1688
i = 8
pid = 0
si = 0x0
si_desc = "udp receiver child=7 sock=91.213.79.31:5060\000\001",
'\000' <repeats 19 times>,
"\020\000\000\000\000\000\000\000\243Mgf\000\000\000\000\260vA\000\000\000\000\000\020\201\351a\377\177",
'\000' <repeats 18 times>,
"P\177\351a\377\177\000\000\002\266K\000\000\000\000"
nrprocs = 8
__FUNCTION__ = "main_loop"
#4 0x0000000000471c38 in main (argc=5, argv=0x7fff61e98118) at main.c:2533
cfg_stream = 0x1970010
c = -1
r = 0
tmp = 0x7fff61e98148 "\211\236\351a\377\177"
tmp_len = 0
port = 5
proto = 0
options = 0x5de800
":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:"
ret = -1
seed = 519948236
rfd = 4
debug_save = 0
debug_flag = 0
dont_fork_cnt = 0
n_lst = 0xbf
p = 0x416bd9 "H\203\304\b\303" <Address 0x416bde out of bounds>
__FUNCTION__ = "main"
(gdb) bt full
#0 0x00007ff92abf3475 in raise () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1 0x00007ff92abf66f0 in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2 0x0000000000548253 in qm_free (qm=0x7ff921970000, p=0x7ff921c3b940,
file=0x7ff92925362d "tm: h_table.c", func=0x7ff9292537d8 "free_cell",
line=178) at mem/q_malloc.c:470
f = 0x7ff921c3b910
size = 5600
next = 0x7fff61e97ac0
prev = 0x7ff9291e571e
__FUNCTION__ = "qm_free"
#3 0x00007ff9291e64a9 in free_cell (dead_cell=0x7ff921c6b870) at
h_table.c:178
b = 0x0
i = 1
rpl = 0x0
tt = 0x0
foo = 0x5000548a29
cbs = 0x0
cbs_tmp = 0x7ff921c3b940
__FUNCTION__ = "free_cell"
#4 0x00007ff9291e7480 in free_hash_table () at h_table.c:441
p_cell = 0x7ff921c6b870
tmp_cell = 0x7ff921a159f0
i = 37066
__FUNCTION__ = "free_hash_table"
#5 0x00007ff9291fad35 in tm_shutdown () at t_funcs.c:122
__FUNCTION__ = "tm_shutdown"
#6 0x00000000004f8101 in destroy_modules () at sr_module.c:817
t = 0x7ff92a807d50
foo = 0x7ff92a807588
__FUNCTION__ = "destroy_modules"
#7 0x00000000004689b2 in cleanup (show_status=1) at main.c:560
memlog = 32761
__FUNCTION__ = "cleanup"
#8 0x0000000000469aab in shutdown_children (sig=15, show_status=1) at
main.c:702
__FUNCTION__ = "shutdown_children"
#9 0x000000000046b146 in handle_sigs () at main.c:793
chld = 0
chld_status = 139
memlog = 0
__FUNCTION__ = "handle_sigs"
#10 0x000000000046f549 in main_loop () at main.c:1746
i = 8
pid = 20250
si = 0x0
si_desc = "udp receiver child=7 sock=91.213.79.31:5060\000\001",
'\000' <repeats 19 times>,
"\020\000\000\000\000\000\000\000\243Mgf\000\000\000\000\260vA\000\000\000\000\000\020\201\351a\377\177",
'\000' <repeats 18 times>,
"P\177\351a\377\177\000\000\002\266K\000\000\000\000"
nrprocs = 8
__FUNCTION__ = "main_loop"
#11 0x0000000000471c38 in main (argc=5, argv=0x7fff61e98118) at main.c:2533
cfg_stream = 0x1970010
c = -1
r = 0
tmp = 0x7fff61e98148 "\211\236\351a\377\177"
tmp_len = 0
port = 5
proto = 0
options = 0x5de800
":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:"
ret = -1
seed = 519948236
rfd = 4
debug_save = 0
debug_flag = 0
dont_fork_cnt = 0
n_lst = 0xbf
p = 0x416bd9 "H\203\304\b\303" <Address 0x416bde out of bounds>
__FUNCTION__ = "main"
Thank you for your help
Hi,
customers PBX----trunk-----kamailio------------freeswitch-------------carrier
We already add Trusted IP’s via SIREMIS 4.0
is it possible with Kamailio to have customers calls come in on a trusted IP and when they send calls we add a header with a [client id] which we can remove on the next ip switch upstream
So example
Call comes in from customer with IP:
their trusted IP source xx.xx.xx.xx
add header with their client ID
route to PSTN
Then my upstream switch will process the customers call and remove the header before sending to our voip carrier. Basically my ip switch will evaluate the client id header for billing, process and strip the header back out.
Thanks
Tony
Hi
We think that we found and fix a bug in the registrar module. The bug is hard to reproduce, and it crashes our Kamailio from time to time (once at 2-3 weeks for us) .
In save.c, function update_contacts() there are two places where we free() a pointer and then we reuse it, line 700 and line 730:
while(ptr){
ptr0 = ptr;
if(ptr!=c)
ul.delete_ucontact(_r, ptr);
ptr=ptr0->next;
}
And then from inside delete_ucontact(_r,ptr) we call mem_delete_ucontact(_r, _c) which calls
free_ucontact(_c) , which calls shm_free(_c) . _c is actually our ptr.
If another process writes at the location pointed by ptr during the "while" loop , the current process will crash.
The bug affects 4.0.4, 4.0.5 and maybe older versions.
We keep the location table in memory, no database backend, and we do alot of REGISTER/un-REGISTER in our environment,
and maybe that's why this bug was not spotted by the community before.
Just to clarify, this fix is in relation with this post:
http://lists.sip-router.org/pipermail/sr-dev/2014-February/022934.html
Please take into consideration the attached patch provided by the Libon Voice Team.
Regards,
Dragos Oancea
Hi List
I'm trying to call over 3G networks, but doesn't work, i think my mobile
provider block voip traffic, is there any way to hide voip traffic or jump
the provider block rule ??
Hello Sirs,
I'm a little confused getting a decision about implementing buddy list
(step: presence & IM). What is the best way for keeping the contacts list:
xmpp or xcap? You will say probably xcap server but even if I intend to use
in the future an xmpp gateway in order to be able to communicate sip with
with xmpp servers like google - google talk?
And why xcap? Because most of the clients has the possibility to connect to
a xcap server to get the buddy list? From web perspective I think both are
OK because of the xhttp module power in kamailio to get the buddy list xml.
Thank you.
Best regards,
Mihai M
I just installed kamailio on Debian 7 and when I start it with init.d I get
the following messages.
root@voip:/etc/kamailio# /etc/init.d/kamailio start
Starting Kamailio:
loading modules under
/usr/lib64/kamailio/modules_k/:/usr/lib64/kamailio/modules/
Listening on
udp: 127.0.0.1:5060
udp: MYSERVERIP:5060
tcp: 127.0.0.1:5060
tcp: MYSERVERIP:5060
tls: 127.0.0.1:5061
tls: MYSERVERIP:5061
Aliases:
tls: voip:5061
tls: localhost:5061
tcp: voip:5060
tcp: localhost:5060
udp: voip:5060
udp: localhost:5060
kamailio error, failed to start.
root@voip:/etc/kamailio#
How can I find out what the problem is?
Sorry ... I disagree at all .... All that features you mention, could be done with kamalio ... BUT you have to work on your cfg to get them. You don't get then out of the box.
Kamailio it's a powerfull tool ... It's not a final product as the AP Net SBC
Best regards
Luis Silva <luisfilsilva(a)gmail.com> wrote:
>_______________________________________________
>SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>sr-users(a)lists.sip-router.org
>http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users