sr-dev May 2019

sr-dev@lists.kamailio.org

29 participants
306 discussions

[kamailio/kamailio] Siptrace patch review (#1955)

by Daniel-Constantin Mierla

### Description A patch was pushed to master branch to enable use of trace_type in the ki_sip_trace_dst_cid_flag(), following the latest additions to the module. It seemed that the trace type was used only for kamailio.cfg functions, because inside ki_sip_trace_dst_cid_flag() the trace_type was parsed and stored in local variable, but it was not used further. I open this issue for review, to be sure something was not overlooked, the commit is: * e8d765610c6926cc6cb4dfa490595214a3680f97 @ionutionita92 - can you have a look and eventually do some tests to be sure it still works as expected for kamailio.cfg functions? There is one more aspect to clarify. The trace info structure is alocated in shared memory, but some of its fields (duplicate uri and correlation id) were set to addresses of function parameters/local variables. The code was relocated and now is at the following lines: * https://github.com/kamailio/kamailio/blob/master/src/modules/siptrace/siptr… Is it safe to do it like this? Are the fields used in this case only in current process and the callbacks use the variant stored in AVP? Speaking of serializing to a string stored in AVP, it might be better to just have a structure compacted with all content in shared memory and stored in an XAVP -- the xavp can store a pointer and also have in its structure the callback to free the pointer.  ### Troubleshooting #### Reproduction  #### Debugging Data  ``` (paste your debugging data here) ``` #### Log Messages  ``` (paste your log messages here) ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` Git Master Branch ``` * **Operating System**:  ``` (paste your output here) ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1955

4 years, 11 months

git:5.2:2d2b9936: htable: fix a possible null pointer dereference in dmq startup error case

by Henning Westerholt

Module: kamailio Branch: 5.2 Commit: 2d2b993673d0296e6d9c08ff78b73341e407a37a URL: https://github.com/kamailio/kamailio/commit/2d2b993673d0296e6d9c08ff78b7334… Author: Henning Westerholt <hw(a)skalatan.de> Committer: Henning Westerholt <hw(a)skalatan.de> Date: 2019-05-31T12:57:56+02:00 htable: fix a possible null pointer dereference in dmq startup error case (cherry picked from commit 6f0b67b675dd18dce60fa3e5a4ece063216bbab5) --- Modified: src/modules/htable/ht_dmq.c --- Diff: https://github.com/kamailio/kamailio/commit/2d2b993673d0296e6d9c08ff78b7334… Patch: https://github.com/kamailio/kamailio/commit/2d2b993673d0296e6d9c08ff78b7334… --- diff --git a/src/modules/htable/ht_dmq.c b/src/modules/htable/ht_dmq.c index 1f27e97684..26c6eb859a 100644 --- a/src/modules/htable/ht_dmq.c +++ b/src/modules/htable/ht_dmq.c @@ -588,11 +588,11 @@ int ht_dmq_handle_sync(srjson_doc_t* jdoc) { if(ht==NULL) { LM_WARN("unable to get table %.*s\n", htname.len, (htname.s)?htname.s:""); - } - - if (ht_set_cell_ex(ht, &cname, type, &val, 0, expire - now) < 0) { - LM_WARN("unable to set cell %.*s in table %.*s\n", - cname.len, cname.s, ht->name.len, ht->name.s); + } else { + if (ht_set_cell_ex(ht, &cname, type, &val, 0, expire - now) < 0) { + LM_WARN("unable to set cell %.*s in table %.*s\n", + cname.len, cname.s, ht->name.len, ht->name.s); + } } }

4 years, 11 months

git:master:6f0b67b6: htable: fix a possible null pointer dereference in dmq startup error case

by Henning Westerholt

Module: kamailio Branch: master Commit: 6f0b67b675dd18dce60fa3e5a4ece063216bbab5 URL: https://github.com/kamailio/kamailio/commit/6f0b67b675dd18dce60fa3e5a4ece06… Author: Henning Westerholt <hw(a)skalatan.de> Committer: Henning Westerholt <hw(a)skalatan.de> Date: 2019-05-31T12:42:21+02:00 htable: fix a possible null pointer dereference in dmq startup error case --- Modified: src/modules/htable/ht_dmq.c --- Diff: https://github.com/kamailio/kamailio/commit/6f0b67b675dd18dce60fa3e5a4ece06… Patch: https://github.com/kamailio/kamailio/commit/6f0b67b675dd18dce60fa3e5a4ece06… --- diff --git a/src/modules/htable/ht_dmq.c b/src/modules/htable/ht_dmq.c index 1f27e97684..26c6eb859a 100644 --- a/src/modules/htable/ht_dmq.c +++ b/src/modules/htable/ht_dmq.c @@ -588,11 +588,11 @@ int ht_dmq_handle_sync(srjson_doc_t* jdoc) { if(ht==NULL) { LM_WARN("unable to get table %.*s\n", htname.len, (htname.s)?htname.s:""); - } - - if (ht_set_cell_ex(ht, &cname, type, &val, 0, expire - now) < 0) { - LM_WARN("unable to set cell %.*s in table %.*s\n", - cname.len, cname.s, ht->name.len, ht->name.s); + } else { + if (ht_set_cell_ex(ht, &cname, type, &val, 0, expire - now) < 0) { + LM_WARN("unable to set cell %.*s in table %.*s\n", + cname.len, cname.s, ht->name.len, ht->name.s); + } } }

4 years, 11 months

[kamailio/kamailio] debian official package repository made by kamailio (#1970)

by xevilstar

Since debian excludes some modules from the repo, I'd love to have an official debian repository for buster and stretch with all modules to add to my /etc/apt/sources.list -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1970

4 years, 11 months

Additional headers on a dispatcher options ping

by Tim Chubb

Hi Is there any mechanism to add a contact and rr headers to the option messages generated by dispatcher? I have a need for both headers to be present otherwise the message gets rejected at the proxy im trying to connect to, the content of the headers in my use case is the from address, so would seem trivial (in so far I know enough c to just about follow what's going on in the code, but wouldn't know where to start to add the functionality) to add using the existing from attribute and a pair of additional modparams to enable this functionality, if its not already possible Currently I have a workaround by generating the pings in asterisk and routing as usual, but would really prefer to not reinvent the wheel and use dispatcher as I do with other trunks and services mainly for consistency and keeping what is essentially a routing issue out of the application stack, as apart from the missing headers dispatchers functionality is exactly what I need. Any suggestions? Tim.

4 years, 11 months

git:master:01795ee7: Makefile.groups: add new module app_lua_sr to lua group

by Henning Westerholt

Module: kamailio Branch: master Commit: 01795ee7f909519814fc8047480c1c436657c505 URL: https://github.com/kamailio/kamailio/commit/01795ee7f909519814fc8047480c1c4… Author: Henning Westerholt <hw(a)skalatan.de> Committer: Henning Westerholt <hw(a)skalatan.de> Date: 2019-05-30T17:29:20+02:00 Makefile.groups: add new module app_lua_sr to lua group --- Modified: src/Makefile.groups --- Diff: https://github.com/kamailio/kamailio/commit/01795ee7f909519814fc8047480c1c4… Patch: https://github.com/kamailio/kamailio/commit/01795ee7f909519814fc8047480c1c4… --- diff --git a/src/Makefile.groups b/src/Makefile.groups index 90f62e0127..229b3fe8d8 100644 --- a/src/Makefile.groups +++ b/src/Makefile.groups @@ -115,7 +115,7 @@ mod_list_presence=presence presence_conference presence_dialoginfo \ # - modules depending on lua library -mod_list_lua=app_lua +mod_list_lua=app_lua app_lua_sr # - modules depending on perl library mod_list_perldeps=app_perl db_perlvdb

4 years, 11 months

New Approach Of Relaying RTP (Media) In TURN

by Mojtaba

Hello Everyone, Since last my email about optimization hiops module for kamailio, I am thinking about new approach of relaying RTP (media) in Kamailio. I know there are some modules like RTPEngine, RTPProxy and rtp_media_server in Kamailio. All those modules are in TURN concept of NAT-Traversal in vioce over ip networks. Suppose there is no needed for transcoding in some calls, then those modules get RTP packets from one hand and relay them to another hand. This activities (with no transcoding) could be done by just forwarding RTP-packet in third level of networks,too. Just like as connection tracking have been doing in Linux Kernel. The RTPEngine use Linux Kernel, But it is different from my own idea. Actually i have written another module in Kamailio (light-rtp-engine or lre) for checking this concept. it works great.It increase concurrent of calls rather than other modules in the same situation (no transcoding situation). Now i want to integrate this module with all other RTP-engine module in Kamailio, For example in some situation that the call no need for transcoding, the module runs as upper layer on other RTP modules and active forwarding packet by add new rule in Linux Kernel connection tracking. Now i need to get some idea of working this module with other RTP module in Kamailio. Do you have any idea in regard of this module works as upper layer on other RTP-modules? Do you have better idea of using this new approach of relaying RTP in Kamailio? With Best Regards. -- --Mojtaba Esfandiari.S

4 years, 11 months

$fU pv Assign New Value Isnt Rewrite old value

by Cléviton Mendes de Araújo

Hi,Kamailio Community Is there a bug when we assign new value to $fU pseudo-variable multi time? My scenery is according below: In a point on config file, let us that $fU value is: 7777. When I do assign: ..... $fU = "5555" + $fU; ### Here $fU = 55557777 ..... In another point, let us that value $sht(htble=>$var(nnnn)) hold is: 44444444. And I do: ..... $fU = $sht(htble=>$var(nnnn)); #### Here, it seems that this is happening $fU = 5555777744444444 ..... When I turn on ngrep analysis, I catch From header: ................. ................. From: "User Name" <sip:5555777744444444@IP-Address> ................. ................. This two assignments are realizing on same route block. So, it seems to be a bug. Best Regards, CMA

4 years, 11 months

RFC: split out old sr api from app_lua

by Daniel-Constantin Mierla

Hello, I am considering to split the app_lua module in order to move the older style API available under Lua 'sr' module in a dedicated module (like app_lua_sr). Later this module can be obsoleted and removed, once we know that everything there is covered by KEMI KSR Lua module. In this way, we make it more clear that KSR is the preferred API to use as well have the app_lua smaller, for those using only KSR and not needing 'sr' API. Therefore I am starting the discussion to see if anyone has something against or other suggestions. I cc-ed sr-dev to make developers aware, but I think the best place for discussion is sr-users, being related to how Kamailio is used, therefore reply only to sr-users. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

4 years, 11 months

git:master:1a2a4fde: modules: readme files regenerated - app_lua ... [skip ci]

by Kamailio Dev

Module: kamailio Branch: master Commit: 1a2a4fdef4d745407c917675782c9e28754a2832 URL: https://github.com/kamailio/kamailio/commit/1a2a4fdef4d745407c917675782c9e2… Author: Kamailio Dev <kamailio.dev(a)kamailio.org> Committer: Kamailio Dev <kamailio.dev(a)kamailio.org> Date: 2019-05-29T14:02:05+02:00 modules: readme files regenerated - app_lua ... [skip ci] --- Modified: src/modules/app_lua/README --- Diff: https://github.com/kamailio/kamailio/commit/1a2a4fdef4d745407c917675782c9e2… Patch: https://github.com/kamailio/kamailio/commit/1a2a4fdef4d745407c917675782c9e2…

4 years, 11 months

← Newer
1
...
6
7
8
9
10
11
12
...
31
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev May 2019