sr-users November 2018

sr-users@lists.kamailio.org

68 participants
88 discussions

Re: [SR-Users] Kamailio 5.1.6 Debian Package -> SEGFAULT

by Floimair Florian

This is the backtrace of 2 core-dumps i got just recently (both with the same timestamp). Nothing obvious that hits my eyes (at least no NULL pointer). Maybe you can see more in it. Backtrace #1: =========== [New LWP 99122] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/usr/sbin/kamailio -P /var/run/kamailio/kamailio.pid -f /etc/kamailio/kamailio.'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007fca0d45e996 in t_should_relay_response (Trans=0x7fca067b2a60, new_code=401, branch=0, should_store=0x7ffff47edd44, should_relay=0x7ffff47edd40, cancel_data=0x7ffff47edf30, reply=0x7fca0d8fd020) at t_reply.c:1282 1282 t_reply.c: No such file or directory. (gdb) bt #0 0x00007fca0d45e996 in t_should_relay_response (Trans=0x7fca067b2a60, new_code=401, branch=0, should_store=0x7ffff47edd44, should_relay=0x7ffff47edd40, cancel_data=0x7ffff47edf30, reply=0x7fca0d8fd020) at t_reply.c:1282 #1 0x00007fca0d46317f in relay_reply (t=0x7fca067b2a60, p_msg=0x7fca0d8fd020, branch=0, msg_status=401, cancel_data=0x7ffff47edf30, do_put_on_wait=1) at t_reply.c:1786 #2 0x00007fca0d469154 in reply_received (p_msg=0x7fca0d8fd020) at t_reply.c:2537 #3 0x000055e77686fbe3 in do_forward_reply (msg=0x7fca0d8fd020, mode=0) at core/forward.c:747 #4 0x000055e776871a00 in forward_reply (msg=0x7fca0d8fd020) at core/forward.c:852 #5 0x000055e7768bd4e7 in receive_msg ( buf=0x55e776da0520 <buf> "SIP/2.0 401 Unauthorized\r\nVia: SIP/2.0/UDP 172.17.217.10;rport=5060;received=172.17.217.10;branch=z9hG4bKe4bf.c46a843afa3ff97f5b20df53926515a2.0;i=62\r\nVia: SIP/2.0/TCP 195.225.36.194:1797;rport=40047;"..., len=736, rcv_info=0x7ffff47ee4e0) at core/receive.c:364 #6 0x000055e7767ce4fe in udp_rcv_loop () at core/udp_server.c:554 #7 0x000055e77673a15d in main_loop () at main.c:1619 #8 0x000055e7767421fe in main (argc=13, argv=0x7ffff47eeb98) at main.c:2638 Backtrace #2: =========== [New LWP 99120] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/usr/sbin/kamailio -P /var/run/kamailio/kamailio.pid -f /etc/kamailio/kamailio.'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007fca0d45e996 in t_should_relay_response (Trans=0x7fca067da3c0, new_code=200, branch=0, should_store=0x7ffff47edd44, should_relay=0x7ffff47edd40, cancel_data=0x7ffff47edf30, reply=0x7fca0d8fd020) at t_reply.c:1282 1282 t_reply.c: No such file or directory. (gdb) bt #0 0x00007fca0d45e996 in t_should_relay_response (Trans=0x7fca067da3c0, new_code=200, branch=0, should_store=0x7ffff47edd44, should_relay=0x7ffff47edd40, cancel_data=0x7ffff47edf30, reply=0x7fca0d8fd020) at t_reply.c:1282 #1 0x00007fca0d46317f in relay_reply (t=0x7fca067da3c0, p_msg=0x7fca0d8fd020, branch=0, msg_status=200, cancel_data=0x7ffff47edf30, do_put_on_wait=1) at t_reply.c:1786 #2 0x00007fca0d469154 in reply_received (p_msg=0x7fca0d8fd020) at t_reply.c:2537 #3 0x000055e77686fbe3 in do_forward_reply (msg=0x7fca0d8fd020, mode=0) at core/forward.c:747 #4 0x000055e776871a00 in forward_reply (msg=0x7fca0d8fd020) at core/forward.c:852 #5 0x000055e7768bd4e7 in receive_msg ( buf=0x55e776da0520 <buf> "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 172.17.217.10;rport=5060;received=172.17.217.10;branch=z9hG4bK3494.0e37cca5019fe3c95285a3464d0eaa5e.0;i=b3\r\nVia: SIP/2.0/TCP 192.168.0.102:53360;rport=53360;received=9"..., len=638, rcv_info=0x7ffff47ee4e0) at core/receive.c:364 #6 0x000055e7767ce4fe in udp_rcv_loop () at core/udp_server.c:554 #7 0x000055e77673a15d in main_loop () at main.c:1619 #8 0x000055e7767421fe in main (argc=13, argv=0x7ffff47eeb98) at main.c:2638

5 years, 3 months

failure route is not executed when suspended invite is cancelled

by Koray Vatansever

Hi all, I'm trying to upgrade kamailio from 4.2.7 to 5.1.5 and I realized that when CANCEL is received for a suspended INVITE, failure route is not executed in release 5.1.5. In 4.2.7 failure route is executed for this scenario. Is this the expected behaviour or am I missing something?

5 years, 3 months

Automating installation

by John Tuxies

Hi all. I am new to this and i would like some help please. I am looking to deploy Kamailio and Asterisk in my systems and i would like to automate the process. I have found a bash script but it it outdated from here: https://github.com/gurumelo/asteriskkamailio i did some changes and modifications to adapt it to newer version of software, but it fails to start Kamailio and continue to Asterisk. I would appreciate if someone could help me with this script and make it work. The systems i am planning to execute it is in Debian 9 and Ubuntu 18.04 server, both 64bit. Sincerely yous, John

5 years, 4 months

core at kamailio 5.1.6

by David Escartín

hello all we are seeing in a new kamailio instance some crashes. We are not sure the root cause, here you have the last core generated https://pastebin.com/xMRrug2X COuld you please take a look to see if there might be any issue with the last message that caused the core (to me seems normal) or there might be some issues related to other system libraries, etc? thanks a lot and regards david

5 years, 4 months

DTLS HA redis-pacemaker-corosync

by Жан Базаров

Hello! Are there any ways to implement using DTLS in redis HA scenario? When I reboot the active RTPEngine server the system correctly fails over to the other server and, after only a small pause (~1s), incoming audio continues to arrive. However, approximately 15 seconds after this I hear nothing but silence. Thanks.

5 years, 4 months

SIP SIMPLE TO XMPP AND VICE VERSA

by sagar malam

Hello, We have a system which using FreeSWITCH for calls and Ejabberd( XMPP) for chat.Now we want to support SIP SIMPLE as well.But we are not going to move old users to SIP SIMPLE but only new users will use SIP SIMPLE.This leads to requirement of having SIP-XMPP gateway for which are are considering Kamailio server. I have gone through documentation about Kamailio XMPP module, it is clear that Kamailio can convert SIP MESSAGE to XMPP so SIP to XMPP will work but what about XMPP to SIP MESSAGE ? Does that work as well ? Thanks in advance. -- Thanks, Sagar

5 years, 4 months

Dialplan Module limits

by Enrico Bandiera

Hi guys, does anyone know which are the limits of the diaplan module? After how many entries I will encounter serious performance issues? Thanks, Enrico.

5 years, 4 months

presence/mwi issue

by Andreas Granig

Hi, Currently playing with presence_mwi in kamailio 5.1, and it appears the issue reported by Juha two years ago at https://lists.kamailio.org//pipermail/sr-dev/2016-September/036609.html seems to have appeared again somewhere along the way. I’m sending a PUBLISH with message-summary event type, however I’m getting this error: ERROR: presence [presentity.c:283]: check_if_dialog(): failed to parse xml document As said in the old thread, it’s not an XML document, so it shouldn’t try to treat it as such. Any ideas? Best, Andreas

5 years, 4 months

Dispatcher with a naptr address as destination

by José Seabra

Hello all, I'm trying to use a naptr address as a dispatcher destination and i'm facing some issues here. When i configure a naptr address in dispatcher table, like: *1:1:sip\:proxy-registrar-ci1.fuze.domain:0:0:'':''* I see kamailio making a dns query of type A, but since that this name doesn't have any A record configured in dns, kamailio didn't get any positive reply from it. Should't kamailio make dns query by this order? 1. NAPTR 2. SRV 3. A I noticed also that if the name configured in dispatcher table is resolved successfully with A record from dns, then kamailio tries to make a query to NAPTR and then SRV services for the exactly same name used for query previously done(type A), but only if it gets a positive answer from dns to the A type query. I'm using kamailio version 5.1.0 with the following dns parameters configured: ####### DNS Parameters ######### dns = no rev_dns = no dns_try_ipv6 = no dns_retr_time = 1 dns_retr_no = 1 dns_cache_del_nonexp = no dns_cache_flags = 1 dns_cache_gc_interval = 120 dns_cache_init = 1 dns_cache_mem = 1000 dns_cache_negative_ttl = 60 dns_try_naptr = yes use_dns_cache = on use_dns_failover = on dns_srv_lb = yes Is there something wrongly configured here that can make kamailio behaves like that? Thank you. Regards -- Cumprimentos José Seabra

5 years, 4 months

Issue with ACK's

by Dan Quinney

Hi all, I’m having some issues with ACK’s. Specifically, when an ACK reaches Kamailio from either Asterisk or an endpoint, Kamailio is adding a second Via header - which isn’t valid as per RFC 3261 (17.1.1.3); “The ACK MUST contain a single Via header field, and this MUST be equal to the top Via header field of the original request." Endpoints are registered with Kamailio but INVITES are routed via Asterisk for dial plan and media reasons. I’m running fairly bog-standard Kamailio and Asterisk installs. I’ve attached a sample PCAP for if anyone has any suggestions. Thanks. Dan

5 years, 4 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users November 2018