sr-users

sr-users@lists.kamailio.org

42 participants
37518 discussions

Bad BYE request
by Duarte Rocha 08 Oct '19

08 Oct '19

Greetings, This is a repeated problem, but i have more info now. Please help understand if there is a problem on my code or if there is any kind of Kamailio bug. On the first INVITE of every call i apply uac_replace_from() and uac_replace_to() in order to normalize numeration. I have the restore_mode set as "auto". The original numeration is : To : 351250000000 From : 351211455000 The INVITE is sent to the client with To and From like this and with the Record-Route headers (Kamailio has 2 Ips and inserts 2 Record-Routes) containing vsf and vst parameters to help the future restores : To: <sip:+351250000000@111.111.111.111> From: <sip:+351211455000@111.111.111.111 >;tag=BD583030373631320511EAE6 Record-Route: <sip:111.111.111.111;r2=on;lr;ftag=BD583030373631320511EAE6;tbk_i=2_2_Y;tbk_o=128_11_Y;vsf=AAAAABgGBAMDAAUBBQAJCnNyAwMcHwIdHQsWHwUMOA--;vst=AAAAABgGBAMHDQgJDQECA3RyAwMcHwIdGgQeHAIFOQ--;did=18e.5d62> Record-Route: <sip:111.111.111.111;r2=on;lr;ftag=BD583030373631320511EAE6;tbk_i=2_2_Y;tbk_o=128_11_Y;vsf=AAAAABgGBAMDAAUBBQAJCnNyAwMcHwIdHQsWHwUMOA--;vst=AAAAABgGBAMHDQgJDQECA3RyAwMcHwIdGgQeHAIFOQ--;did=18e.5d62> My client, upon receiving the INVITE, also does some changes in the numeration and sends a 183 reply with the following headers : Record-Route: <sip:111.111.111.111;r2=on;lr;ftag=BD583030373631320511EAE6;tbk_i=2_2_Y;tbk_o=128_11_Y;vsf=AAAAABgGBAMDAAUBBQAJCnNyAwMcHwIdHQsWHwUMOA--;vst=AAAAABgGBAMHDQgJDQECA3RyAwMcHwIdGgQeHAIFOQ--;did=18e.5d62> Record-Route: <sip:111.111.111.111;r2=on;lr;ftag=BD583030373631320511EAE6;tbk_i=2_2_Y;tbk_o=128_11_Y;vsf=AAAAABgGBAMDAAUBBQAJCnNyAwMcHwIdHQsWHwUMOA--;vst=AAAAABgGBAMHDQgJDQECA3RyAwMcHwIdGgQeHAIFOQ--;did=18e.5d62> From: "+351211455000" <sip:I2116446I_500@111.111.111.111 >;tag=BD583030373631320511EAE6 To: <sip:+351250000000@111.111.111.111>;tag=as3e46f684 After Kamailio processes the reply, To and >From are restored to it's original values and the reply is relayed : From: <sip:351211455000@111.111.111.111 >;tag=BD583030373631320511EAE6 To: <sip:351250000000@111.111.111.111>;tag=as3e46f684 Here, the restore works perfectly. By the end of the call the client sends me a BYE request with Route, From and To like this : Route: <sip:111.111.111.111;r2=on;lr;ftag=BD583030373631320511EAE6;tbk_i=2_2_Y;tbk_o=128_11_Y;vsf=AAAAABgGBAMDAAUBBQAJCnNyAwMcHwIdHQsWHwUMOA--;vst=AAAAABgGBAMHDQgJDQECA3RyAwMcHwIdGgQeHAIFOQ--;did=18e.5d62>,<sip:212.13.40.205;r2=on;lr;ftag=BD583030373631320511EAE6;tbk_i=2_2_Y;tbk_o=128_11_Y;vsf=AAAAABgGBAMDAAUBBQAJCnNyAwMcHwIdHQsWHwUMOA--;vst=AAAAABgGBAMHDQgJDQECA3RyAwMcHwIdGgQeHAIFOQ--;did=18e.5d62> From: <sip:+351250000000@111.111.111.111 >;tag=as3e46f684 To: "+351211455000" <sip:I2116446I_500@111.111.111.111 >;tag=BD583030373631320511EAE6 Here, the difference between 183 and BYE seems to be only in the Route\Record-Route are built (2 Headers or one header with 2 uri). Now, there are a couple of problems relaying the BYE that seem to me to be related to auto replace. This BYE message isn't logged on the onsend-route and it logs a couple of errors : ERROR: <core> [core/parser/msg_parser.c:164]: get_hdr_field(): bad to header ERROR: <core> [core/parser/msg_parser.c:337]: parse_headers(): bad header field [To: "+351211455000" <sip:Q4525417L_<:C212.13.38.148>;tag=3DC130303736313205201F18#015#012Call-ID: 020FAAC7] ERROR: dialog [dlg_handlers.c:666]: pre_match_parse(): bad request or missing CALLID/TO hdr :-/ ERROR: <core> [core/parser/parse_addr_spec.c:719]: parse_addr_spec(): unexpected char [<] in status 6: ["+351211455000" <sip:Q4525417L_] . Despite not being logged on onsend_route and creating some errors, the BYE is still relayed like this : From: < sip:351250000000@111.111.111.111>;tag=as3e46f684 To: "+351211455000" <sip:Q4525417L_<:C111.111.111.111>;tag=BD583030373631320511EAE6 This, naturally, generates a "400 Bad Request" reply from the next equipment. I've also logged the $tU values along the code for BYE requests and it always logs the "I2116446I_500", so i don't know if my code can be the cause of this. A couple of questions and comments - What can i do to better debug this issue? I want to be sure if the problem comes from my code of if it is a Kamailio issue. Right now i'm not sure where to look. - Can a request be sent without passing on onsend_route ? I have used this code to "catch" the BYE, which works for other BYEs - if( $rm == "BYE") {xerr("On send : To User = $tU");}

3 2

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

Jump to page:

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