Module: kamailio
Branch: master
Commit: 1fd57e57255cb7f6d76326a255a3a91d107cba89
URL: https://github.com/kamailio/kamailio/commit/1fd57e57255cb7f6d76326a255a3a91…
Author: Florian Floimair <f.floimair(a)commend.com>
Committer: Henning Westerholt <hw(a)gilawa.com>
Date: 2023-05-12T17:26:03+02:00
tls: update documentation (TLS v1.0 & 1.1 deprecation)
---
Modified: src/modules/tls/doc/params.xml
---
Diff: https://github.com/kamailio/kamailio/commit/1fd57e57255cb7f6d76326a255a3a91…
Patch: https://github.com/kamailio/kamailio/commit/1fd57e57255cb7f6d76326a255a3a91…
---
diff --git a/src/modules/tls/doc/params.xml b/src/modules/tls/doc/params.xml
index b51e5ce99a0..1e8ca7f3e94 100644
--- a/src/modules/tls/doc/params.xml
+++ b/src/modules/tls/doc/params.xml
@@ -105,9 +105,10 @@
<para>
If RFC 3261 conformance is desired, at least TLSv1 must be used. For
compatibility with older clients SSLv23 is the option, but again, be aware
- of security concerns, SSLv2/3 being considered very insecure by 2014.
+ of security concerns, SSLv2/3 as well as TLS v1.0 and v1.1 are being considered very insecure
+ and are therefore deprecated since March 2021 (RFC 8996).
For current information about what's considered secure, please consult,
- IETF BCP 195, currently RFC 7525 - "Recommendations for Secure Use of
+ IETF BCP 195, currently RFC 9325 - "Recommendations for Secure Use of
Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"
</para>
<example>
Hi everybody,
I'm new to Kamailio and I want to know the best way to manage SIP authentication with a Kamailio proxy. Currently, I'm using htables with DDI as key_value, but this configuration is causing my database to become overly extensive. For each DDI, I need three rows in the database. If anyone can suggest a better solution to handle the issue of large credential tables, I would greatly appreciate it.
Thank you.
### Description
Kamailio sending HELD request with broken sip uri when the INVITE message contains a display name or display name with special character "&".
```
P-Asserted-Identity: "User &" <sip:+12001112233@206.147.236.78:5060>
```
or
```
P-Asserted-Identity: "User" <sip:+12001112233@206.147.236.78:5060>
```
For the first case, HELD request body looks like
```xml
<?xml version="1.0" encoding="UTF-8"?>
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held" responseTime="5000">
<locationType exact="true">geodetic locationURI</locationType>
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<uri />
</device>
</locationRequest>
```
Here `uri` element is empty.
For the second case, HELD request body looks like (ident formatted)
```
<?xml version="1.0" encoding="UTF-8"?>
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held" responseTime="5000">
<locationType exact="true">geodetic locationURI</locationType>
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<uri>"User" <sip:+12001112233@206.147.236.78:5060></uri>
</device>
</locationRequest>
```
In [HELD schema](https://datatracker.ietf.org/doc/html/rfc6155#section-6) the 'uri' element specified as
```
<xs:element name="uri" type="xs:anyURI"/>
```
For me looks like here `display name` cannot be used.
Moreover, if an inbound call does not contain `P-Asserted-Identity` header then `lost` properly extracts uri from the `From` header.
For me look like need to improve `P-Asserted-Identity` parsing in the `lost` module and properly extract uri from header value.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3426
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3426(a)github.com>
(also adding sr-dev)
Hello,
I have cherry-picked the commit. Its technically a new feature addition, which would not qualify for a backport to a stable branch. On the other hand, if KEMI is not usable without that, we certainly import KEMI changes into stable branches so it would qualify for a backport. This unclear status was probably the reason that it was not included into the backports so far.
If somebody is against adding this change, I will revert it of course. I did not cherry-picked it to 5.5 branch.
Cheers,
Henning
From: Michal Hajek <michal.hajek(a)daktela.com>
Sent: Donnerstag, 11. Mai 2023 12:16
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: [SR-Users] GeoIP2 and KEMI
Hello,
why this commit is not in branch 5.6?
https://github.com/kamailio/kamailio/commit/21817906853140322c701f8cbb82010…
Without this, is KEMI and GeoIP2 incompatible.
Thanks
Michal
Hi Sergey,
I am not the one that works on the Kamailio docker packages, so others can probably comment more.
But I think after we switched the kamailio docker to the github repository, it also make sense to move the other smaller “special” Kamailio repositories from docker hub to github. Just to have it in one place and to be less confusing for users and developers.
Cheers,
Henning
From: Sergey Safarov <s.safarov(a)gmail.com>
Sent: Freitag, 28. April 2023 19:59
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: [SR-Users] kamailio/kamailio-ci docker image
Hi
Now "kamailio/kamailio-ci" docker image is pushed to GitHub packages<https://github.com/kamailio/kamailio-ci/pkgs/container/kamailio-ci> only.
I have a question should we completely switch to using the GitHub docker repo and remove the "kamailio/kamailio-ci" docker image from Docker Hub<https://hub.docker.com/repository/docker/kamailio/kamailio-ci>?
Or required to push the "kamailio/kamailio-ci" docker image to GitHub packages and Docker Hub repos?
Sergey
Module doc says:
4.5. plp_limit_column (string)
Name of 'limit' column.
Default value is “limit”.
According to source src/modules/pipelimit/pl_db.c default value is plimit
#define RLP_LIMIT_COL "plimit"
So the doc should say:
Default value is “plimit”.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3449
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3449(a)github.com>