sr-users October 2019

sr-users@lists.kamailio.org

59 participants
86 discussions

SIP-links adjacency
by Oleg Belousov 07 Oct '19

07 Oct '19

Hello. In our setup kamailio perfoms some logic depending on call direction, inbound or outbound. Call direction is identified by 2 SBC IP (IP_inbound/IP_outbound), we currently use for that 2 dispatcher groups and that is working fine. Now number of peer nodes increased from one SBC till few tens, but we still need to keep SIP-links adjacency, meaning that call which arrived from SBC_N IP_inbound need to be submitted via same SBC_N IP_outbound and vice versa. There could be few approaches to implement that requirement, I'm wondering if can use existing dispatcher function/select destination logic to support SIP-links adjacency. -- obelousov.tel

3 4

q_malloc crash on Kamailio 5.2.3 with http_async_query function
by Michal Škuta 07 Oct '19

07 Oct '19

Hello everyone, I am adding some new features to our Kamailio server, one of them is sending HTTP POST request after calls end. We created simple route like this and we are calling it from event_route[dialog_end]: route[HTTP_TEST_CALL_END] { t_newtran(); $http_req(body) = "TEST"; http_async_query("http://192.168.6.23:2080/cdr_http", "HTTP_TEST_REPLY"); } Problem is that Kamailio is crashing on line *http_async_query*, the log from crash: Oct 3 16:13:37 sip_server /opt/ipgate/kamailio/sbin/kamailio[5331]: CRITICAL: <core> [core/mem/q_malloc.c:149]: qm_debug_check_frag(): BUG: qm: prev. fragm. tail overwritten(c0003032, abcdefed)[0x97a7ff3c:0x97a7ff58]! Memory allocator was called from http_async_client: hm_hash.c:82. Fragment marked by http_async_client: hm_hash.c:71. Exec from core/mem/q_malloc.c:384. In older Kamailio 4.4 I am using http_async_query with no problems. I opened issue on GitHub: https://github.com/kamailio/kamailio/issues/2091 I hope that is ok, more logs and core dump is in the issue. Any help or suggestion is welcomed. Sincerely Michal

2 2

using http_async_query
by David Villasmil 05 Oct '19

05 Oct '19

Hello guys, So, i'm using http_async_query to send out requests. It may happen that the request times out, in this case, i would like to try a new destination, i.e. with ds_select (NOT ds_delect_dest or ds_next, because i don't want the $du to be set, since in my case i don't actually have a SIP packet). Is is possible to get the original http request url in the http_async_query timeout route? Thanks! Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

1 1

storing vars in htable
by David Villasmil 05 Oct '19

05 Oct '19

Hello guys, I'm storing some data in an htable, like so: $var(http_query) = "/default/en_US/send.html?u=user&p=pass&l=$var(next_channel)&n=$var(to)&m=$var(message)"; then i need to store it: $sht(http_requests=>$http_req_id) = $var(http_query); But what's stored is the actual vars, not the the values, it's stored like: sh store: /default/en_US/send.html?u=user&p=pass&l=$var(next_channel)&n=$var(to)&m=$var(message) Why is that? shouldn't the vars be parsed? Thanks Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

2 2

Re: [SR-Users] Call limit through shared database
by Olli Attila 04 Oct '19

04 Oct '19

Hello Henning, I tried the dialog profile sharing with dmq&dialog modules and now the syncing works between the two kam nodes. Thank you! Is there a way to keep the dialog profiles persistent (load from db if kam restarts)? I was thinking a scenario where kam1 has already the call limit maxed out and kam2 suddenly reboots and after reboot, kam2 should be aware of dialogs on kam1 to be able to limit calls again correctly. Cheers, Olli

3 3

Re: [SR-Users] Call limit through shared database
by Olli Attila 04 Oct '19

04 Oct '19

Hello, I had the following enabled in db_mode param and now it is actually working: *1 - REALTIME* - any dialog information changes will be reflected into the database immediately. Restarting either of the kam1 or kam2 proxies "on the fly" will result in retrieving dialog profiles correctly from database. Cheers, Olli

1 0

Record-Route management
by Duarte Rocha 03 Oct '19

03 Oct '19

Greetings, I have multiple IPs in my Kamailio. In some scenarios, the caller and the called connect to different IPs and in others, they use the same IP. Currently i'm running with the RR's module "enable_double_rr" parameter set so i can have one Record-Route for each IP used on the call. However, in the scenario that both caller and called have the same IP, i would like to only have on Record-Route in order to save on the pactet's size. Is this possible to have those two scenarios on the same Kamailio ? Best Regards

2 2

string manipulation
by David Villasmil 03 Oct '19

03 Oct '19

Hello guys, I'm receiving an http request via xhttp, something like: http://ip.com/request?value1=123&value2=2313&value3... Is it possible to get those values somehow? I also have a suri coming from a ds_select in _dsdst_, I need to get the host from that _dsdst_ Any way of doing this? Thanks all Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

2 2

Get destination out of _dsdst_
by David Villasmil 03 Oct '19

03 Oct '19

Hello guys, I've never used "ds_select" as opposed to "ds_select_dst", and i would like to get the actual destination out of _dsdst_ I've got modparam("dispatcher", "xavp_dst", "_dsdst_") and then i'm trying to do: if(!ds_select("100", "4")) { send_reply("404", "No destination"); exit; }else{ xlog("L_ERR", "[XHTTP]: The next destination for SMS is: [$xavp(_dsdst_)]\n"); ds_mark_dst("d"); } But that's coming up with The next destination for SMS is: [<<xavp:0x7fbe87acdbf0>>] I need to get the actual ip address out of the struct. Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

2 2

Development is open for future release of v5.4.x series
by Daniel-Constantin Mierla 03 Oct '19

03 Oct '19

Hello, the branch 5.3 was created late last evening, therefore the master branch is open for adding new features, to be part of future release series v5.4.x. Any bug fix committed to master that applies to 5.3.x or older stable branches should be backported as usual with "git cherry-pick -x ..." to appropriate branches like 5.3 or 5.2. Expect that v5.3.0 will be released in a few weeks from now. Based on the workflow used during the past years, the next future release v5.4.0 should be out after another 8-10 months of development, plus 1-2 months of testing, so sometime in close to the end of spring 2020 or afterwards. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training, Oct 21-23, 2019, Berlin, Germany -- https://asipto.com/u/kat

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2026

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 October 2019