sr-users May 2015

sr-users@lists.kamailio.org

80 participants
115 discussions

how to delete key from htable?
by Juha Heinanen 13 May '15

13 May '15

there exists rpc command htable.delete that can be used to delete a key from htable. is there a way to delete a key in the config file like assigning $null to it or do i need to use sht_rm_name_re function that feels like an overkill? -- juha

2 4

Kamailio-4.1.5 memory leak
by Bui Minh Yen 13 May '15

13 May '15

Hi everyone, I am using Kamailio-4.1.5. Sometime kamailio was crash because memory leak. Log when out of mem May 2 09:49:00 vnpsip01 /usr/local/sbin/kamailio[30821]: ERROR: tm [t_lookup.c:1472]: t_newtran(): ERROR: t_newtran: new_t failed May 2 09:49:00 vnpsip01 /usr/local/sbin/kamailio[30821]: ERROR: tm [t_lookup.c:1332]: new_t(): ERROR: new_t: out of mem: May 2 09:49:00 vnpsip01 /usr/local/sbin/kamailio[30821]: ERROR: tm [t_lookup.c:1472]: t_newtran(): ERROR: t_newtran: new_t failed May 2 09:49:00 vnpsip01 /usr/local/sbin/kamailio[30821]: ERROR: usrloc [ucontact.c:103]: new_ucontact(): no more shm memory May 2 09:49:00 vnpsip01 /usr/local/sbin/kamailio[30821]: ERROR: usrloc [urecord.c:155]: mem_insert_ucontact(): failed to create new contact May 2 09:49:00 vnpsip01 /usr/local/sbin/kamailio[30821]: ERROR: usrloc [urecord.c:547]: insert_ucontact(): failed to insert contact May 2 09:49:00 vnpsip01 /usr/local/sbin/kamailio[30821]: ERROR: registrar [save.c:708]: update_contacts(): failed to insert contact May 2 09:49:00 vnpsip01 /usr/local/sbin/kamailio[30821]: ERROR: tm [t_lookup.c:1332]: new_t(): ERROR: new_t: out of mem: May 2 09:49:00 vnpsip01 /usr/local/sbin/kamailio[30821]: ERROR: tm [t_lookup.c:1472]: t_newtran(): ERROR: t_newtran: new_t failed May 2 09:49:00 vnpsip01 /usr/local/sbin/kamailio[30821]: ERROR: usrloc [ucontact.c:103]: new_ucontact(): no more shm memory May 2 09:49:00 vnpsip01 /usr/local/sbin/kamailio[30821]: ERROR: usrloc [urecord.c:155]: mem_insert_ucontact(): failed to create new contact May 2 09:49:00 vnpsip01 /usr/local/sbin/kamailio[30821]: ERROR: usrloc [urecord.c:547]: insert_ucontact(): failed to insert contact May 2 09:49:00 vnpsip01 /usr/local/sbin/kamailio[30821]: ERROR: registrar [save.c:521]: insert_contacts(): failed to insert contact Log when kamailio was crash May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30818]: ALERT: <core> [main.c:775]: handle_sigs(): child process 30821 exited by a signal 11 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30818]: ALERT: <core> [main.c:778]: handle_sigs(): core was not generated May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30818]: INFO: <core> [main.c:790]: handle_sigs(): INFO: terminating due to SIGCHLD May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: INFO: <core> [main.c:841]: sig_usr(): INFO: signal 15 received May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: <core> [main.c:852]: sig_usr(): Memory status (pkg): May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: (0x7f6af5968010): May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: heap size= 749731840 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: used= 1110960, used+overhead=1663384, free=748068456 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: max used (+overhead)= 1825240 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: dumping all alloc'ed. fragments: May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 0. N address=0x7f6af599d528 frag=0x7f6af599d4f8 size=1024 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: str_hash.h: str_hash_alloc(69) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 1. N address=0x7f6af599d988 frag=0x7f6af599d958 size=256 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30828]: INFO: <core> [main.c:841]: sig_usr(): INFO: signal 15 received May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: str_hash.h: str_hash_alloc(69) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 2. N address=0x7f6af599dae8 frag=0x7f6af599dab8 size=176 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: counters.c: cnt_hash_add(339) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 3. N address=0x7f6af599dbf8 frag=0x7f6af599dbc8 size=240 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: counters.c: cnt_hash_add(339) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 4. N address=0x7f6af599dd48 frag=0x7f6af599dd18 size=128 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: counters.c: init_counters(129) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 5. N address=0x7f6af599de28 frag=0x7f6af599ddf8 size=16 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: modparam.c: set_mod_param_regex(124) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 6. N address=0x7f6af599de98 frag=0x7f6af599de68 size=128 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: str_hash.h: str_hash_alloc(69) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 7. N address=0x7f6af599df78 frag=0x7f6af599df48 size=48 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: route.c: route_add(159) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 8. N address=0x7f6af599e008 frag=0x7f6af599dfd8 size=16 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: route.c: init_rlist(181) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 9. N address=0x7f6af599e078 frag=0x7f6af599e048 size=128 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: str_hash.h: str_hash_alloc(69) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 10. N address=0x7f6af599e158 frag=0x7f6af599e128 size=48 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: route.c: route_add(159) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 11. N address=0x7f6af599e1e8 frag=0x7f6af599e1b8 size=16 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: route.c: init_rlist(181) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 12. N address=0x7f6af599e258 frag=0x7f6af599e228 size=128 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: str_hash.h: str_hash_alloc(69) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 13. N address=0x7f6af599e338 frag=0x7f6af599e308 size=48 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: route.c: route_add(159) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 14. N address=0x7f6af599e3c8 frag=0x7f6af599e398 size=16 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: route.c: init_rlist(181) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 15. N address=0x7f6af599e438 frag=0x7f6af599e408 size=128 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: str_hash.h: str_hash_alloc(69) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30833]: INFO: <core> [main.c:841]: sig_usr(): INFO: signal 15 received May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30833]: NOTICE: <core> [main.c:852]: sig_usr(): Memory status (pkg): May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30833]: NOTICE: qm_status: (0x7f6af5968010): May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30833]: NOTICE: qm_status: heap size= 749731840 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30833]: NOTICE: qm_status: used= 1110768, used+overhead=1663192, free=748068648 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30833]: NOTICE: qm_status: max used (+overhead)= 1825240 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30833]: NOTICE: qm_status: dumping all alloc'ed. fragments: May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30833]: NOTICE: qm_status: 0. N address=0x7f6af599d528 frag=0x7f6af599d4f8 size=1024 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30833]: NOTICE: qm_status: alloc'd from <core>: str_hash.h: str_hash_alloc(69) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30833]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30833]: NOTICE: qm_status: 1. N address=0x7f6af599d988 frag=0x7f6af599d958 size=256 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30833]: NOTICE: qm_status: alloc'd from <core>: str_hash.h: str_hash_alloc(69) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30827]: INFO: <core> [main.c:841]: sig_usr(): INFO: signal 15 received May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: INFO: <core> [main.c:841]: sig_usr(): INFO: signal 15 received May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30828]: NOTICE: <core> [main.c:852]: sig_usr(): Memory status (pkg): May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: <core> [main.c:852]: sig_usr(): Memory status (pkg): May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: qm_status: (0x7f6af5968010): May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: qm_status: heap size= 749731840 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: qm_status: used= 1110768, used+overhead=1663192, free=748068648 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: qm_status: max used (+overhead)= 1825240 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: qm_status: dumping all alloc'ed. fragments: May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30828]: NOTICE: qm_status: (0x7f6af5968010): May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: qm_status: 0. N address=0x7f6af599d528 frag=0x7f6af599d4f8 size=1024 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: qm_status: alloc'd from <core>: str_hash.h: str_hash_alloc(69) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30832]: INFO: <core> [main.c:841]: sig_usr(): INFO: signal 15 received May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30832]: NOTICE: <core> [main.c:852]: sig_usr(): Memory status (pkg): May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30832]: NOTICE: qm_status: (0x7f6af5968010): May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30832]: NOTICE: qm_status: heap size= 749731840 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30832]: NOTICE: qm_status: used= 1110768, used+overhead=1663192, free=748068648 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30832]: NOTICE: qm_status: max used (+overhead)= 1825240 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30832]: NOTICE: qm_status: dumping all alloc'ed. fragments: May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30832]: NOTICE: qm_status: 0. N address=0x7f6af599d528 frag=0x7f6af599d4f8 size=1024 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: qm_status: 1. N address=0x7f6af599d988 frag=0x7f6af599d958 size=256 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30832]: NOTICE: qm_status: alloc'd from <core>: str_hash.h: str_hash_alloc(69) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: qm_status: alloc'd from <core>: str_hash.h: str_hash_alloc(69) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30834]: INFO: <core> [main.c:841]: sig_usr(): INFO: signal 15 received May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: qm_status: 2. N address=0x7f6af599dae8 frag=0x7f6af599dab8 size=176 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: qm_status: alloc'd from <core>: counters.c: cnt_hash_add(339) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30832]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30832]: NOTICE: qm_status: 1. N address=0x7f6af599d988 frag=0x7f6af599d958 size=256 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30834]: NOTICE: <core> [main.c:852]: sig_usr(): Memory status (pkg): May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 16. N address=0x7f6af599e518 frag=0x7f6af599e4e8 size=48 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30834]: NOTICE: qm_status: (0x7f6af5968010): May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30822]: INFO: <core> [main.c:841]: sig_usr(): INFO: signal 15 received May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30822]: NOTICE: <core> [main.c:852]: sig_usr(): Memory status (pkg): Could you help me to fix this problem! Thanks so much! -- --------------------------- *Bui Thi Minh Yen*

2 5

Memory leak or bad setting.
by Kjeld Flarup 13 May '15

13 May '15

Hello We experienced a failure on our kamailio (4.2.1+trusty), which required a restart. May 6 07:40:41 rtpproxy01 /usr/sbin/kamailio[5467]: ERROR: <core> [msg_translator.c:2270]: generate_res_buf_from_sip_res(): out of mem Afterwards we inspected all the settings to be using default, but at a much higher level than an other older kamailio which runs much more traffic. The big difference, is that this kamailio works with rtpengine. Does that require more memory? We also observed that the free memory is constantly falling on some instances. They all started with 16MB but after 1½ day some are on 11.6 Is this normal behaviour that will find a natural level or is there something bad going on? We can also see that there are frags. Is that to be worried about, or is this natural? kamcmd pkg.stats | egrep -e 'free|frag' free: 16362760 total_frags: 17 free: 15835176 total_frags: 232 free: 15845760 total_frags: 205 free: 15829288 total_frags: 188 free: 15847456 total_frags: 181 free: 15853024 total_frags: 183 free: 15873232 total_frags: 225 free: 15858584 total_frags: 231 free: 15834592 total_frags: 205 free: 15852520 total_frags: 132 free: 15869048 total_frags: 120 free: 15824872 total_frags: 100 free: 15828448 total_frags: 113 free: 15858216 total_frags: 109 free: 15861992 total_frags: 82 free: 15871712 total_frags: 110 free: 15813824 total_frags: 109 free: 11583736 total_frags: 121 free: 11588896 total_frags: 106 free: 11580448 total_frags: 118 free: 11586312 total_frags: 134 free: 11592840 total_frags: 159 free: 11632536 total_frags: 120 free: 11582368 total_frags: 127 free: 11660104 total_frags: 97 free: 16352192 total_frags: 14 free: 16351088 total_frags: 13 free: 16341248 total_frags: 46 free: 16351184 total_frags: 19 We use 4.2.1+trusty with these modules, is it possible that a newer version has fixed some memory leak? loadmodule "db_mysql.so" loadmodule "mi_fifo.so" loadmodule "kex.so" loadmodule "tm.so" loadmodule "tmx.so" loadmodule "sl.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "textops.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "sanity.so" loadmodule "ctl.so" loadmodule "mi_rpc.so" loadmodule "acc.so" loadmodule "dispatcher.so" loadmodule "permissions.so" loadmodule "sdpops.so" loadmodule "rtpengine.so" -- Med venlig hilsen / Best regards Kjeld Flarup (Christensen) M.Sc E.E, Teknisk chef Viptel ApS, Benslehøjvej 3, DK-7470 Karup J Telefon: +45 46949949, Telefax: +45 46949950, http://viptel.dk

2 3

Multi-homed Kamailio Modifies ACK
by SamyGo 13 May '15

13 May '15

Hi all, I'm having a scenario where I'm sending call to CISCO IAD2431. The call establishes with 200OK from CISCO and Kamailio sends back modified ACK. Cisco at this points gives out an error and sends 200OK again, Kamailio replies with ACK, and this cycle goes on until the call drops. Here is the error from CISCO: Failed FROM/TO Request check old_from: "Test Phone" <sip:+14432232221@192.168.1.106>;tag=as370915fc old_to: <sip:+14444812211@sip.iamip.com:5041>;tag=9FEC572E-100F new_from: "Test Phone" <sip:+14432232221@192.168.1.106>;tag=as370915fc new_to: <sip:+14444812211@192.168.1.244:5041>;tag=9FE I've #auto_aliases=no and, listen=udp:44.33.22.11:5041 listen=udp:192.168.1.244:5041 Kamailio sends INVITE through the Public IP to the CISCO gw, but decides to change the ACK header. Any advise please. Best Regards, Sammy.

2 3

kamailio slow/no response for requests on particular ports
by Karthik Srinivasan 12 May '15

12 May '15

Hi, I have encountered an issue with kamailio and am hoping someone on this email distro can help: Here's my setup and description of the issue: I am running kamailio version 3.1.4. I have the kamailio process bound to ports 5060, 5070, and 5090. all UDP. I have several client devices registering to the kamailio registrar. The issue I have encountered is this: SIP registrations to port 5070 are fine for a period of time; by fine I mean clients send SIP registration requests to kamailio; and kamailio responds promptly to the request. by period of time I mean (this could be somewhat random) that for10 hours; 12 hours; 1 hour; that kamailo has no issue processing requests. after this random time period has elapsed, kamailo isn't able to respond to sip registrations and other messages in timely manner; to the point where the clients timeout and have to resend their registration requests. at times, kamailio does respond to the requests (with a significant delay) and at other times no response is received by the client. the user experience is intermittent registration delays/failures. The same behavior is seen on port 5090. I have not encountered the issue yet on port 5060. During times when kamailio isn't able to respond timely to requests on a particular port, requests to other ports are responded to timely. for ex: if port 5070 encounters the issue; port 5060 and 5090 seem fine. meaning, I can point my client devices to 5060 or 5090 and kamailio processes the requests timely. I have studied a tcp dump on the server end (kamailio side) and noticed that the network layer shows the messages from the client to be received timely while kamailio is encountering this issue. which indicates to me that it probably isn't a network lag related issue. Something at the application layer is probably causing kamailio to not respond timely. Furthermore the issue resolves itself after a period of time; that is, kamailio begins to respond to messages timely on the problematic port. I haven't had a chance yet to determine exactly how long it takes to recover. it certainly takes some time though. at least 30 minutes; maybe more. I can also state that the load on the kamailio system is minimal. far below than what the performance metrics state it can handle. Has anyone encountered this issue where kamalio isn't responding to registration and other requests timely on a particular port but does so fine for other ports? Any help on this would be appreciated. Thanks, Karthik

2 5

Ims_charging lose all charging information when restart
by Yasin CANER 12 May '15

12 May '15

3 4

DMQ htable replication issue.
by José Seabra 12 May '15

12 May '15

Hello there, I'm using DMQ module to replicate an htable between several kamailio servers, what i'm noticing is that DMQ is sending the information from one server to another, but the htable name is not the same, for example: The original htable name is $sht(fscache=>queue:2), this htable is replicated to another server and the name (queue:2) will be replaced to some random value like this: $sht(fscache=>3c34e55ae6f9-rsf8qhhwntvw) What happens is that the other server cannot get the data replicated, because in script kamailio is looking for $sht(fscache=>queue:2) that is the original name. My kamailio version is 4.2.2, i have tested also with version 4.2.4 but I got the same behavior. This is an expected behavior or a bug? In case of expected behavior how I can configure it in order to get the value replicated from one server to another? Thank you for your help -- Cumprimentos José Seabra

3 7

Handling 407 Proxy Authentication, Elastix MT
by Darren Campbell (Primar) 12 May '15

12 May '15

Hi all Have Asterisk listening on 127.0.0.1 and aiming to route all inbound/outbound SIP via Kamailio listening on 127.0.0.1 and external interface. Inbound calls from the SIP PROVIDER work just fine. Have NAT, rtpproxy configured for successful registration and subsequent INVITEs etc. Experiencing some challenges with the outgoing INVITES, primarily authenticating the outbound INVITEs. The current situation is this: Asterisk > INVITE > Kamailio > INVITE > SIP PROVIDER SIP PROVIDER > 407 Proxy Authenticate > Kamailio > Transaction Cancelled. Asterisk then plays number unavailable message. The desired situation is more like this: Asterisk > INVITE > Kamailio > INVITE > SIP PROVIDER SIP PROVIDER > 407 Proxy Authenticate > Kamailio > Asterisk Asterisk > INVITE (with auth digest etc) > Kamailio > INVITE > SIP PROVIDER An attempted solution was made by having Kamailio authenticate using the uac module. However, ideally Kamailio should be mostly transparent and Asterisk should be handling and responding to the 407 Proxy Authentication. If there is someone in the Kamailio community that has addressed this situation before, guidance would be much appreciated. Regards, Darren

2 8

Media Proxy and STUN
by Nahum Nir 11 May '15

11 May '15

Hi All, After reading the docs I got that it is possible to configure the server so it will change the SDP so clients will send the media to the media proxy. But, what if the clients are not behind a symmetric NAT and using ICE where able to get their real IP:port? How can the server be aware to this and not change the SDP? Thanks, Nir

2 1

Kamailio authentication method
by Mathys Frédéric 10 May '15

10 May '15

Hello, In my scenario with a Kamailio server, I have a VOIP client connecting to the server which, for some reasons, cannot calculate MD5 hashes but only SHA. In this situation, would it be possible to change the authentication algorithm by either modifying Kamailio scripts or writing an external module to do that? As far as I know, the authentication response is calculated as follow (standard HTTP Digest authentication) : HA1=MD5(username:realm:password) HA2=MD5(method:digestURI) response=MD5(HA1:nonce:HA2) For that, I have to save ha1 and ha1b values in the DB with the SHA function directly (with a trigger for example), and then change the authentication method too. What is the best solution to do that? Does a module already exists? Thank you! Frederic Mathys System Integration & Validation

3 6

← Newer
1
...
6
7
8
9
10
11
12
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 May 2015