Dear Kamailio Developers,
I am writing to report a potential bug in Kamailio's handling of base64 decoding when using the Lua scripting interface (app_lua).
It appears that base64 decoding behaves inconsistently between Lua scripts and kamailio.cfg.
When using `$(var(encoded_json){s.decode.base64t})` in kamailio.cfg, where $var(encoded_json) contains the encoded base64 string: `eyJmb28iOiJiYXIifQ` it decodes to the correct `{"foo":"bar"}`.
But when using the same transformation in Lua `KSR.xlog.xinfo("Decoded in Lua: ".. KSR.pv.get("$(var(encoded_json){s.decode.base64t})"))` it logs a corrupted encoded base64 string: `Decoded in Lua: ..]..#035z{b.?...#036..-....`
Thank you in advance for looking into this issue. Please let me know if you need additional details or test cases.
Kind regards,
Dbrcm
Hello,
we should consider an online devel meeting sometime soon to summarize
what was done at (and still needs to be done after) devel meeting in
Dusseldorf and plan a bit the targets for next major release 6.0.
If considered useful, I propose Dec 9, 2024 (Monday) at 15:00UTC (16:00
Berlin/Paris/Madrid/Rome), but we can also look for other dates as well.
Topics to be discussed can be added at:
-
https://github.com/kamailio/kamailio-wiki/blob/main/docs/devel/irc-meetings…
Pull requests can be made by users without git access.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Hello,
I propose to aim freezing the development for 6.0.x series at the end of
the 16th of December 2024 (Monday).
New features that one wants to get in this release series have to be
pushed to git repository or pull requests made for them. Afterwards
usually follows a 4-6 weeks of testing till the first release 6.0.0.
Unfreezing will happen earlier, after the first weeks of testing when
the 6.0 branch will be created.
Cheers,
Daniel
--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com
Hi
We have FreeSWITCH and Kamailio presence servers set up. FreeSWITCH sends
XML RPC messages to the Kamailio presence servers for PUBLISH operations,
and we receive 200 OK responses in return. These responses include the
SIP-ETag and Expires headers. However, the Kamailio presence server is not
consistently generating NOTIFY packets. This issue seems to occur randomly.
Can you please suggest this for presence servers. Thank you in advance.
Hi Gang
How is record_route() determining if it needs to add two RR Header?
Kamailio 5.8.4
I'm attempting to perform route header hiding by by rebuilding some of
the topos functionality with perl.
So towards the CPE I'm removing all existing RR header and want to
replace them with one header containing an attribute which the CPE is
then sending back and allows me to restore the Route header.
But I came across an issue which an empty RR header being created with
this (simplified) script:
modparam("rr", "enable_double_rr", 1)
perl_exec("hide_route"); # Stores Route-Set and sets $avp(rrattr) as id
remove_hf("Record-Route");
msg_apply_changes();
loose_route(); # Required for record_route()?
add_rr_param(";rr=$avp(rrattr)"); # Add Param to identify saved route set
record_route();
I end up with:
Record-Route: <sip:;r2=on;lr;rr=id007>
Record-Route: <sip:157.161.x.x;r2=on;lr;rr=id007>
The first header missing the IP address, the message being dropped by
the CPE
There is no transport change.
If I set enable_double_rr to 0 only the 2nd RR header is created and
this works as expected but I am not sure if some situations would need
double RR.
What causes the double RR to be created in my case?
Mit freundlichen Grüssen
-Benoît Panizzon-
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
Hi List
I'm looking into the perl module.
Am I right, that I can not add or remove HF from an app_perl subroutine?
I would need to pass an AVP from perl to tell Kamailio what to do?
Goal is an attempt to re-build part of the topos functionality in
perl but only handling RR and Route Header only on one leg, not on
both.
--
Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
Hi,
I noticed that if I enable tcp_accept_haproxy kamailio still can accept connections without the PROXY-protocol header.
The documentation on the wiki has the following note:
"Please note that enabling this option will reject any inbound TCP connection that does not conform to the PROXY-protocol spec."
https://www.kamailio.org/wiki/cookbooks/devel/core#tcp_accept_haproxy
This could be true up until a specific version of kamalio but from 5.7.4+ this limitation is seems to be removed.
Enabling tcp_accept_haproxy is breaking the outbound/rr module because it con’t find the socket based on the address and port from the flow token.
The flow tokens created by a REGISTER on a connection without a PROXY header can be used.
Flow tokens created from a connection with PROXY-protocol header will fail with "cannot find socket from flow-token” once loose_route is invoked.
loose.c:561
/* First, force the local socket */
si = find_si(&rcv->dst_ip, rcv->dst_port, rcv->proto);
if(si)
set_force_socket(_m, si);
else {
LM_INFO("cannot find socket from flow-token\n");
return -1;
}
I’m not sure if the address and/or port values stored in the flow token are incorrect or the problem lies in the matiching in find_is(…).
Wolter
Hello,
I am using letsencrypt cert and key and do not want to restart kamailio
every 3 months to load new ones.
I know that there is: kamcmd tls.reload method but it has an error for me.
error: 500 - Error while fixing TLS configuration (consult server log)
I am checking the logs and see:
kamailio[3865480]: INFO: tls [tls_domain.c:345]: ksr_tls_fill_missing():
TLSs<default>: tls_method=3
kamailio[3865480]: INFO: tls [tls_domain.c:357]: ksr_tls_fill_missing():
TLSs<default>: certificate='/etc/kamailio/certs/my_cert.crt'
kamailio[3865480]: INFO: tls [tls_domain.c:364]: ksr_tls_fill_missing():
TLSs<default>: ca_list='(null)'
kamailio[3865480]: INFO: tls [tls_domain.c:371]: ksr_tls_fill_missing():
TLSs<default>: ca_path='(null)'
kamailio[3865480]: INFO: tls [tls_domain.c:378]: ksr_tls_fill_missing():
TLSs<default>: crl='(null)'
kamailio[3865480]: INFO: tls [tls_domain.c:382]: ksr_tls_fill_missing():
TLSs<default>: require_certificate=0
kamailio[3865480]: INFO: tls [tls_domain.c:390]: ksr_tls_fill_missing():
TLSs<default>: cipher_list='(null)'
kamailio[3865480]: INFO: tls [tls_domain.c:397]: ksr_tls_fill_missing():
TLSs<default>: private_key='/etc/kamailio/certs/private.key'
kamailio[3865480]: INFO: tls [tls_domain.c:401]: ksr_tls_fill_missing():
TLSs<default>: verify_certificate=0
kamailio[3865480]: INFO: tls [tls_domain.c:406]: ksr_tls_fill_missing():
TLSs<default>: verify_depth=9
kamailio[3865480]: INFO: tls [tls_domain.c:410]: ksr_tls_fill_missing():
TLSs<default>: verify_client=0
kamailio[3865480]: NOTICE: tls [tls_domain.c:1168]: ksr_tls_fix_domain():
registered server_name callback handler for socket [:0],
server_name='<default>' ...
kamailio[3865480]: ERROR: tls [tls_domain.c:590]: load_cert():
TLSs<default>: Unable to load certificate file
'/etc/kamailio/certs/my_cert.crt'
kamailio[3865480]: ERROR: tls [tls_util.h:49]: tls_err_ret():
load_cert:error:03000072:digital envelope routines::decode error (sni:
unknown)
kamailio[3865480]: ERROR: tls [tls_util.h:49]: tls_err_ret():
load_cert:error:0A00018F:SSL routines::ee key too small (sni: unknown)
Any advice ?
It's interesting that there are not any errors in case I restart kamailio.
I can make TLS calls without problems.
deb 12.5
version: kamailio 5.7.4 (x86_64/linux)
Hello,
FOSDEM'25 will host again a RTC DevRoom during the afternoon of February
1, 2025 (Saturday) -- more details and the call for presentation can be
read at:
- https://lists.fosdem.org/pipermail/fosdem/2024q4/003584.html
I am not sure if I can participate (chances are more towards no, than to
yes), but if anyone considers to go to the event, it will be good to
submit a proposal to cover a bit Kamailio as well (it doesn't have to be
entirely about Kamailio).
Note that FOSDEM imposes a strict deadline this time for submissions
(Dec 1, 2024), thus is no much time left. Should anyone in these groups
plans to submit a proposal, let us know, so the others have an idea
about it.
Cheers,
Daniel
--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com
Hi,
we would like to replicate a SIP-message ("REGISTER" in our case) to a
set of nodes for further asynchronous processing. The message is already
processed on the local Kamailio.
We thought about using the tm-module in conjunction with the dispatcher
module so we can reliably forward the message.
This seems to work, however we get a new problem: Kamailio forwards the
response it gets from those nodes.
When we drop the response in the reply_route, it gets dropped before TM
can see it.
When we drop the response in the on_reply_route, it still will be
forwarded. (adding or removing a header here works, however) $du is set
to $null.
Is there any clean way to suppress that response being forwarded back to
the original requester?
Best regards
Christian Berger
--
Christian Berger - berger(a)sipgate.de
Telefon: +49 (0)211-63 55 55-0
Telefax: +49 (0)211-63 55 55-22
sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf
HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois
Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391
www.sipgate.de - www.sipgate.co.uk