[SR-Users] Re: Bug in htable in 5.8.0
Thanks Daniel, I’ll give that a try. Brooks Bridges Sr. Developer [https://files.skyetel.com/logo.png] Direct: (888) 444‑ Office: (561) 453‑4085 Email: bbrid...@skyetel.com 902 Clint Moore Road Suite 206 Boca Raton, FL 33487 www.skyetel.com From: Daniel-Constantin Mierla Sent: Thursday, March 14, 2024 23:16 To: Kamailio (SER) - Users Mailing List Cc: Brooks Bridges Subject: Re: [SR-Users] Bug in htable in 5.8.0 Hello, On 15.03.24 00:15, Brooks Bridges via sr-users wrote: We have some scripts that are setting values in an htable for various things, one of which is to disable options replies to take a system “out of service”. We discovered today upon deploying 5.8.0 that the “htable.seti” command appears to be broken. [root@ip-10-52-42-102 ~]# kamcmd htable.seti system_settings option_pings_off 1 error: 500 - Not enough parameters (htable name, key name and value) however if we do htable.sets it works fine (although not an integer so it’s breaking our shutdown scripts). [root@ip-10-52-42-102 ~]# kamcmd htable.sets system_settings option_pings_off 1 Ok. Key set to new value. [root@ip-10-52-42-102 ~]# I’ve looked through the commit history for htable and haven’t found anything that really stands out as a possible issue, so can the gurus please take a look? the problem should be with kamcmd+ctl, not htable, use kamctl (or kamcli) instead: kamctl rpc htable.seti system_settings option_pings_off 1 (kamcli rpc htable.seti system_settings option_pings_off 1) I will look into kamcmd/ctl, likely is related to conversion of values, many fields are now long instead of int and kamcmd is not much maintained, it uses a custom (undocumented) binary-rpc protocol and none of its original developers is active. Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com Kamailio World Conference, April 18-19, 2024, Berlin -- kamailioworld.com Confidentiality Notice: This e-mail, and any attachment to it, contains privileged and confidential information intended only for the use of the individual(s) or entity named on the e-mail. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that reading this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: topology hiding with active dispatcher ip
thanks
because of "There is also a limitation regarding the use of the
“msg_apply_changes()” function together with the “uac_replace_*”
functions for messages that are loose-routed (e.g. Re-INVITE requests).
In this case you need to call the “loose_route()” function after the
replace and msg_apply_changes. Otherwise Kamailio can create replies
with wrong From/To headers (e.g. for the 100 - Trying reply in the
Re-INVITE example)."
can you confirm the correct practice is
...
ds_select_dst(TRUNK, "6");
uac_replace_to("sip:" + $tU + "@" + $dd);
msg_apply_changes();
loose_route();
...
record_route();
xlog("L_NOTICE", "tu $tu \n");
route(RELAY);
or is it better use restore_mode =AUTO + dialog ?
Marek
Dne 2024-03-11 v 19:32 Alex Balashov via sr-users napsal(a):
You can obtain the destination set IP from $dd, or $(du{uri.host}). However,
you can't just modify the To URI like that.
You will need to do it in a way that doesn't break standards-based proscriptions about
what a proxy can do, otherwise endpoint A can look at the modified header received in
responses from endpoint B and say, "I didn't send that!"
Kamailio provides such a mechanism. In brief, it conceals the in-flight
alterations to the To URI from endpoint A:
https://kamailio.org/docs/modules/5.8.x/modules/uac.html#uac.f.uac_replace_to
-- Alex
On 11 Mar 2024, at 12:43, marek via sr-users
wrote:
hi,
i have kamailio acting as SBC
i need hide topology like this
ds_select_dst(DSP_GRP_TRUNK, "6");
$tu = $(tu{re.subst,/PRIVATE_IP/IP_OF_CURRENT_SELECTED_DISPATCHER/g});
what is best way for IP extraction from $du?
thanks
Marek
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
[SR-Users] Re: Need guidance on Teams interop with Kamailio
Your Kamailio is using the RURI for routing the BYE and not RR header.
My tip is to xlog your Kamailio config in order to see if the subsequent BYE
request will run the loose_route function inside your route[WITHINDLG].
if (loose_route()) {
if (is_method("BYE")) {
xlog("L_INFO","Running loose route for subsequent BYE request from $si : $sp
\n");
}
I also recommend not to remove any record route headers when engaging with MS
Teams - so do not remove any RR header and make sure your FreePBX include
record route header originally received from Teams.
Regarding the call disconnect: Might be that the corresponding ACK or the 200
OK (depending on Teams being UAC/UAS`) is not handled from MS Teams side.
Again, make sure not to replace to much of the headers received from Teams
apart from what is mentioned in the MS Teams Kamailio guide.
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
