sr-users April 2017

sr-users@lists.kamailio.org

79 participants
113 discussions

JANSSON module not working for multiple JSON objects

by vivek＠advaitamtech.com

Hi All, Am using JANSSON module to parse the JSON object I receive. I tried using JSON module of kamailio. Since its giving error in loading the module due to error"libjson-c.so.3: cannot open shared object file: No such file or directory", I went ahead to use JANSSON module. JANSSON module is parsing the single JSON object perfectly. But not parsing the multiple JSON objects. JSON object am trying to parse: $avp(result1)= "[{"origin":"125.16.231.74","Dest":"725.76.731.77"},{"origin":"225.26.231.24","Dest":"225.26.231.27"}]" JANSSON API used: jansson_get("origin", "$avp(result1)", "$var(origin)"); Any suggestions will be really helpful. Thanks, Vivek

6 years, 12 months

topos and PRACK problem

by Sergey Basov

Hi All. I have just try to test topos with GW which requires PRACK. As you can see UA at packet 21 send PRACK to topos contact, but after topos, on other kamailio side in PRACK request line present not kontact but record-route header. Can you fix it? Thank you. -- Best regards, Sergey Basov e-mail: sergey.v.basov(a)gmail.com

6 years, 12 months

SIGCHLD causes termination, but it appears that no child process has actually stopped.

by Cody Herzog

Hello. I'm running Kamailio 4.3.5 on Ubuntu Server 14.04. I just started using the app_python module together with the OpenTok Python SDK, described here: https://tokbox.com/developer/sdks/python/ My basic Python test script works fine, but when I add an import statement in the Python script to bring in a package from the OpenTok Python SDK, Kamailio terminates right after launch with the following log message: "terminating due to SIGCHLD" I was surprised to not find any extra log messages indicating which child process was causing the signal. I hacked the code in the handle_sigs() function in main.c.c to NOT terminate in response to SIGCHLD, and was surprised to see that my Python script was working fine, and was able to properly use the OpenTok Python SDK. I then started adding more debugging log statements and discovered that the call to waitpid() was returning 0, which apparently indicates that no child process has changed state. It's very strange, because it seems that SIGCHLD is being sent and handled, but waitpid() is indicating that no child process has changed state. I'm not sure if that is valid situation which needs to be handled. Perhaps SIGCHLD is sometimes sent for spurious or harmless reasons which should be ignored, and not result in total Kamailio termination. My current workaround is to NOT terminate when SIGCHLD is received and waitpid() indicates that no child process has changed state. In other words, I only terminate when the waitpid() while() loop has been entered at least once due to a return value greater than 0. Does that seem like a change that might make sense in the master branch going forward, or does it seem dangerous somehow? I'm not sure if this is helpful, but the waitid() system call (available since Linux 2.6.9) provides more precise control over which child state changes to wait for. http://manpages.ubuntu.com/manpages/trusty/man2/wait.2.html Thanks for any help.

6 years, 12 months

Query with regard to http_client and http_async_client

by Ramachandran, Agalya (Contractor)

Hi Giacomo, I have few questions with regard to rest client in kamailio. 1) I see there are two modules in kamailio for rest client. http_client, http_async_client. I hope http_client does the http transfer in synchronous way. http_async_client does the http transfer in asynchronous manner. Correct me if am wrong here. 2) I want to achieve https transfers in async way, so choosing http_async_client. Is there a way that kamailio maintains persistent TCP connection pooling for http transfer. I see there is a "workers" parameter in http_async_client. By increasing this number does it result it more http request's handling? 3) Also, I have some questions regarding documentation for module http_async_client in 5.0 version. In the API exposure, it says "http_async_query(url, route_name)". But the example if I want to use POST, it says "http_async_query("http://example.com/test.php", "{'r_uri':'$rU', 'f_uri':'$fU'}", "HTTP_REPLY");" There is a parameter mismatch between the example and the actual function. If I try to use GET query, kamailio service is starting. But if I try to give the POST query with payload, kamailio service is not started. It says, sctp_core_destroy(): SCTP API not initialized. Also I have noticed that, functions like http_append_header(),http_set_method() are removed in 5.0 version, whereas we have this API's is 4.x versions. Is there some issue with the documentation for 5.0 ? Please let me the know the details for the above queries. Regards, Agalya

6 years, 12 months

forwarding multiple times

by hdssdsdsdsfsdf hdssdsdsdsfsdf

Hi all, I'm trying to transmit a CANCEL sip message from one server to multiple other servers (using ds_select_domain and ds_next_domain). Ideally, I would simply use forward() multiple times. The problem is however, that this would apply the changes of forward() multiple times too, for example adding multiple via-headers. I tried to use forward() for the first transmission and then send() for the next ones, but it turns out send() uses the original message to send, and not the message as crafted by forward. As such, it seems I need exactly what's in the middle of these: Either a forward that operates on the original message, or a send that operates on the message as crafter by previous forward. Does anyone know how to achieve this? The only other solution I see is to manually write some forwarding routing, but it seems tedious to craft the via-headers and fix the domain to be forwarded to. Thanks and cheers,

6 years, 12 months

How to eliminate Content-Length:0 from sl_send_reply

by Pranathi Venkatayogi

Hi, How do I eliminate Content-Length:0 from sip reply when using sl_send_reply? I wanted to generate 200 ok, with SDP payload. I appended headers like below. The packet seems ok except there is extra "Content-Length:0", which is causing problems. Any workarounds? The packet being generated is: Note the extra content-length: 0 at the end. SIP/2.0 200 OK Via: SIP/2.0/UDP 10.0.0.12:59404;rport=59404;branch=z9hG4bKPjb7d0391f8f7f479b812f6e5feadfa3c5;received=10.11.200.46 From: "cust1" <sip:cust1@devtranslation.sms-test.cyracom.com>;tag=afcffa277e2a43dc88fafc612f538864 To: <sip:spanish@devtranslation.sms-test.cyracom.com>;tag=37b119f34ca40c158c5b7306e1aa8d72.b73a Call-ID: 7f73e5d03e15425395fac930eae423bd CSeq: 31419 INVITE Content-Type: application/sdp Content-Length: 350 v=0 o=- 3688213899 3688213900 IN IP4 10.99.52.17 s=Blink 1.4.2 (Windows) t=0 0 m=message 2855 TCP/MSRP * c=IN IP4 10.99.52.17 a=path:msrps://10.99.52.17:2855/116701522521345;tcp a=accept-types:message/cpim text/* image/* application/im-iscomposing+xml a=accept-wrapped-types:text/* image/* application/im-iscomposing+xml a=setup:active Content-Length: 0 Code in config is: append_to_reply("Content-Type: application/sdp\r\n"); append_to_reply("Content-Length: 350\r\n"); append_to_reply("\r\n"); append_to_reply("v=0\r\n"); append_to_reply("o=- 3688213899 3688213900 IN IP4 MY_IP_ADDR\r\n"); append_to_reply("s=Blink 1.4.2 (Windows)\r\n"); append_to_reply("t=0 0\r\n"); append_to_reply("m=message 2855 TCP/MSRP *\r\n"); append_to_reply("c=IN IP4 MY_IP_ADDR\r\n"); append_to_reply("a=path:msrps://MY_IP_ADDR:2855/$var(ssessid);tcp\r\n"); append_to_reply("a=accept-types:message/cpim text/* image/* application/im-iscomposing+xml\r\n"); append_to_reply("a=accept-wrapped-types:text/* image/* application/im-iscomposing+xml\r\n"); append_to_reply("a=setup:active\r\n"); sl_send_reply("200", "OK"); Thanks, Pranathi Venkatayogi System Developer II (520) 745-9447 x4466 www.cyracom.com<http://www.cyracom.com/> Join us: [cid:image001.gif@01D1C9C9.C4E8B6D0] <https://www.facebook.com/pages/CyraCom-LLC/134704783312720> [cid:image002.gif@01D1C9C9.C4E8B6D0] <https://twitter.com/cyracom> [cid:image003.gif@01D1C9C9.C4E8B6D0] <http://www.linkedin.com/company/cyracom> [cid:image004.gif@01D1C9C9.C4E8B6D0] <http://www.cyracom.com/blog/> [cid:image005.png@01D1C9C9.C4E8B6D0] DISCLAIMER: This e-mail and any attached content may contain confidential or privileged material delivered for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender immediately by reply e-mail and delete all copies of this message. It is the recipient's responsibility to scan this e-mail and any attachments for viruses. The content of this e-mail message, including any attachments, does not comprise a contract or a portion of a contract, and so does not bind CyraCom International, Inc. or any of its agents or subsidiaries. CyraCom, LLC and Voiance Language Services, LLC are wholly owned subsidiaries of CyraCom International, Inc.

6 years, 12 months

Re: [SR-Users] Kamailio Issues

by Robert Boisvert

Santosh, Looks like you didn't include the mohdir information (see http://kamailio.org/docs/modules/4.4.x/modules/mohqueue.html#dir.parms) or there are no files in that directory. BTW, I rarely use this email address so please address your questions to sr-users(a)lists.kamailio.org. Hope this helps, Bob On Thu, Apr 20, 2017 at 11:26 AM, santosh gupta <santosh.gupta.g(a)gmail.com> wrote: > HI, > > Was working on Kamailio for MohQueue n getting the below error. > Let me know if you can help me. > > I had already checked everything. > 1. Files are located in proper directory. > 2. Files are having proper permissions. > 3. Database is having proper tables. > 4. Tried many versions of Kamailio i.e 4.4,5.0 also 5.0.1 > > ERROR: mohqueue [mohq_db.c:504]: update_mohq_lst(): Queue,Field > (operators,mohdir): Unable to find MOH files > > -------------------- > With Regards > Santosh Gupta > +91 9323043570 >

6 years, 12 months

4.4.5 Shared memory leak with t_suspend/t_continue

by Julia Boudniatsky

Hello all, I need to fork an incoming call to the second destination, after receiving 180 reply from the first destination. I use kamailio version 4.4.5 It working fine, but with shared memory leak. The script part: $avp(00x)=$_s(sip:$var(00x)@$si:$sp;user=phone); if(!is_known_dlg()){ dlg_manage(); } t_relay(); append_branch("$avp(00x)"); if(t_suspend()) { xlog("L_NOTICE","FORK: suspend transaction[$T(id_index):$T(id_label)]\r\n"); } onreply_route [REPLY_TO_SOURCE] { if ($T_reply_code=="180") { t_continue("$T(id_index)", "$T(id_label)", "RELAY_FORK"); } } route[RELAY_FORK] { $ru=$avp(00x); $avp(tu) = $_s(sip:$rU@$td;user=phone); uac_replace_to("$avp(tu)"); remove_hf("Supported"); xlog("L_NOTICE","RELAY_FORK : $rm CSeq[$hdr(CSeq)] branch[$T_branch_idx]\r\n"); t_relay(); } Please find the result of *kamcmd corex.shm_summary* after 300 calls Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: summarizing all alloc'ed. fragments: Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 176 bytes from dialog: dlg_profile.c: set_dlg_profile(574) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 3 size= 264 bytes from dialog: dlg_var.c: new_dlg_var(97) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 3 size= 152 bytes from dialog: dlg_hash.c: dlg_set_leg_info(526) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 3 size= 144 bytes from dialog: dlg_hash.c: dlg_set_leg_info(509) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 2 size= 1184 bytes from dialog: dlg_hash.c: build_new_dlg(441) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 3 size= 24 bytes from dialog: dlg_var.c: new_dlg_var(106) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 3 size= 24 bytes from dialog: dlg_var.c: new_dlg_var(116) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 3 size= 88 bytes from dialog: dlg_hash.c: dlg_set_leg_info(517) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 337 size= 367448 bytes from tm: t_reply.c: relay_reply(1891) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 334 size= 549312 bytes from tm: t_msgbuilder.c: build_local_reparse(344) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 672 size= 1123536 bytes from core: msg_translator.c: build_req_buf_from_sip_req(2154) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 337 size= 505048 bytes from core: sip_msg_clone.c: msg_lump_cloner(978) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 331 size= 14784 bytes from tm: t_reply.c: update_totag_set(312) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 340 size= 3566680 bytes from core: sip_msg_clone.c: sip_msg_shm_clone(494) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 339 size= 5024 bytes from dialog: dlg_handlers.c: dlg_get_iuid_shm_clone(280) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 337 size= 2528256 bytes from tm: h_table.c: build_cell(317) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 331 size= 10096 bytes from tm: t_reply.c: update_totag_set(313) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 2390 size= 315368 bytes from core: usr_avp.c: create_avp(175) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 36480 bytes from core: counters.c: counters_prefork_init(207) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 10944 bytes from sl: sl_stats.c: init_sl_stats_child(125) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 512 bytes from tmx: tmx_pretran.c: tmx_init_pretran_table(90) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 14592 bytes from tm: t_stats.c: init_tm_stats_child(60) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 2736 bytes from kex: pkg_stats.c: pkg_proc_stats_init(79) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 3 size= 88 bytes from core: cfg/cfg_struct.c: cfg_clone_str(130) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 648 bytes from core: cfg/cfg_struct.c: cfg_shmize(217) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from core: pt.c: init_pt(110) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from core: pt.c: init_pt(105) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 7984 bytes from core: pt.c: init_pt(104) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8192 bytes from htable: ht_api.c: ht_init_tables(381) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from cfgutils: cfgutils.c: mod_init(935) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from cfgutils: cfgutils.c: mod_init(929) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from cfgutils: cfgutils.c: mod_init(921) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 131088 bytes from dialog: dlg_hash.c: init_dlg_table(284) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from dialog: dlg_hash.c: init_dlg_table(276) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from dialog: dlg_hash.c: init_dlg_table(269) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from dialog: dlg_hash.c: init_dlg_table(264) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from dialog: dlg_timer.c: init_dlg_timer(57) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 32 bytes from dialog: dlg_timer.c: init_dlg_timer(48) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 312 bytes from dialog: dlg_profile.c: new_dlg_profile(187) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 432 bytes from dispatcher: dispatch.c: reindex_dests(601) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 678 size= 31456 bytes from tm: t_hooks.c: insert_tmcb(137) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 3 size= 32 bytes from dispatcher: dispatch.c: ds_set_attrs(235) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 3 size= 72 bytes from dispatcher: dispatch.c: add_dest2list(351) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 3 size= 360 bytes from core: timer.c: register_timer(1011) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 840 bytes from dispatcher: dispatch.c: add_dest2list(325) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 16 bytes from dispatcher: dispatch.c: init_data(204) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 16 bytes from dispatcher: dispatch.c: init_data(195) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from dispatcher: dispatcher.c: ds_parse_reply_codes(1029) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from dispatcher: dispatcher.c: mod_init(309) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from dispatcher: dispatcher.c: mod_init(307) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from dispatcher: dispatch.c: ds_ping_active_init(102) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from sl: sl_funcs.c: sl_startup(83) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from sl: sl_stats.c: init_sl_stats(110) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 16 bytes from tm: t_hooks.c: init_tmcb_lists(74) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 16 bytes from tm: t_hooks.c: init_tmcb_lists(72) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 2097152 bytes from tm: h_table.c: init_hash_table(467) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 3 size= 96 bytes from core: cfg/cfg_ctx.c: cfg_register_ctx(47) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from core: usr_avp.c: init_avps(90) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from core: usr_avp.c: init_avps(89) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 16384 bytes from core: dst_blacklist.c: init_dst_blacklist(437) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from core: dst_blacklist.c: init_dst_blacklist(430) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 2 size= 96 bytes from core: timer.c: timer_alloc(514) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from core: dns_cache.c: init_dns_cache(366) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 16384 bytes from core: dns_cache.c: init_dns_cache(358) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 16 bytes from core: dns_cache.c: init_dns_cache(351) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from core: dns_cache.c: init_dns_cache(345) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from core: timer.c: init_timer(283) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 16384 bytes from core: timer.c: init_timer(282) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from core: timer.c: init_timer(281) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from core: timer.c: init_timer(280) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from core: timer.c: init_timer(269) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from core: timer.c: init_timer(237) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 278544 bytes from core: timer.c: init_timer(220) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from core: timer.c: init_timer(219) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from core: timer.c: init_timer(206) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 64 bytes from core: cfg/cfg_struct.c: cfg_child_cb_new(830) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from core: cfg/cfg_struct.c: sr_cfg_init(361) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from core: cfg/cfg_struct.c: sr_cfg_init(354) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from core: cfg/cfg_struct.c: sr_cfg_init(347) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from core: cfg/cfg_struct.c: sr_cfg_init(335) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from core: cfg/cfg_struct.c: sr_cfg_init(323) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 232 bytes from htable: ht_api.c: ht_add_table(278) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from pv: pv_shv.c: add_shvar(177) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 64 bytes from pv: pv_shv.c: add_shvar(170) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 80 bytes from pv: ../../lock_alloc.h: lock_set_alloc(70) Apr 24 15:08:53 vm-tkamasy1 /usr/local/sbin/kamailio[2795]: WARNING: fm_status: count= 1 size= 8 bytes from core: mem/shm.c: shm_core_lock_init(153) Thank you for help.

6 years, 12 months

Kamailio SIP Proxy solution

by Hai Bui Duc Ha

Hi all, I'm researching the solution on Kamilio like SIP forward message: - At the moment, the customer has server IP PBX and their clients. - Then, the client just point the SIP Porxy configure to Kamailio. After that, Kamailio will forward to IP PBX and send the event to another server. - Everything will be not changed for customer site. I found the link do the similar thing but it still authenticate on Kamailio: http://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb… Do you have any advice ? Regrads, Hai Bui -- Hai Bui VoIP engineer, Cvoice team, HTK-HCM Office Mobile: +84-165-618-9876

6 years, 12 months

Warnings at apply_changes()

by Diego Nadares

Hi list, I'm converting body message to multipart. Calls establishes ok and Kamailio it's not logging errors but I'm seeing some info and warnings that I don't know it they are correct. Maybe you could tell me if it's normal or if I'm doing something wrong in my script. kamailio[13428]: INFO: <script>: Original content type is application/sdp kamailio[13428]: INFO: <core> [msg_translator.c:1693]: get_boundary(): Content-Type hdr has no params <application/sdp> kamailio[13428]: WARNING: <core> [msg_translator.c:1959]: build_req_buf_from_sip_req(): check_boundaries error kamailio[13428]: INFO: <script>: Appending GTD to body I use the following sintax: route{ ... route(MANAGE_MULTIPART); ... } route[MANAGE_MULTIPART]{ .... if (is_method("INVITE") && !has_totag() && has_body()){ ... xlog("L_INFO", "Original content type is $cT"); set_body_multipart(); *msg_apply_changes();* xlog("L_INFO", "Appending GTD to body"); ... } ... } Invite example: INVITE sip:222222222@172.16.205.122:5060 SIP/2.0 Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-28085-1-0 From: "111111111" <sip:1111111111@172.16.213.21:5060;user=phone>;tag=1 To: <sip:2222222222@172.16.205.122:5060> Call-ID: 1-28085(a)172.16.213.21 CSeq: 1 INVITE Contact: "1111111111" <sip:111111111@172.16.213.21:5060> Max-Forwards: 70 Subject: Performance Test Content-Type: application/sdp Content-Length: 137 v=0 o=user1 53655765 2353687637 IN IP4 172.16.213.21 s=- c=IN IP4 172.16.213.21 t=0 0 m=audio 6000 RTP/AVP 8 a=rtpmap:8 PCMA/8000 As you can see the log says that "Content-Type hdr has no params <application/sdp>" but in the line before says "Original content type is application/sdp". I'm running kamailio 4.4 by the way. Thanks in advance. Diego.

6 years, 12 months

← Newer
1
2
3
4
5
6
7
...
12
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 April 2017