Aloha,
I'm experiencing this internal DNS problem with Kamailio, can't seem to
figure out what's causing it. Maybe someone can help.
Essentially, from time to time (one or two times a day) this situation
happens, starting with logs:
linux kamailio[773]: ERROR: uac [uac_reg.c:1163]: uac_reg_send(): failed to
send request for [some-uuid]
linux kamailio[773]: ERROR: <core> [core/resolve.c:1730]:
sip_hostport2su(): could not resolve hostname: "my.domain.net"
linux kamailio[773]: ERROR: tm [ut.h:309]: uri2dst2(): failed to resolve "
my.domain.net"
linux kamailio[773]: ERROR: tm [uac.c:480]: t_uac_prepare(): no socket found
# Do a Kamailio internal DNS lookup, no results found???
root@linux:~# kamcmd dns.lookup a my.domain.net
error: 400 - Not found
# Do a system DNS lookup. All good.
root@linux:~# dig my.domain.net
;; QUESTION SECTION:
;my.domain.net. IN A
;; ANSWER SECTION:
my.domain.net. 18000 IN A 192.168.0.1
# Delete internal Kamailio DNS record
root@linux:~# kamcmd dns.delete_a my.domain.net
# Lookup again right away. It's there, problem fixed. Why??
root@linux:~# kamcmd dns.lookup a my.domain.net
{
name: my.domain.net
type: A
size_bytes: 120
reference_counter: 2
permanent: no
expires: 7674
last_used: 0
negative_entry: no
records: {
{
rr_idx: 0
rr_ip: 192.168.0.1
rr_permanent: no
rr_expires: 7674
}
}
}
Hello,
I have some questions about dispatcher's behavior. I noticed that when I first ds_select_dst() a specific dispatcher group ID, ds_next_dst() will cycle through the active destinations in that group. When it reaches the end of the destinations in the group, it does not return "false", instead it starts to return destinations that are not a part of that group, ie. those destinations which are listed prior to the selected group in the dispatcher.list file. Is this the expected behavior? I've observed it on kamailio 5.3 and 5.5 releases.
My dispatcher.list:
# Group 1
1 sip:127.0.0.1:5071;transport=udp 8 0
# Group 2
2 sip:127.0.0.1:5072;transport=udp 8 0
# Group 3
3 sip:127.0.0.1:7010;transport=udp 8 0
3 sip:127.0.0.1:7011;transport=udp 8 0
3 sip:127.0.0.1:7012;transport=udp 8 0
# Group 4
4 sip:127.0.0.1:5071;transport=udp 8 0
4 sip:127.0.0.1:5072;transport=udp 8 0
I have the following in failure_route (excerpt):
$var(dsFoundDestination) = 0;
if (t_any_replied())
{
xavp_params_implode("_dsdst_", "$var(dsDestinations)");
xlog("L_INFO", "FAILURE ROUTE: Already have replies on this transaction. Selecting next destination from: [$var(dsDestinations)]");
if (ds_next_dst())
{
xavp_params_implode("_dsdst_", "$var(dsDestinations)");
xlog("L_INFO", "FAILURE ROUTE: Next destination selected: [$du] from [$var(dsDestinations)]");
$var(dsFoundDestination) = 1;
}
}
else if (ds_select_dst("3", "8")) // Dispatcher Group 3
{
xlog("L_INFO", "FAILURE ROUTE: Did not find any replies on this transaction. Selected destination: [$du]");
$var(dsFoundDestination) = 1;
}
if ($var(dsFoundDestination))
{
$var(logString) = "FAILURE ROUTE: Relayed to [" + $du + "]";
if (t_relay())
{
xlog("L_INFO", "$var(logString)");
}
}
Produces the following logs:
FAILURE ROUTE: Did not find any replies on this transaction. Selected destination: [sip:127.0.0.1:7012;transport=udp]
FAILURE ROUTE: Relayed to [sip:127.0.0.1:7012;transport=udp]
FAILURE ROUTE: Already have replies on this transaction. Selecting next destination from: [grp=3;uri=sip:127.0.0.1:7012;transport=udp;]
FAILURE ROUTE: Next destination selected: [sip:127.0.0.1:7011;transport=udp] from [grp=3;uri=sip:127.0.0.1:7011;transport=udp;]
FAILURE ROUTE: Relayed to [sip:127.0.0.1:7011;transport=udp]
FAILURE ROUTE: Already have replies on this transaction. Selecting next destination from: [grp=3;uri=sip:127.0.0.1:7011;transport=udp;]
FAILURE ROUTE: Next destination selected: [sip:127.0.0.1:7010;transport=udp] from [grp=3;uri=sip:127.0.0.1:7010;transport=udp;]
FAILURE ROUTE: Relayed to [sip:127.0.0.1:7010;transport=udp]
FAILURE ROUTE: Already have replies on this transaction. Selecting next destination from: [grp=3;uri=sip:127.0.0.1:7010;transport=udp;]
FAILURE ROUTE: Next destination selected: [sip:127.0.0.1:5072;transport=udp] from [grp=2;uri=sip:127.0.0.1:5072;transport=udp;]
FAILURE ROUTE: Relayed to [sip:127.0.0.1:5072;transport=udp]
FAILURE ROUTE: Already have replies on this transaction. Selecting next destination from: [grp=2;uri=sip:127.0.0.1:5072;transport=udp;]
FAILURE ROUTE: Next destination selected: [sip:127.0.0.1:5072;transport=udp] from [grp=2;uri=sip:127.0.0.1:5072;transport=udp;]
FAILURE ROUTE: Relayed to [sip:127.0.0.1:5072;transport=udp]
FAILURE ROUTE: Already have replies on this transaction. Selecting next destination from: [grp=2;uri=sip:127.0.0.1:5072;transport=udp;]
FAILURE ROUTE: Next destination selected: [sip:127.0.0.1:5071;transport=udp] from [grp=1;uri=sip:127.0.0.1:5071;transport=udp;]
FAILURE ROUTE: Relayed to [sip:127.0.0.1:5071;transport=udp]
I want to stop the loop once there are no more active destinations in group 3. Is the solution simply to check that the selected destination is part of the desired group and stop processing if it is not?
Thanks for your time.
Hello,
Kamailio SIP Server v5.7.2 stable release is out.
This is a maintenance release of the latest stable branch, 5.7, that
includes fixes since the release of v5.7.1. There is no change to
database schema or configuration language structure that you have to do
on previous installations of v5.7.x. Deployments running previous v5.7.x
versions are strongly recommended to be upgraded to v5.7.2.
For more details about version 5.7.2 (including links and guidelines to
download the tarball or from GIT repository), visit:
* https://www.kamailio.org/w/2023/09/kamailio-v5-7-2-released/
RPM, Debian/Ubuntu packages will be available soon as well.
Many thanks to all contributing and using Kamailio!
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - www.kamailioworld.com
Hello,
I am considering to release Kamailio v5.7.2 (out of branch 5.7) this
week (likely on Wednesday or Thursday, Sep 27/28, 2023). If anyone is
aware of issues not yet on the bug tracker, report them there asap in
order to have a better chance to be fixed.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - www.kamailioworld.com
Hello Kamailio Community,
I'm currently working on a project that involves complex SIP routing and handling. I've encountered some difficulties while using change_reply_status, and append_hf functions in failure_route route in Kamailio. Although the documentation does provide guidance, the behaviors I am experiencing aren't aligning with the expected outcomes.
Issue 1: failure_route
I've set up a failure_route to handle specific SIP response codes (>4xx). However, I've observed that it get trigered and lunched, but I can't use change_reply_status or append_hf, I was using this first in onreply_route.
Issue 2: change_reply_status
I tried to use the change_reply_status function to modify the status of SIP replies, but it raises an error that this command cannot be executed here.
Issue 3: append_hf
I've also attempted to use append_hf in my failure_route block to add headers to replies, but the headers are not being added as expected.
As a workaround, I've been using send_reply and append_to_reply for adding custom headers, and they seem to be working as expected. However, I found some old messages in kamailio mailing list, I can summerize what I learned like this ```
#Functions and Context
- append_hf(): Adds a header to the currently processed SIP message. If you are in a route {...} block, then this adds the header to the request. If you are in an onreply_route, it adds the header to the reply. This function always acts on the message currently under scrutiny.
- append_to_reply(): This function is used to add a header to a reply that will be generated by Kamailio at a later time. This function only affects replies generated by Kamailio itself and is not applicable for messages that are simply being forwarded.
#Contexts
- route {...}: This is typically where the incoming SIP request gets processed. Here, append_hf() will add headers to that request, and append_to_reply() will add headers to any replies that Kamailio might generate for this request.
- onreply_route: This is where incoming SIP replies are processed. Here, append_hf() will act on the reply, not the request.
``` I'd like to know if there is a way to handle sip replies in failure_route, because send_reply make a new reply from kamailio, instead I want to keep some important headers from the original reply.
I'd appreciate any insights or guidance the community can offer.
Best regards,
Hello Kamailio,
Is it possible to use RTPengine with a single UDP port for all calls instead of a range of ports?
For example, when an invite is received or sent, the offered SDP for RTPengine is to receive RTP packets on a single port that is the same for all other calls, so that on firewalls only one port is to be opened.
Hello all,
I have my rtpengine configured to use ports 20000 - 50000 for RTP in
rtpengine.conf.
Now i want to able to select the port or the port range in a call by call
basis. Is that possible?
I've tried to use "media-address" flag on rtpengine_manage but i wasn't
successful.
Thanks in advance,
Cheers,
Duarte Rocha
Hello!
We had several crashs of Kamailio (5.3.4) in the last weeks. Each time, the
last logs are:
/usr/local/sbin/kamailio[20942]: CRITICAL: <core> [core/forward.c:347]:
get_send_socket2(): unsupported proto 0 (*)
/usr/local/sbin/kamailio[20966]: CRITICAL: <core> [core/forward.c:347]:
get_send_socket2(): unsupported proto 111 (unknown)
When we look to the coredump, here below the first traces:
(gdb) bt
#0 0x00007f70131b3d91 in prepare_new_uac (t=0x7f6fe1d45340,
i_req=0x7f7016fbe208, branch=0, uri=0x7fff37142fa0, path=0x7fff37142f80,
next_hop=0x7f7016fbe480, fsocket=0x0,
snd_flags=..., fproto=0, flags=2, instance=0x7fff37142f70,
ruid=0x7fff37142f60, location_ua=0x7fff37142f50) at t_fwd.c:463
#1 0x00007f70131b7c42 in add_uac (t=0x7f6fe1d45340, request=0x7f7016fbe208,
uri=0x7f7016fbe480, next_hop=0x7f7016fbe480, path=0x7f7016fbe848, proxy=0x0,
fsocket=0x0,
snd_flags=..., proto=0, flags=2, instance=0x7f7016fbe858,
ruid=0x7f7016fbe870, location_ua=0x7f7016fbe880) at t_fwd.c:805
#2 0x00007f70131bfebd in t_forward_nonack (t=0x7f6fe1d45340,
p_msg=0x7f7016fbe208, proxy=0x0, proto=0) at t_fwd.c:1667
#3 0x00007f701316cf44 in t_relay_to (p_msg=0x7f7016fbe208, proxy=0x0,
proto=0, replicate=0) at t_funcs.c:332
#4 0x00007f70131a3a11 in _w_t_relay_to (p_msg=0x7f7016fbe208, proxy=0x0,
force_proto=0) at tm.c:1689
#5 0x00007f70131a4c51 in w_t_relay (p_msg=0x7f7016fbe208, _foo=0x0,
_bar=0x0) at tm.c:1889
#6 0x00000000005a1f57 in do_action (h=0x7fff37143d90, a=0x7f7016bd1b10,
msg=0x7f7016fbe208) at core/action.c:1071
#7 0x00000000005aeb1e in run_actions (h=0x7fff37143d90, a=0x7f7016bd1b10,
msg=0x7f7016fbe208) at core/action.c:1576
#8 0x00000000005af1df in run_actions_safe (h=0x7fff37146e90,
a=0x7f7016bd1b10, msg=0x7f7016fbe208) at core/action.c:1640
#9 0x000000000066aa50 in rval_get_int (h=0x7fff37146e90,
msg=0x7f7016fbe208, i=0x7fff37144238, rv=0x7f7016bd1e60, cache=0x0) at
core/rvalue.c:915
#10 0x000000000066f000 in rval_expr_eval_int (h=0x7fff37146e90,
msg=0x7f7016fbe208, res=0x7fff37144238, rve=0x7f7016bd1e58) at
core/rvalue.c:1913
#11 0x000000000066f453 in rval_expr_eval_int (h=0x7fff37146e90,
msg=0x7f7016fbe208, res=0x7fff371446ec, rve=0x7f7016bd2588) at
core/rvalue.c:1921
#12 0x00000000005a1a1d in do_action (h=0x7fff37146e90, a=0x7f7016bd2e08,
msg=0x7f7016fbe208) at core/action.c:1047
#13 0x00000000005aeb1e in run_actions (h=0x7fff37146e90, a=0x7f7016bcbd20,
msg=0x7f7016fbe208) at core/action.c:1576
#14 0x000000000059e97d in do_action (h=0x7fff37146e90, a=0x7f7016ef19b8,
msg=0x7f7016fbe208) at core/action.c:695
#15 0x00000000005aeb1e in run_actions (h=0x7fff37146e90, a=0x7f7016e3f578,
msg=0x7f7016fbe208) at core/action.c:1576
#16 0x000000000059e97d in do_action (h=0x7fff37146e90, a=0x7f7016c220a0,
msg=0x7f7016fbe208) at core/action.c:695
#17 0x00000000005aeb1e in run_actions (h=0x7fff37146e90, a=0x7f7016c220a0,
msg=0x7f7016fbe208) at core/action.c:1576
#18 0x00000000005aae93 in do_action (h=0x7fff37146e90, a=0x7f7016c23978,
msg=0x7f7016fbe208) at core/action.c:1207
#19 0x00000000005aeb1e in run_actions (h=0x7fff37146e90, a=0x7f7016c20748,
msg=0x7f7016fbe208) at core/action.c:1576
#20 0x00000000005a1ec6 in do_action (h=0x7fff37146e90, a=0x7f7016c576a0,
msg=0x7f7016fbe208) at core/action.c:1062
#21 0x00000000005aeb1e in run_actions (h=0x7fff37146e90, a=0x7f7016c0b770,
msg=0x7f7016fbe208) at core/action.c:1576
#22 0x000000000059e97d in do_action (h=0x7fff37146e90, a=0x7f7016bc9920,
msg=0x7f7016fbe208) at core/action.c:695
#23 0x00000000005aeb1e in run_actions (h=0x7fff37146e90, a=0x7f7016bb9100,
msg=0x7f7016fbe208) at core/action.c:1576
#24 0x00000000005af2a7 in run_top_route (a=0x7f7016bb9100,
msg=0x7f7016fbe208, c=0x0) at core/action.c:1661
#25 0x00000000005bcb7a in receive_msg (
buf=0xadbd80 <buf.6971> "INVITE sip:AAAAAAAAAA@W.X.Y.Z SIP/2.0\r\nVia:
SIP/2.0/UDP W.X.Y.Z;rport;branch=z9hG4bKZD8Za7p2XF7cF\r\nMax-Forwards:
69\r\nFrom: \"AAAAAAAAAA\" sip:AAAAAAAAAA@W.X.Y.Z;tag=aXy4Na2NtvKBK\r\nTo:
<"..., len=1011, rcv_info=0x7fff371474c0) at core/receive.c:423
#26 0x0000000000488e7f in udp_rcv_loop () at core/udp_server.c:548
#27 0x000000000042650f in main_loop () at main.c:1673
#28 0x000000000042ec18 in main (argc=7, argv=0x7fff37147c38) at main.c:2802
Is there anything relevant in this to know what's wrong?
Regards,
Igor.
--
Cet e-mail a été vérifié par le logiciel antivirus d'Avast.
www.avast.com