sr-users

sr-users@lists.kamailio.org

42 participants
37519 discussions

Trying to fail a call over after 200 OK
by iTalk IP Support Department 28 Dec '17

28 Dec '17

Hi Everyone: I would appreciate your insight regarding a problem we are trying to solve. We are using Kamailio (4.1.8) along with multiple asterisk (13 and above) clusters for various telephony features. We are using the dispatcher module to send calls to the asterisk clusters in round robin and failover algorithms. We need a solution to fail a call and hand it over to another asterisk server after Kamailio has received a 200OK from Asterisk server A. I understand the failover works before the 200OK is sent from asterisk A and calls can easily be sent to asterisk B but again the challenge here to fail the call over to another asterisk server after a 200OK is received from the first one. If this is impossible I was wondering if refer and re-direct is an option to get this done. Thanks in advance for looking at this and for your responses.

2 1

Handling redirect replies and send to new host
by voipspace voipspace 28 Dec '17

28 Dec '17

Hi I am aiming to do the following User calls to Kamailio Switch (A) Switch (A) calls to Kamailio redirect server (B).. (B) runs script to determine route (B) sends Stateless 300 redirect reply to (A). (A) sends ACK to (B). (A) send user call to another host (extracted from header variable from redirect reply) (A) call to (B) rewritehost("x.x.x.x"); t_relay(); (A) On receipt of the 300 response I do not want this redirect to go back to the user. onreply_route { if (t_check_status("3[0-9][0-9]")) { // How do I send ACK to (B) to finish this redirect ? // Then I want a new relay to the host. How would I do it ? } }

3 2

PUBLISH modification.
by Володимир Іванець 27 Dec '17

27 Dec '17

Hello! I am trying to modify PUBLISH packet before handle_publish function execution. The best what I could think of is to make all required changes, update Destination URI to the Kamailio itself and then send it. In this case Kamailio will receive another PUBLISH packet with modified values. I was wondering someone knows cleaner way of achieving this. Thanks!

2 2

How to send "bye" to caller when callee abruptly terminates (Connection reset by peer)
by Pranathi Venkatayogi 26 Dec '17

26 Dec '17

Hi, Currently when callee abruptly closes the connection (TCP RST), Kamailio does not send “BYE” to the caller. Caller is left to believe that he is talking to the callee. What is best way to solve this? I have attempted using tcpops module to track connection RSTs and then send $dlg_bye in event_route[tcp:reset] . In the event_route, I can access only these - $conid , $Ri , $Rp , $si , $sp and $proto variable and do not know how to get to the dlg this connection belongs. Questions: How do I load the dialog associated with this conid? Is there a way to enumerate all dialogs? Thanks in advance, Pranathi.

2 2

Module dispatcher no
by Евгений Голей 26 Dec '17

26 Dec '17

Hello! Sorry for English, I know only Russian . There was a situation when it is necessary to control 1 IP address of the remote gateway from different sockets to kamailio. This is necessary to provide a backup bypass to a remote gateway through two independent Internet providers. Previously, I used the dispatcher module, but in this situation it did not help, I want to understand it the way it should or it's a bug. Here are the settings ------------(PROV-1)----------------\ / \ / (socket:udp:Y1.Y1.Y1.Y1:7060) Remote GW (sip:A1.A1.A1.A1:5060)------ (INTERNET) KAMAILIO \ (socket:udp:X1.X1.X1.X1:7060) \ / -----------(PROV-2)------------------/ kamailio.cfg ... loadmodule "dispatcher.so" ################################################################# modparam("dispatcher", "db_url", "mysql://root:@localhost/kamailio510") modparam("dispatcher", "dst_avp", "$avp(test)") modparam("dispatcher", "flags", 2) modparam("dispatcher", "ds_ping_method", "OPTIONS") modparam("dispatcher", "ds_ping_interval", 30) modparam("dispatcher", "ds_probing_threshold", 1) modparam("dispatcher", "ds_inactive_threshold", 2) modparam("dispatcher", "ds_probing_mode", 1) List gw dispatcher ]# kamcmd dispatcher.list { NRSETS: 1 RECORDS: { SET: { ID: 1 TARGETS: { DEST: { URI: sip:A1.A1.A1.A1:5060 FLAGS: AP PRIORITY: 2 ATTRS: { BODY: socket=udp:Y1.Y1.Y1.Y1:7060 DUID: MAXLOAD: 0 WEIGHT: 0 RWEIGHT: 0 SOCKET: udp:Y1.Y1.Y1.Y1:7060 } } DEST: { URI: sip:A1.A1.A1.A1:5060 FLAGS: AP PRIORITY: 1 ATTRS: { BODY: socket=udp:X1.X1.X1.X1:7060 DUID: MAXLOAD: 0 WEIGHT: 0 RWEIGHT: 0 SOCKET: udp:X1.X1.X1.X1:7060 } } } } } } Result if the remote gateway is not accessible through the network of the provider 2 (udp:X1.X1.X1.X1:7060), for the unknown reason the status of the first record, which corresponds to the provider 1 (udp:Y1.Y1.Y1.Y1:7060), changes. There are no errors with sockets, OPTIONS packages are sent and a response of 200 OK from the provider is received. 1. OPTIONS requests are sent through provider 2, but there are no answers. But the status changes for some reason at the first. # kamcmd dispatcher.list { NRSETS: 1 RECORDS: { SET: { ID: 1 TARGETS: { DEST: { URI: sip:A1.A1.A1.A1:5060 FLAGS: IP PRIORITY: 2 ATTRS: { BODY: socket=udp:Y1.Y1.Y1.Y1:7060 DUID: MAXLOAD: 0 WEIGHT: 0 RWEIGHT: 0 SOCKET: udp:Y1.Y1.Y1.Y1:7060 } } DEST: { URI: sip:A1.A1.A1.A1:5060 FLAGS: AP PRIORITY: 1 ATTRS: { BODY: socket=udp:X1.X1.X1.X1:7060 DUID: MAXLOAD: 0 WEIGHT: 0 RWEIGHT: 0 SOCKET: udp:X1.X1.X1.X1:7060 } } } } } } At testing it was found out, that камаилио does not allow to supervise a condition at use my circuit. I tried on 5.0.3 and on 5.1.0 the dispatcher works similarly. Please help with advice. Best regards Evgeniy

1 0

Multiple Kamailio Servers + Location Table
by Daniel W. Graham 26 Dec '17

26 Dec '17

When multiple Kamailio servers are using the same database with different server_id's (one active the rest standby in this test), records disappear and are no longer tracked in location database table. Some entries remain, but it never populates to the normal amount unless only one server is using the database. Anyone run into this before? Happened with 5.0 and is happening with 5.1. -dan

4 7

Dispatcher module OPTIONS and event routes: how are they handled by core?
by George Diamantopoulos 21 Dec '17

21 Dec '17

Hello all, I use the dispatcher module extensively for load balancing and fail-over. My kamailio instance is multihomed, and I use the "socket" attribute to determine which socket SIP messages should use for each dispatcher destination, as such: +----+-------+-------------------------+-------+----------+-----------------------------+ | id | setid | destination | flags | priority | attrs | +----+-------+-------------------------+-------+----------+-----------------------------+ | 1 | 0 | sip:192.168.0.1:5060 | 8 | 0 | socket=udp: 10.10.10.1:5060 | | 2 | 1 | sip:111.111.11.1:5060 | 8 | 0 | socket=udp: 44.44.44.1:5060 | | 3 | 1 | sip:222.222.22.2:5060 | 8 | 0 | socket=udp: 55.55.55.1:5060 | +----+-------+-------------------------+-------+----------+-----------------------------+ The dispatcher module uses OPTIONS to probe each destination for availability. When a destination goes down or up, the respective event-route is executed. What I need to do is to be able to "capture" the sending socket used for this probing when a destination becomes unavailable or available in the event-routes. The $fs variable is set, but unfortunately its value does not make sense. Here's an example route and the results that are printed: event_route[dispatcher:dst-down] { xlog("L_ERR", "Destination down: $rm $ru ($du) $ds $fs $Ru $T_req($fs) $T_req($Ru)\n"); } Now say destination with id = '2' goes down. This is what I get in the logs for the event_route above: ERROR: <script>: Destination down: OPTIONS sip:111.111.11.1:5060 (sip: 192.168.0.1:5060) Contact: <sip:111.111.11.1:5060> udp:10.10.10.1:5060 <null> <null> <null> The xlog PV/log mapping for the above line is the following: $rm: OPTIONS $ru: sip:111.111.11.1:5060 $du: sip:192.168.0.1:5060 $ds: Contact: <sip:111.111.11.1:5060> $Ru: udp:10.10.10.1:5060 The rest are $null. $ru and $ds are consistent with the actual destination being probed, $du and $fs are not (the are set to values corresponding to id = '1', for some reason). This log line is, of course, inaccurate. Not only does it not make sense, but also this is not consistent with messages captured on network interfaces using sngrep: Kamailio does indeed behave as it should, the OPTIONS is sent out to 111.111.11.1 from socket udp:44.44.44.1:5060. But this is not reflected in the log entry above when the event_route is executed. Now the weird part is that this OPTIONS "transaction" (which is locally generated by kamailio) has the $du PV set to the value of another destination (namely the that of id = '1'). As a result, the $fs PV is consistent with that choice for $du. I can verify with sngrep that this is not the case in reality, as the request was sent to destination id = '2' from the correct socket as indicated above. What I would like to ask is whether these "OPTIONS" used by dispatcher for probing go through the request_route processing at some point. This is the only way that would explain the $du PV being set to a false value. If yes, is there any way to prevent this from happening? I need to be able to access the $fs PV when a destination goes up or down, and I can't have any other configuration file routes interfering with that. Thanks! Best regards, George

2 4

strange --dialog in delete state is too old-- log line managing dialog hashes
by David Escartín 21 Dec '17

21 Dec '17

hello all recently we are seeing some weird messages handling with dialogs in Kamailio version 5.0 we sometimes are seeing messages like /usr/local/kamailio/sbin/kamailio[15372]: NOTICE: dialog [dlg_hash.c:249]: dlg_clean_run(): dialog in delete state is too old (0x7fa65445c850 ref 3) /usr/local/kamailio/sbin/kamailio[15372]: NOTICE: dialog [dlg_hash.c:235]: dlg_clean_run(): dialog in early state is too old (0x7fa652d57110 ref 1) we increased the debug description adding some lines to the dialog module code so we could track the calls of the calls that these messages belong to, and we could see that those messages appeared in calls just released at that moment, for example: <134>Nov 4 11:21:38 localhost /usr/local/kamailio/sbin/kamailio[4108]: INFO: mad-localhost-1 Call 97980 / Call-ID 1409565771_82382809(a)195.219.240.46: Creating dialog [8043:21772] with hash id 21772 and hash entry 8043 <134>Nov 4 11:21:38 localhost /usr/local/kamailio/sbin/kamailio[4106]: INFO: mad-localhost-1 Call 97980 / Call-ID 1409565771_82382809(a)195.219.240.46: Status 100, 6610 <134>Nov 4 11:21:39 localhost /usr/local/kamailio/sbin/kamailio[4111]: INFO: mad-localhost-1 Call 97980 / Call-ID 1409565771_82382809(a)195.219.240.46: CANCEL received in A-Leg, relaying downstream <134>Nov 4 11:21:39 localhost /usr/local/kamailio/sbin/kamailio[4112]: INFO: mad-localhost-1 Call 97980 / Call-ID 1409565771_82382809(a)195.219.240.46: Status 487, 6610 <133>Nov 4 11:21:39 localhost /usr/local/kamailio/sbin/kamailio[4139]: NOTICE: dialog [dlg_hash.c:251]: dlg_clean_run(): dialog in delete state is too old (0x7fa0c02a6870 ref 3) with callid '1409565771_82382809(a)195.219.240.46' <129>Nov 4 11:21:39 mad-proxy-inout-1 /usr/local/kamailio/sbin/kamailio[4112]: ALERT: dialog [dlg_handlers.c:1715]: dlg_run_event_route(): after event route - dialog not found [8043:21772] (1/5) (0x7fa0c02a6870) with callid '1409565771_82382809(a)195.219.240.46' we printed the dialog id and entry hash values and we can see there are no other calls creating same values in the previous hours, or using same memory allocation, or same callid, so it seems like there was some kind of strange issue with the dialog timers....¿? By the way, this is happening only few times (80-100 times) a day having many thousands of calls, so it's quite difficult for us to duplicate, we couldn't do it until now. We also tried to use the timer_procs 0 or 1 to use a different proc timer but seems the issue happens in both scenarios. The configuration change we made and seems it was done when these messages started to appear is to use dialog event_route when ended and failed to do some stuff there managing some dialog variables. Does ti make any sense that attempting to use those variables could cause these behaviour? Do you have any idea about it could be or how we can check it deeper? thanks a lot and regards david escartin

2 9

How to add new user to Kamailio using PHP shell_exec?
by Arun NV 21 Dec '17

21 Dec '17

There is a requirement to add a new user to *Kamailio* programmatically using *PHP*. I tried to add username and password to *subscriber* table manually using *SQL* queries, but it won't works because *ha1* and *ha1b* should be added to the table. I don't know how Kamailio generate *ha1* and *ha1b*. Following are the manually added entries using *kamctl* tool. mysql> select * from subscriber limit 2; +----+----------+---------------+--------------+---------------+----------------------------------+----------------------------------+------+ | id | username | domain | password | email_address | ha1 | ha1b | rpid | +----+----------+---------------+--------------+---------------+----------------------------------+----------------------------------+------+ | 9 | 1010101 | 10.101.101.10 | aswwwwwwwsdf | | a37d1785953310c206481ca1a33f16b6 | 7e981130f05a547a738d3c29031e89d0 | NULL | | 10 | 1010102 | 10.101.101.10 | 6eeeeee8a72 | | 6b574f9047206481ca1a33501d7dbdce | cd9a8b89d926f3cb1290311a8cb8a2a8 | NULL | +----+----------+---------------+--------------+---------------+----------------------------------+----------------------------------+------+ Then I tried with *shell_exec* function in *PHP* to use *kamctl* command(*kamctl add username password*). but it will prompt for *Kamailio* read-write user's password. So following command cannot add new users to Kamailio $res = shell_exec("sudo kamctl add new_username new_password); so, please suggest a way to add new user's to *Kamailio* programmatically. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

3 2

4.4.4 CPU 100%
by Tomas Zanet 21 Dec '17

21 Dec '17

Hi all, I’ve been using Kamailio 4.4.4 for 8 months without any problems but in recent days, I’m having some issues with our server and, when it happens, it cannot get new registrations. Using top I saw a kamailio process is eating all CPU. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1556 kamailio 20 0 1010884 27624 24520 R 98.5 1.4 150:07.59 kamailio I got backtrace attaching to Kamailio with gdb. Here is the backtrace: #0 0x00007fb996992d6d in accept () at ../sysdeps/unix/syscall-template.S:81 #1 0x00000000005f3615 in handle_new_connect (si=0x7fb9960b4fa8) at tcp_main.c:3894 #2 0x00000000005f7029 in handle_io (fm=0x7fb9961da520, ev=1, idx=-1) at tcp_main.c:4199 #3 0x00000000005c68b2 in io_wait_loop_epoll (h=0xa1fdc0 <io_h>, t=5, repeat=0) at io_wait.h:1065 #4 0x00000000005fa04a in tcp_main_loop () at tcp_main.c:4490 #5 0x00000000004b48ba in main_loop () at main.c:1712 #6 0x00000000004bad12 in main (argc=13, argv=0x7ffd14247c18) at main.c:2631 (gdb) bt At the moment I found the issue, there were 862 sip client registered correctly. Our server is configured to use only TLS and mysql as backend. /usr/local/sbin/kamailio -v version: kamailio 4.4.4 (x86_64/linux) 852c47 flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 852c47 compiled on 15:56:18 Dec 15 2016 with gcc 4.8.4 Can anyone address me to find out why this happens? Many thanks, T. Tomas Zanet R&D Software designer tzanet(a)came.com CAME S.p.A.

2 2

Jump to page:

2025

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