sr-users April 2016

sr-users@lists.kamailio.org

76 participants
114 discussions

BLF: Turning a key on/off without a dialog

by Ali Pey

Hello, I use presence and dialog modules for my BLF keys; however, I have a key (e.g. park) that I need to turn on/off outside a dialog: Certain Invite message would need to cause the BLF key to become busy and another unrelated Invite message would need to turn the BLF key off. What's the best and easiest way to do this? Best regards, Ali Pey

7 years, 12 months

Are sip calls working OK?

by Aloysius Bolskey Clark Donson

Dear Friends, I started to use my sip account few monts ago sip:4095xx@iptel.org It was working OK, but at the end of March I realised that I could not get any calls in my account. I own also a sip account in callcentric and works OK. So my zoiper version seems nothing to do on it Have you changed the setup of the account (iptel)? I got a real US phone number in IPCall associated to my sip account. IPCall is giving up, so that is the reason why the calls made to my real phone numbers ar not being forwarded to my sip account. But I have no idea why my sip:4095xx@iptel.org is not working thanks in advance looking forward your kind answer jose

7 years, 12 months

Using flags in t_branch_timeout() section of failure_route{}

by Marrold

Hi all, I'm having issues using flags in a t_branch_timeout() of failure_route{} A brief summary of the code - onreply_route{ setflag(14); } failure_route { if (t_branch_timeout()) { xlog("L_ALERT","t_branch_timeout()\n$mb"); if (isflagset(14)) { xlog("L_ALERT","isflagset(14) - YES\n$mb"); } } } The call flow is below, t_branch_timeout() is being triggered when the 200 OK is not ACK'd -- INVITE -> <- 100 Trying -- <- 180 Ringing -- <- 200 OK -- <- 200 OK -- <- 200 OK -- <- 200 OK -- I can attempt to create a minimal .cfg if anyone wishes to replicate it, assuming I'm not missing something stupid. Thanks, Matthew

7 years, 12 months

NO RTP when using kamailio on public IP

by Ankitt Sharma

hello, i've been trying to setup my communication setup , everything works fine when i use my kamailio setup within the local network but as soon as i assign a public IP to kamailio , there is no RTP flow between the clients i searched over internet and found that rtpengine module should be used when using the stup on public network ,and tried configureation(with some tweaks) given by https://github.com/caruizdiaz/kamailio-ws i also observed that the call still flows when the two clients are in same network. please help what should i do! thanx in advance! :)

8 years

Kamailio IMS+FHoSS: Error "Visited Network Identity not found, responding with 400"

by Трущенков Алексей

Good afternoon! I use Kamailio from BOX from Article https://www.kamailio.org/w/2016/02/kamailio-ims-getting-started-box/ The client can not register (use Boghe IMS Client as IMS client) i-cscf log 10(1991) INFO: <script>: [REGISTER] from [sip:alice@net1.test] to > [sip:alice@net1.test] > 10(1991) ERROR: <script>: REGISTER (sip:alice@net1.test (10.0.0.10:1173) > to sip:alice@net1.test, 9848450f-c6dd-5b5e-6516-addaf85a9f2f) > 10(1991) ERROR: ims_icscf [registration.c:149]: > I_perform_user_authorization_request(): ERR:I_UAR: Visited Network Identity > not found, responding with 400 > 10(1991) ERROR: tm [t_lookup.c:1497]: t_get_trans_ident(): ERROR: > t_get_trans_ident: no transaction found I would be glad of any help. Thank you. --------------------- Trushenkov Alexey

8 years

Understanding the new interface (kemi) for embedded interpreters

by Daniel-Constantin Mierla

Hello, (cross-posting because the details are useful for both devels and users) Yesterday during the IRC meeting about Kamailio, one group of topics was about Kamailio 5.0, and the new feature of using embedded interpreters for external programming languages was highly debated. So I am trying to clarify some of its aspects. The new framework is referenced as kemi, chosen by me as an abbreviation for Kamaialio EMbedded Interface. We already had embedded interpreters for many years, respectively: - Lua via app_lua module (probably most developed and most used) - Perl via app_perl module (iirc, the oldest embedded interpreter) - Python via app_python (I discovered during the last days that it has quite a lot of features, just not documented -- never used it before) - Java via app_java (this one is a bit of a blackhole for me, never looked at it, don't know what it offers/how it is supposed to be used) - .NET group of languages via app_mono (e.g., C#, but also some variants of JavaScript, Python and maybe even Java) To clarify, an embedded interpreter means that Kamailio is linking to itself the interpreter of that language and kamailio becomes the interpreter of the language. It is not launching the standard interpreter for that language, therefore it is very fast at runtime. Moreover, kamailio is extending the language with new modules, giving access to Kamailio C functions. In other words, for example with Python, Kamailio becomes equivalent to the "python" application plus two extensions (modules) named Router (developed in the past inside app_python) and KSR (developed for kemi). At this moment, the kemi was implemented in app_lua and app_python modules. To understand what is all about, I am going to give an example with a function from maxfwd module. In default kamailio.cfg next statement is present: if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } mf_process_maxfwd_header("10") is the function exported by maxfwd: - https://www.kamailio.org/docs/modules/stable/modules/maxfwd.html#maxfwd.f.m… The parameter can be as a static number (like above) or a number provided via a variable, like next: $var(p) = 10; mf_process_maxfwd_header("$var(p)") The corresponding C code for this config function is: static int w_process_maxfwd_header(struct sip_msg* msg, char* str1, char* str2) { int mfval; if (get_int_fparam(&mfval, msg, (fparam_t*) str1) < 0) { LM_ERR("could not get param value\n"); return -1; } return process_maxfwd_header(msg, mfval); } The function get_int_fparam() is practically returning the int value of the parmeter, no matter it was a static value or a variable, then process_maxfwd_header(...) is executed with the int parameter. The msg is the SIP message structure present mostly everywhere in the C code related to the classic config interpreter. To be used inside the config file, the C function has to be exported via a cmd_export_t structure added to "struct module_exports exports", respectively: static cmd_export_t cmds[]={ ... {"mf_process_maxfwd_header", (cmd_function)w_process_maxfwd_header, 1, fixup_var_int_1, 0, REQUEST_ROUTE}, ... To get the same function in a kemi interpreter (Lua, Python at this moment), following C code was added: static sr_kemi_t sr_kemi_maxfwd_exports[] = { { str_init("maxfwd"), str_init("process_maxfwd"), SR_KEMIP_INT, process_maxfwd_header, { SR_KEMIP_INT, SR_KEMIP_NONE, SR_KEMIP_NONE, SR_KEMIP_NONE, SR_KEMIP_NONE, SR_KEMIP_NONE } }, { {0, 0}, {0, 0}, 0, NULL, { 0, 0, 0, 0, 0, 0 } } }; int mod_register(char *path, int *dlflags, void *p1, void *p2) { sr_kemi_modules_add(sr_kemi_maxfwd_exports); return 0; } The structure sr_kemi_t sr_kemi_maxfwd_exports exports directly the existing function process_maxfwd_header(), which is also executed by the function from kamailio.cfg after resolving the parameter to an int value. In the case of kemi, the Lua or Python will give directly an integer value, so no need for resolving that with a fixup wrapper. The mod_register() function is something already existing, providing a way to execute code when a module was loaded (e.g., is used for many years by modules such as tls, mysql, etc.). In this case it was added, because maxfwd didn't need anything at load time before. Practically, no C code extension was written to maxfwd module from point of view of SIP routing. Just an existing function was exported. Now, what's actually the role of this kemi framework ... The app_lua already exported the kamailio.cfg function mf_process_maxfwd_header() as sr.process_maxfwd() since Kamailio v3.1, see its usage in the tutorial: - https://kb.asipto.com/kamailio:usage:k32-lua-routing#lua_script But a Lua specific wrapper had to be written: - https://github.com/kamailio/kamailio/blob/master/modules/app_lua/app_lua_ex… All the other embedded interpreters would have needed to get a wrapper as well to export this function. That's obviously costing time and maintenance resources. So kemi is a common framework to export C function to any of the embedded interpreters, meaning that once a function is exported from a module, it becomes available to all embedded interpreters, no longer being necessary to write a specif wrapper per interpreter. The app_* module needs a bit of coding to use the kemi exported functions (already done for Lua and Python), but then nothing needs to be done for new exported functions by modules. As a matter of fact, lots of functions can be just exported, as you could see in the example with maxfwd. In some cases, maybe some functions need to be split, so the fixup handling is done separately and then calls a common C function. So, what we had so far: [native kamailio cfg script] <===> [fixup framework for variables] <===> [C implementation of function] The above stays in place, no change to it. What we got extra: [embedded language script] <===> [kemi framework] <===> [C implementation of function] In addition, kemi allows to write the routing blocks all in embedded language. Core parameters, loading modules and modules' parameters stay like so far, but there is no need to write request_route{}, failure_route, etc.. blocks. Some functions with a specific names have to be written in the embedded language script, see more at: - https://www.kamailio.org/wiki/devel/config-engines In several days I expect to be possible to have routing blocks of kamailio-basic.cfg written via kemi interpreters. That will allow testing the performance impact. Right now Lua and Python use different mechanism of exporting Kamailio C functions, the one from Python should be faster, but relies on defining some C wrappers inside the module. Anyhow Lua might be faster as interpreter itself -- and at the end it can just get the same mechanism as Python. app_lua already supports reloading the routing script without restarting kamailio, one of the features asked from time to time. Besides that, of course, a big benefit is the access to a very large set of extensions already available as Lua/Python libraries. Also important, many peoples are already familiar with these languages and there is plenty of good documentation about those languages. The classic/native kamailio.cfg format (and the interpreter for it) stays there -- same common C functions are shared with kemi, so any addition in the future will be visible to everywhere. The native interpreter will remain the option for extreme optimizations for those that deal with enormous amount of SIP traffic (e.g., heavy load balancers), but I expect that at least Lua will be in pair of performances with a registrar deployment. I hope I could shed some light on various aspects of the new framework for embedded interpreters. Expect very soon news about ability to build full routing logic in Lua/Python, hopefully many of you will join to test the results and compare with native alternatives. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, Berlin, May 18-20, 2016 - http://www.kamailioworld.com

8 years

irc devel meeting summary

by Fred Posner

Greetings, Minutes from the recent devel meeting have been posted to the wiki: https://www.kamailio.org/wiki/devel/irc-meetings/2016a-minutes In summary, this was a 3+ hour meeting held on IRC #kamailio -- one of the longer meetings on record. No current "critical" issues were open, and the meeting moved to a discussion of for a testing framework and being able to load as many modules as possible in a running Kamailio system. Olle Johansson suggested a competition for Kamailio World: "The one with a kamailio with most loaded modules running at kamailio-world gets a beer." A discussion then occurred regarding the appropriateness of returning a 200 OK when no data exists during a xmlrpc request. The consensus seemed to side with how we currently return data with the suggestion of moving further discussion to the mailing list. The Kamailio team will be looking to both upgrading the Kamailio servers to Debian Jessie as well as utilizing a "responsive" template for the main website; making the site more mobile/user friendly. Kamailio 5 was discussed with a suggestion for a developers meeting in Stockholm, perhaps in June, to hammer out the framework. Daniel was thanked for moving forward with the Lua routing aspects of Kamailio 5 while ensuring that you will still be able to utilize the config file (as current) without Lua. Additional languages, such as python, will be coming. Daniel will be working on a tutorial for exporting the kamailio.cfg to an embedded interpreter in the future. As part of Kamailio 5, the source tree structure will be improved, most likely utilizing subdirectories to better organize the different elements of the software. There will also be a change in the method of checking the database schema for compatibility with the version of software running. This summary represents just an appetizer of the incredible meeting that took place. The minutes are available for you to read at your leisure and your participation is always encouraged through the mailing lists, IRC, as well as github. The meeting never ends... it just continues on the mailing lists. =) Best regards, Fred Posner http://www.palner.com

8 years

A: Open discussion about Kamailio in about 30min

by Daniel-Constantin Mierla

Hello, long time involved in VoIP and friend of Kamailio, Suzanne Bowen has organized an open discussion about Kamailio on a web platform blah.im. The link of the session is: - https://blab.im/didx-exchange-kamailio-world-talk-on-privacy-scalability-re… It is planned to start at 12:00GMT (13:00 London, 14:00 Berlin), I will join it and I expect that the platform is allowing many to watch and ask questions. Hopefully few other Kamailio folks will join the conversation. Rather short notice here, but if you have something to ask about SIP, VoIP, Kamailio, you should try to participate. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, Berlin, May 18-20, 2016 - http://www.kamailioworld.com

8 years

BYE packet looping and loose routing

by Yasin CANER

8 years

The book of "SIP Routing with Kamailio"

by Jay Li

Dear all, I'm looking for a document/book that explains the kamailio.cfg in detail. I've gone over the suggested study material "SER-Getting Started" which is such a nice book that explains ser.cfg line by line. I know Asipto has published a book named "SIP Routing with Kamailio". Just wondering if "SIP Routing with Kamailio" is written in a similar format when it comes to explain the kamailio.cfg. Hopefully I can get some information about the book before I make the purchase. Thanks. Regards,Jay

8 years

← 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 2016