sr-users December 2018

sr-users@lists.kamailio.org

60 participants
73 discussions

by Soltanici Ilie

Hi, version: kamailio 5.1.6 (x86_64/linux) 7d1964 Also, i'm using force_rport(); in routing configuration file, but 'received' parameter anyway is missing :( Thank You.

5 years, 3 months

kamailio rabbitmq segfault

by Sylvain Boily

Hello, I tried to test the rabbitmq module in kamailio with the debian 9 repo from kamailio.org but there is a segfault when the service is launched. Is there is people also have this issue? /etc/init.d/kamailio restart [....] Restarting kamailio (via systemctl): kamailio.serviceJun 9 13:02:03 siprouter kamailio: DEBUG: <core> [core/cfg.y:1659]: yyparse(): loading module rabbitmq.so Jun 9 13:02:03 siprouter kamailio: DEBUG: <core> [core/sr_module.c:575]: load_module(): trying to load </usr/lib/x86_64-linux-gnu/kamailio/modules/rabbitmq.so> Jun 9 13:02:03 siprouter kamailio: DEBUG: <core> [core/kemi.c:1295]: sr_kemi_modules_add(): adding module: rabbitmq Jun 9 13:02:03 siprouter kamailio: DEBUG: <core> [core/cfg.lex:1737]: pp_define(): defining id: MOD_rabbitmq Jun 9 13:02:03 siprouter kernel: [159315.610811] kamailio[13226]: segfault at 7f03b2296287 ip 00007f03b2080ca3 sp 00007fff133285c0 error 7 in librabbitmq.so.4.2.0[7f03b2074000+13000] Jun 9 13:02:03 siprouter /usr/sbin/kamailio[13226]: DEBUG: <core> [core/sr_module.c:988]: init_mod(): rabbitmq Sylvain

5 years, 3 months

"Discarded invalid SRTP packet: authentication failed" warning

by David Cunningham

Hello, We're having an issue with rtpengine (used by Kamailio) where audio works initially, but then after an apparently random amount of time stop working. We see that when audio stops working rtpengine logs this: Dec 10 09:58:57 hostname rtpengine[376]: WARNING: [Pl1SeGDssOsDNWQdvey4lg.. port 48766]: Discarded invalid SRTP packet: authentication failed It then logs similar messages until the call hangs up. No such messages were logged while audio was working. Searching for this error message suggests that a change in the SSRC can cause the problem, but we don't see any such change in the PCAP. The source IP, port, codec, and SSRC all stay the same, and the Sequence increments as normal. Does anyone have suggestions on where to look next? We can share the PCAP privately if that would help anyone. Thanks for any advice! -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782

5 years, 3 months

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

Dispatcher probing

by Duarte Rocha

Hey. I have another question regarding the Dispatcher Probing. In my SBC, a Gateway is defined by it's IP, Port and SAP (Kamailio's IP used for signaling). Those 3 parameters are defined in the Gateway table. In this case ( using Options for probing), i only have access to the destination IP ($dd) and Port ($dp). I need to know the SAP associated to the gateway that is currently being probed, in order to force the correct socket in the OPTIONS request. Is there any way to get more info about the db line that is being read by dispatcher for the probing? If that's not possible i was thinking about querying my db for the Ip:Port pair and if i got more than one result, do forking using the the SAPs in the results, sending multiple OPTIONS through the multiple sockets. In this case, if only one of the OPTIONS is answered, will the gateway still appear as "Active" ? Best Regards, Duarte Rocha

5 years, 3 months

Phonenum Module

by Soltanici Ilie

Hi All, How can i get Local Number by using phonenum module? What is the variable for that? Thank You

5 years, 3 months

Logging from cfg file

by Muhammad Allaudin

Hi everyone, I have recently started working on Kamailio, I am trying to learn the basics. For "Register" route, I am trying to print the log but log is not appearing in log file. Other logs are there, only this one is missing. *if(is_method("REGISTER")){* * log(2, "Register request");* *}* I will be really helpful if you can help me with this. Thanks & Kind Regards *Regards,* *M.Allaudin* *Software EngineerNowtel GroupPhone # +92-333-8291874Blogger @ allaudin.github.io <http://allaudin.github.io>*

5 years, 3 months

A bit trick in msg_translator.c source file

by Mojtaba

Hello , Does anybody know why the lenght of both ip-address (s and name) in check_via_address function in msg_translator.c source file dose not check first? Actually i think it's better do. For example if via:192.168.122.1 and src:192.168.122.100, the result returned true, as they are not the same! With.Regards. Mojtaba Happy new year --Mojtaba Esfandiari.S

5 years, 3 months

Re: [SR-Users] kamailio does not responde if an rtpengine is unreachable

by David Escartin

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" <miconda(a)gmail.com> Sent: Friday, December 28, 2018 9:15am To: "Juha Heinanen" <jh(a)tutpro.com> Cc: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org> 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(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

5 years, 3 months

kamailio does not responde if an rtpengine is unreachable

by Juha Heinanen

I noticed that if one rtpengine in a set is unreachable, kamailio 5.2 does start, but does not process any SIP requests. Is this intentional? -- Juha

5 years, 3 months

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 December 2018