I have kamailio behind a TLS termination proxy so the sockets are correctly
deduced to be TCP. However the clients only talk TLS to the proxy and are
confused when the top Via header added by Kamailio is TCP. Is there a way
for Kamailio to forcibly pretend its protocol is TLS? Like
advertised_address but "advertised_protocol" instead.
(With pjsip testing: it has a flag use_tls which ignores TCP from Kamailio
and continues to use the persistent TLS transport to proxy. Linphone fails
because it tries to honor TCP in Via and is unable to establish TCP
transport).
BTW I am using t_relay_to_tcp so Kamailio will return traffic to the proxy
as TCP even though the contact addresses specify transport=TLS.
Hi everybody,
I'm just testing Kamailio 5.4.1 with dialog replication over DMQ. This
seems to work very good. Dialogs are replicated without problems.
When I'm restarting one node I would have expected, that all dialogs are
synced again, just like in dmq_usrloc.
But this does not happen. After a restart the nodes dialog-list is empty.
Did I miss somethin? Is there a special parameter that I have to set?
BR, Björn
--
Björn Klasen, Specialist
TNG Stadtnetz GmbH, Network Management (VoIP)
Projensdorfer Straße 324
24106 Kiel
Germany
T +49 431/ 530530
F +49 431/ 7097-555
mailto: bklasen(a)tng.de
http://www.tng.de
Register: Amtsgericht Kiel HRB 6002 KI
Executive board (Geschäftsführung): Dr.-Ing. Volkmar Hausberg,
Sven Schade, Carsten Tolkmit, Dr. Sven Willert
Tax-Id (Steuernr.): 2029047020, VAT-Id (USt-Id): DE225201428
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
Hi,
I am building a configuration script where for some traffic flows
parallel forking will be needed, and in this case I need to go beyond
the default max limit of the max amount of branches.
Apart from this specific case the traffic load that kamailio will need
to handle is very low, let's say just one second here and there with up
to 5 concurrent calls at most.
This limit is as far as I understand set here:
usr/local/src/kamailio-5.6/kamailio/src/core/config.h
And the default limit is:
#define MAX_BRANCHES_LIMIT 32 /*!< limit of maximum
number of branches per transaction */
Here are the questions I have related to this:
1) If I increase the value of this constant in config.h, how high is it
reasonable to set this value and still have a stable system?
2) If I increase MAX_BRANCHES_LIMIT beyond 32, are there also other
parameters that needs to be changed for the system to be able to cope,
and if so whichparameters?
Regards,
Lars
Just checking to see if this is the designed behavior. The SL module will attempt to match ACKs for stateless replies and handle them (absorb them?).
The question I have is that it looks as though this ACK gets counted as dropped by the core.drop_requests from the KEX module. Tested using this config:
#!KAMAILIO
loadmodule "pv"
loadmodule "sl"
loadmodule "xlog"
loadmodule "kex"
loadmodule "corex"
loadmodule "ctl"
modparam("sl", "bind_tm", 0)
route {
xinfo("[$ci] $rm Request. Src:[$si:$sp] RURI:[$ru] To:[$tu] From:[$fu]\n");
sl_send_reply("404", "Not Found");
}
event_route[sl:filtered-ack] {
xnotice("sl:filtered-ack ACK [$ci] to local reply absorbed\n");
}
Then validate by kamcmd stats.fetch core:drop_requests
Is this the designed and "correct" behavior?
Kaufman
Hello,
Kamailio SIP Server v5.7.1 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.0. 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.1.
For more details about version 5.7.1 (including links and guidelines to
download the tarball or from GIT repository), visit:
* https://www.kamailio.org/w/2023/06/kamailio-v5-7-1-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
Hi All
I have setup kamailio using websockets(wss) i am trying to forward any registration that comes to kamailio to go to asterisk, so in theory kamailio is a registration proxy
i have set rewritehostport("xxx.xxx.xxx[:5080](http://node3.sipalto.com:5080)");
the registration forwards fine but the contact on asterisk side shows as sip:xxx:kamailioip.xxxx.invalid
so therefore asterisk sees the sip peer as offline
what am i missing :(
Sent with [Proton Mail](https://proton.me/) secure email.
Hello,
I am considering to release Kamailio v5.7.1 (out of branch 5.7) this
week (likely on Wednesday or Thursday, Jun 28/29, 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
Hi Experts,
We wished to used the LCR Module to be able to select the Gateway(s) to
send the calls to based on the From(Caller) Username.
Based on the LCR Documentation, the usage of other fields like request URI
or prefix etc is pretty clear. But for the From Usename I am having certain
trouble understanding the same. It refers to some mtree. Excerpt below:
"A gateway matches a request if user part of Request-URI matches "prefix",
caller URI matches "from_uri" pattern,* caller URI userpart matches mtree
with "mt_value"*, and callee URI matches "request_uri" pattern in a tuple
that is associated with the gateway."
Can someone explain/ share a sample lcr_rule table entries for the From
Username that can be matched against the incoming sip message for gw
selection? Do we need to manually create an mtree by the name "*lcr*".
Asking based on the below section in LCR documentation? Any pointers are
highly appreciated.
3.35. mtree (string)
Name of mtree to which load_gws() matches caller URI userpart.
*Default value is "lcr".*
Regards,
Harneet Singh
--
"Once you eliminate the impossible, whatever remains, no matter how
improbable, must be the truth" - Sir Arthur Conan Doyle
Hello,
I'm currently experiencing some odd behaviours when using these functions
and I need some help debugging to find the root of the issue.
I receive a call from a client and do some changes to the To and From
header using auto mode with password. Encrypted info goes on the
Record-Route header parameters (vsf\vst) normally.
1 - On subsequent requests sent by the originating client, domains on To
and From header are different from the ones sent in the first INVITE. In
this scenario, somehow the automatic modifying has errors on the end
result. Can the different domains affect the end result of the automatic
modifying or only the vsf\vst parameters and password are needed to the
auto replace\restore?
2 - How can I decrypt the info on vsf and vst parameters in order to verify
the info sent and the encryption?
Cheers,
Duarte Rocha
