sr-users December 2017

sr-users@lists.kamailio.org

73 participants
101 discussions

Bind IP to Kamailio without restart
by Duarte Rocha 29 Dec '17

29 Dec '17

Greetings, I want to add a new IP to eht0 in my proxy and i want Kamailio to be able to listen to it without me having to restart it. I already have the "listen" parameter set to listen=udp:eth0:5060. Is there any way to reload this parameter it in runtime in order to include the new ip? Is there any alternative to this ? Thanks in advance. Cheers

2 1

PCSCF Access denied issue
by Kranti Kumar 29 Dec '17

29 Dec '17

Hi All, We are using *Kamailio IMS VM* image and we are able to run HSS(/hss.sh) successfully. But while running PCSCF (kamailio -f /usr/local/etc/kamailio/kamailio-pcscf.cfg), we are getting below errors. 0(1772) DEBUG: <core> [db.c:209]: db_bind_mod(): using db bind api for db_mysql 0(1772) DEBUG: <core> [db.c:314]: db_do_init2(): connection 0x7f208368d1b8 not found in pool 0(1772) DEBUG: db_mysql [km_my_con.c:98]: db_mysql_new_connection(): opening co nnection: mysql://xxxx:xxxx@server.net1.test/pcscf 0(1772) ERROR: db_mysql [km_my_con.c:124]: db_mysql_new_connection(): driver er ror: Access denied for user 'pcscf'@'pcscf.net1.test' (using password: YES) 0(1772) ERROR: <core> [db.c:318]: db_do_init2(): could not add connection to the pool 0(1772) ERROR: ims_usrloc_pcscf [usrloc_db.c:79]: init_db(): unable to co nnect to the database 0(1772) ERROR: ims_usrloc_pcscf [ul_mod.c:203]: mod_init(): Error initializing db connection 0(1772) ERROR: <core> [sr_module.c:962]: init_mod(): Error while initializing module ims_usrloc_pcscf (/usr/local/lib64/kamailio/modules/ims_usrloc_pcscf.so) ERROR: error while initializing modules To fix the above error, we tried below commands *mysql -u root -p GRANT ALL ON *.* TO root IDENTIFIED BY 'root'; quit* - replace bind-address in /etc/mysql/my.cnf to 0.0.0.0 But still we are getting the same issue. Could any one please help us to resolve this issue. Could any one please guide us the troubleshooting steps. Thank you so much in advance. Regards, -kranti

4 6

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

← Newer
1
2
3
4
5
6
7
...
11
Older →

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