[SR-Users] Re: How to use environment variable

[Olle E. Johansson via sr-users]

> On 28 Apr 2024, at 10:57, Pavan Kumar via sr-users 
>  wrote:
> 
> Hi everyone,
> 
> I am trying to assign environment variable as follows
> 
> listen=udp:0.0.0.0:5060  advertise $env(MY_IP):5060
> 
> Looks like using the environment variable as above is an invalid 
> configuration.
> 
> Is there a way to use IP from env var to advertise. Even better, is there a 
> way to use result in a stun query as an advertised address?

The config variables (called pseudo-variables in documentation) can only be 
used in the routing scripts, not in the core parameters section.

There is a way to add defines for substitution on the command line and use them 
though. Check the documentation in the core cookbook on how to use defines and 
the command line help for more information.

/O__
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] Kamailio Yocto package

[Olle E. Johansson via sr-users]

Hello Kamailians!

Before I start going down this path - anyone that has written a Kamailio Yocto 
layer and want to share either layer or experience or both?

For those that doesn’t know: Yocto is a toolkit for building your own Linux 
distros for embedded systems.

/O
__
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: best approach to setup SIP Session sharing between servers

[Olle E. Johansson via sr-users]

In theory if you set the record-route to a DNS name and not an Ip address, then 
endpoints should be able to failover within a dialog - but as Alex says - 
transactions may fail. In many cases there are retry timers to restart 
transactions that fail. 

This means that if a call starts with an INVITE transaction on one server, it 
should in theory be able to find another server for the BYE. Whether this DNS 
srv based fail over is implemented in end-points is up to testing to prove. If 
not, then virtual IP failover is your best friend.

/O

> On 27 Feb 2024, at 13:33, Alex Balashov via sr-users 
>  wrote:
> 
> That would require transaction replication, which Kamailio doesn't have. 
> 
> Most messages can be processed statelessly, so this isn't a huge obstacle. 
> However, CANCELs won't work.
> 
>> On 27 Feb 2024, at 06:49, Sergio Charrua via sr-users 
>>  wrote:
>> 
>> Hi all!
>> 
>> I am having some difficulties/doubts on what would be the best approach to 
>> let multiple Kamailio servers share their SIP sessions between each other.
>> The goal is to have HA on Kamailio cluster such that if a call is received 
>> and initiated on Kamailio #1, and during any moment of the call (before or 
>> while established) if the server #1 goes down or Kamailio stops working for 
>> any reason, the call can be processed by Kamailio server #n available in the 
>> cluster.
>> I do not want to mess with Virtual IPs or DNS, that is not the point, but 
>> instead need to get a proper way to share SIP sessions between Kamailio 
>> servers such that any server could continue the call without issue.
>> 
>> I have checked the Dialog and DMQ module, but I am not sure if that is the 
>> way to go
>> 
>> Could any one share a solution for this?
>> 
>> Greatly appreciated.
>> 
>> Cheers,
>> 
>> 
>> Sérgio Charrua
>> www.voip.pt 
>> 
>> 
>> __
>> 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:
> 
> -- 
> Alex Balashov
> Principal Consultant
> Evariste Systems LLC
> Web: https://evaristesys.com
> Tel: +1-706-510-6800
> 
> __
> 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: Upgrade Minor versions

[Olle E. Johansson via sr-users]

> On 24 Nov 2023, at 15:30, Gavin Baumanis via sr-users 
>  wrote:
> 
> Hi there,
> 
> I have taken over a project that uses Kamailio.
Good for you! :-)

> I am aware of what we use it for - I am just not sure on the how... apart 
> from what I have read in the docs.
> 
> We're currently running 5.4.2 and I'd like to upgrade to (at least) the 
> latest 5.4 offering - as that seems as if it would be the easiest and safest 
> option.
> 
> So I am hoping I might get some direction, please - on the way forward for an 
> upgrade.
> The documentation seems OK if you're upgrading minor versions... but I 
> couldn;t find anything about upgrading patch versions.


In general, updating within a release version, like 5.4 and 5.5 - from 5.4.2 to 
5.4.3 does not require any config changes.
When you update from 5.4.x to 5.5.x there may be both config changes and 
changes in database schemas, so that’s more tricky
and you will have to dig down to documentation to get advice.

Regards,
/O
__
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: STIR/SHAKEN with Kamailio

[Olle E. Johansson via sr-users]

> On 19 Oct 2023, at 18:46, Alex Balashov via sr-users 
>  wrote:
> 
> Would join Kaufman here to say that free-range STIR/SHAKEN implementations in 
> the US are limited by the small number of certified authentication providers, 
> but presumably the EU version will to some extent avoid US-style Guilded Age 
> corporate welfare…
Sadly that’s my view of the US implementation. I can’t say if it solved the 
problem, but I can see that a lot of new and old actors
got an oppurtunity to earn more money.

There’s no EU-wide implementation or regulation at this point. I am aware of 
France. There are certainly discussions.
/O
> 
> -- Alex
> 
>> On 19 Oct 2023, at 09:33, Ben Kaufman via sr-users 
>>  wrote:
>> 
>> Like some of the other posters here, we’ve implemented it as a 302-redirect 
>> server. This was the primary reason for using the secsipid rather than 
>> stirshaken module.  Both modules have a function to append an Identity 
>> header, but secsipid also has functions to simply build the identity header 
>> which can then easily be appended to the reply, rather than only appending 
>> to the request and plucking the Identity header from there.  Secsipid also 
>> has a function secsipid_sign() which allows for creating your own JWT.  This 
>> is useful if you want to create some variations on the Identity header - we 
>> use this to create div passports (as opposed to shaken passports) in some 
>> situations.
>> 
>> Not sure how it will be implemented there, but the biggest challenge for me 
>> in the US was acquiring certificates because there is a very limited number 
>> of regulatory approved vendors.
> 
> -- 
> Alex Balashov
> Principal Consultant
> Evariste Systems LLC
> Web: https://evaristesys.com
> Tel: +1-706-510-6800
> 
> __
> 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] STIR/SHAKEN with Kamailio

[Olle E. Johansson via sr-users]

Hello Kamailians!

As STIR/SHAKEN seems to cross the ocean and arrive on the European shores, I’m 
curious on how you’ve implemented it with Kamailio. I asked on our Matrix chat 
and got two responses that seems to not use the Kamailio STIR/SHAKEN support 
but rather a 3rd party service that they’ve integrated using restful APIs.

Please help me and share how you’re implementing STIR/SHAKEN with Kamailio.

I’m not shaken, nor stirred. yet.

Regards,
/O
__
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: Software bill of materials (SBOM)

[Olle E. Johansson via sr-users]

> On 28 Sep 2023, at 12:36, Ivan Ribakov via sr-users 
>  wrote:
> 
> Hi Olle,
> 
> Yes, I realised by now that taking enabled Kamailio modules into account when 
> generating SBOM is too much to ask. I'd be ok with obtaining full list of 
> Kamailio dependencies (with transitive dependencies if possible) and then 
> manually filtering them based on module usage. Not sure if at any point 
> during Kamailio build process all sources + dependency sources/binaries are 
> present in the system for scanning/identification?
> 
> I'm mainly interested in listing (and validating licenses) and having a 
> general inventory. Any recommendations?
> 
I did try a beta of a tool in cyclonedx toolset for scanning C files and it 
crashed. Will try again, but so far I haven’t succeeded. 
I suggest we would need one SBOM based on a linux distro, like Debian and one
more generic based on C code and the versions of libraries we recommend. I have 
tried to add pointers to the various
third party dependencies in the READMEs over the years in a somewhat 
unstructured effort, but the information is there.
Maybe we can add the dependencies in a way that’s parseable in order to build 
an SBOM.

C code doesn’t have package management like Python, Perl, Go and others so it’s 
tricky to automate creation of SBOMs.

I think that the SBOM tree for the source code and dependencies would grow 
quite large.

Anyway -  at this time, I failed. :-)

/O
> 
> 
> 
> -- 
> Ivan Ribakov
> Software Engineer
> www.zaleos.net <http://www.zaleos.net/>
> 
> 
> 
> 
> 
> On Thu, 28 Sept 2023 at 10:58, Olle E. Johansson via sr-users 
> mailto:sr-users@lists.kamailio.org>> wrote:
>> Still digging through this. There are tools that can list your packages if 
>> you install Linux packages, i.e. Debian.
>> But there are no tools that can parse your kamailio config to really see 
>> what’s loaded and active.
>> 
>> It all depends on what you want to do with the SBOM - if you want to check 
>> for vulnerabilities, list licenses
>> or have a generic inventory.
>> 
>> /O
>> 
>>> On 28 Sep 2023, at 09:41, Henning Westerholt via sr-users 
>>> mailto:sr-users@lists.kamailio.org>> wrote:
>>> 
>>> Hello,
>>>  
>>> I think Olle was looking into that some month ago, maybe (when he reads it) 
>>> can share some of his research results if possible.
>>> You can also find some of his articles e.g., on his linkedin page.
>>>  
>>> Cheers,
>>>  
>>> Henning
>>>  
>>> -- 
>>> Henning Westerholt – https://skalatan.de/blog/
>>> Kamailio services – https://gilawa.com <https://gilawa.com/>
>>>  
>>> From: Ivan Ribakov via sr-users >> <mailto:sr-users@lists.kamailio.org>> 
>>> Sent: Mittwoch, 27. September 2023 21:11
>>> To: Kamailio (SER) - Users Mailing List >> <mailto:sr-users@lists.kamailio.org>>
>>> Cc: Ivan Ribakov mailto:i.riba...@zaleos.net>>
>>> Subject: [SR-Users] Software bill of materials (SBOM)
>>>  
>>> Any recommendations for a tool that can generate SBOM for a Kamailio 
>>> instance based on configured modules?
>>>  
>>> Thanks,
>>> Ivan
>>> __
>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>> To unsubscribe send an email to sr-users-le...@lists.kamailio.org 
>>> <mailto: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 
>> <mailto: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:

__
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: Software bill of materials (SBOM)

[Olle E. Johansson via sr-users]

Still digging through this. There are tools that can list your packages if you 
install Linux packages, i.e. Debian.
But there are no tools that can parse your kamailio config to really see what’s 
loaded and active.

It all depends on what you want to do with the SBOM - if you want to check for 
vulnerabilities, list licenses
or have a generic inventory.

/O

> On 28 Sep 2023, at 09:41, Henning Westerholt via sr-users 
>  wrote:
> 
> Hello,
>  
> I think Olle was looking into that some month ago, maybe (when he reads it) 
> can share some of his research results if possible.
> You can also find some of his articles e.g., on his linkedin page.
>  
> Cheers,
>  
> Henning
>  
> -- 
> Henning Westerholt – https://skalatan.de/blog/
> Kamailio services – https://gilawa.com 
>  
> From: Ivan Ribakov via sr-users  > 
> Sent: Mittwoch, 27. September 2023 21:11
> To: Kamailio (SER) - Users Mailing List  >
> Cc: Ivan Ribakov mailto:i.riba...@zaleos.net>>
> Subject: [SR-Users] Software bill of materials (SBOM)
>  
> Any recommendations for a tool that can generate SBOM for a Kamailio instance 
> based on configured modules?
>  
> Thanks,
> Ivan
> __
> 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: kamcmd reload is slow or blocking additional reloads

[Olle E. Johansson]

> On 5 Sep 2023, at 10:43, Martin Nyström  wrote:
> 
> Thanks,
>  
> I’ll keep the reload_delta above 0 but I’ll lower it a bit.
>  
> My question has been answered, but as OEJ said I think you should update the 
> message returned when performing an RPC reload and streamline the JSON body 
> response. It appears each module has its own OK message.
>  
I started working on that a while ago, thanks for the reminder :-)

/O
>  
> /M
>  
> From: Daniel-Constantin Mierla mailto:mico...@gmail.com>>
> Date: Tuesday, 5 September 2023 at 10:26
> To: Kamailio (SER) - Users Mailing List  <mailto:sr-users@lists.kamailio.org>>, Martin Nyström 
> mailto:martin.nyst...@connectel.se>>
> Subject: Re: [SR-Users] Re: kamcmd reload is slow or blocking additional 
> reloads
> 
> CAUTION: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. 
> 
>  
> 
> Hello,
>  
> it is not taking so long to load the records, there is a limit related to how 
> often the reload commands can be executed:
>  
>   - 
> https://www.kamailio.org/docs/modules/stable/modules/permissions.html#permissions.p.reload_delta
>  
> It is by design for safety reasons. If you do need reloading very often, it 
> might be just better to match with sql query (sqlops) directly over the 
> database table records.
>  
> Cheers,
> Daniel
>  
> On 05.09.23 10:19, Martin Nyström wrote:
> Hey OEJ 
>  
> Yes, the message returned should be updated. However, before resorting to 
> htables I am still curious why it would take ~8 seconds to load my 4-row 
> large, trusted table from db.
> Is there a way I can troubleshoot this further? I’ve solved this temporary 
> with a queue for the rpc requests.
>  
>  
>  
> /M
>  
> From: Olle E. Johansson  <mailto:o...@edvina.net>
> Date: Tuesday, 5 September 2023 at 09:13
> To: Kamailio (SER) - Users Mailing List  
> <mailto:sr-users@lists.kamailio.org>
> Subject: [SR-Users] Re: kamcmd reload is slow or blocking additional reloads
> 
> CAUTION: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. 
> 
>  
> 
>  
> 
> 
> 
> On 4 Sep 2023, at 15:46, Martin Nyström 
> <mailto:martin.nyst...@connectel.se> wrote:
>  
> Hello,
>  
> Hi Martin :-) !
> 
> 
> 
> Running ”kamcmd permissions.trustedReload” it instantly returns “Reload OK” 
> but I cannot repeat the reload for about 8 seconds. This is the same for 
> dialplan.reload and dispatcher.reload.
>  
> root@superman.local <mailto:root@superman.local>:/# kamcmd 
> permissions.trustedReload
> Reload OK
> That message should propably be changed to “Reload initiated OK"
> 
> 
> root@superman.local <mailto:root@superman.local>:/# kamcmd 
> permissions.trustedReload
> error: 500 - ongoing reload
> root@superman.local <mailto:root@superman.local>:/# kamcmd 
> permissions.trustedReload
> error: 500 - ongoing reload
>  
> There are scenarios where I might need to reload the permission table 
> multiple times within this 8 second window. Is this some kind of intended 
> block or is something at fault?
>  
> modparam("db_mysql", "ping_interval", 60)
> modparam("db_mysql", "timeout_interval", 4)
> modparam("db_mysql", "auto_reconnect", 1)
> modparam("db_mysql", "opt_ssl_mode", 0)
> modparam("permissions", "db_url", "mysql://kamailio:x@aws-rds-database 
> /kamailio")
>  
> version: kamailio 5.7.1 (x86_64/linux) 
> flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, 
> USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, 
> F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, 
> USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, 
> HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
> ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, 
> BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
> id: unknown 
> compiled with gcc 10.2.1
>  
>  
> Maybe think about using htables instead as you can manipulate them easier.
>  
> We may want a way to check last reload of trusted table in order to confirm 
> that it was loaded ok. 
>  
> /O
> 
> 
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an em

[SR-Users] Re: Set a License for Kamailio

[Olle E. Johansson]

> On 5 Sep 2023, at 14:45, Ali Taher  wrote:
> 
> Hello,
>  
> Is it possible to put a kind of license for Kamailio, in a way that it works 
> for 1 week for example, and after that it will not process new requests?
>  
Curious question: Why?

There’s no code in Kamailio for that. However you can surely build something 
using the configuration language or use a 3rd party scripting language like 
Python for it.

/O__
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: kamcmd reload is slow or blocking additional reloads

[Olle E. Johansson]

> On 4 Sep 2023, at 15:46, Martin Nyström  wrote:
> 
> Hello,
>  
Hi Martin :-) !

> Running ”kamcmd permissions.trustedReload” it instantly returns “Reload OK” 
> but I cannot repeat the reload for about 8 seconds. This is the same for 
> dialplan.reload and dispatcher.reload.
>  
> root@superman.local :/# kamcmd 
> permissions.trustedReload
> Reload OK
That message should propably be changed to “Reload initiated OK"
> root@superman.local :/# kamcmd 
> permissions.trustedReload
> error: 500 - ongoing reload
> root@superman.local :/# kamcmd 
> permissions.trustedReload
> error: 500 - ongoing reload
>  
> There are scenarios where I might need to reload the permission table 
> multiple times within this 8 second window. Is this some kind of intended 
> block or is something at fault?
>  
> modparam("db_mysql", "ping_interval", 60)
> modparam("db_mysql", "timeout_interval", 4)
> modparam("db_mysql", "auto_reconnect", 1)
> modparam("db_mysql", "opt_ssl_mode", 0)
> modparam("permissions", "db_url", "mysql://kamailio:x@aws-rds-database 
> /kamailio")
>  
> version: kamailio 5.7.1 (x86_64/linux) 
> flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, 
> USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, 
> F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, 
> USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, 
> HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
> ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, 
> BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
> id: unknown 
> compiled with gcc 10.2.1
>  
>  
Maybe think about using htables instead as you can manipulate them easier.

We may want a way to check last reload of trusted table in order to confirm 
that it was loaded ok. 

/O__
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: use_dns_failover default value

[Olle E. Johansson]

I agree with Daniel here. Within the platforms we rarely use DNS as most 
systems are fixed
(not moving around, have a permanent IP address) and we handle failover and 
load balancing
using solutions like the Kamailio dispatcher.

>From the client side, like softphones or desktop phones, I personally use a 
>lot of DNS
to find the first hop SIP server. This way I can manage the clients, control 
load balancing,
provider failover and make sure they always reach the service.

Cheers,
/O

> On 22 Aug 2023, at 21:14, Daniel-Constantin Mierla  wrote:
> 
> Hello,
> 
> DNS-based routing is not very common in telecommunications, most of the
> interconnects being done based on IP routing and IP-trusted rules.
> Because DNS is usually a blocking operation that involves network
> communication (therefore can introduce delays), many of the dns features
> are turned off by default. When one has to build a system that relies
> significantly on DNS-based routing, those features can be turned on via
> config.
> 
> Cheers,
> Daniel
> 
> On 22.08.23 17:07, Silvan Nagl wrote:
>> Hi,
>> 
>> I would like to know the reason for having "off" as default value for
>> use_dns_failover.
>> https://github.com/kamailio/kamailio/issues/3547
>> 
>> Greetings,
>> Silvan
>> 
> -- 
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio World Conference - www.kamailioworld.com
> 
> __
> 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: Kamailio dns-failover / dns-loadbalancing with slow responding client.

[Olle E. Johansson]

I had similar problems using dispatcher. Asterisk somehow locked up, so 
dispatcher moved on before asterisk had sent 100 trying. After the call was up 
on another instance, the first Asterisk suddenly responded and that caused a 
lot of issues. I could not repeat it, but it happened now and then. 

Maybe this is something that we should find a solution too. I don’t know what 
can be seen as similarities here, but it seems like
an attempt to complete a transaction that is abandoned before any response then 
wakes up after Kamailio finds another
server by using DNS or dispatcher (generating internal 408 timeout).

Food for thought.

/O

> On 14 Aug 2023, at 10:03, Ihor Olkhovskyi  wrote:
> 
> Hello,
> 
> I'm having somewhat looks-alike problem with long responce from endpoints and 
> ended up tracking status of transaction (or dialog) htabled with callerid 
> key. 
> So, when I'm receiving an "outdated" responce, I'm checking the status of the 
> whole transaction (or dialog) and acting accordingly.
> 
> Hopefuly, this idea can point you to solution.
> 
> Cheers,
> Ihor
> 
> Le ven. 11 août 2023 à 22:32, Henning Westerholt  > a écrit :
>> Hello,
>> 
>>  
>> 
>> this sounds odd. Are you maybe using a failure route to intercept the 503 
>> and send the INVITE to a new destination?
>> 
>>  
>> 
>> Cheers,
>> 
>>  
>> 
>> Henning
>> 
>>  
>> 
>> --
>> 
>> Henning Westerholt – https://skalatan.de/blog/
>> 
>> Kamailio services – https://gilawa.com 
>>  
>> 
>> From: Mattis Lind mailto:mattisl...@gmail.com>> 
>> Sent: Donnerstag, 10. August 2023 15:02
>> To: sr-users@lists.kamailio.org 
>> Subject: [SR-Users] Kamailio dns-failover / dns-loadbalancing with slow 
>> responding client.
>> 
>>  
>> 
>> Hello!
>> 
>>  
>> 
>> I am looking into a problem where we have Kamailio forwarding calls to two 
>> or more "recording-clients". I will try my best to describe the problem and 
>> would appreciate it if someone has an idea what to do. Please feel free to 
>> ask if you think I have forgotten to describe something that might be 
>> important or something is unclear in what I have written.
>> 
>>  
>> 
>> We use use_dns_failover=yes and dns_srv_lb=yes so calls get load balancing 
>> to the "recording-clients". There is also the t_set_fr(6,1000) parameter 
>> set so that if there is no response within 1 second it would try the next 
>> recording-client. The SRV record points to two or more recording clients.
>> 
>>  
>> 
>> It now happens that the recording-clients sometimes have some kind of 
>> temporary problem so it will respond with a 503 after 5 seconds.
>> 
>>  
>> 
>> What happens is that after the 1 second timeout trying to get the INVITE 
>> through to the first recording-client Kamailio will internally generate a 
>> 408. This will cause it to failover to another recording-client which 
>> happily takes care of the INVITE and responds properly with a 200 OK. 
>> 
>>  
>> 
>> Everything would have been just fine except for the fact that the first 
>> recording-client is just slow and finally responds with a 503. This 503 is 
>> not relayed backwards since a 200 has already been forwarded back to the 
>> caller. But when receiving the 503 Kamailio will initiate a new INVITE which 
>> is trying to set up a new call to a recording client. It looks like it is 
>> doing a new failover regardless if it already has done a failover for this 
>> failed transaction.
>> 
>>  
>> 
>> I don't want Kamailio to send that last INVITE when receiving the 503. How 
>> can I configure Kamailio to disregard the last 503 (except for responding 
>> with an ACK) and not initiate a new INVITE?
>> 
>>  
>> 
>> I have tried a lot of different changes to the configuration but failed to 
>> achieve this, unfortunately. Do I need to use the dispatcher module to 
>> achieve this?
>> 
>>  
>> 
>> /Mattis
>> 
>> __
>> 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:
> 
> 
> -- 
> Best regards,
> Ihor (Igor)
> __
> 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: where add contact header to ack for fail messages

[Olle E. Johansson]

> On 11 May 2023, at 12:31, Henning Westerholt  wrote:
> 
> Hello,
> 
> why you actually need to add the Contact header to the ACK? According to the 
> RFC 3261 is should be an optional header to that message.
> 
For a failure message there can not be any Contact header. Never. There’s no 
one to contact!

/O
> Cheers,
> 
> Henning
> 
> -Original Message-
> From: James Browne  
> Sent: Mittwoch, 10. Mai 2023 14:08
> To: Kamailio (SER) - Users Mailing List 
> Subject: [SR-Users] Re: where add contact header to ack for fail messages
> 
> I made simple tests and it seems that this is a kamailio-TM-internal message 
> being sent, not being processed by the cfg file.
> 
> If this is simple enough and deterministic, you may consider using the corex 
> module to edit the message as it's being sent "on the wire". I can't think of 
> any other solution.
> https://kamailio.org/docs/modules/5.6.x/modules/corex.html#corex.evr.network_msg
> You may be able to write some code that manipulates the message to manually 
> add the Contact header. Maybe even the append_hf function may work here, but 
> it seems unlikely.
> 
> James
> 
> On Mon, 8 May 2023 at 12:28, mohsen khashei  wrote:
>> 
>> thanks for the reply I tried it and it didn't work. also I tried 
>> onsend_route with no luck.
>> 
>> On Sun, May 7, 2023 at 7:00 PM Yuriy G  wrote:
>>> 
>>> Try here
>>> https://www.kamailio.org/docs/modules/5.6.x/modules/tm.html#tm.e.loca
>>> l-request
>>> 
>>> However I would doubt first do I do something right by adding contact to 
>>> ACK message wichbasicaly confirmation of the final transaction and contact 
>>> here is meaningless.
>>> 
>>> On Sun, 7 May 2023, 16:48 mohsen khashei,  wrote:
 
 Hi I want to know where kamailio sends ack messages to faiurel messages 
 (status >=400) so that I I add Contact header to the ack.
 I tried WITHINDLG with no luck.
 thanks
 __
 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:
>> 
>> __
>> 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:
> __
> 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: [sr-dev] RFC: selective backports to latest stable as a dedicated git branch

[Olle E. Johansson]

> On 2 May 2023, at 12:10, Daniel-Constantin Mierla  wrote:
> 
> Hello,
> 
> during past on-site/online devel meetings as well as on mailing lists or
> tracker, there were various discussions around the idea or requests to
> make new features available quicker to stable branches.
> 
> Of course, one can do local git cherry-picking, but I thought to bring
> this in discussion and see if makes sense to get something more
> coordinated between developers and community. Therefore I am
> cross-posting to sr-dev and sr-users to see if there is interest for it
> from both communities.
> 
> Somehow inspired from Debian, my first idea would be to create a
> "x.y-backports" branch, where "x.y" is the branch for the stable release
> series. For example, with 5.6 release series built from branch "5.6",
> there could be "5.6-backports" branch which is kept in sync in "5.6" but
> also can get "selected" new features from devel (master branch) backported.
> 
> The "selected" new features should be mostly a matter of the people
> willing to put effort in backporting, but I would consider a list
> recommendations not to end up with devel and backports branches being
> more or less the same. For example, in the "no-backporting" list:
> 
>   - no backporting of completely new modules
>   - no backporting of significant changes to the config file language
> and native scripting interpreter
I would add
   - no changes to database schemas or versions

/O
> 
> In the "ok-to-backport":
> 
>   - updates to enable use with newer versions of external libraries
>   - changes to make some functions/modules to cope better with the core
> infrastructure or end points
> 
> Commits to the backports branch can be proposed via pull requests.
> 
> The backports branch should be done only for latest stable version,
> picking from the development version. Right now it would be 5.6, but we
> can wait till 5.7 is released and then have it for it.
> 
> No packaging and no official releases should be made from backports
> branch, only a git branch to be maintained as a community effort. Of
> course, if someone wants to put more resources into it, we can discuss
> about.
> 
> Anyhow, the first questions would be if such branch sounds good to have
> and if there are people that think they can also contribute to maintain it.
> 
> Cheers,
> Daniel
> 
> -- 
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com
> 
> ___
> Kamailio (SER) - Development Mailing List
> To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

__
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: Kamailio use case

[Olle E. Johansson]

> On 26 Apr 2023, at 00:38, jdprs...@gmail.com wrote:
> 
> Hello All, new subscriber here.
> 
> I've been reading kamailio documentation to check if kamailio has a use case 
> on the architecture for the solution for my company's software, here an small 
> architecture diagram of our solution.
> 
> sipclient <> [ Middleware ] <-> SBC
> 
> Our middle ware is both a sip proxy and media proxy. we have a large number 
> of sip clients but a small calling number, 
> 
> our current bottleneck is that the middleware can't handle a high number of 
> registration, i would like to deploy Kamailio as a load balancer for 
> registrations, making sure it is statefull so registrations and calls are 
> hashed into the same middleware server.
> 
> sipclients < > [ kamailio ] <--> [ middleware1, 
> middleware2,...,middleware N] <-> SBC
> 
> Any thoughts or pointers?
> _
You want to look at the dispatcher module that can dispatch based on hashes.

/O
__
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: rtpengine module: Actions caused by rtpengine_manage() on reply-codes?

[Olle E. Johansson]

> On 25 Apr 2023, at 18:00, Richard Fuchs  wrote:
> 
> On 25/04/2023 10.59, [EXT] Olle E. Johansson wrote:
>>> One workaround (kludge/hack) I've seen is to store the last successful SDP 
>>> somewhere, then intercept and drop the 488 and replay the last offer/answer 
>>> with the stored SDPs. (Absolutely not something I would consider a proper 
>>> solution…)
>> That will break more than it helps.
>> But is there a way to “revert” back. Let’s say I store the last successful 
>> SDPs - can I transmit them to RTPengine to revert. If I have the dialog 
>> module I could very well save them within the context of the dialog.
> Yeah that's exactly what I was talking about. You can replay the last 
> successful rtpengine_offer()/_answer() with a stored SDP, and that would 
> revert the call to the last state. That's what read_sdp_pv and write_sdp_pv 
> config params are for.
Beautiful

>> Would be nice to have a “rtpengine_revert()” command that resets back to the 
>> state before the last INVITE, the last successful state with complete offer 
>> and answer.
> 
> That's what a theoretical handling of 488 etc would entail, yes…


Thank you for the quick answers. And thank you for all your work on RTPengine!

/O

__
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: rtpengine module: Actions caused by rtpengine_manage() on reply-codes?

[Olle E. Johansson]

> On 25 Apr 2023, at 14:04, Richard Fuchs  wrote:
> 
> On 25/04/2023 02.39, [EXT] Olle E. Johansson wrote:
>> So how do we handle a reinvite that is not accepted and tell RTPengine to 
>> fall back?
>> 
>> Consider:
>> 
>> 1. Successfull INVITE/200OK/ACK with alaw only
>> - RTPengine setup and active
>> 2. Re-invite with video added
>> - RTP engine active with video
>> 3. Re-invite denied with 488
>>- How do we tel RTPengine to skip video?
>> 
>> In many cases a re-invite is just hold/off hold or mute/off mute so it’s no 
>> problem, But if we have significant modification of media - ports, types and 
>> codecs (if RTPengine transcodes) a failed re-invite could be hurtful to the 
>> call. Unless there’s some code in RTPengine to handle this.
> 
> Currently there's no way to signal these types of events to rtpengine, and so 
> there's no automatic handling of them. It would be a great feature to have, 
> just someone needs to implement it 嵐
> 
It’s just code, right?
 
> An additional complication is that an event such as a 488 might require 
> cooperation from the SIP layer to rectify (depending on the exact scenario), 
> e.g. another invite/ok subsequent to the 488, but without knowledge of the 
> opposite-side device. In general this would go beyond the scope of what a 
> plain SIP proxy does.
Kamailio is way more than a “plain SIP proxy” - ha ha. But I understand what 
you mean.

> 
> One workaround (kludge/hack) I've seen is to store the last successful SDP 
> somewhere, then intercept and drop the 488 and replay the last offer/answer 
> with the stored SDPs. (Absolutely not something I would consider a proper 
> solution…)
That will break more than it helps.
But is there a way to “revert” back. Let’s say I store the last successful SDPs 
- can I transmit them to RTPengine to revert. If I have the dialog module I 
could very well save them within the context of the dialog.

Would be nice to have a “rtpengine_revert()” command that resets back to the 
state before the last INVITE, the last successful state with complete offer and 
answer.

> 
> For the concrete example you've given, that currently wouldn't even work with 
> explicit signalling to rtpengine as we don't support manipulating entire 
> media sections yet. That's a feature that should™ hopefully™ be coming soon™.

Let’s pray to the gods of realtime communication then :-)

Thank you for your answer.

/O
__
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: sips to sip with TLS proxy

[Olle E. Johansson]

Agree, the SIPS: URL was probably a good idea at the time of writing the SIP 
RFC (20 years ago) since other protocols had secure variants, like HTTPS, LDAPS 
etc.
But the specs wasn’t very well considered and is today generally thought of as 
a bad idea. There has been a few attempts to fix it, but nothing that got 
implemented by a large amount of implementations.

As an example: If your device registers with a SIPS: contact it has to have a 
server cert and accept incoming TLS connections from the server. This will not 
work if the phone is behind NAT.

Better to use the SIP: URI and set transport to TLS.

/O

> On 24 Apr 2023, at 16:22, Daniel-Constantin Mierla  wrote:
> 
> The sips scheme is misleading because people expect to be SIP over TLS, but 
> it is not, it is SIP over secure network, which can be a private network or a 
> vpn. So the sips can meet the requirements even for sip over udp.
> 
> But if you say that the call get's connected, only that is no audio and ends 
> quickly, likely the issue is with the RTP layer, when the sips endpoint 
> expect srtp and the other endpoint does not do it.
> 
> Probably you have to share the ngrep output or pcap with all sip messages of 
> such call.
> 
> Cheers,
> Daniel
> 
> On 24.04.23 16:14, Kiss Zoltán wrote:
>> Hi,
>>  
>> We have to test every scenario, but the latest issue was we have one way rtp 
>> and the call is dropped after 6 seconds cc.
>> In the test the calle was the GS phone which is registered via Kamailio, and 
>> the called party was an another phone witch was registered directly tot he 
>> backend Asterisk.
>> After switching GrandStream phone to sip scheme, then everything is working 
>> fine again.
>>  
>> Zoltan
>>  
>> From: Daniel-Constantin Mierla  
>>  
>> Sent: Monday, April 24, 2023 4:11 PM
>> To: Kamailio (SER) - Users Mailing List  
>> ; Kiss Zoltán  
>> 
>> Subject: Re: [SR-Users] sips to sip with TLS proxy
>>  
>> Hello,
>>  
>> just to clarify: you cannot initiate calls from the phone or you can't sent 
>> calls to the phone?
>>  
>> Cheers,
>> Daniel
>>  
>> On 24.04.23 15:58, Kiss Zoltán wrote:
>> Hi all,
>>  
>> We have a working Kamailio setup, lets call it a transparent proxy for 
>> Asterisk boxes. Its based on domain and dispatcher modules and everything is 
>> working as expected with the test clients (more or less microsip, softphone 
>> for ios, etc). We are tried to register with a Grandstream deskphone today, 
>> and we see that the phone sending sips:xxx in the Reg Contact field for 
>> example. Because the sips schema, the register is working, but we cannot 
>> initiate calls from this phone. If we are turning SIP scheme to sip from 
>> sips in the phone, then everything is working as expected.
>> I think we can transform those requests from sips to sip with Kamailio, but 
>> currently we dont know where can we start.
>> Has anybody a suggestion about this issue? I know that we can transform 
>> ruri, contact, etc with textops, nathelper and a lot of other modules, but 
>> what is the best for this sips->sip translation?
>>  
>> Thanks for your help.
>>  
>> With kind regards,
>> Zoltan
>> 
>> 
>> __
>> 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:
>>  
>> 
>> -- 
>> Daniel-Constantin Mierla -- www.asipto.com 
>> www.twitter.com/miconda  -- 
>> www.linkedin.com/in/miconda 
>> Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com 
>> -- 
> Daniel-Constantin Mierla -- www.asipto.com 
> www.twitter.com/miconda  -- 
> www.linkedin.com/in/miconda 
> Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com 
> __
> 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: rtpengine module: Actions caused by rtpengine_manage() on reply-codes?

[Olle E. Johansson]

> On 24 Apr 2023, at 16:17, Daniel-Constantin Mierla  wrote:
> 
> 
> On 24.04.23 10:29, Olle E. Johansson wrote:
>> 
>>> On 24 Apr 2023, at 10:02, Alex Balashov  wrote:
>>> 
>>> 
>>>> On Apr 24, 2023, at 2:46 AM, Henning Westerholt  wrote:
>>>> 
>>>> Hello,
>>>> 
>>>> actually, this also documented in the kamailio modules readme:
>>>> 
>>>> https://kamailio.org/docs/modules/5.5.x/modules/rtpengine.html#rtpengine.f.rtpengine_manage
>>>> 
>>>> "- If reply to INVITE with code >= 300 do rtpengine_delete()"
>>> Yeah, it is. 
>>> 
>>> But what I think Benoît was really getting at is a question not addressed 
>>> by the documentation or the source code: do I really want to 'delete' for 
>>> _any_ >= 300 reply code, or are there corner cases, like 488 for a reinvite 
>>> (where the standards say the call must continue according to previous 
>>> parameters if a reinvite fails)? And if so, are there any others, or is 488 
>>> truly it?
>> Agree that the reinvite case is interesting, exactly because of the possible 
>> fallback to original state.
>> 
>> I guess there are a number of possible codes, like a timeout (408) or system 
>> problem (5xx) in addition to the “correct” code 488 where fallback could 
>> happen.
> 
> rtpengine_manage() should be used in failure_route only when knowing
> that the call is failing completely. In failure route it should not be
> used for the purpose of an offer, that is for branch_route usage. The
> rtpengine offer()/answer()/delete() functions are there to use when
> specific needs pop up.
> 
> Of course, then config conditions can be used to exclude cases as needed.

So how do we handle a reinvite that is not accepted and tell RTPengine to fall 
back?

Consider:

1. Successfull INVITE/200OK/ACK with alaw only
- RTPengine setup and active
2. Re-invite with video added
- RTP engine active with video
3. Re-invite denied with 488
   - How do we tel RTPengine to skip video?

In many cases a re-invite is just hold/off hold or mute/off mute so it’s no 
problem, But if we have significant modification of media - ports, types and 
codecs (if RTPengine transcodes) a failed re-invite could be hurtful to the 
call. Unless there’s some code in RTPengine to handle this.

/O
__
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: rtpengine module: Actions caused by rtpengine_manage() on reply-codes?

[Olle E. Johansson]

> On 24 Apr 2023, at 10:02, Alex Balashov  wrote:
> 
> 
>> On Apr 24, 2023, at 2:46 AM, Henning Westerholt  wrote:
>> 
>> Hello,
>> 
>> actually, this also documented in the kamailio modules readme:
>> 
>> https://kamailio.org/docs/modules/5.5.x/modules/rtpengine.html#rtpengine.f.rtpengine_manage
>> 
>> "- If reply to INVITE with code >= 300 do rtpengine_delete()"
> 
> Yeah, it is. 
> 
> But what I think Benoît was really getting at is a question not addressed by 
> the documentation or the source code: do I really want to 'delete' for _any_ 
> >= 300 reply code, or are there corner cases, like 488 for a reinvite (where 
> the standards say the call must continue according to previous parameters if 
> a reinvite fails)? And if so, are there any others, or is 488 truly it?

Agree that the reinvite case is interesting, exactly because of the possible 
fallback to original state.

I guess there are a number of possible codes, like a timeout (408) or system 
problem (5xx) in addition to the “correct” code 488 where fallback could happen.

/O
__
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: urn:emergency:service:sos as RURI

[Olle E. Johansson]

> On 4 Apr 2023, at 13:04, Fred Posner  wrote:
> 
> I don’t believe kamailio does rfc8141 but I may not be correct. 
> 
> —fred 
> 
>> On Apr 4, 2023, at 6:03 AM, a.izquie...@zaleos.net wrote:
>> 
>> Hello,
>> 
>> I'm running a Kamailio instance with some routing logic in it. When a UA 
>> sends an INVITE with urn:emergency:service:sos as RURI, Kamailio responds 
>> with a 400 Bad Request URI. I have set debug log level and it looks like the 
>> problem is in the parse_uri.c when sanity_check("1511", "7") is called:
If you read the docs for the sanity module, you’ll soon discover that it’s 
focused on SIP URI’s, not URN’s.  I do think that Kamailio can handle URNs
but you have to be careful when selecting which modules and functions to use 
with those.

Vaguely remember testing this at SIPit, but that was a long time ago :-)
/O
>> 
>> parse_uri(): bad char ':' in state 3 parsed:  (21) / 
>>  (25)
>> 
>> According to RFC8141 (https://www.rfc-editor.org/rfc/rfc8141), this is a 
>> correct URN, but maybe I'm missing something.
>> 
>> Is there a way to make Kamailio parse this RURI?
>> 
>> Kamailio version used: 5.6.4
>> 
>> Thank you!
>> __
>> 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:

__
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] Three year old issue with a new CVE vulnerability report being reported

[Olle E. Johansson]

Hi Kamailians!

A new CVE with a critical severity level was published recently for an almost 
three year old bug,
which was also fixed and released three years ago (CVE-2020-27507).

The issue was fixed in Kamailio 5.4.2 and is not present in newer releases.

The Kamailio project has unfortunately not been involved in the CVE process or
been informed about this old issue being published at this time.

We take vulnerability handling seriously and our process is documented at:
https://www.kamailio.org/wikidocs/security/policy/

The latest stable branch is 5.6, with v5.6.4 released out of it.

Reference:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-27507

Best regards and thanks for flying Kamailio!

The Kamailio dev team

through 
/Olle
__
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: transport=ws causing kamailio to use wrong listen socket

[Olle E. Johansson]

Just curious, in most solutions using web sockets we reuse the existing client 
socket for outbound SIP messages and Kamailio never opens a web socket 
connection outbound, as most clients are just clients, not web servers. That’s 
propably why this was never a problem for anyone.

Is there even code in Kamailio to open an outbound web socket?

/O

> On 28 Jan 2023, at 10:35, Henning Westerholt  wrote:
> 
> Hello,
>  
> indeed Kamailio takes „ws“ as normal web socket, and “wss” as secure 
> websockets. Compare e.g. to the pseudo-variables docs.
>  
> Maybe your Kamailio should insert the location entries with “;transport=wss”?
>  
> Cheers,
>  
> Henning
>  
> -- 
> Henning Westerholt – https://skalatan.de/blog/
> Kamailio services – https://gilawa.com 
>  
> From: Karsten Horsmann mailto:khorsm...@gmail.com>> 
> Sent: Friday, January 27, 2023 6:45 PM
> To: Kamailio (SER) - Users Mailing List  >
> Subject: [SR-Users] Re: transport=ws causing kamailio to use wrong listen 
> socket
>  
> Hi Nathan,
>  
>  
> I use secure websocket and it works with out an issue. Can you provide a bit 
> more Information? Kamailio version an a bit of your config would help the 
> list to figure out why it's not working for you. 
>  
> mailto:nathan.brun...@talksome.com>> schrieb am 
> Fr., 27. Jan. 2023, 16:08:
> Hi all,
> 
> We're hitting an issue while integrating secure websockets in our existing 
> SIP infrastructure using Kamailio.
> 
> When the registration comes in, it causes an entry in our AOR table, with 
> ";transport=ws" appended.
> When we want to send a message to this client (using t_relay), kamailio seems 
> to take 'ws' as being *unsecure* websockets. In turn, this makes Kamailio try 
> to send out the message using a TCP listener - while it should have picked 
> the TLS listener.
> 
> There are some remarks in the sources about ws vs. wss, so i'm struggling to 
> figure out where things go wrong. I've also created github issue #3340 with 
> more details.
> 
> Any help would be appreciated. If this turns out to be a Kamailio bug, i'm 
> happy to provide a patch.
> __
> 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:

__
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: SIP Trunk with multiple phone numbers for account

[Olle E. Johansson]

The IETF GIN standard for SIP was developed for this use-case, and it’s part of 
SIPconnect from SIP forum.

/O

> On 19 Jan 2023, at 15:30, Alex Balashov  wrote:
> 
> The proper place is the user part of the Request URI (R-URI).
> 
>> On Jan 19, 2023, at 9:05 AM, Carlos Escalona  
>> wrote:
>> 
>> Hello all! I have a question. In my system we use a series of VoIP providers 
>> to receive external calls to our telephone numbers, for the same provider we 
>> have several registered numbers and we need our providers to send that 
>> information in some way, so far it does not seem that there is a common way 
>> to do it (report the number that was dialed by the person who made the 
>> call). From what I understand, SIP does not have a place for that 
>> information because there are no things like phone numbers in the 
>> specification, my question is, is there a correct place to send such 
>> information, or is it entirely up to each provider? (Now, the most common is 
>> to have in the RURI and To header, the id of the trunk registered in the 
>> uacreg table) I have seen a couple of options that seem to me the most 
>> “correct”: send the information in the To header or send in a custom header.
>> 
>> I really appreciate any help you can provide.
>> 
>> Atenciosamente,
>> 
>> 
>> Carlos Escalona
>> IT - Development
>>  41 3073-0091 | R 1011  www.techer.com.br
>> 
>> O conteúdo desta mensagem é confidencial. Se você não se encontra na lista 
>> de destinatários ou tenha recebido por engano, não a copie, imprima, envie, 
>> ou utilize, de qualquer forma, seu conteúdo. Neste caso, destrua a mensagem 
>> e, por favor, notifique o remetente.
>> __
>> 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:
> 
> -- 
> Alex Balashov
> Principal Consultant
> Evariste Systems LLC
> Web: https://evaristesys.com
> Tel: +1-706-510-6800
> 
> __
> 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: Authenticated ACK: $au not set?

[Olle E. Johansson]

> On 16 Jan 2023, at 14:41, Benoit Panizzon  wrote:
> 
> Hi Gang
> 
> I have this code snipplet:
> 
>if (has_credentials("$fd")) {
>xlog("L_INFO", "$cfg(route): got $rm with credentials. 
> Validate them!\n");
>   if ($aU == $null) {
>   xlog("L_INFO", "$cfg(route): no auth user, send 
> challenge\n");
>   }
>   auth_challenge("$fd", "0");
>   exit;
>   }
>   }
> 
> Please don't ask if this makes sense, it's a constructed snipplet to show the 
> situation.
> 
> If $rm is INVITE, this works fine, no challenge is being sent, $au is 
> populated.
> If $rm is ACK (some CPE seem to send the Credentials with each message) then 
> $au is $null,
> auth_challenge is called and fails.

SInce you can’t respond to ACK, you can’t challenge it.

ACK is the only SIP request method that you can’t respond to. I won’t start a 
discussion on which transaction it belongs to, because that’s hardcore SIP, but 
to simplify: “ACK is a response to the 200 OK in the INVITE transaction”.

/O
__
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: Too many 200:OK sip responses

[Olle E. Johansson]

> On 5 Jan 2023, at 07:06, Waqar 40  wrote:
> 
> Dear All,
> 
> For a normal call, Kamailio receives 200:OK sip response for the method 
> invite only once but for some calls, it receives 200:OK too many times around 
> 6 to 7. And I also do not receive BYE or any other packets for this kind of 
> call. How can I detect such calls in Kamailio and cancel them? I am inserting 
> data of the calls in the database when the call occurs and deleting it when 
> BYE is received but for these calls as I don't receive BYE so I am unable to 
> delete the record of such calls.
The 200 OK is retransmitted until an ACK is received. You have a routing 
problem somewhere.

> Is there a way to detect such calls? Like How can I count if the number of 
> 200:OK responses is more than one or anything like that?
The problem is not the number of 200 Ok but the missing ACK. Does the 200 OK 
reach the calling end point? Does it transmit an ACK? Is that received by 
Kamailio?

/O

__
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: Call drop when reinvite is proceed

[Olle E. Johansson]

> On 4 Jan 2023, at 14:28, nathan.casti...@snapcom.fr wrote:
> 
> Hello all,
> 
> I'm trying to figure out one problem on my Kamailio server.
> 
> When kamailio receive a reinvite from the infra, I get the error message "477 
> - Unforunately error on sending to next hop" and the call drop. 
> I don't understand why this message appears as the first invite is well 
> answered and the call is going well.
The first invite and a reinvite is routed different ways. The re-invite is in 
dialog and thus follows the record route and the contact address.

> 
> Any ideas how to resolve this issue ?
Read the headers and figure it out :-)

Cheers,
/O

__
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: How to have Kamailio retry backends

[Olle E. Johansson]

> On 21 Dec 2022, at 12:41, Unai Rodriguez  wrote:
> 
> I’d like to implement a counter per INVITE. Do I need to use the counters 
> (https://www.kamailio.org/docs/modules/devel/modules/counters.html 
> ) module 
> or statistics 
> (https://kamailio.org/docs/modules/devel/modules/statistics.html 
> ) module or 
> could someone provide any pointers? Thank you so much
> 
There are plenty of counters. The SNMPstats module also implements quite a lot 
of them.
https://kamailio.org/docs/modules/5.6.x/modules/snmpstats.html

/O

> With best wishes,
> Unai Rodriguez
> On 13 Dec 2022, 18:28 +0100, Henning Westerholt , wrote:
>> Hello,
>> 
>>  
>> regarding limiting the number of gateways retries, you can use different 
>> failure routes (e.g. jump from first to second and then stop), you can keep 
>> an counter, or probably just rely on ds_next_dst() reaching the end of 
>> available gateways in the XAVP (did not checked code).
>> 
>>  
>> Cheers,
>> 
>>  
>> Henning
>> 
>>  
>> --
>> 
>> Henning Westerholt – https://skalatan.de/blog/ 
>> Kamailio services – https://gilawa.com 
>>  
>> From: Unai Rodriguez 
>> Sent: Tuesday, December 13, 2022 5:32 PM
>> To: Kamailio (SER) - Users Mailing List ; 
>> Henning Westerholt 
>> Subject: RE: [SR-Users] How to have Kamailio retry backends
>> 
>>  
>> Hi Henning/All,
>> 
>> After some digging we realized the system was already retrying thanks to 
>> this block on kamailio.cfg
>> 
>> # Try next destionations in failure route
>> failure_route[RTF_DISPATCH] {
>> if (t_is_canceled()) {
>> exit;
>> }
>> # next DST - only for 500 or local timeout
>> if (t_check_status("500")
>> or (t_branch_timeout() and !t_branch_replied())) {
>> if(ds_next_dst()) {
>> t_on_failure("RTF_DISPATCH");
>> route(RELAY);
>> exit;
>> }
>> }
>> }
>> 
>> How can we control the maximum number of retries? Seems to be infinite at 
>> the moment? Or !t_branch_replied()means that each backend can only reply 
>> once?
>> 
>> Thanks you
>> 
>>  
>> With best wishes,
>> 
>> Unai Rodriguez
>> 
>> On 6 Dec 2022, 10:04 +0100, Henning Westerholt > >, wrote:
>> 
>> 
>> Hello,
>> 
>>  
>> you can implement this by using a failure_route. There is one example in the 
>> dispatcher module configuration how to do it.
>> 
>>  
>> Cheers,
>> 
>>  
>> Henning
>> 
>>  
>> --
>> 
>> Henning Westerholt – https://skalatan.de/blog/ 
>> Kamailio services – https://gilawa.com 
>>  
>> From: sr-users > > On Behalf Of Unai Rodriguez
>> Sent: Saturday, December 3, 2022 5:16 PM
>> To: sr-users@lists.kamailio.org 
>> Subject: [SR-Users] How to have Kamailio retry backends
>> 
>>  
>> Dear List,
>> 
>> We’re using Kamailio to load balance MRCP requests to multiple backend 
>> groups with a configuration as follows:
>> 
>> # kamailio.cfg
>> ...
>> ...
>> route[DISPATCH] {
>> if($ua=="mrcp_backend_1") {
>> if(!ds_select_dst("1", "4")) {
>>send_reply("404", "No 
>> destination");
>>exit;
>> }
>> }
>> if($ua=="mrcp_backend_2") {
>> if(!ds_select_dst("2", "4")) {
>>send_reply("404", "No 
>> destination");
>>exit;
>> }
>> }
>> xlog("L_DBG", "--- SCRIPT: going to <$ru> via <$du>\n");
>> t_on_failure("RTF_DISPATCH");
>> route(RELAY);
>> exit;
>> }
>> ...
>> ...
>> 
>> # dispatcher.list
>> 1 sip:mrcp01.server.int:8060;transport=tcp 
>> 
>> 1 sip:mrcp02.server.int:8060;transport=tcp 
>> 
>> 
>> 2 sip:mrcp03.server.int:8060;transport=tcp 
>> 
>> 2 sip:mrcp04.server.int:8060;transport=tcp 
>> 
>> 
>> With this configuration, Kamailio load balances the initial SIP INVITE among 
>> the MRCP servers. After the INVITE, the service communicates directly to the 
>> MRCP servers via SIP (for hanging up the call), MRCPv2 (for sending speech 
>> control messages), and RTP (for sending audio).
>> 
>> We would like to implement a configurable number of retries, so that if a 
>> particular backend times out, Kamailio would retry X times to other 
>> backend(s). In short, something equivalent to HAProxy’s retries 
>> , 
>> but for Kamailio. This probably implies having Kamailio always as part of 
>> our communication (not just load 

Re: [SR-Users] Does Kamailio supports Voice and Video call support for 5G Core

[Olle E. Johansson]

Hello Pooja,

In Open Source people contribute of their time to help when they can. If you 
mail out and does not get any response, it is likely
because no one has an answer and in some cases, that they don’t really 
understand the questions.

Your message has a lot of abbreviations I personally have no understanding of 
and thus I can not make any comment.

Sending a reminder does seldom help. Rephrasing or looking for similar topics 
may help, like asking
“Is anyone here interested in Vo5G and kamailio usage for that core?”

Cheers,
/O

> On 8 Dec 2022, at 10:57, Pooja Yadav  wrote:
> 
> Hello Team,
> 
> This is just a Gentle Reminder. We need to confirm this as we have our 
> customer requirements on priority. 
> Your inputs will be helpful to us.
> 
> 
> Thanks and Regards 
> Pooja Yadav
> 
> 
> 
>> On 05-Dec-2022, at 6:00 PM, Pooja Yadav  wrote:
>> 
>> 
>> Hi Kamailio community,
>> 
>> We just want to check does Kamailio IMS supports the functionality of Voice 
>> and Video call support (Vo5G) with 5G core?
>> If yes, please share the document reference. Else, please guide us when it 
>> will be available.
>> Any plans in upcoming release to support HTTP2 based SBI interface between 
>> P- CSCF and PCF.
>> 
>> Your inputs will be highly appreciated.
>> 
>> Thanks & Regards,
>> Pooja Yadav
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

__
Kamailio - Users Mailing List - Non Commercial Discussions
sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] KAMCTL error

[Olle E. Johansson]

> On 7 Dec 2022, at 11:49, Govind Swamy  wrote:
> 
> 
> 
> Hi
> 
>  am unable to create using kamctl

And you got an error message. Have you checked your configuration?

kamctlrc

/O


__
Kamailio - Users Mailing List - Non Commercial Discussions
sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] acc module => account register messages?

[Olle E. Johansson]

7.1.  acc_log_request(comment)

acc_request reports on a request, for example, it can be used to report on 
missed calls to off-line users who are replied 404 - Not Found. To avoid 
multiple reports on UDP request retransmission, you would need to embed the 
action in stateful processing.


Greetings from IETF in London, where not much SIP-like happens

/O

> On 11 Nov 2022, at 09:01, Henning Westerholt  wrote:
> 
> Hello,
> 
> just add some xlog messages with the content you like to have in the logs, 
> this is the easiest way.
> 
> Cheers,
> 
> Henning
> 
> -- 
> Henning Westerholt – https://skalatan.de/blog/
> Kamailio services – https://gilawa.com
> 
> -Original Message-
> From: sr-users  On Behalf Of Benoît 
> Panizzon
> Sent: Friday, November 11, 2022 9:53 AM
> To: sr-users@lists.kamailio.org
> Subject: [SR-Users] acc module => account register messages?
> 
> Hi
> 
> Is there a way to get register messages into accounting?
> 
> This could come in handy while helping figure out if clients were not 
> registered while calls attemted to reach them.
> 
> --
> 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 PrattelnFax  +41 61 826 93 01
> Schweiz Web  http://www.imp.ch
> __
> 
> __
> Kamailio - Users Mailing List - Non Commercial Discussions 
> sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

__
Kamailio - Users Mailing List - Non Commercial Discussions
sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] tsilo logging

[Olle E. Johansson]

> On 13 Oct 2022, at 13:50, Alex Balashov  wrote:
> 
> Hi,
> 
> When there are no stored transactions for an AOR, it logs this error:
> 
> Oct 13 07:48:18 gw1 /usr/sbin/kamailio[14758]: ERROR: tsilo [ts_append.c:64]: 
> ts_append(): failed to retrieve record for sip:abalas...@sip.evaristesys.com
> 
> But not having transactions ts_store()’d is a rather normal occurrence, 
> right? It is the expected case the vast majority of the time that someone 
> registers. 
> 
> Does that mean one is simply destined to have this scary-looking error, to 
> the syslog ERROR facility, for a normal runtime condition? Is there not some 
> principle against using attention-grabbing error messages this way? Would a 
> patch to fix be welcome?

I think that’s a bad sysadm experience… Could be a WARNING or a DEBUG. 

Do you get an error code indicating that your silo is empty?

/O
__
Kamailio - Users Mailing List - Non Commercial Discussions
sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Log levels severely impacts performance

[Olle E. Johansson]

> On 16 Sept 2022, at 10:12, Henning Westerholt  wrote:
> 
> Hello,
>  
> In the case of rsyslogd the default behaviour is since many years to use 
> asynchronous operations. Refer e.g. to:
> https://www.rsyslog.com/doc/v8-stable/compatibility/v3compatibility.html 
> <https://www.rsyslog.com/doc/v8-stable/compatibility/v3compatibility.html>
THank you! I will read up on that.

/O
>  
> Cheers,
>  
> Henning
>  
> -- 
> Henning Westerholt – https://skalatan.de/blog/ <https://skalatan.de/blog/>
> Kamailio services – https://gilawa.com <https://gilawa.com/>
>  
> From: sr-users  <mailto:sr-users-boun...@lists.kamailio.org>> On Behalf Of Olle E. Johansson
> Sent: Friday, September 16, 2022 9:47 AM
> To: Kamailio (SER) - Users Mailing List  <mailto:sr-users@lists.kamailio.org>>
> Subject: Re: [SR-Users] Log levels severely impacts performance
>  
>  
> 
> 
> On 15 Sept 2022, at 23:20, Alex Balashov  <mailto:abalas...@evaristesys.com>> wrote:
>  
> The problem was either that asynchronous logging was not turned on,
>  
> As standard syslog is very synchronous - how do you turn on asynchronous 
> logging? Curious :-)
>  
> /O

__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Log levels severely impacts performance

[Olle E. Johansson]

> On 15 Sept 2022, at 23:20, Alex Balashov  wrote:
> 
> The problem was either that asynchronous logging was not turned on,

As standard syslog is very synchronous - how do you turn on asynchronous 
logging? Curious :-)

/O__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] How to enforce max_contacts at registration?

[Olle E. Johansson]

> On 16 Aug 2022, at 16:09, Benoit Panizzon  wrote:
> 
> Hi List
> 
> After some more google research and finding this thread
> 
> https://www.mail-archive.com/sr-dev@lists.kamailio.org/msg18728.html
> 
> and some more testing, I think I can conclude that setting 
> 
> $xavp(reg=>max_contacts) = $anyvalue
> 
> is just not working as described in the documentation:
> 
> https://kamailio.org/docs/modules/5.1.x/modules/registrar.html#idp47250596
> 
> So I went ahead and pulled:
> 
> reg_fetch_contacts("location", "$var(saveuri)", "caller")
> to get $(ulc(caller=>count))
> 
> But now I face a new problem: When I get a registration, I don't know
> if this a legitimate update for a existing registration or the insertion
> of a new registration which would exceed the numbers of registration I
> want to allow for that specific AOR.
That’s something that is only handled by SIP outbound with reg-id’s.
Otherwise it’s a SIP-philosophy issue that’s been discussed since RFC 3261
was published…

> 
> Any hint how to solve that challenge or how $xavp(reg=>max_contacts)
> could be made to work as documented?
Limiting the number of contacts and throwing away existing but valid (not 
expired)
entries only work if you are sure there’s one account per device. If that’s
the case, then save() has an option for you.

If there are multiple devices, then it really doesn’t work. Especially if there 
are multiple
devices behind the same NAT.

Cheers,
/O


__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Forward reply in onreply_route

[Olle E. Johansson]

> On 28 Jun 2022, at 15:54, Carsten Bock  wrote:
> 
> Hi,
> 
> Question:
> Is there a way to forward a reply from the reply route and do other stuff 
> afterward? We are currently doing operations on a 183 reply and it would be 
> useful if we could forward the reply before continuing to process other stuff.
> 
> High-Level example:
> 
> route {
>   t_on_reply("REPLY");
>   t_relay();
> }
> 
> onreply_route[REPLY] {
>   // Forward the reply to the Caller
>   t_relay(); // Does not work, as t_relay is only allowed in request and 
> failure-routes
>   
>   // Do other fancy stuff, e.g. a DB Update or anything else
> }
> 
> Any ideas?
I don’t know how to do it that way, but I would add stuff to mqueue and process 
it asynchronously in the background.

/O
> 
> Thanks,
> Carsten
> 
> 
> 
> 
> --
> Carsten Bock I CTO & Founder
> 
> ng-voice GmbH
> Trostbrücke 1 I 20457 Hamburg I Germany
> T +49 179 2021244 I www.ng-voice.com 
> Registry Office at Local Court Hamburg, HRB 120189
> Managing Directors: Dr. David Bachmann, Carsten Bock
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>  * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:
>  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] How to handle a 301 redirect request from a client?

[Olle E. Johansson]

> 24 juni 2022 kl. 17:34 skrev Patrick Karton :
> 
> if something is still  appended to From User thats means you updated $fU also 
> before update it in branch_route.
> 
> surely you update $fU also in route[IMP_ROUTE_TO_CORE] thats why.
> 
> all updates to $fU must be done once otherwise you concatenate it.
Is this documented anywhere? If not, we need to add it to docs.

/O
> 
> 
> 
> 
> 
> De : Benoît Panizzon mailto:benoit.paniz...@imp.ch>>
> Envoyé : vendredi 24 juin 2022 16:10
> À : Patrick Karton  >
> Cc : Kamailio (SER) - Users Mailing List  >
> Objet : Re: [SR-Users] How to handle a 301 redirect request from a client?
> 
> Salut Patrick
> 
> > since you want to apply manipulation on the new user received from
> > 300 response you need to use branch_route for this. thats one of his
> > purpose.
> 
> So that is what I attempted...
> 
> if (t_check_status("(301)|(302)") or (t_branch_timeout() and 
> !t_branch_replied())) {
> t_on_branch("TEST_BR");
> route(IMP_ROUTE_TO_CORE);
> exit;
> }
> 
> branch_route[TEST_BR]
> {
> xlog("L_ERR", "$cfg(route): HERE WE ARE\n"); # To verify via logs 
> this was triggered
> $fU = "+41441234567";
> }
> 
> I still end up with +41441234567 being appended to the From User HF I
> have set previously for the invite towards the CPE which then replied
> with 302
> 
> For better understanding, this is the situation:
> 
> We want to use e164 on the 'core' as this is the format we have defined
> as 'normalized' format and which is also in use on IC to other TSP.
> Only to/from the customer CPE we translate numbers to from the mostly
> used national format.
> 
> Basically replacing +41 with '0' and + with '00' and the other way round.
> 
> So in this example From user is +41441234567 and location lookup is performed.
> Then From user is translated to 0441234567 to reflect the national
> notation and display the callerID in a usual format to the customer.
> 
> But when I get a 302 from that CPE and need to send the call back on an
> IC. I want to preserve the original From: username and translate
> it back to e164. But as I already have set $fU = "0441234567" when I do an
> additional $fU = "+41441234567" in branch_route, I and up with
> 
> From: "John Doe" <0441234567+41441234...@sip.example.com 
> >;user=phone
> 
> as setting $fU is APPENDING. No matter if I do this on a failure route
> or a branch route.
> 
> Or did I miss a trick? :-)
> 
> Would I need to also use branch_route to send the initial call towards
> the customer CPE and set the 'localized' $fU there? Is this message
> being dropped and the original one used again when triggering
> failure_route? Is this how it's supposed to work?
> 
> --
> 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 PrattelnFax  +41 61 826 93 01
> Schweiz Web  http://www.imp.ch 
> __
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>  * sr-users@lists.kamailio.org 
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:
>  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
> 


signature.asc
Description: Message signed with OpenPGP
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] [Kamailio-Business] Kamailio v5.6.0 Released - new major version is out

[Olle E. Johansson]

> On 23 May 2022, at 15:00, Daniel-Constantin Mierla  wrote:
> 
> Kamailio v5.6.0 is out – it comes with 7 new modules and a considerable
> set of improvements touching again more than 90 existing modules.

A big thank you to all developers! Great work!

/O
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] unable to get local issuer certificate

[Olle E. Johansson]

tls_dump_cert_info(): tls_connect: server certificate issuer:/C=US/O=Microsoft 
Corporation/CN=Microsoft RSA TLS CA 01

THis is not sectigo signed - is my guess. It’s the other sides cert that 
Kamailio can’t verify. You need to add that CA cert to the Kamailio CA store.

/O

> On 5 May 2022, at 14:09, Володимир Іванець  wrote:
> 
> tls_dump_cert_info(): tls_connect: server certificate 
> issuer:/C=US/O=Microsoft Corporation/CN=Microsoft RSA TLS CA 01

__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] DMQ version compatability

[Olle E. Johansson]

Maybe we should include a “version” field in all DMQ messages, like we have a 
version for database tables to avoid compatibility issues. If we get a DMQ with 
the wrong version compared with the module running’s idea of current DMQ 
version for that module, we can just ignore it.

/O

> On 18 Mar 2022, at 16:56, Alex Balashov  wrote:
> 
> It sounds like this is a broad-based principle about DMQ compatibility that 
> is generalised beyond any specific module. Are you looking for an alternate 
> set of rules that specially apply to only one module and not to any other 
> module, or are you looking for a “de facto” exception that cannot be endorsed 
> in principle?
> 

> —
> Sent from mobile, with due apologies for brevity and errors.
> 
>> On Mar 18, 2022, at 11:52 AM, Ben Kaufman  wrote:
>> 
>> 
>> Daniel,
>>  
>> In a recent thread you stated the following regarding DMQ compatibility 
>> between versions:
>> “if you do dmq replication between kamailio systems running different major 
>> versions, then it is likely to get memory leaks due to replication of data 
>> and most probably cannot be fixed. This is because internal structures of 
>> modules (also dmq commands) can change, practically what an instance does is 
>> not ensured to happen on the other instance. Just for example, from my mind, 
>> htable got some changes during past releases, dmq also has significant 
>> enhancements by getting support for more transport protocols.”
>> 
>> Is it possible to get a bit more clarification on this, particularly as it 
>> relates to DMQ_USRLOC?  I’m hoping to do rolling updates, but don’t want to 
>> end up in a situation where I’ve caused myself more problems than I’ve 
>> solved.
>>  
>>  
>> Ben Kaufman
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>>  * sr-users@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to the 
>> sender!
>> Edit mailing list options or unsubscribe:
>>  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>  * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:
>  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Dialog module and DMQ

[Olle E. Johansson]

Hi!

The documentation on the DMQ support in the dialog module is a bit short, so I 
will ask here for clarifications:

If I want to enable a rough limit on concurrent calls - will all servers share 
a $DLG_count ?

Will get_profile_size() return the number of dialogs belonging to a profile on 
ALL servers?

Thank you!

/Olle



__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Re-using an existing TLS connection

[Olle E. Johansson]

> On 25 Feb 2022, at 09:32, Matthias Urlichs  wrote:
> 
> Signed PGP part
> Hello,
> 
> My problem: our provider opens a TLS connection to us. They want us to use 
> this channel for outgoing calls, instead of opening a new SIP connection to 
> their server.
> 
> Is there a way to teach Kamailio to do that?

As Henning already answered, yes. But if you are security-consious it would 
from a SIP security standpoint require that their side present a client cert 
that you can verify so you are really sending calls to the right provider.

/O


signature.asc
Description: Message signed with OpenPGP
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] ?= kamailio : how to xlog the value of "myself"=?utf-8?q? ?

[Olle E. Johansson]

Hello!

“myself” is a function that has one or several domains in it configured in your 
configuration. What you normally want to log is the domain that matches myself, 
with could be $rD if you are checking the domain of the request URI.

/O
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] SEMS license with kamailio and rtpengine

[Olle E. Johansson]

  
> · Please have a look to the GPLv2 FAQ, many topics you’ve raised are 
> discussed there https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html 
> <https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html>
> · You should really consult a lawyer for this specific questions
>  
> Regarding the licence of the configuration (native script vs. KEMI) – my 
> understanding would be that a native Kamailio cfg script would be independent 
> of GPL as its interpreted (and practically the customer gets the “source 
> code” anyway). But KEMI LUA code that is pre-compiled would fall under the 
> GPL, so the customer has a right to get the source code for it. Compare e.g., 
> to this: 
> https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfInterpreterIsGPL 
> <https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfInterpreterIsGPL>
>  
> Cheers,
>  
> Henning
>  
> -- 
> Henning Westerholt – https://skalatan.de/blog/ <https://skalatan.de/blog/>
> Kamailio services – https://gilawa.com <https://gilawa.com/>
>  
> From: sr-users  
> <mailto:sr-users-boun...@lists.kamailio.org> On Behalf Of Olle E. Johansson
> Sent: Thursday, February 10, 2022 8:13 AM
> To: Kamailio (SER) - Users Mailing List  
> <mailto:sr-users@lists.kamailio.org>
> Subject: Re: [SR-Users] SEMS license with kamailio and rtpengine
>  
> Hi Seven!
> Note that many of these questions open a legal discussion that has been going 
> on for many years. I base my answers on what I know, which may not be the 
> full truth. Regardless, I have been involved in these kind of discussions for 
> almost 30 years of working in open source.
>  
> First, note that there are two kind of situations to observe. One is when 
> your application is executing in a system. The other is the license of the 
> written source code files. 
>  
> Secondly, license and copyright are two different things. You always have the 
> copyright to your source code.
>  
> In Kamailio there are source code files that have a different license than 
> the rest of the files. That means that if you copy that source code and 
> create a new product that license applies.
>  
> Kamailio as a whole is released under GPL version 2. When you run Kamailio in 
> your server, that license applies to it all, regardless of the license of 
> various source code files.
>  
> Also note that I base this discussion on a delivery of a system to a 
> customer. When you run Kamailio as a service you do not deliver (according to 
> GPL v2) and the customer doesn’t have the same rights to the source.
>  
> Also note that (as other persons has pointed out) that it’s the recipient of 
> the binaries that has the rights, not the world. If I am not your customer, I 
> can’t demand the source code according to the GPL. The customer that receives 
> the code has the right to do whatever they want with it - like publishing the 
> source on GitHub for the world to enjoy.
>  
>  
>  
> 
> 10 feb. 2022 kl. 00:16 skrev Seven Du  <mailto:dujinf...@gmail.com>>:
>  
> I have some questions on this, e.g. on Kamailio:
>  
> 1. The core and some modules is GPL. I packaged that without change, and sell 
> to a customer. and when the customer asks for source, I told him to download 
> from the kamailio website, since I didn't change anything. Is that correct?
> How you distribute the source code to the customer is irrelevant here. Note 
> that if you end up having to provide it on a floppy disk or a USB stick, you 
> can charge for that according to the GPL :-)
> 
>  
> 2. I can also host the source on my own website, with some more helper 
> scripts for building and packaging. That should be better?
> I can’t judge if it’s better or worse, it has very little relevance to with 
> the license. Just make sure that you include the signatures made by the 
> Kamailio team so the customer can trace it back to the source and make sure 
> there’s no changes.
>  
> 
>  
> 3. I write a new module, 100% code wrote from scratch, just follow the module 
> guidelines or example code to expose/add hooks to core,  dynamically loaded 
> into kamailio. Do I need to use GPL or can it be any license or even closed 
> source? can I sell the standalone module in binary?
> Your source code has to be licensed in a license that can end up being 
> compatible with GPL. You can not have a commercial license on it, since when 
> executing it as part of Kamailio, GPL applies.
> Since your module ends up being GPL while running in a system you deliver for 
> a fee or for free to your customer, your customers has a right to the source 
> code.
>  
>  
> 
>  
> 4. my module still should be GPL sin

Re: [SR-Users] SEMS license with kamailio and rtpengine

[Olle E. Johansson]

> On 10 Feb 2022, at 09:01, Daniel-Constantin Mierla  wrote:
> 
> Hello,
> 
> On 10.02.22 08:36, Henning Westerholt wrote:
>> Hello,
>>  
>> just to add to the discussion:
>>  
>> Please have a look to the GPLv2 FAQ, many topics you’ve raised are discussed 
>> there https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html 
>> <https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html>
>> You should really consult a lawyer for this specific questions
>>  
>> Regarding the licence of the configuration (native script vs. KEMI) – my 
>> understanding would be that a native Kamailio cfg script would be 
>> independent of GPL as its interpreted (and practically the customer gets the 
>> “source code” anyway). But KEMI LUA code that is pre-compiled would fall 
>> under the GPL, so the customer has a right to get the source code for it. 
>> Compare e.g., to 
>> this:https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfInterpreterIsGPL
>>  
>> <https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfInterpreterIsGPL>
>>  
> I guess that the pre-compile is done by the luac, because Kamailio does not 
> have such feature. Kamailio can only load a lua script (plain or 
> pre-compiled) and push it as a parameter to liblua functions. In my opinion 
> this is only file/data loading from kamailio point of view, definitely does 
> not seem a linking/compile operation. It can be seen as something similar to 
> reading SIP messages from the socket (everything is a file descriptor in 
> unix/linux philosophy) and I assume nobody considers that received/sent SIP 
> messages have to be GPL.
> 
> From this perspective, none of the config files (no matter they are native 
> scripting, lua, python, javascript, etc...) are forced to be GPL, it is the 
> decision of the config author what's its license.
> 
I suggest that we formally clarify this just to avoid any misunderstandings, 
much like we did in Asterisk.

/O
> Cheers,
> Daniel
> 
> 
> 
>> Cheers,
>>  
>> Henning
>>  
>> -- 
>> Henning Westerholt – https://skalatan.de/blog/ <https://skalatan.de/blog/>
>> Kamailio services – https://gilawa.com <https://gilawa.com/>
>>  
>> From: sr-users  
>> <mailto:sr-users-boun...@lists.kamailio.org> On Behalf Of Olle E. Johansson
>> Sent: Thursday, February 10, 2022 8:13 AM
>> To: Kamailio (SER) - Users Mailing List  
>> <mailto:sr-users@lists.kamailio.org>
>> Subject: Re: [SR-Users] SEMS license with kamailio and rtpengine
>>  
>> Hi Seven!
>> Note that many of these questions open a legal discussion that has been 
>> going on for many years. I base my answers on what I know, which may not be 
>> the full truth. Regardless, I have been involved in these kind of 
>> discussions for almost 30 years of working in open source.
>>  
>> First, note that there are two kind of situations to observe. One is when 
>> your application is executing in a system. The other is the license of the 
>> written source code files. 
>>  
>> Secondly, license and copyright are two different things. You always have 
>> the copyright to your source code.
>>  
>> In Kamailio there are source code files that have a different license than 
>> the rest of the files. That means that if you copy that source code and 
>> create a new product that license applies.
>>  
>> Kamailio as a whole is released under GPL version 2. When you run Kamailio 
>> in your server, that license applies to it all, regardless of the license of 
>> various source code files.
>>  
>> Also note that I base this discussion on a delivery of a system to a 
>> customer. When you run Kamailio as a service you do not deliver (according 
>> to GPL v2) and the customer doesn’t have the same rights to the source.
>>  
>> Also note that (as other persons has pointed out) that it’s the recipient of 
>> the binaries that has the rights, not the world. If I am not your customer, 
>> I can’t demand the source code according to the GPL. The customer that 
>> receives the code has the right to do whatever they want with it - like 
>> publishing the source on GitHub for the world to enjoy.
>>  
>>  
>> 
>> 
>> 10 feb. 2022 kl. 00:16 skrev Seven Du > <mailto:dujinf...@gmail.com>>:
>>  
>> I have some questions on this, e.g. on Kamailio:
>>  
>> 1. The core and some modules is GPL. I packaged that without change, and 
>> sell to a customer. and when the customer asks for source, I told him to 
>> download from the kamail

Re: [SR-Users] SEMS license with kamailio and rtpengine

[Olle E. Johansson]

Hi Seven!
Note that many of these questions open a legal discussion that has been going 
on for many years. I base my answers on what I know, which may not be the full 
truth. Regardless, I have been involved in these kind of discussions for almost 
30 years of working in open source.

First, note that there are two kind of situations to observe. One is when your 
application is executing in a system. The other is the license of the written 
source code files.

Secondly, license and copyright are two different things. You always have the 
copyright to your source code.

In Kamailio there are source code files that have a different license than the 
rest of the files. That means that if you copy that source code and create a 
new product that license applies.

Kamailio as a whole is released under GPL version 2. When you run Kamailio in 
your server, that license applies to it all, regardless of the license of 
various source code files.

Also note that I base this discussion on a delivery of a system to a customer. 
When you run Kamailio as a service you do not deliver (according to GPL v2) and 
the customer doesn’t have the same rights to the source.

Also note that (as other persons has pointed out) that it’s the recipient of 
the binaries that has the rights, not the world. If I am not your customer, I 
can’t demand the source code according to the GPL. The customer that receives 
the code has the right to do whatever they want with it - like publishing the 
source on GitHub for the world to enjoy.



> 10 feb. 2022 kl. 00:16 skrev Seven Du :
> 
> I have some questions on this, e.g. on Kamailio:
> 
> 1. The core and some modules is GPL. I packaged that without change, and sell 
> to a customer. and when the customer asks for source, I told him to download 
> from the kamailio website, since I didn't change anything. Is that correct?
How you distribute the source code to the customer is irrelevant here. Note 
that if you end up having to provide it on a floppy disk or a USB stick, you 
can charge for that according to the GPL :-)
> 
> 2. I can also host the source on my own website, with some more helper 
> scripts for building and packaging. That should be better?
I can’t judge if it’s better or worse, it has very little relevance to with the 
license. Just make sure that you include the signatures made by the Kamailio 
team so the customer can trace it back to the source and make sure there’s no 
changes.

> 
> 3. I write a new module, 100% code wrote from scratch, just follow the module 
> guidelines or example code to expose/add hooks to core,  dynamically loaded 
> into kamailio. Do I need to use GPL or can it be any license or even closed 
> source? can I sell the standalone module in binary?
Your source code has to be licensed in a license that can end up being 
compatible with GPL. You can not have a commercial license on it, since when 
executing it as part of Kamailio, GPL applies.
Since your module ends up being GPL while running in a system you deliver for a 
fee or for free to your customer, your customers has a right to the source code.


> 
> 4. my module still should be GPL since I have to call GPL code in kamailio 
> source, e.g. string functions in core. or maybe it's ok if string functions 
> in kamailio core is BSD?
When executing ALL of Kamailio is GPL, including all linked modules.

> 
> 5. If my module link to a 3rd party lib (e.g. libclosed-source.so or 
> libclosed-source.a I think there's no difference?) which is not open source 
> (but free to sell), can I sell it w/o the source of libclosed-source ?
Linking means that you execute in the same processes and according to most this 
means that GPL applies. That’s why we have a lot of protocols where most people 
think that GPL does not apply, even though some people want to discuss that. In 
my personal view it’s ok to write commercial software that communicates over 
RPC or by using the http_client with Kamailio.

In Asterisk, the license specially permits this use of the various Asterisk 
protocols since there was discussions. Most Asterisk developers believed it 
wasn’t necessary and that GPL did not apply when using protocol based API’s. 
But nevertheless, just to avoid discussions, this was clarified in the license.
> 
> 6. If answer to 5 is yes, I can write my own libclosed-source and sell with 
> whatever license?
You can, but if it links to Kamailio in run-time, then it will at that point 
become GPL licensed regardless of what you have written. That’s why many 
companies stay away from GPL, especially libraries that are licensed with GPL, 
because it can affect your own licenses.

> 
> 7. Regards to KEMI, if I write routing scripts with Lua (compiled with luac) 
> and sell to a customer, should I open source the Lua code? The Lua code calls 
> Kamailio core functions which might be GPL.
That is an interesting question which I’m not ready to answer. I think the 
intention of the Kamailio dev team is that your code should 

Re: [SR-Users] SEMS license with kamailio and rtpengine

[Olle E. Johansson]

> On 9 Feb 2022, at 08:20, Juha Heinanen  wrote:
> 
> In case of SEMS and Kamailio the added value a company can provide on
> the free source code is on how it is configured (Kamailio) or what kind
> of applications have been written using it (SEMS).
> 
Exactly.

With Kamailio you can do almost anything in the configuration, especially now 
that we have KEMI.

But there are still old-fashioned managers out there that think
- they’re solution is UNIQUE
- they have to modify the source and keep the changes
- they have to write a kamailio module in C for their unique business logic

In most cases all these assumptions are wrong.

If you do modify the source or add your own module and distribute it, you are 
likely going to have GPL issues. Don’t go down that rabbit hole.

/O
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] SEMS license with kamailio and rtpengine

[Olle E. Johansson]

> 8 feb. 2022 kl. 17:51 skrev Alex Balashov :
> 
> You do not need to purchase a licence to incorporate SEMS into a service 
> platform to sell telephony to customers. You may not, however, sell SEMS per 
> se.
> 
That’s wrong. You may sell GPL-licensed software. But if you changed the code, 
the GPL forces you to make the source of the code available to your customers 
under GPL, should they request it.

There are many boxes out there selling with Asterisk in it, with Asterisk still 
under GPL.

Only if you changed SEMS code and want to sell it under a non-GPL commercial 
license you will need to discuss licensing with the license holders.

/O
> That’s the very, very simple version.
> 
> —
> Sent from mobile, with due apologies for brevity and errors.
> 
>> On Feb 8, 2022, at 11:47 AM, Patrick Karton  wrote:
>> 
>> 
>> Hello im using kamailio and rtpengine to build a custom SBC.
>> 
>> i was using freeswitch as my b2bua but i noticed a lot of issues when cps 
>> and simultaneous increased so i tried sems and i have better results.
>> 
>> But i do not really understand sems license so i want to know if i can use 
>> it.
>> 
>> i read from sems github
>> 
>> "It is licensed under dual
>>  license terms, the GPL (v2+) and proprietary license. This
>>  program is released under the GPL with the additional exemption
>>  that compiling, linking, and/or using OpenSSL is allowed.
>> 
>>  For a license to use SEMS under non-GPL terms, please contact
>>  FRAFOS GmbH at i...@frafos.com"
>> 
>> so my question is if i want to use sems as b2bua with kamailio and rtpengine 
>> and make profit of it do i need to purchase a license each time i want to 
>> sell it to a customer ?
>> 
>> 
>> Thanks.
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>>  * sr-users@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to the 
>> sender!
>> Edit mailing list options or unsubscribe:
>>  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>  * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:
>  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



signature.asc
Description: Message signed with OpenPGP
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] REGISTER with http_async_client ?

[Olle E. Johansson]

> On 3 Feb 2022, at 09:54, Cyril Ramière  wrote:
> 
> Hi Olle, 
> 
> I prefer not to use it since you rightly pointed out that it will block the 
> thread during the request
Depends of course of your HTTP server… And the number of UDP/TCP listeners. It 
won’t block all listeners.
Since registrations are less time-critical, you could handle the request 
asynchronously in a background process and thus not block the listener which 
would lead to more or less the same as using http_asynch. Just fire up a large 
amount of background processes :-)

/O
> 
> Since a lot of sip phones will register & interact with kamailio it could 
> seriously hurt the performance.
> 
> I will implement caching for sure regardless of the 
> async/non-async-non-optimal solution, but I still hope that this issue will 
> be solved.
> 
> Cheers,
> 
> Cyril
> 
> Le jeu. 3 févr. 2022 à 07:57, Olle E. Johansson  <mailto:o...@edvina.net>> a écrit :
> 
> 
>> On 2 Feb 2022, at 23:58, Cyril Ramière > <mailto:cyril.rami...@gmail.com>> wrote:
>> 
>> Hi Karsten,
>> 
>> Thanks for the clue, unfortunately I can't use this module because the 
>> clients are "dumb" sip phones.
>> 
>> The goal of my implementation is to use our application API to handle the 
>> login.
>> 
>> The plan was that a sip phone sends a REGISTER, I ask the API endpoint if 
>> this user/password is ok to connect and allow/deny based on the reply and 
>> informations provided by the API.
>> 
>> Everything is relying on the fact that I can make my HTTP call when handling 
>> the REGISTER, sadly for me, it doesn't work and I still can't figure why.
> Try http_client. I’ve used it a lot of time for authentication. It will block 
> your thread while waiting for response, but you can handle some of those 
> issues by caching secrets for a short time with htable.
> 
> /O
>> 
>> Cheers,
>> 
>> Cyril
>> 
>> Le mer. 2 févr. 2022 à 19:49, Karsten Horsmann > <mailto:khorsm...@gmail.com>> a écrit :
>> Hi Cyril,
>> 
>> This Kamailio module could imho do the same 
>> 
>> https://www.kamailio.org/docs/modules/devel/modules/auth_ephemeral.html 
>> <https://www.kamailio.org/docs/modules/devel/modules/auth_ephemeral.html>
>> 
>> 
>> Cyril Ramière mailto:cyril.rami...@gmail.com>> 
>> schrieb am Do., 27. Jan. 2022, 08:04:
>> Hi there,
>> 
>> I have a weird issue with kamailio (latest docker image 
>> kamailio-ci:5.5.2-alpine) and http_async_client.
>> 
>> Before posting a lot of logs, let me describe what I want to achieve.
>> 
>> I have a Kamailio and a SIP Phone.
>> 
>> The SIP phone sends a REGISTER to kamailio, then in my routing block, I 
>> check if I have an Authorization header.
>> 
>> Since I don't have an Authorization (first message), I use "www_challenge()".
>> This replies to the SIP phone, and then the SIP phone sends a new REGISTER 
>> with the correct Authorization header.
>> 
>> So far so good.
>> 
>> Now, when I get the REGISTER with Authorization header, I want to ask an 
>> HTTP endpoint if this user is allowed to connect and check the password 
>> using http_async_query().
>> 
>> The problem is that when the transaction resumes, the tmx module is unhappy 
>> and throws this error :
>> 
>> 30(36) CRITICAL: tmx [t_var.c:546]: pv_get_tm_reply_code(): no picked branch 
>> (-1) for a final response in MODE_ONFAILURE
>> 
>> And a 500 error is sent back to the sip phone.
>> The AUTH_REPLY route is still called and I can use the $http* values.
>> 
>> Do you see something that I am doing wrong or missing in my logic?
>> Is pausing/resuming to use the async http client is allowed if I'm handling 
>> a REGISTER transaction?
>> 
>> Here's a simplified version of my routing block (not far from reality):
>> 
>> # SNIP 
>> 
>> request_route{
>> route(AUTH);
>> 
>> route[AUTH]{
>> if (is_method("REGISTER"){
>> if(no_auth_header){
>> www_challenge("$td","1");
>> exit;
>> }
>> else{
>> t_newtran();
>> http_async_query("http://xxx.xxx.xxx.xxx:9000/auth?foo=bar 
>> <http://xxx.xxx.xxx.xxx:9000/auth?foo=bar>", "AUTH_REPLY");
>> }
>> }
>> }
>> 
>> route[AUTH_REPLY]{
>> xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
>> }
>> 
>

Re: [SR-Users] REGISTER with http_async_client ?

[Olle E. Johansson]

> On 2 Feb 2022, at 23:58, Cyril Ramière  wrote:
> 
> Hi Karsten,
> 
> Thanks for the clue, unfortunately I can't use this module because the 
> clients are "dumb" sip phones.
> 
> The goal of my implementation is to use our application API to handle the 
> login.
> 
> The plan was that a sip phone sends a REGISTER, I ask the API endpoint if 
> this user/password is ok to connect and allow/deny based on the reply and 
> informations provided by the API.
> 
> Everything is relying on the fact that I can make my HTTP call when handling 
> the REGISTER, sadly for me, it doesn't work and I still can't figure why.
Try http_client. I’ve used it a lot of time for authentication. It will block 
your thread while waiting for response, but you can handle some of those issues 
by caching secrets for a short time with htable.

/O
> 
> Cheers,
> 
> Cyril
> 
> Le mer. 2 févr. 2022 à 19:49, Karsten Horsmann  > a écrit :
> Hi Cyril,
> 
> This Kamailio module could imho do the same 
> 
> https://www.kamailio.org/docs/modules/devel/modules/auth_ephemeral.html 
> 
> 
> 
> Cyril Ramière mailto:cyril.rami...@gmail.com>> 
> schrieb am Do., 27. Jan. 2022, 08:04:
> Hi there,
> 
> I have a weird issue with kamailio (latest docker image 
> kamailio-ci:5.5.2-alpine) and http_async_client.
> 
> Before posting a lot of logs, let me describe what I want to achieve.
> 
> I have a Kamailio and a SIP Phone.
> 
> The SIP phone sends a REGISTER to kamailio, then in my routing block, I check 
> if I have an Authorization header.
> 
> Since I don't have an Authorization (first message), I use "www_challenge()".
> This replies to the SIP phone, and then the SIP phone sends a new REGISTER 
> with the correct Authorization header.
> 
> So far so good.
> 
> Now, when I get the REGISTER with Authorization header, I want to ask an HTTP 
> endpoint if this user is allowed to connect and check the password using 
> http_async_query().
> 
> The problem is that when the transaction resumes, the tmx module is unhappy 
> and throws this error :
> 
> 30(36) CRITICAL: tmx [t_var.c:546]: pv_get_tm_reply_code(): no picked branch 
> (-1) for a final response in MODE_ONFAILURE
> 
> And a 500 error is sent back to the sip phone.
> The AUTH_REPLY route is still called and I can use the $http* values.
> 
> Do you see something that I am doing wrong or missing in my logic?
> Is pausing/resuming to use the async http client is allowed if I'm handling a 
> REGISTER transaction?
> 
> Here's a simplified version of my routing block (not far from reality):
> 
> # SNIP 
> 
> request_route{
> route(AUTH);
> 
> route[AUTH]{
> if (is_method("REGISTER"){
> if(no_auth_header){
> www_challenge("$td","1");
> exit;
> }
> else{
> t_newtran();
> http_async_query("http://xxx.xxx.xxx.xxx:9000/auth?foo=bar 
> ", "AUTH_REPLY");
> }
> }
> }
> 
> route[AUTH_REPLY]{
> xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
> }
> 
> }
> # END SNIP
> 
> 
> Best regards!
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@lists.kamailio.org 
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
> 
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@lists.kamailio.org 
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
> 
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>  * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:
>  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Call Preservation Mode in Kamailio

[Olle E. Johansson]

> On 9 Jan 2022, at 11:48, varun pratapsingh  wrote:
> 
> Happy New Year 2022 Everyone. Wish you a lot of innovation this year!
> 
> I was just curious to know if any of us had handled the mid-call failures 
> using the Kamailio. I am writing a SIP Client to handle the failures by using 
> the DNS SRV based failover and Fallback approach where I am using two 
> Kamailio instances as Outbound Proxy resolved by DNS SRV lookup. Everything 
> is fine except for on-going calls. How to handle the mid-call failovers? Is 
> there any way in Kamailio like Call Preservation mode or something?
The SIP standards document setting up a call successfully with DNS support - 
NAPTR and SRV. But mid-call failover is not specified anywhere. There are some 
hints in RFC 3263 on using SRV names in route headers that could be interesting.

/O
> 
> Any suggestions or ideas to handle midcall failover so that if a current 
> Outbound Proxy goes down then all the ongoing calls can be seamlessly routed 
> through another Kamailio (secondary).
> 
> Thanks and Regards
> Varun
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>  * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:
>  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Forcing Outbound Socket

[Olle E. Johansson]

> 10 nov. 2021 kl. 18:21 skrev Ross McKillop :
> 
> Hi,
> 
> Thanks, I was almost certain that is set but it seems it may not be so will 
> double check that, thank you :)
> 
> Now to solve the other issue….
Just a nit-picking note: All these are non-standard fixes. The standard based 
way is to use the outbound module, it’s the way to allow the sip server to use 
an inbound TCP connection for outbound requests. This applies to client2server 
connections.

For server2server connections there is a requirement of mutual TLS auth in 
order to be able to reuse the connection in both directions.

Cheers,
/O
> 
> Ross
> 
>> On 10 Nov 2021, at 17:14, Federico Cabiddu > > wrote:
>> 
>> Hi,
>> to force kamailio to use, for outbound connections, a specific tcp port 
>> (define in a "listen" directive), you have to set the reuse_tcp_port 
>> parameter (https://www.kamailio.org/wiki/cookbooks/5.5.x/core#tcp_reuse_port 
>> ).
>> 
>> Cheers,
>> 
>> Federico
>> 
>> On Wed, Nov 10, 2021 at 4:36 PM Ross McKillop > > wrote:
>> Hi All,
>> 
>> Try as I may I cannot force an outbound TCP request to use a non-ephemeral 
>> source port.
>> 
>> Looking at the documentation it seems that as long as I have a line like
>> 
>> listen=tcp:10.30.0.55:3339 
>> 
>> I should be able to force an outbound connection to originate from that host 
>> and port, i.e. to establish a persistent connection from a specific socket 
>> to a remote host, but having tried to set it via $fs and set_send_socket() 
>> it always uses an ephemeral port.
>> 
>> Ideally I would like kamailio to use a specific source port for contacting a 
>> specific remote host and keep the TCP socket established, and it seems like 
>> it should be simple enough to do but it's not working as expected.
>> 
>> Best,
>> Ross
>> 
>> 
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>>   * sr-users@lists.kamailio.org 
>> Important: keep the mailing list in the recipients, do not reply only to the 
>> sender!
>> Edit mailing list options or unsubscribe:
>>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
>> 
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>>  * sr-users@lists.kamailio.org 
>> Important: keep the mailing list in the recipients, do not reply only to the 
>> sender!
>> Edit mailing list options or unsubscribe:
>>  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
>> 
> 
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>  * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:
>  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



signature.asc
Description: Message signed with OpenPGP
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] sql_xquery return 1 on 0 rows?

[Olle E. Johansson]

Just to brainstorm: We may want to look into implementing something like the 
old xpath or new shiny jpath (for json) for the xavps.

And if someone volunteer to write more xavp example code to explain them I 
think we would make life easier for a lot of Kamailians. 

/O

> On 9 Nov 2021, at 08:26, Daniel-Constantin Mierla  wrote:
> 
> Hello,
> 
> sql_xquery() does not store anything inside $dbr(...), it stores the
> result inside $xavp(...).
> 
> You have to use sql_query() to store inside $dbr().
> 
> Cheers,
> Daniel
> 
> On 05.11.21 15:55, Benoît Panizzon wrote:
>> Dear List...
>> 
>> kamcmd> version
>> kamailio 5.4.7 (x86_64/linux)
>> 
>> Strange issue found.
>> 
>> According to: 
>> https://kamailio.org/docs/modules/5.4.x/modules/sqlops.html
>> 
>> I should get return value 2 if no rows returned:
>> 
>> $var(query) contains a query that does not match (number is not
>> assigned)
>> 
>>if (sql_xquery("impkam", "$var(query)", "assignedtn") == 1) {
>>if ($avp(debug) > 1) {
>>xlog("L_INFO", "$cfg(route): SQL Dump Result: 
>> $var(assignedtn) ROWS: $dbr(assignedtn=>rows) \n");
>>  }
>>  do stuff with the assigned number
>>  } else {
>>  do stuff in case that number is not assigned
>>  }
>> 
>> Log Output:
>> 
>> CHECK_ASSIGNED_TN: SQL Dump Result: 0 ROWS: 0
>> 
>> So the return value of the query was == 1 but the result contains no
>> rows. How can that be?
>> 
>> -- 
>> 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 PrattelnFax  +41 61 826 93 01
>> Schweiz Web  http://www.imp.ch
>> __
>> 
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>>  * sr-users@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to the 
>> sender!
>> Edit mailing list options or unsubscribe:
>>  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> 
> -- 
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio Advanced Training - Online
> Nov 08-11, 2021 (Europe Timezone) - Feb 21-24, 2022 (America Timezone)
>  * https://www.asipto.com/sw/kamailio-advanced-training-online/
> 
> 
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>  * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:
>  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio as SUBCRIBE client

[Olle E. Johansson]

> On 8 Oct 2021, at 08:47, Daniel-Constantin Mierla  wrote:
> 
> Hello,
> 
> presence service are decoupled from registration service in SIP. To get
> notified on a specific event, then the UA has to send a SUBSCRIBE to the
> presentity for that event. Even the SUBSCRIBE comes to Kamailio, you can
> route it to another SIP system. It is quite common for Kamailio to
> handle SUBSCRIBE for user presence event and route SUBSCRIBE for MWI to
> media server (e.g., Asterisk or FreeSwitch). Just to routing based on
> Event header conditions.
> 
For scalability, a media server can PUBLISH events to Kamailio that will
handle a large amount of subscribers that get the events.

I think there was some work done in Asterisk to get this done. I had an early
implementation many years ago. Don’t know the current state though.

/O 
> Cheers,
> Daniel
> 
> On 07.10.21 18:05, Jerry Kendall wrote:
>> 
>> Hi there...
>> 
>> Is there a way for Kamailio to proxy the presence status of items on
>> FreeSWITCH???
>> 
>> for example:
>> 
>> x201 registers via Kamailio and subscribes to the presence of 'Night
>> Mode' (normally, BLF set to *21)
>> Night Mode is on the FreeSWITCH server and toggled by dialing a
>> feature code (*21)
>> How can I get the status of Night Mode sent to the BLFs on x201 when
>> the device is reg'd to Kamailio and not FS ?
>> 
>> 
>> Can it be done? (likely but how)
>> 
>> 
>> Jerry
>> 
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>>  * sr-users@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only
>> to the sender!
>> Edit mailing list options or unsubscribe:
>>  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> 
> -- 
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio Advanced Training - Online
> Nov 08-11, 2021 (Europe Timezone) - Nov 22-25, 2021 (America Timezone)
>  * https://www.asipto.com/sw/kamailio-advanced-training-online/
> 
> 
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>  * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:
>  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] What does "tls.reload" actually do?

[Olle E. Johansson]

> On 30 Aug 2021, at 14:23, Daniel-Constantin Mierla  wrote:
> 
> Actually the active tls connections are not closed (and thus not
> re-opened) on tls.reload. It should use the new tls.cfg and
> corresponding certs only for the new connections. Old connections should
> not affected by reload.
Cool. Thank you for that clarification.

/O
> 
> Cheers,
> Daniel
> 
> On 30.08.21 13:57, Olle E. Johansson wrote:
>> For the archives:
>> 
>> If you have a configuration file for your tls connections (not kamailio.cfg 
>> modparams) I believe the TLS module will reopen connections at tls.reload. 
>> If you update the certificates the new ones will be active after reload. 
>> This does not happen if you use modparams. Meaning if you use letsencrypt, 
>> your hook to reload with new certs is tls.reload.
>> This propably means that open connections will be closed.
>> 
>> I don’t know if connections are affected if you use modparams. 
>> /O
>> 
>> 
>> 
>>> On 30 Aug 2021, at 13:39, Sebastian Damm  wrote:
>>> 
>>> Hi,
>>> 
>>> I suppose, it happens for real connections, too. But since it's so 
>>> sporadically, I guess, clients just retry and then it works.
>>> 
>>> The operating system is an Ubuntu 18.04 (getting replaced by Ubuntu 20.04 
>>> soon), thus it's running with libssl 1.1.1.
>>> 
>>> Regards,
>>> Sebastian
>>> 
>>> - Ursprüngliche Mail -
>>> Von: "miconda" 
>>> An: "sr-users" , "Sebastian Damm" 
>>> 
>>> Gesendet: Montag, 30. August 2021 13:28:04
>>> Betreff: Re: [SR-Users] What does "tls.reload" actually do?
>>> 
>>> Hello,
>>> 
>>> does it happen only for connections done by the monitoring system? Or
>>> also for the connections tried from the usual sip phones?
>>> 
>>> What is the operating system and libssl version?
>>> 
>>> Cheers,
>>> Daniel
>>> 
>>> On 30.08.21 11:57, Sebastian Damm wrote:
>>>> Hi Henning,
>>>> 
>>>> unfortunately, I don't have a host without traffic showing the same 
>>>> behavior. Our dev hosts usually don't run long enough. (And they usually 
>>>> don't get monitored.)
>>>> 
>>>> The "sporadically" meant, that it can take sometimes up to one week until 
>>>> it occurs on the same host again. And yes, some hosts have a bit more 
>>>> traffic than others, I suppose that's why it occurs earlier on some hosts, 
>>>> later on others.
>>>> 
>>>> I guess we have to deploy updates more often. ;)
>>>> 
>>>> Regards,
>>>> Sebastian
>>>> 
>>>> - Ursprüngliche Mail -
>>>> Von: "Henning Westerholt" 
>>>> An: "sr-users" 
>>>> CC: "Sebastian Damm" 
>>>> Gesendet: Dienstag, 24. August 2021 14:21:31
>>>> Betreff: RE: What does "tls.reload" actually do?
>>>> 
>>>> Hello Sebastian,
>>>> 
>>>> on a first look to the code the tls.reload does similar operations as done 
>>>> during normal server startup, like
>>>> - load configuration
>>>> - fixing domains
>>>> - check sockets
>>>> 
>>>> If the error only happens sporadic and, on some servers, it is probably 
>>>> either an error that only occurs in specific circumstances unrelated to 
>>>> kamailio, or some internal corruption topic in the module/server.
>>>> 
>>>> Do you see it also on e.g., test systems without any real load? Is there a 
>>>> difference between the systems in kind of load, and this maybe also causes 
>>>> some difference when the error occurs?
>>>> 
>>>> Cheers,
>>>> 
>>>> Henning
>>>> 
>>>> -- 
>>>> Henning Westerholt - https://skalatan.de/blog/
>>>> Kamailio services - https://gilawa.com 
>>>> 
>>>> -Original Message-
>>>> From: sr-users  On Behalf Of 
>>>> Sebastian Damm
>>>> Sent: Tuesday, August 24, 2021 1:58 PM
>>>> To: sr-users 
>>>> Subject: [SR-Users] What does "tls.reload" actually do?
>>>> 
>>>> Hi,
>>>> 
>>>> I noticed a strange behavior on some of our proxy servers, all running 
>>>> Kamailio 5.3.8. After running fo

Re: [SR-Users] What does "tls.reload" actually do?

[Olle E. Johansson]

For the archives:

If you have a configuration file for your tls connections (not kamailio.cfg 
modparams) I believe the TLS module will reopen connections at tls.reload. If 
you update the certificates the new ones will be active after reload. This does 
not happen if you use modparams. Meaning if you use letsencrypt, your hook to 
reload with new certs is tls.reload.
This propably means that open connections will be closed.

I don’t know if connections are affected if you use modparams. 
/O



> On 30 Aug 2021, at 13:39, Sebastian Damm  wrote:
> 
> Hi,
> 
> I suppose, it happens for real connections, too. But since it's so 
> sporadically, I guess, clients just retry and then it works.
> 
> The operating system is an Ubuntu 18.04 (getting replaced by Ubuntu 20.04 
> soon), thus it's running with libssl 1.1.1.
> 
> Regards,
> Sebastian
> 
> - Ursprüngliche Mail -
> Von: "miconda" 
> An: "sr-users" , "Sebastian Damm" 
> 
> Gesendet: Montag, 30. August 2021 13:28:04
> Betreff: Re: [SR-Users] What does "tls.reload" actually do?
> 
> Hello,
> 
> does it happen only for connections done by the monitoring system? Or
> also for the connections tried from the usual sip phones?
> 
> What is the operating system and libssl version?
> 
> Cheers,
> Daniel
> 
> On 30.08.21 11:57, Sebastian Damm wrote:
>> Hi Henning,
>> 
>> unfortunately, I don't have a host without traffic showing the same 
>> behavior. Our dev hosts usually don't run long enough. (And they usually 
>> don't get monitored.)
>> 
>> The "sporadically" meant, that it can take sometimes up to one week until it 
>> occurs on the same host again. And yes, some hosts have a bit more traffic 
>> than others, I suppose that's why it occurs earlier on some hosts, later on 
>> others.
>> 
>> I guess we have to deploy updates more often. ;)
>> 
>> Regards,
>> Sebastian
>> 
>> - Ursprüngliche Mail -
>> Von: "Henning Westerholt" 
>> An: "sr-users" 
>> CC: "Sebastian Damm" 
>> Gesendet: Dienstag, 24. August 2021 14:21:31
>> Betreff: RE: What does "tls.reload" actually do?
>> 
>> Hello Sebastian,
>> 
>> on a first look to the code the tls.reload does similar operations as done 
>> during normal server startup, like
>> - load configuration
>> - fixing domains
>> - check sockets
>> 
>> If the error only happens sporadic and, on some servers, it is probably 
>> either an error that only occurs in specific circumstances unrelated to 
>> kamailio, or some internal corruption topic in the module/server.
>> 
>> Do you see it also on e.g., test systems without any real load? Is there a 
>> difference between the systems in kind of load, and this maybe also causes 
>> some difference when the error occurs?
>> 
>> Cheers,
>> 
>> Henning
>> 
>> -- 
>> Henning Westerholt - https://skalatan.de/blog/
>> Kamailio services - https://gilawa.com 
>> 
>> -Original Message-
>> From: sr-users  On Behalf Of Sebastian 
>> Damm
>> Sent: Tuesday, August 24, 2021 1:58 PM
>> To: sr-users 
>> Subject: [SR-Users] What does "tls.reload" actually do?
>> 
>> Hi,
>> 
>> I noticed a strange behavior on some of our proxy servers, all running 
>> Kamailio 5.3.8. After running for some time (weeks), our monitoring system 
>> sporadically starts reporting errors. The check connects via tls and 
>> registers to an Asterisk behind the proxy server. When this happens, the 
>> Kamailio log shows the following line:
>> 
>> ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:1409441B:SSL 
>> routines:ssl3_read_bytes:tlsv1 alert decrypt error
>> 
>> When restarting Kamailio, the problem goes away only to come back after some 
>> weeks uptime again.
>> 
>> On one host, I tried to find something using kamcmd, and I don't know why 
>> but I also issued "tls.reload". And from that point, the monitoring system 
>> has not reported the system as faulty anymore. I repeated the same thing on 
>> other hosts when the problem occured there, all with the same result. 
>> "tls.reload" helps. But from the documentation, I don't know why.
>> 
>> Does anybody have an explanation for it?
>> 
>> Regards,
>> Sebastian
>> 
>> 
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>>  * sr-users@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to the 
>> sender!
>> Edit mailing list options or unsubscribe:
>>  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> 
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>>  * sr-users@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to the 
>> sender!
>> Edit mailing list options or unsubscribe:
>>  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> 
> -- 
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda/
> 
> 

Re: [SR-Users] Is this idea even feasible?

[Olle E. Johansson]

> 18 aug. 2021 kl. 18:18 skrev Antony Stone 
> :
> 
> So, yes, I know that is one way to do it.  What I do not know is how to inject
> this into an existing dialogue between client and server.  That is why I
> thought a SIP proxy would be a suitable solution, because it would naturally
> be placed between client and server to start with.
The SIP protocol does not allow you to inject messages in the middle of a SIP 
dialog. The CSEQs will be out of order on one end and other messages will be 
ignored. That’s why everyone points you to the b2bua solutions where you have 
different dialogs on both ends.

Start with accepting that, then look for a small b2bua that fits your needs, 
that isn’t configured to be a full featured PBX, which you clearly stated that 
you don’t want.

/O


signature.asc
Description: Message signed with OpenPGP
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] DMQ_USRLOC module and calls

[Olle E. Johansson]

> On 13 Jul 2021, at 14:46, Social Boh  wrote:
> 
> Hello,
> 
> I'm testing DMQ_USRLOC modulo between two Kamailio servers (A) and (B)
> 
> The two servers share the same domain and using Amazon Route53 to distributes 
> 50% requests each Server.
> 
> The problem is when I try to make a call from user A (registered on kamailio 
> A) and the user B (registered on Kamailio B).
> 
> The call follow this flow:
> 
> User A --> KamailioA --> UserB
> 
> go directly to userB because KamailioA know, via DMQ_USRLOC IP and port of 
> UserB. With some Softphone the call work with audio without problem; with 
> other Softphone USERB never answer the INVITE sends from Kamailio. Is it 
> possible use this flow?
> 
> USER A --> KamailioA --> KamailioB --> User B
> 
> to resolve this kind of problem or is there other available option?

If the softphone is behind NAT it has a relation to one IP address in the NAT. 
You need to send the INVITE from that IP and no other IP in order to reach the 
device. Even without NAT, many devices just don’t respond to messages from 
unknown IP addresses.

/O
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Websocket In-dialoge SIP routing failed post network loss due to aliases

[Olle E. Johansson]

> On 30 Jun 2021, at 10:14, Juha Heinanen  wrote:
> 
> Olle E. Johansson writes:
> 
>>> Have you checked baresip?
>> 
>> I don’t recall baresip having a full SIP outbound implementation.
> 
> baresip is able to register with two outbound proxies and supports gruu
> (below). What else is needed?

Full support for SIP outbound (using REG-id when registering etc).
Last time I looked we did not have all nuts and bolts for it, but let’s give it 
a try.

/O
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Websocket In-dialoge SIP routing failed post network loss due to aliases

[Olle E. Johansson]

> On 30 Jun 2021, at 09:49, Juha Heinanen  wrote:
> 
> Olle E. Johansson writes:
> 
>> Full implementation of SIP outbound is the only solution close to
>> solving this problem in the IETF standards. 
>> However, I have seen no single SIP client that have implemented this,
>> even though Kamailio supports 
>> it on the server side. The idea is that you always have two TCP
>> connections to two active servers.
> 
> Have you checked baresip?

I don’t recall baresip having a full SIP outbound implementation.

SIP outbound seems to be an elegant solution to a non-problem. Maybe it’s 
coming back on the radar now, several years later and we need to start working 
on it as more and more SIP moves to TCP/TLS or WebSocket and network operators 
implement CGnat and other middleboxes that do strange stuff to open flows.

Without SIP outbound a SIP UA using TLS needs to have a server cert and accept 
incoming TLS connections, which of course does not work over NAT, so if we want 
to be RFC compliant, we should at least copy the RFC for SIP over WebSocket 
“half-outbound” requirement to SIP/TLS and SIP/TCP.

I have started discussions about this “half-outbound” concept a few times, but 
haven’t gotten much support in the SIPcore IETF group. Meanwhile, Kamailio 
actually breaks the RFC by sending outbound requests on the inbound TLS 
connection. It works, but it’s not RFC compliant.

Cheers,
/O
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Websocket In-dialoge SIP routing failed post network loss due to aliases

[Olle E. Johansson]

> On 30 Jun 2021, at 09:10, Shahid Hussain  wrote:
> 
> Hi,
> Websocket module documentation has a code reference to use aliases for SIP 
> routing. However, aliases will not work in the following setup and situation.
> 1. Kamailio is configured with active and standby node
> 2. Ping is implemented from webclient and kamailio responds with pong.
> 3. Two clients ClinetA and ClientB registered themselves to Kamailio.
> 4. After SIP negotiation (INVITE-200OK) each client learnt about below 
> aliases.
> Alias of ClientA:
> alias=172.27.6.98~58336
> Alias of ClientB:
> alias=172.27.6.98~58342
>  
> So normally if ClientB wants to send SIP message to ClientA, SIP URI from 
> ClientB looks like below
> ACK sip:v9d0gtl6@q0lrdlj63pik.invalid;alias=172.27.6.98~58336~5;transport=ws 
> SIP/2.0
>  4. Call is in a connected state.
> 
> Following is the issue.
> i.  Switchover (or network lost or reboot) at Kamailio happened
> ii.  Due to ping pong both the clients detected network loss individually and 
> re-registered themselves.
> iii.  Aliases of both the clients got changed.
> New Alias of ClientA:
> alias=172.27.6.98~ 58346
>  
> New Alias of ClientB:
> alias=172.27.6.98~ 58348
>  
> iv.   But ClientB doesn’t know that ClientA also re-registered and ClientA’s 
> alias got changed and vice-versa
> v.Because of this ClientB still sends BYE with Initial alias
> BYE sip:v9d0gtl6@q0lrdlj63pik.invalid;alias=172.27.6.98~58336~5;transport=ws 
> SIP/2.0
> 
> Would like to know what is the recommended solution for this problem using 
> alias or is it a limitation of using alias?

Full implementation of SIP outbound is the only solution close to solving this 
problem in the IETF standards.
However, I have seen no single SIP client that have implemented this, even 
though Kamailio supports
it on the server side. The idea is that you always have two TCP connections to 
two active servers.

https://datatracker.ietf.org/doc/rfc5626/ 


Having said that, SIP outbound enables registration survival and always being 
reachable, but it does not handle dialog survival. It was something we 
discussed for a while at the latest Kamailio dev meeting.

Hopefully the actual RTP streams can survive the failover and the call can go 
on, but if it depends on SIP signalling there’s no other way (that i know of) 
to survive and move the call to a new server with a new TCP connection. I have 
struggled with similar problems and made possible call survival in the case of 
lost SIP signalling path. It requires SIP uas that doesn’t implement any 
keepalive or SIP timer that will hangup if SIP signalling is dead.

/O__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] SNMP counter doesn't increase in stateful proxy

[Olle E. Johansson]

> On 6 Apr 2021, at 12:14, Marat Gareev  wrote:
> 
> It looks like custom metrics are only available in xHTTP_PROM module.
You can read them with jsonrpc as well and add them as custom 
counters in your snmpd.conf

/O
> 
> вт, 6 апр. 2021 г. в 10:25, Daniel-Constantin Mierla  >:
> Just for sake of completion of the knowledge here in the mailing list 
> archive: do custom counters become available in snmpstats?
> 
> Cheers,
> Daniel
> 
> On 30.03.21 13:55, Marat Gareev wrote:
>> Thanks, Daniel.
>> 
>> In this case I'll define a custom counter.
>> 
>> Marat
>> 
>> вт, 30 мар. 2021 г. в 14:06, Daniel-Constantin Mierla > >:
>> Hello,
>> 
>> the statistics from the core are only for stateless forwarding.
>> 
>> You can check if tmx module offers the numbers you are looking for (load the 
>> module and check the output of 'kamctl stats').
>> 
>> If not, you can also define new statistics in the config with the module:
>> 
>>   * https://www.kamailio.org/docs/modules/stable/modules/statistics.html 
>> 
>> An you can incremented when you use t_relay(). Alternative, you can use 
>> onsend_route for requests.
>> 
>> On the other hand, I do not use snmp module to see if there is any option to 
>> export config-defined stats to snmp.
>> 
>> Firthermore, maybe you can switch to statsd module for pushing out the stats 
>> or pull them via rpc.
>> 
>> Cheers,
>> Daniel
>> 
>> On 25.03.21 16:45, Marat Gareev wrote:
>>> Hello,
>>> 
>>> I'm trying to get the total number of SIP request messages sent out by the 
>>> proxy with kamailioSIPSummaryOutRequest scalar.
>>> But the value doesn't increase if I use t_relay() (with forward() counter 
>>> works).
>>> 
>>> Related thread 
>>> .
>>> 
>>> Is there another SNMP counter which contains a total number of OUT requests?
>>> 
>>> Marat
>>> 
>>> 
>>> ___
>>> Kamailio (SER) - Users Mailing List
>>> sr-users@lists.kamailio.org 
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
>>> 
>> -- 
>> Daniel-Constantin Mierla -- www.asipto.com 
>> www.twitter.com/miconda  -- 
>> www.linkedin.com/in/miconda 
>> Funding: https://www.paypal.me/dcmierla -- 
> Daniel-Constantin Mierla -- www.asipto.com 
> www.twitter.com/miconda  -- 
> www.linkedin.com/in/miconda 
> Funding: https://www.paypal.me/dcmierla 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] event_route when all modules have been loaded?

[Olle E. Johansson]

> On 1 Mar 2021, at 12:11, Juha Heinanen  wrote:
> 
> Daniel-Constantin Mierla writes:
> 
>> I think it does not matter the type of transport for the worker, likely
>> the docs had udp because that's usually the first worker. Also, IIRC,
>> sip specs mandate UDP support, but kamailio can start without.
> 
> Yes, SIP specs mandate UDP support,
In implementations yes. But you can freely choose what you have in your
service. Which is what NAPTR is there for - to indicate to users what
kind of protocols your service supports and you preference.

To clarify: There’s no mandate that a service has to support UDP.

> but if a sip proxy does now have any
> clients using UDP, it does not make sense to enable UDP transport to
> consume resources for nothing.
I have services that are TLS only. That’s RFC compliant too :-)

/O

> 
>> Have you tried with no udp socket and the event route was not
>> executed?
> 
> Yes, I tried I like this:
> 
> event_route[core:worker-one-init] {
>xinfo("** at core:worker-one-init\n");
> }
> 
> and didn't get the message to syslog when I started Kamailio.  So it
> works as specified in core cookbook.
> 
> -- Juha
> 
> 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Critical : Kamilio is not starting when loading Dispatcher module .

[Olle E. Johansson]

> On 23 Feb 2021, at 05:36, Amul Tyagi  wrote:
> 
> Feb 18 18:33:19 CICTPH01LLB01 /usr/sbin/kamailio[18817]: ERROR:  
> [core/tcp_main.c:2863]: tcp_init(): bind(d, 0x7f81495f1efc, 16) on 
> 127.0.0.1:5060 : Address already in use
Please check the above log for your reference. There’s one ERROR in your output 
that you need to
check.

Something is already listening to loopback interface port 5060 that blocks 
Kamailio from starting.

/O___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] R-R to MS Teams Proxy

[Olle E. Johansson]

> On 10 Feb 2021, at 21:01, Juha Heinanen  wrote:
> 
> When request is sent from Kamailio to MS Teams SIP Proxy, the top R-R
> URI needs to contain FQDN of Kamailio SIP proxy instead of its IP
> address.  Document
> 
>  https://skalatan.de/de/blog/kamailio-sbc-teams
> 
> suggest to replace record_route(); call with
> 
>  record_route_preset("SBC-DNS-DOMAIN:5061;transport=tls", "SBC-IP-ADDR:5060");
> 
> That works only in a very simple case where the request came in over UDP
> or TCP and SIP Proxy has only one listening address, i.e., SBC-IP-ADDR.
> 
> One way to solve the problem might be a new r_r function that would take
> FQDN of the top R-R URI as argument or introduction of a pv from where
> the current record_route() function would take the FQDN if it has been
> set.
> 
> Any comments or other solutions?

This is needed for all TLS rr’s since we need to vallidate the cert 
with the FQDN.

/O
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] failover on SIP servers

[Olle E. Johansson]

> On 31 Jan 2021, at 16:39, Alex Balashov  wrote:
> 
> Your life will be a lot simpler if you avoid SRV.

I think those are different things. 

DNS SRV/NAPTR are tools for a service provider to tell users and devices how to 
connect to the service.
By modifying DNS records, you can control your heard and handle failover and 
load balancing.

Dispatcher is great if you control both ends of the connection or have a 
service provider
who doesn’t understand the benefits of DNS.

/O
> 
> —
> Sent from mobile, with due apologies for brevity and errors.
> 
>> On Jan 31, 2021, at 10:06 AM, AL RSM  wrote:
>> 
>> 
>> 
>> Hi,
>> 
>> I was wondering what is the recommended approach to implement a failover on 
>> several destination SIP servers:
>> 
>> 1) using DNS SRV records
>> 2) using dispatcher list
>> 3) combination of both.
>> 
>> 
>> Thanks,
>> AL
>> 
>> 
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] FQDN endpoint as rd

[Olle E. Johansson]

> On 26 Jan 2021, at 17:32, AL RSM  wrote:
> 
> Hi,
> 
> I was wondering if Kamailio can support FQDN endpoint which resolves to 
> multiple IPs, checks if the first IP is not reachable, try the next one in 
> the list.

The SIP protocol has support for DNS NAPTR and SRV records to handle this. 
Kamailio fully supports this.

/O

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] NAT problem with recvonly calls

[Olle E. Johansson]

> On 8 Dec 2020, at 18:55, Richard Fuchs  wrote:
> 
> Use IPv6 

While I like that proposal, assuming that IPv6 will not have a stateful 
firewall is propably not a good assumption.
So I suspect that an IPv6 firewall would not let the packets in if there is not 
outbound traffic first. I do like Ovidius
ICE-based solution and would like to add RTCP - if muxed it would open the 
port, but the likelyhood that it’s 
implemented is propably low.

IPv6 greetings!
/O :-)
> 
> Cheers
> 
> On 07/12/2020 23.01, David Cunningham wrote:
>> Hello,
>> 
>> We have a problem with a SIP doorbell device which sends media one way only, 
>> and NAT at the receiving device.
>> 
>> When the doorbell button is pressed it makes a call to a configured 
>> destination. Since the doorbell only sends and doesn't receive it sends the 
>> INVITE with sendonly in the SDP, and the destination then replies with a 200 
>> OK with recvonly in the SDP. The problem is that the destination is behind 
>> NAT, and its reply contains a private network IP in the SDP.
>> 
>> Normally Asterisk when nat=yes works around that by adjusting the 
>> destination for RTP to be the address it actually receives audio from, 
>> however because this device is recvonly Asterisk never receives audio from 
>> it. This means Asterisk keeps trying to send the doorbell's RTP to the 
>> private network IP which of course fails, and the destination never gets the 
>> RTP from the doorbell.
>> 
>> We haven't found a solution in Asterisk to this, so are now looking to 
>> Kamailio which acts as a load-balancing proxy in front of Asterisk for one. 
>> For example, maybe we could use fix_nated_sdp, but only on 200 OK's with 
>> recvonly.
>> 
>> Has anyone else encountered this, and are there any recommended solutions?
>> 
>> Thank you in advance!
>> 
>> -- 
>> David Cunningham, Voisonics Limited
>> http://voisonics.com/ 
>> USA: +1 213 221 1092
>> New Zealand: +64 (0)28 2558 3782
>> 
>> 
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org 
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
>> 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] How to DIY/Setup An Open Source IP PBX Appliance/Server?

[Olle E. Johansson]

If you want to discuss Asterisk, I recommend that you use the Asterisk mailing 
lists.
This is not it.

/O

> On 1 Dec 2020, at 16:17, Turritopsis Dohrnii Teo En Ming 
>  wrote:
> 
> Subject: How to DIY/Setup An Open Source IP PBX Appliance/Server?
> 
> Good day from Singapore,
> 
> After reading recent reviews, I gather that Asterisk is the gold standard 
> when it comes to open source VoIP systems and it is the most famous open 
> source PBX out there.
> 
> Article: Compare the Top 10 Best Open Source PBX Software of 2020
> Link: https://www.voipreview.org/business-voip/best-open-source-pbx-software
> 
> Article: Top 10 Free Open Source PBX Software Solutions
> Link: https://getvoip.com/blog/2016/09/23/best-open-source-pbx-software/
> 
> The following is an excerpt from Wikipedia:
> 
> "Asterisk is a core component in many commercial products and open-source 
> projects. Some of the commercial products are hardware and software bundles, 
> for which the manufacturer supports and releases the software with an 
> open-source distribution model.
> 
> AskoziaPBX, a fork of the m0n0wall project, uses Asterisk PBX software to 
> realize all telephony functions.
> 
> AstLinux is a "Network Appliance for Communications" open-source software 
> distribution.[15]
> 
> FreePBX, an open-source graphical user interface, bundles Asterisk as the 
> core of its FreePBX Distro[16]
> 
> LinuxMCE bundles Asterisk to provide telephony; there is also an embedded 
> version of Asterisk for OpenWrt routers.
> 
> PBX in a Flash/Incredible PBX and trixbox are software PBXes based on 
> Asterisk.
> 
> Elastix previously used Asterisk, HylaFAX, Openfire and Postfix to offer PBX, 
> fax, instant messaging and email functions, respectively, before switching to 
> 3CX.
> 
> Issabel is an open-source Unified Communications software which uses Asterisk 
> for telephony functions. It was forked from the open-source versions of 
> Elastix when 3CX acquired it.
> 
> *astTECS uses Asterisk in its VoIP and mobile gateways."
> 
> Link: https://en.wikipedia.org/wiki/Asterisk_(PBX)
> 
> I would like to DIY/setup an IP PBX appliance/server using free open source 
> projects.
> Which free open source project, mentioned in the list and links above, would 
> you recommend to DIY my IP PBX appliance/server?
> 
> Should I buy a desktop computer or get one of those appliances listed in the 
> link below to serve as my IP PBX appliance/server?
> 
> Link: 
> https://www.lazada.sg/products/pfsense-iron-metal-case-fanless-intel-celeron-j1800-dual-core-mini-pc-firewall-soft-router-with-ddr3l-msata-ssd-4-gigabit-lan-rj45-com-port-i449270007-s1196780479.html?spm=a2o42.searchlist.list.89.100857d22PjCYx=1
> 
> Please also refer me to very good, detailed and well explained 
> guides/tutorials/manuals on setting up open source IP PBX appliances/servers.
> 
> Lastly, please recommend a cheap and affordable IP phone (suggest brand and 
> model) to go along with my DIY open source IP PBX appliance/server.
> 
> Mr. Turritopsis Dohrnii Teo En Ming, 42 years as of 1st December 2020 
> Tuesday, is a TARGETED INDIVIDUAL (TI) living in Singapore.
> 
> Thank you very much.
> 
> 
> 
> 
> 
> 
> 
> -BEGIN EMAIL SIGNATURE-
> 
> The Gospel for all Targeted Individuals (TIs):
> 
> [The New York Times] Microwave Weapons Are Prime Suspect in Ills of
> U.S. Embassy Workers
> 
> Link: 
> https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html
> 
> 
> 
> Singaporean Targeted Individual Mr. Turritopsis Dohrnii Teo En Ming's Academic
> Qualifications as at 14 Feb 2019 and refugee seeking attempts at the United 
> Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan (5 Aug 2019) and 
> Australia (25 Dec 2019 to 9 Jan 2020):
> 
> [1] https://tdtemcerts.wordpress.com/
> 
> [2] https://tdtemcerts.blogspot.sg/
> 
> [3] https://www.scribd.com/user/270125049/Teo-En-Ming
> 
> -END EMAIL SIGNATURE-
> 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Presence of plain text username and password in kamailio.cfg

[Olle E. Johansson]

It is an interesting proposal to find a way for Kamailio to fetch external 
credentials in run-time,
not having them in clear text in config files. Like integration with hashicorp 
vault or something.

/O

> On 18 Nov 2020, at 15:50, Ahmed Marsou  wrote:
> 
>  Thank you so much, David and Alexandru. 
> I'm not sure but i read something about reading the config from my.cnf
> 
> http://www.kamailio.org/docs/modules/5.0.x/modules/db_mysql.html#idp419 
> 
> 
> The problem is that my.cnf, have 600 permission and I'm running kamailio with 
> user kamailio, so the question is, 
> There is a way to read this file as root on startup but run kamailio as 
> kamailio?
> The option AWS Parameter Store, is something related to amazon, right?
> 
> Tank you so much.
> 
> El mié., 18 nov. 2020 a las 15:29, David Villasmil 
> (mailto:david.villasmil.w...@gmail.com>>) 
> escribió:
> I just get the params from AWS Parameter Store and pass it to Kamailio on 
> startup. Downsize is you can see them in “ps”.
> 
> On Wed, 18 Nov 2020 at 12:40, Alexandru Covalschi <568...@gmail.com 
> > wrote:
> Alternative way is to use unixodbc, but it just means you put the password 
> into another file.
> 
> ср, 18 нояб. 2020 г. в 14:35, Alexandru Covalschi <568...@gmail.com 
> >:
> Don't use databases. Create an API and use it to access the data you need. 
> Won't work for every possible usage, but in general API-driven SIP-routing is 
> very possible with Kamailio, especially with KEMI.
> 
> ср, 18 нояб. 2020 г. в 11:32, Ahmed Marsou  >:
> Hi;
> I want to remove all plain text usernames an passwords from kamailio.cfg 
> file. Like modparam("auth_db", "db_url", 
> "dbdriver://username:password@dbhost/dbname")
> or this  
> modparam("sqlops","sqlcon","ca=>dbdriver://username:password@dbhost/dbname")
> Can you help me with some ideas of how can I handle that?
> Thank you.
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org 
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
> 
> 
> 
> -- 
> Alexandru Covalschi
> VoIP engineer and system administrator
> tel: +37367398493
> 
> 
> 
> -- 
> Alexandru Covalschi
> VoIP engineer and system administrator
> tel: +37367398493
> 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org 
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
> 
> -- 
> Regards,
> 
> David Villasmil
> email: david.villasmil.w...@gmail.com 
> phone: +34669448337
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org 
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
> 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Confusion about TCP worker ports

[Olle E. Johansson]

> On 29 Oct 2020, at 21:51, Alex Balashov  wrote:
> 
> On 10/29/20 4:48 PM, Noah Mehl wrote:
> 
>> Or the expectation is that the receiving side will send replies to
>> port 5060 (which I guess is broken in Freeswitch sometimes?)
> That is precisely the expectation, because dispatcher doesn't keep dedicated 
> listeners for replies to its own OPTIONS requests.
> 
> That's what I meant about asymmetric signalling: it is completely legal to 
> send from an actual port of Y while having a Via header that says "hit me 
> back at port X". That's exactly what FS should do.
> 
Alex - aren’t you thinking UDP now?

For TCP, responses go the path of the request, back on the same socket that is 
already open. From RFC 3261:

18.2.2  Sending Responses

   The server transport uses the value of the top Via header field in
   order to determine where to send a response.  It MUST follow the
   following process:

  o  If the "sent-protocol" is a reliable transport protocol such as
 TCP or SCTP, or TLS over those, the response MUST be sent using
 the existing connection to the source of the original request
 that created the transaction, if that connection is still open.
 This requires the server transport to maintain an association
 between server transactions and transport connections.  If that
 connection is no longer open, the server SHOULD open a
 connection to the IP address in the "received" parameter, if
 present, using the port in the "sent-by" value, or the default
 port for that transport, if no port is specified.  If that
 connection attempt fails, the server SHOULD use the procedures
 in [4 ] for servers in 
order to determine the IP address and
 port to open the connection and send the response to.

/O___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] about registrar save()/lookup()

[Olle E. Johansson]

> On 20 Oct 2020, at 09:12, Daniel-Constantin Mierla  wrote:
> 
> The functions are in corex module:
> 
>   - 
> https://www.kamailio.org/docs/modules/stable/modules/kex.html#kex.f.setbflag 
> <https://www.kamailio.org/docs/modules/stable/modules/kex.html#kex.f.setbflag>Thanks,
>  I missed that.
> Enhancements to the documentation is welcome always. Given that people here 
> have commit access, is there no reason to open an issue about this one, just 
> add to the docs what is considered to be good to have there.
> 
> 

Well, sometimes having an issue makes it easier to remember to fix it when you 
can’t attack the problem right away. :-)

/O

> 
> 
> Cheers,
> Daniel
> 
> On 20.10.20 09:02, Olle E. Johansson wrote:
>> It is mentioned here https://kamailio.org/dokuwiki/doku.php/utils:flags 
>> <https://kamailio.org/dokuwiki/doku.php/utils:flags>
>> 
>> But you are right, it is something that should exist in both registrar and 
>> usrloc
>> documentation.
>> 
>> The functions for managing them seems to be missing from the core cookbook 
>> too.
>> 
>> Please open an issue on this.
>> 
>> Thanks.
>> 
>> /O
>> 
>>> On 20 Oct 2020, at 07:45, Juha Heinanen >> <mailto:j...@tutpro.com>> wrote:
>>> 
>>> I didn't find any mention in registrar module README that save()
>>> function saves also branch flags and that lookup() retrieves them.
>>> 
>>> Is that documented somewhere?
>>> 
>>> -- Juha
>>> 
>>> ___
>>> Kamailio (SER) - Users Mailing List
>>> sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
>>> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>> 
>> 
>> 
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
>> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> -- 
> Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com/>
> www.twitter.com/miconda <http://www.twitter.com/miconda> -- 
> www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
> Funding: https://www.paypal.me/dcmierla <https://www.paypal.me/dcmierla>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] about registrar save()/lookup()

[Olle E. Johansson]

It is mentioned here https://kamailio.org/dokuwiki/doku.php/utils:flags 


But you are right, it is something that should exist in both registrar and 
usrloc
documentation.

The functions for managing them seems to be missing from the core cookbook too.

Please open an issue on this.

Thanks.

/O

> On 20 Oct 2020, at 07:45, Juha Heinanen  wrote:
> 
> I didn't find any mention in registrar module README that save()
> function saves also branch flags and that lookup() retrieves them.
> 
> Is that documented somewhere?
> 
> -- Juha
> 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] SRTP

[Olle E. Johansson]

> On 14 Oct 2020, at 16:48, Andy Kama  wrote:
> 
> Hi Fred
> 
> So i am running rtpengine but prob i am having is i receive the call as rtp 
> and need it to become srtp before i send it to the carrier
> then the carrier sends me a call as srtp and need that to become normal rtp 
> before i can go to the uac

THat is exactly what rtpengine does for you. Go explore their documentation!

/O :-)
> 
> On Wed, Oct 14, 2020 at 3:27 PM Fred Posner  > wrote:
> On Wed, 2020-10-14 at 11:51 +0100, Andy Kama wrote:
> > Hi All,
> > 
> > I have setup a tls connection to a sip provider and it works
> > perfectly
> > But they are requesting i send srtp
> > i can find any documentation how i do it with rtpengine etc?
> > 
> > any guidance would be appreciated
> > 
> > 
> 
> Generally this would be initiated by the endpoint making/receiving the
> call and can be as simple as making sure it's offered in the phone
> settings.
> 
> If you need to bridge rtp with srtp, you can look at rtpengine (
> https://www.kamailio.org/docs/modules/stable/modules/rtpengine.html 
> )
> for information on flagging the offer/manage.
> 
> Of course, this would also require you to install and run rtpengine.
> 
> -- 
> Fred Posner
> f...@palner.com 
> https://www.palner.com 
> 
> Need Fred? Call Fred. 336-HEY-FRED
> Matrix: @fred:matrix.lod.com 
> 
> 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org 
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
> 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio vulnerable to header smuggling possible due to bypass of remove_hf

[Olle E. Johansson]

> On 22 Sep 2020, at 16:19, Gerry | Rigatta  wrote:
> 
> Hi Olle,
> 
> the page you are pointing to does not contain any Kamailio security 
> advisories. What is needed is a timeline of advisories so one can and 
> understand whether one's system is vulnerable, and what the vulnerability is 
> - like this:
> https://www.asterisk.org/downloads/security-advisories/ 
> <https://www.asterisk.org/downloads/security-advisories/>
When we publish advisories, there will be a timeline of them.
> 
> As mentioned it would be also helpful to label github issues so one can 
> filter for security issues.
As many have stated here, we are looking for volonteers to help. Most 
developers are aiming to fix issues quickly as they pop up.

As I stated earlier, this requires a larger discussion between developers. 
Thanks for your input!

Trust me, what you add here is something we have discussed many times before, 
not just now and we are very well aware of it.

/O
> 
> Best Gerry
> 
> 
>> On 22 Sep 2020, at 15:26, Olle E. Johansson > <mailto:o...@edvina.net>> wrote:
>> 
>> 
>> 
>>> On 22 Sep 2020, at 13:30, Gerry | Rigatta >> <mailto:gjacob...@rigatta.com>> wrote:
>>> 
>>> Hi Daniel,
>>> 
>>> your frustration is understandable and I hope you excuse a further comment. 
>>> What is missing, IMVHO, is a central point of reference for all Kamailio 
>>> security issues. Googling for “Kamailio security” reveals 
>>> https://www.cvedetails.com/vulnerability-list/vendor_id-15820/Kamailio.html 
>>> <https://www.cvedetails.com/vulnerability-list/vendor_id-15820/Kamailio.html>
>>>  as the most comprehensive source. However it lacks this latest header bug.
>>> 
>> https://www.kamailio.org/wiki/security/policy 
>> <https://www.kamailio.org/wiki/security/policy>
>> 
>> Maybe we should make it easier to find from the home page as you did not 
>> find it.
>> 
>> /O
>>> My suggestion would be to create a special “Security Advisories” page on 
>>> the kamailio website which points to security news, so that Google indexes 
>>> that page. As for example Asterisk has 
>>> https://www.asterisk.org/downloads/security-advisories/ 
>>> <https://www.asterisk.org/downloads/security-advisories/>
>>> 
>>> And create on github an extra “security” label so one can filter for that. 
>>> https://github.com/kamailio/kamailio/labels 
>>> <https://github.com/kamailio/kamailio/labels>
>>> And then point from the above mentioned “Security Advisories” page to a 
>>> filtered github view.
>>> 
>>> Thanks for your great work on Kamailio. Its highly appreciated!
>>> 
>>> Best Gerry
>>> 
>>> 
>>>> On 22 Sep 2020, at 12:55, Daniel-Constantin Mierla >>> <mailto:mico...@gmail.com>> wrote:
>>>> 
>>>> At least in my case you push out some inaccurate information. I never said 
>>>> my "deployments were not affected since non-standard headers were not 
>>>> used".
>>>> 
>>>> Iirc, I only said that none of my deployments were affected by this issue 
>>>> -- respectively quoting from my message: "None of my deployments were 
>>>> affected." 
>>>> from:https://lists.kamailio.org/pipermail/sr-users/2020-September/110315.html
>>>>  
>>>> <https://lists.kamailio.org/pipermail/sr-users/2020-September/110315.html> 
>>>> . If I am mistaken and you found another remark from me, just point to my 
>>>> message from where you got that.
>>>> 
>>>> So, for further clarification: either non standard headers were used for 
>>>> non-security related features (e.g., used for troubleshooting purposes) or 
>>>> the issue didn't affect the deployments from different perspective (e.g., 
>>>> traffic was checked to be from a trusted source).
>>>> 
>>>> And remember that the issue was not with remove_hf() function itself, like 
>>>> it is somehow propagated by blog posts, but it was in the parser, so use 
>>>> of custom headers between two kamailio was not affected if an edge proxy 
>>>> did something like:
>>>> 
>>>> remove_hf("X-H");
>>>> 
>>>> append_hf("X-H: abc\r\n");
>>>> 
>>>> And then, if next hop Kamailio was using $hdr(X-H), it will get "abc" 
>>>> (value added by previous Kamailio), not what a bad actor would add as "X-H 
>

Re: [SR-Users] Kamailio vulnerable to header smuggling possible due to bypass of remove_hf

[Olle E. Johansson]

s for what so ever reasons.
>> 
>> This should be my last comment on the thread, I do not want to spend any 
>> more time in clarifying what people think I said or I did.
>> 
>> Cheers,
>> Daniel
>> 
>> On 22.09.20 11:31, Sandro Gauci wrote:
>>> I know I am waking up an old debate by replying to this thread. Deeply 
>>> sorry :-)
>>> 
>>> Finally got around to writing up a blog post about this very thread where I 
>>> (think) I spared absolutely no one, not even myself. 
>>> 
>>> My post is called "The great Kamailio security debate and some 
>>> misconceptions debunked" and can be read here:
>>> 
>>> https://www.rtcsec.com/2020/09/02-kamailio-security-debate-and-misconceptions/
>>>  
>>> <https://www.rtcsec.com/2020/09/02-kamailio-security-debate-and-misconceptions/>
>>> 
>>> The ToC:
>>> Introduction
>>> A bit of background before diving in
>>> Claim: this issue does not affect many organisations
>>> Claim: custom headers are only known to internal users
>>> Claim: if it’s an 18 year old bug, it can’t have been high risk
>>> Claim: this should have been found if people were doing proper testing
>>> Claim: infrequent advisories = project is not serious about security
>>> Claim: limited number of advisories = project is more secure
>>> Claim: if you’re serious about security, monitor the mailing lists
>>> Claim: security experts should decide what is a security vulnerability
>>> Discussion: when should the project publish an advisory?
>>> Discussion: educational security role
>>> Moving forward
>>> Hope that it is at least interesting and perhaps even constructive!
>>> 
>>> Best wishes,
>>> 
>>> --
>>>  
>>> Sandro Gauci, CEO at Enable Security GmbH
>>> 
>>> Register of Companies:  AG Charlottenburg HRB 173016 B
>>> Company HQ:   Pappelallee 78/79, 10437 Berlin, 
>>> Germany
>>> PGP/Encrypted comms: https://keybase.io/sandrogauci 
>>> <https://keybase.io/sandrogauci>
>>> Our blog:https://www.rtcsec.com 
>>> <https://www.rtcsec.com/>
>>> Other points of contact:  https://enablesecurity.com/#contact-us 
>>> <https://enablesecurity.com/#contact-us>
>>> 
>>> 
>>> 
>>> On Thu, 3 Sep 2020, at 10:34 AM, Olle E. Johansson wrote:
>>>> Well, you have defined one definitive line between being stupid and 
>>>> following some current practise :-)
>>>> 
>>>> I like to think we as a project have an educational role as well. In this 
>>>> case explaining the bug we had and what it can cause.
>>>> We should definitely add a warning along the lines you write too - relying 
>>>> on headers alone is bad and not best current practise.
>>>> 
>>>> /O
>>>> 
>>>>> On 3 Sep 2020, at 10:14, davy van de moere >>>> <mailto:davy.van.de.mo...@gmail.com>> wrote:
>>>>> 
>>>>> After 20 years in voip, my 2 cents on this, if you succeed in creating a 
>>>>> voip system where the security of the whole relies on the ability to 
>>>>> remove (or only keep specific) custom sip headers, you will wake up one 
>>>>> morning realizing a bunch of people in Palestine made a gazillion calls 
>>>>> over your system to expensive destinations, bringing you to or over the 
>>>>> edge of bankruptcy.
>>>>> 
>>>>> Security should be multilayered, one header sneaking through should not 
>>>>> give any big problems. 
>>>>> 
>>>>> From a security point of view, this could be called a 'normal' security 
>>>>> risk, I think. It's a bit more than low as you can do more than just get 
>>>>> some info, but it's not high, as you would need to have many other 
>>>>> factors going wrong to get to a successful exploit. 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Op do 3 sep. 2020 om 09:18 schreef Olle E. Johansson >>>> <mailto:o...@edvina.net>>:
>>>>> One thought - we may have to separate security vulnerability reporting 
>>>>> from security advisory documents. I think in some cases, where a common 
>>>>> use of a product can lead to issues (but it is not clearly a bug that 
>&g

Re: [SR-Users] Kamailio vulnerable to header smuggling possible due to bypass of remove_hf

[Olle E. Johansson]

> On 22 Sep 2020, at 11:31, Sandro Gauci  wrote:
> 
> I know I am waking up an old debate by replying to this thread. Deeply sorry 
> :-)
> 
> Finally got around to writing up a blog post about this very thread where I 
> (think) I spared absolutely no one, not even myself. 
Thank you, a very good post. Maybe something that we want to come back to as a 
community
in an open brainstorm meeting rather than a formal meeting - to see what comes 
out.

Cheers,
/O
> 
> My post is called "The great Kamailio security debate and some misconceptions 
> debunked" and can be read here:
> 
> https://www.rtcsec.com/2020/09/02-kamailio-security-debate-and-misconceptions/
>  
> <https://www.rtcsec.com/2020/09/02-kamailio-security-debate-and-misconceptions/>
> 
> The ToC:
> Introduction
> A bit of background before diving in
> Claim: this issue does not affect many organisations
> Claim: custom headers are only known to internal users
> Claim: if it’s an 18 year old bug, it can’t have been high risk
> Claim: this should have been found if people were doing proper testing
> Claim: infrequent advisories = project is not serious about security
> Claim: limited number of advisories = project is more secure
> Claim: if you’re serious about security, monitor the mailing lists
> Claim: security experts should decide what is a security vulnerability
> Discussion: when should the project publish an advisory?
> Discussion: educational security role
> Moving forward
> Hope that it is at least interesting and perhaps even constructive!
> 
> Best wishes,
> 
> --
>  
> Sandro Gauci, CEO at Enable Security GmbH
> 
> Register of Companies:  AG Charlottenburg HRB 173016 B
> Company HQ:   Pappelallee 78/79, 10437 Berlin, Germany
> PGP/Encrypted comms: https://keybase.io/sandrogauci 
> <https://keybase.io/sandrogauci>
> Our blog:https://www.rtcsec.com 
> <https://www.rtcsec.com/>
>     Other points of contact:  https://enablesecurity.com/#contact-us 
> <https://enablesecurity.com/#contact-us>
> 
> 
> 
> On Thu, 3 Sep 2020, at 10:34 AM, Olle E. Johansson wrote:
>> Well, you have defined one definitive line between being stupid and 
>> following some current practise :-)
>> 
>> I like to think we as a project have an educational role as well. In this 
>> case explaining the bug we had and what it can cause.
>> We should definitely add a warning along the lines you write too - relying 
>> on headers alone is bad and not best current practise.
>> 
>> /O
>> 
>>> On 3 Sep 2020, at 10:14, davy van de moere >> <mailto:davy.van.de.mo...@gmail.com>> wrote:
>>> 
>>> After 20 years in voip, my 2 cents on this, if you succeed in creating a 
>>> voip system where the security of the whole relies on the ability to remove 
>>> (or only keep specific) custom sip headers, you will wake up one morning 
>>> realizing a bunch of people in Palestine made a gazillion calls over your 
>>> system to expensive destinations, bringing you to or over the edge of 
>>> bankruptcy.
>>> 
>>> Security should be multilayered, one header sneaking through should not 
>>> give any big problems. 
>>> 
>>> From a security point of view, this could be called a 'normal' security 
>>> risk, I think. It's a bit more than low as you can do more than just get 
>>> some info, but it's not high, as you would need to have many other factors 
>>> going wrong to get to a successful exploit. 
>>> 
>>> 
>>> 
>>> 
>>> Op do 3 sep. 2020 om 09:18 schreef Olle E. Johansson >> <mailto:o...@edvina.net>>:
>>> One thought - we may have to separate security vulnerability reporting from 
>>> security advisory documents. I think in some cases, where a common use of a 
>>> product can lead to issues (but it is not clearly a bug that cause crashes 
>>> in our code) we may have to send out an advisory and publish it in the same 
>>> way. The problem with that is where the border is between just doing stupid 
>>> things like taking SQL statements from SIP headers and issues like this 
>>> that are harder to catch.
>>> 
>>> We had a long and hard discussion about this in the Asterisk project many 
>>> years ago - a very common dialplan construct (that was documented in many 
>>> places) was indeed very dangerous. It wasn’t any code in asterisk that 
>>> caused the issue, just a common dialplan construct that existed in many, 
>>> many production sys

Re: [SR-Users] Kamailio Slack Channel Invite

[Olle E. Johansson]

> On 21 Sep 2020, at 11:15, Peter Baines  wrote:
> 
> Hi,
> 
> Can someone send me an invite to the Kamailio Slack channel please.

I am not aware of a slack channel. We have an IRC channel and a matrix channel.

https://www.kamailio.org/w/irc-channels/ 


#kamailio:matrix.kamailio 



/O

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Using Kamalio as a proxy for internal servers

[Olle E. Johansson]

> On 7 Sep 2020, at 12:24, Sergey Safarov  wrote:
> 
> To resolve such an issue I switched to use IPv6 on internal SIP servers for 
> signaling and IPv4 for RTPmedia.
> 
> For me works like a charm.
Very elegant solution!

/O
> 
> On Mon, Sep 7, 2020 at 9:58 AM Olle E. Johansson  <mailto:o...@edvina.net>> wrote:
> You need to define another listen= without the advertise for communication 
> with internal servers. Either another IP or another port.
> 
> /O
> 
>> On 6 Sep 2020, at 17:34, Moshe Katz > <mailto:kohenk...@gmail.com>> wrote:
>> 
>> Hello all,
>> 
>> (Note: I previously posted a more detailed version of this question on 
>> StackOverflow at https://stackoverflow.com/q/63760506/829970 
>> <https://stackoverflow.com/q/63760506/829970> . This version is simplified 
>> to fit better in an email.)
>> 
>> I have Kamailio 5.4.1 (and RTPEngine) running on an internal server with a 
>> private IP address 172.31.7.96 and One-to-one NAT to an external IP address. 
>> The external IP is 192.0.2.100. (Note: The internal IP addresses are all 
>> unedited, but the public IPs have been replaced with TEST-NET-1 and 
>> TEST-NET-2 example addresses.) I will eventually be doing transcoding with 
>> RTPEngine, but for now this is a simple SIP Proxy.
>> 
>> Kamailio is installed on Ubuntu 18.04 using the DEB packages from 
>> dev.kamailio.org/kamailio54 <http://dev.kamailio.org/kamailio54> and is 
>> using the stock configuration that comes with those packages, except for the 
>> following changes:
>> 
>> #!define WITH_NAT
>> #!define WITH_RTPENGINE
>> #!define WITH_MYSQL
>> #!define WITH_AUTH
>> #!define WITH_IPAUTH
>> 
>> listen=udp:0.0.0.0:5060 <http://0.0.0.0:5060/> advertise 192.0.2.100:5060 
>> <http://192.0.2.100:5060/>
>> 
>> #!define DBURL "mysql://kamailio:REAL_PASSWORD_HERE@127.0.0.1/kamailio 
>> <http://kamailio:REAL_PASSWORD_HERE@127.0.0.1/kamailio>"
>> 
>> I have internal SIP servers with private IP addresses in the 172.31.7.0/24 
>> <http://172.31.7.0/24> range that I want to have send all SIP traffic 
>> through the Kamailio server. The internal servers are running a Java SIP 
>> client with the `OUTBOUND_PROXY` setting set to 172.31.7.96.
>> 
>> The problem I have is that the SIP `200 OK` message sent by Kamailio to my 
>> SIP server has its `Record-Route` header set to the public IP address 
>> `192.0.2.100` instead of the private address `172.31.7.96`. The SIP client 
>> therefore tries to send the `ACK` message back to the public address, but it 
>> has no route to the public address so the ACK never gets sent.
>> 
>> How can I configure Kamailio to use the public IP for external traffic but 
>> the private IP for communicating with internal machines on the same subnet?
>> 
>> I tried setting `mhomed=1`, but the machine isn't actually multi-homed so 
>> that didn't work.
>> 
>> I thought of adding a second listen line `listen=udp:172.31.7.96:5061 
>> <http://172.31.7.96:5061/>` and having the internal servers talk to port 
>> 5061, but that doesn't work because Kamailio uses the 5061 definition for 
>> the external side too.
>> 
>> I see in the docs that it is possible to name the listener lines, but I 
>> don't understand how to use those names in a way that would be relevant to 
>> my issue.
>> 
>> Thank you very much for your help,
>> 
>> Moshe
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
>> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Using Kamalio as a proxy for internal servers

[Olle E. Johansson]

You need to define another listen= without the advertise for communication with 
internal servers. Either another IP or another port.

/O

> On 6 Sep 2020, at 17:34, Moshe Katz  wrote:
> 
> Hello all,
> 
> (Note: I previously posted a more detailed version of this question on 
> StackOverflow at https://stackoverflow.com/q/63760506/829970 
>  . This version is simplified to 
> fit better in an email.)
> 
> I have Kamailio 5.4.1 (and RTPEngine) running on an internal server with a 
> private IP address 172.31.7.96 and One-to-one NAT to an external IP address. 
> The external IP is 192.0.2.100. (Note: The internal IP addresses are all 
> unedited, but the public IPs have been replaced with TEST-NET-1 and 
> TEST-NET-2 example addresses.) I will eventually be doing transcoding with 
> RTPEngine, but for now this is a simple SIP Proxy.
> 
> Kamailio is installed on Ubuntu 18.04 using the DEB packages from 
> dev.kamailio.org/kamailio54  and is using 
> the stock configuration that comes with those packages, except for the 
> following changes:
> 
> #!define WITH_NAT
> #!define WITH_RTPENGINE
> #!define WITH_MYSQL
> #!define WITH_AUTH
> #!define WITH_IPAUTH
> 
> listen=udp:0.0.0.0:5060  advertise 192.0.2.100:5060 
> 
> 
> #!define DBURL "mysql://kamailio:REAL_PASSWORD_HERE@127.0.0.1/kamailio 
> "
> 
> I have internal SIP servers with private IP addresses in the 172.31.7.0/24 
>  range that I want to have send all SIP traffic through 
> the Kamailio server. The internal servers are running a Java SIP client with 
> the `OUTBOUND_PROXY` setting set to 172.31.7.96.
> 
> The problem I have is that the SIP `200 OK` message sent by Kamailio to my 
> SIP server has its `Record-Route` header set to the public IP address 
> `192.0.2.100` instead of the private address `172.31.7.96`. The SIP client 
> therefore tries to send the `ACK` message back to the public address, but it 
> has no route to the public address so the ACK never gets sent.
> 
> How can I configure Kamailio to use the public IP for external traffic but 
> the private IP for communicating with internal machines on the same subnet?
> 
> I tried setting `mhomed=1`, but the machine isn't actually multi-homed so 
> that didn't work.
> 
> I thought of adding a second listen line `listen=udp:172.31.7.96:5061 
> ` and having the internal servers talk to port 
> 5061, but that doesn't work because Kamailio uses the 5061 definition for the 
> external side too.
> 
> I see in the docs that it is possible to name the listener lines, but I don't 
> understand how to use those names in a way that would be relevant to my issue.
> 
> Thank you very much for your help,
> 
> Moshe
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio vulnerable to header smuggling possible due to bypass of remove_hf

[Olle E. Johansson]

Well, you have defined one definitive line between being stupid and following 
some current practise :-)

I like to think we as a project have an educational role as well. In this case 
explaining the bug we had and what it can cause.
We should definitely add a warning along the lines you write too - relying on 
headers alone is bad and not best current practise.

/O

> On 3 Sep 2020, at 10:14, davy van de moere  
> wrote:
> 
> After 20 years in voip, my 2 cents on this, if you succeed in creating a voip 
> system where the security of the whole relies on the ability to remove (or 
> only keep specific) custom sip headers, you will wake up one morning 
> realizing a bunch of people in Palestine made a gazillion calls over your 
> system to expensive destinations, bringing you to or over the edge of 
> bankruptcy.
> 
> Security should be multilayered, one header sneaking through should not give 
> any big problems. 
> 
> From a security point of view, this could be called a 'normal' security risk, 
> I think. It's a bit more than low as you can do more than just get some info, 
> but it's not high, as you would need to have many other factors going wrong 
> to get to a successful exploit. 
> 
> 
> 
> 
> Op do 3 sep. 2020 om 09:18 schreef Olle E. Johansson  <mailto:o...@edvina.net>>:
> One thought - we may have to separate security vulnerability reporting from 
> security advisory documents. I think in some cases, where a common use of a 
> product can lead to issues (but it is not clearly a bug that cause crashes in 
> our code) we may have to send out an advisory and publish it in the same way. 
> The problem with that is where the border is between just doing stupid things 
> like taking SQL statements from SIP headers and issues like this that are 
> harder to catch.
> 
> We had a long and hard discussion about this in the Asterisk project many 
> years ago - a very common dialplan construct (that was documented in many 
> places) was indeed very dangerous. It wasn’t any code in asterisk that caused 
> the issue, just a common dialplan construct that existed in many, many 
> production systems. In the end, if I remember correctly, the project issued 
> an advisory and added a README about it.
> 
> Maybe that’s a way forward.
> 
> /O
> 
>> On 2 Sep 2020, at 21:25, Henning Westerholt > <mailto:h...@skalatan.de>> wrote:
>> 
>> Hello Maxim,
>>  
>> have a look to the first sentence:
>>  
>> “A security vulnerability is (for example) when a user of Kamailio can cause 
>> Kamailio to crash or lock up by sending messages to the server process.”
>>  
>> So there is some limitation regarding vulnerability criticality defined in 
>> there. But of course (as I already mentioned), it might be improved to e.g. 
>> use CVSS scoring instead.
>>  
>> Cheers,
>>  
>> Henning
>>  
>> From: Maxim Sobolev mailto:sobo...@sippysoft.com>> 
>> Sent: Wednesday, September 2, 2020 9:15 PM
>> To: Henning Westerholt mailto:h...@skalatan.de>>
>> Cc: Daniel-Constantin Mierla mailto:mico...@gmail.com>>; 
>> yufei@gmail.com <mailto:yufei@gmail.com>; Olle E. Johansson 
>> mailto:o...@edvina.net>>; Gerry | Rigatta 
>> mailto:gjacob...@rigatta.com>>; Kamailio (SER) - 
>> Users Mailing List > <mailto:sr-users@lists.kamailio.org>>; jbro...@signalogic.com 
>> <mailto:jbro...@signalogic.com>
>> Subject: Re: [SR-Users] Kamailio vulnerable to header smuggling possible due 
>> to bypass of remove_hf
>>  
>> On Wed, Sep 2, 2020 at 11:30 AM Henning Westerholt > <mailto:h...@skalatan.de>> wrote:
>> Hello Maxim,
>>  
>> thank you for the clarification, appreciated.
>>  
>> No worries, hope to have a civilized discussion.
>>  
>> Just one clarification, my comment regarding the advisory from 2018 was not 
>> meant as advertisement etc..
>>  
>> Point taken, I dramatized of course to underline my point. 
>>  
>> One suggestion to objectify the whole discussion, there exists a well-known 
>> and accepted metric for vulnerabilities: CVSS [1]
>> If I calculate the CVSS score for this issue, it results in a medium level 
>> with score 5.8. But this is of course again (at least somewhat) influenced 
>> from my point of view to this bug.
>>  
>> Some projects have a policy to only do a security announcement for 
>> vulnerabilities with score high and critical. For Kamailio this is not yet 
>> defined in a detailed way, due to the size of the project and other factors.
>>  
>> So, If people in this discussion (or other people on the l

Re: [SR-Users] Kamailio vulnerable to header smuggling possible due to bypass of remove_hf

[Olle E. Johansson]

One thought - we may have to separate security vulnerability reporting from 
security advisory documents. I think in some cases, where a common use of a 
product can lead to issues (but it is not clearly a bug that cause crashes in 
our code) we may have to send out an advisory and publish it in the same way. 
The problem with that is where the border is between just doing stupid things 
like taking SQL statements from SIP headers and issues like this that are 
harder to catch.

We had a long and hard discussion about this in the Asterisk project many years 
ago - a very common dialplan construct (that was documented in many places) was 
indeed very dangerous. It wasn’t any code in asterisk that caused the issue, 
just a common dialplan construct that existed in many, many production systems. 
In the end, if I remember correctly, the project issued an advisory and added a 
README about it.

Maybe that’s a way forward.

/O

> On 2 Sep 2020, at 21:25, Henning Westerholt  wrote:
> 
> Hello Maxim,
>  
> have a look to the first sentence:
>  
> “A security vulnerability is (for example) when a user of Kamailio can cause 
> Kamailio to crash or lock up by sending messages to the server process.”
>  
> So there is some limitation regarding vulnerability criticality defined in 
> there. But of course (as I already mentioned), it might be improved to e.g. 
> use CVSS scoring instead.
>  
> Cheers,
>  
> Henning
>  
> From: Maxim Sobolev mailto:sobo...@sippysoft.com>> 
> Sent: Wednesday, September 2, 2020 9:15 PM
> To: Henning Westerholt mailto:h...@skalatan.de>>
> Cc: Daniel-Constantin Mierla mailto:mico...@gmail.com>>; 
> yufei@gmail.com <mailto:yufei@gmail.com>; Olle E. Johansson 
> mailto:o...@edvina.net>>; Gerry | Rigatta 
> mailto:gjacob...@rigatta.com>>; Kamailio (SER) - 
> Users Mailing List  <mailto:sr-users@lists.kamailio.org>>; jbro...@signalogic.com 
> <mailto:jbro...@signalogic.com>
> Subject: Re: [SR-Users] Kamailio vulnerable to header smuggling possible due 
> to bypass of remove_hf
>  
> On Wed, Sep 2, 2020 at 11:30 AM Henning Westerholt  <mailto:h...@skalatan.de>> wrote:
> Hello Maxim,
>  
> thank you for the clarification, appreciated.
>  
> No worries, hope to have a civilized discussion.
>  
> Just one clarification, my comment regarding the advisory from 2018 was not 
> meant as advertisement etc..
>  
> Point taken, I dramatized of course to underline my point. 
>  
> One suggestion to objectify the whole discussion, there exists a well-known 
> and accepted metric for vulnerabilities: CVSS [1]
> If I calculate the CVSS score for this issue, it results in a medium level 
> with score 5.8. But this is of course again (at least somewhat) influenced 
> from my point of view to this bug.
>  
> Some projects have a policy to only do a security announcement for 
> vulnerabilities with score high and critical. For Kamailio this is not yet 
> defined in a detailed way, due to the size of the project and other factors.
>  
> So, If people in this discussion (or other people on the list) are interested 
> in improving the project security processes – this wiki page with the current 
> process might be a good starting 
> point:https://www.kamailio.org/wiki/security/policy 
> <https://www.kamailio.org/wiki/security/policy>
>  
> Please suggest your improvements to the existing process (preferable in a new 
> discussion thread) on the sr-dev list. If you want to do it in private, feel 
> free contact the management list.
>  
> Well, first suggestion after having read it: to start actually following 
> what's documented before any improvements are made. ;-) The policy says plain 
> and simple (quote):
>  
> Publishing security vulnerabilities
> 
> Kamailio will publish security vulnerabilities, including an CVE ID, on the 
> kamailio-business mailing list, sr-dev, sr-users as well as related lists. 
> The advisories will also be published on the kamailio.org 
> <http://kamailio.org/> web site. 
>  
> CVE entries should be created for vulnerabilities in the core and major 
> modules, for rarely used modules this is not necessary. If there are several 
> security issues together in one release, they should be announced together.  
>  
> I might be missing something obvious, but there is no "if" or "maybe" or "it 
> depends". Any module that has been 18 years with the project qualifies to be 
> a "major module" to me... 
>  
> -Max

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] MD5 and SHA-256 instead of MD5 or SHA-256...

[Olle E. Johansson]

> On 17 Jun 2020, at 17:22, Maxim Sobolev  wrote:
> 
> Whoever works on this needs to consider two things I think:
> 
> - ability to select algorithms when challenging UAC (MD5-only, SHA256-only, 
> SHA-512/256-only, all permutations). The RFC allows UAS to include multiple 
> HFs(*).  MD5-only should probably be the default. I suspect there might be a 
> significantly non-trivial population of UACs that would get confused 
> receiving multiple digests. Plus enabling challenges for all protocols would 
> expand the size of 401s messages.
Agree, multiple challenges will break stuff. I’m not sure that implementations 
actually bother with parsing the algorithm parameter.
> 
> - ability to accept response in either of supported hashing methods or any 
> combination of thereof. The reasonable default here is probably MD5-only for 
> now, again to prevent the possibility of foul play when we only request MD5, 
> while for some reason getting say SHA-256 back.
If you challenge with SHA512 only, you should not accept anything else.

> 
> -Max
> *) Example:
> 401 Unauthorized
> [..]
> WWW-Authenticate: Digest
>realm="http-a...@example.org ",
>qop="auth, auth-int",
>algorithm=SHA-256,
>nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
>opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
> WWW-Authenticate: Digest
>realm="http-a...@example.org ",
>qop="auth, auth-int",
>algorithm=MD5,
>nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
>opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS”

So the question is how to migrate. I don’t believe migrating within the same UA 
base will work smootlhy ever. If you have a provisioning system
it is easy setting up a SIP subdomain, let’s say “strong.example.com 
” and use that either for OB proxy or SIP domain, 
dependinig on your setup.
By doing that, you can have a zone witih devices/clients that can handle 
stronger auth and *only* use that. For the old ones, keep them
running until you reasonable can upgrade them. 

Of course you can do this witih realms too, but that requires a strong realm 
implementation in the UA’s, something that SNOM had in
the beginning but removed (maybe it was too hard to explain).

Cheers,
/O
> 
> 
> On Tue., Jun. 16, 2020, 12:13 p.m. Aymeric Moizard,  > wrote:
> 
> Le mar. 16 juin 2020 à 20:42, Henning Westerholt  > a écrit :
> Hello,
> 
>  
> 
> take a look to this parameter, you can switch between MD5 and SHA256, but 
> only use once at a time:
> 
>  
> 
> https://www.kamailio.org/docs/modules/5.3.x/modules/auth.html#auth.p.algorithm
>  
> 
>  
> 
> About planned features – I am not aware of major extensions in this module. 
> Of course, any contribution is welcome.
> 
> 
> Thanks for your answer.
> If I have some time, I might try to make a PR on being able to select the 
> algorithm at runtime.
> 
> Regards,
> Aymeric
>  
>  
> 
> Cheers,
> 
>  
> 
> Henning
> 
>  
> 
> --
> 
> Henning Westerholt – https://skalatan.de/blog/ 
> Kamailio services – https://gilawa.com 
>  
> 
> From: sr-users  > On Behalf Of Aymeric Moizard
> Sent: Monday, June 15, 2020 10:31 PM
> To: Kamailio (SER) - Users Mailing List  >
> Subject: [SR-Users] MD5 and SHA-256 instead of MD5 or SHA-256...
> 
>  
> 
> Hi All,
> 
>  
> 
> I'd like to improve my setup by switching to SHA-256. 
> 
> However, as a first step, I would like to offer both MD5 and SHA-256
> 
> in 2 different WWW-Authenticate header.
> 
>  
> 
> If I'm correct, this is not doable with the latest auth module?
> 
> Is this a planned feature?
> 
>  
> 
> As an alternative, I would like to decide the algorithm in the script
> 
> instead of a module parameter. It looks to me this is also not doable?
> 
> Again, is this a planned feature?
> 
>  
> 
> Thanks to all,
> 
>  
> 
> Regards
> 
> Aymeric
> 
>  
> 
> --
> 
> Antisip - http://www.antisip.com 
> 
> -- 
> Antisip - http://www.antisip.com 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org 
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
> 

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] MD5 and SHA-256 instead of MD5 or SHA-256...

[Olle E. Johansson]

> On 17 Jun 2020, at 10:58, Aymeric Moizard  <mailto:amoiz...@gmail.com>> wrote:
> 
> 
> 
> Le mer. 17 juin 2020 à 08:29, Olle E. Johansson  <mailto:o...@edvina.net>> a écrit :
> Aymeric,
> Good to hear from you!
> 
> ;)
> 
> There’s been some discussion in the IETF which we haven’t resolved on how to 
> handle this. I think you need to setup
> different domains or realms each with one auth algorithm. If you offer two at 
> the same time - what’s the point?
> 
> I don't understand why using different realm compared to one realm for both 
> would be better?
Each realm would have a *SINGLE* auth algorithm.

> 
> You are still wide open for downgrade attacks and haven’t accomplished much. 
> 
> Today, MD5 is used. If both MD5 and SHA-256 are proposed, it can't be worst 
> in terms of security... It is true that it doesn't bring much!
Right, if you think you are raising security, you’re wrong… That’s a problem.

> 
> My intention is to start migration.
> I guess, today, the safest start is to choose at runtime based on the 
> user-agent or some internal rules. In a later step, the old way would be 
> removed.
Maybe, but in many cases that will never happen because you have legacy phones 
that hang around until the end of time.
We need to find a decent way to make segments of your network require stronger 
algorithms and don’t offer downgrades. Basing that on user-agent headers is not 
a working solution - and you know it :-)

> 
> If people providing services don't start to use newer algo, there won't be 
> any effort on the endpoint side.
> 
> My initial complete objective: (theory)
> 1/ offer bother md5 and sha-256 to user-agent which still use md5 and which 
> are NOT broken in this mode. (Runtime decision)
> 2/ offer only sha-256 to user-agent with sha-256 support.
> 3/ offer only MD5 to user-agent with don't support sha-256 AND are broken if 
> both are offered.
> 
> I could also start with point 2 and 3 only, but would prefer to have 1/2/3…
Check RFC 8760 for advice and hints on this.

Cheers
/O
> 
> 
> Regards,
> Aymeric
> 
> I guess we will have to wait until the IETF resolves this issue, which 
> propably applies to more protocols.
> The big question is how to upgrade a user base to stronger authentication 
> algorithms in HTTP Digest auth
> without allowing downgrade attacks.
> 
> Cheers,
> /O
> 
>> On 16 Jun 2020, at 20:42, Henning Westerholt > <mailto:h...@skalatan.de>> wrote:
>> 
>> Hello,
>>  
>> take a look to this parameter, you can switch between MD5 and SHA256, but 
>> only use once at a time:
>>  
>> https://www.kamailio.org/docs/modules/5.3.x/modules/auth.html#auth.p.algorithm
>>  
>> <https://www.kamailio.org/docs/modules/5.3.x/modules/auth.html#auth.p.algorithm>
>>  
>> About planned features – I am not aware of major extensions in this module. 
>> Of course, any contribution is welcome.
>>  
>> Cheers,
>>  
>> Henning
>>  
>> -- 
>> Henning Westerholt – https://skalatan.de/blog/ <https://skalatan.de/blog/>
>> Kamailio services – https://gilawa.com <https://gilawa.com/>
>>  
>> From: sr-users > <mailto:sr-users-boun...@lists.kamailio.org>> On Behalf Of Aymeric Moizard
>> Sent: Monday, June 15, 2020 10:31 PM
>> To: Kamailio (SER) - Users Mailing List > <mailto:sr-users@lists.kamailio.org>>
>> Subject: [SR-Users] MD5 and SHA-256 instead of MD5 or SHA-256...
>>  
>> Hi All,
>>  
>> I'd like to improve my setup by switching to SHA-256. 
>> However, as a first step, I would like to offer both MD5 and SHA-256
>> in 2 different WWW-Authenticate header.
>>  
>> If I'm correct, this is not doable with the latest auth module?
>> Is this a planned feature?
>>  
>> As an alternative, I would like to decide the algorithm in the script
>> instead of a module parameter. It looks to me this is also not doable?
>> Again, is this a planned feature?
>>  
>> Thanks to all,
>>  
>> Regards
>> Aymeric
>>  
>> -- 
>> Antisip - http://www.antisip.com 
>> <http://www.antisip.com/>___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
>> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] MD5 and SHA-256 instead of MD5 or SHA-256...

[Olle E. Johansson]

> On 17 Jun 2020, at 10:58, Aymeric Moizard  wrote:
> 
> 
> 
> Le mer. 17 juin 2020 à 08:29, Olle E. Johansson  <mailto:o...@edvina.net>> a écrit :
> Aymeric,
> Good to hear from you!
> 
> ;)
> 
> There’s been some discussion in the IETF which we haven’t resolved on how to 
> handle this. I think you need to setup
> different domains or realms each with one auth algorithm. If you offer two at 
> the same time - what’s the point?
> 
> I don't understand why using different realm compared to one realm for both 
> would be better?
Each realm would have a *SINGLE* auth algorithm.

> 
> You are still wide open for downgrade attacks and haven’t accomplished much. 
> 
> Today, MD5 is used. If both MD5 and SHA-256 are proposed, it can't be worst 
> in terms of security... It is true that it doesn't bring much!
Right, if you think you are raising security, you’re wrong… That’s a problem.

> 
> My intention is to start migration.
> I guess, today, the safest start is to choose at runtime based on the 
> user-agent or some internal rules. In a later step, the old way would be 
> removed.
Maybe, but in many cases that will never happen because you have legacy phones 
that hang around until the end of time.
We need to find a decent way to make segments of your network require stronger 
algorithms and don’t offer downgrades. Basing that on user-agent headers is not 
a working solution - and you know it :-)

> 
> If people providing services don't start to use newer algo, there won't be 
> any effort on the endpoint side.
> 
> My initial complete objective: (theory)
> 1/ offer bother md5 and sha-256 to user-agent which still use md5 and which 
> are NOT broken in this mode. (Runtime decision)
> 2/ offer only sha-256 to user-agent with sha-256 support.
> 3/ offer only MD5 to user-agent with don't support sha-256 AND are broken if 
> both are offered.
> 
> I could also start with point 2 and 3 only, but would prefer to have 1/2/3…
Check RFC 8760 for advice and hints on this.

Cheers
/O
> 
> 
> Regards,
> Aymeric
> 
> I guess we will have to wait until the IETF resolves this issue, which 
> propably applies to more protocols.
> The big question is how to upgrade a user base to stronger authentication 
> algorithms in HTTP Digest auth
> without allowing downgrade attacks.
> 
> Cheers,
> /O
> 
>> On 16 Jun 2020, at 20:42, Henning Westerholt > <mailto:h...@skalatan.de>> wrote:
>> 
>> Hello,
>>  
>> take a look to this parameter, you can switch between MD5 and SHA256, but 
>> only use once at a time:
>>  
>> https://www.kamailio.org/docs/modules/5.3.x/modules/auth.html#auth.p.algorithm
>>  
>> <https://www.kamailio.org/docs/modules/5.3.x/modules/auth.html#auth.p.algorithm>
>>  
>> About planned features – I am not aware of major extensions in this module. 
>> Of course, any contribution is welcome.
>>  
>> Cheers,
>>  
>> Henning
>>  
>> -- 
>> Henning Westerholt – https://skalatan.de/blog/ <https://skalatan.de/blog/>
>> Kamailio services – https://gilawa.com <https://gilawa.com/>
>>  
>> From: sr-users > <mailto:sr-users-boun...@lists.kamailio.org>> On Behalf Of Aymeric Moizard
>> Sent: Monday, June 15, 2020 10:31 PM
>> To: Kamailio (SER) - Users Mailing List > <mailto:sr-users@lists.kamailio.org>>
>> Subject: [SR-Users] MD5 and SHA-256 instead of MD5 or SHA-256...
>>  
>> Hi All,
>>  
>> I'd like to improve my setup by switching to SHA-256. 
>> However, as a first step, I would like to offer both MD5 and SHA-256
>> in 2 different WWW-Authenticate header.
>>  
>> If I'm correct, this is not doable with the latest auth module?
>> Is this a planned feature?
>>  
>> As an alternative, I would like to decide the algorithm in the script
>> instead of a module parameter. It looks to me this is also not doable?
>> Again, is this a planned feature?
>>  
>> Thanks to all,
>>  
>> Regards
>> Aymeric
>>  
>> -- 
>> Antisip - http://www.antisip.com 
>> <http://www.antisip.com/>___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
>> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] MD5 and SHA-256 instead of MD5 or SHA-256...

[Olle E. Johansson]

Aymeric,
Good to hear from you!

There’s been some discussion in the IETF which we haven’t resolved on how to 
handle this. I think you need to setup
different domains or realms each with one auth algorithm. If you offer two at 
the same time - what’s the point?
You are still wide open for downgrade attacks and haven’t accomplished much. 

I guess we will have to wait until the IETF resolves this issue, which propably 
applies to more protocols.
The big question is how to upgrade a user base to stronger authentication 
algorithms in HTTP Digest auth
without allowing downgrade attacks.

Cheers,
/O

> On 16 Jun 2020, at 20:42, Henning Westerholt  wrote:
> 
> Hello,
>  
> take a look to this parameter, you can switch between MD5 and SHA256, but 
> only use once at a time:
>  
> https://www.kamailio.org/docs/modules/5.3.x/modules/auth.html#auth.p.algorithm
>  
> 
>  
> About planned features – I am not aware of major extensions in this module. 
> Of course, any contribution is welcome.
>  
> Cheers,
>  
> Henning
>  
> -- 
> Henning Westerholt – https://skalatan.de/blog/ 
> Kamailio services – https://gilawa.com 
>  
> From: sr-users  > On Behalf Of Aymeric Moizard
> Sent: Monday, June 15, 2020 10:31 PM
> To: Kamailio (SER) - Users Mailing List  >
> Subject: [SR-Users] MD5 and SHA-256 instead of MD5 or SHA-256...
>  
> Hi All,
>  
> I'd like to improve my setup by switching to SHA-256. 
> However, as a first step, I would like to offer both MD5 and SHA-256
> in 2 different WWW-Authenticate header.
>  
> If I'm correct, this is not doable with the latest auth module?
> Is this a planned feature?
>  
> As an alternative, I would like to decide the algorithm in the script
> instead of a module parameter. It looks to me this is also not doable?
> Again, is this a planned feature?
>  
> Thanks to all,
>  
> Regards
> Aymeric
>  
> -- 
> Antisip - http://www.antisip.com 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org 
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
> 
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Determine correct port in record-route if kamailio is behind NAT

[Olle E. Johansson]

Record route is used for coming transactions on the same dialog and needs to be 
something
the server is listening to.

The server (on the other side) for a TCP connection may reuse the TCP 
connection (if outbound is used) or
setup a new connection to the port advertised in Record-route/Route-headers.

As 5060 is the port Kamailio listens to, that is the one to be advertised. The 
other one
is just a source port used for outbound connections and nothing Kamailio 
listens on for
inbound connections.

/O

> On 12 May 2020, at 11:39, Michal Popovic  wrote:
> 
> Hi Daniel,
> 
> thank you for your help.
> 
> I have found out that reason for this behaviour was that kamailio relay UDP 
> connection to TCP connection and tm module adds two record-routes.
> This is correct behaviour, but I am not sure if it is correct that first 
> record-route advertised port 5060 if kamailio opens random port for the 
> connection.
> Shouldn't there be a port that was used for outgoing connection?
> 
> Record-Route:  5060;transport=tcp;r2=on;lr=on;ftag=as1f9ba470>
> Record-Route: 
> 
> Bye,
> Michal
> 
> 
>> On 11 May 2020, at 13:39, Daniel-Constantin Mierla > > wrote:
>> 
>> Hello,
>> 
>> the nature of tcp protocol makes local ports on connect (as well
>> accepted connection ports) ephemeral. Kamailio has for that reason
>> "connection aliases", so the matching is also done based on advertised
>> attributes, not only on connection source ip/port. The interconnect
>> provider should do it also for tcp/tls. I am not sure now, but I think
>> there is also in the RFC specs something about.
>> 
>> Then, the alternative, with the latest kernels and kamailio, you can try
>> to reuse the tcp port:
>> 
>>   * https://www.kamailio.org/wiki/cookbooks/5.3.x/core#tcp_reuse_port 
>> 
>> 
>> On the other hand, the firewall may associate a different extern port
>> for connections originated from the same source ip/port, you will have
>> to test and see what happens.
>> 
>> Cheers,
>> Daniel
>> 
>> On 11.05.20 12:23, Michal Popovic wrote:
>>> Hello,
>>> 
>>> so it looks like kamailio used random port for opening connections to our 
>>> partners but did not updates record-route port properly. AWS has symmetric 
>>> NAT and that works fine.
>>> 
>>> Is there any way how to identify port and rewrite record-route?
>>> 
>>> Thanks.
>>> 
>>> Bye,
>>> Michal
>>> 
 On 7 May 2020, at 17:25, Michal Popovic >>> > wrote:
 
 Hello,
 
 our kamailio used for sip trunk interconnections is behind NAT and our 
 cloud provider opens random outgoing ports for outbound connections.
 Our record-route is set to our external address and port 5060, that is 
 probably incorrect, but we did not had any issues.
 One of our partners suddenly begin sending BYEs to the port advertised in 
 record-route instead of port from where he received call.
 
 What is a correct approach here if we are not able to determine open port 
 behind NAT?
 
 Bye,
 Michal
 ___
 Kamailio (SER) - Users Mailing List
 sr-users@lists.kamailio.org 
 https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>> 
>>> ___
>>> Kamailio (SER) - Users Mailing List
>>> sr-users@lists.kamailio.org 
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> 
>> -- 
>> Daniel-Constantin Mierla -- www.asipto.com 
>> www.twitter.com/miconda  -- 
>> www.linkedin.com/in/miconda 
>> Funding: https://www.paypal.me/dcmierla 
>> 
> 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] RTCP

[Olle E. Johansson]

> On 7 May 2020, at 17:08, David Villasmil  
> wrote:
> 
> Hello guys,
> 
> We have clients/vendor who exchange RTP directly to each other. But we'd like 
> to get RTCP packets (and proxy them to the other side). 
> 
> Is this at all possible?

Anything is possible, but how do you see this being a Kamailio issue? 

Kamailio isn’t involved in proxying media and if you use
RTPengine or RTPproxy RTCP packets are handled like RTP packets.

Check with the vendors of your devices.

/O
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Parallel forking - first responder wins

[Olle E. Johansson]

That is the reply route.

Start testing and adding logging.

The case with multiple 200 OK is something we have tested many times. The proxy 
should NOT try to do anything in that case, just
forward the multiple 200 OK to the caller and let the UA decide what to do. The 
UA needs to ACK both, and if it can’t somehow
handle multiple calls, send a BYE to one of them.

/O

> On 20 Apr 2020, at 15:55, Ivan Ribakov  wrote:
> 
> Just thought of a follow up question - is it possible to find out which of 
> the branches Kamailio chose as the winner? According to RFC multiple 200 OK 
> could arrive before CANCEL is sent. Do I need to look for an outgoing ACK to 
> know for sure which branch was chosen for sure or is there a way I could 
> “catch” a winning branch through some sort of custom branch route (thinking 
> along the lines of “t_on_branch_success”)?
> 
> Thanks,
> Ivan
> 
>> On 20 Apr 2020, at 15:28, Ivan Ribakov > <mailto:i.riba...@zaleos.net>> wrote:
>> 
>> Thanks for pointing me to the specific section, Giovanni! I was searching 
>> RFC for the “fork” and “merge” keywords so I never got even close to this 
>> part of RFC.
>> 
>> 
>>> On 20 Apr 2020, at 13:27, Giovanni Maruzzelli >> <mailto:gmar...@gmail.com>> wrote:
>>> 
>>> ( and is implemented in automatic: when receive the 200 OK for a branch 
>>> (the winning one), Kamailio sends CANCEL to the other branches )
>>> 
>>> 
>>> On Mon, Apr 20, 2020 at 12:48 PM Giovanni Maruzzelli >> <mailto:gmar...@gmail.com>> wrote:
>>> Maybe is not very explicit, but I believe section 16.7(10) of RFC 3261 deal 
>>> with it (sends CANCEL to branches)
>>> -giovanni
>>> 
>>> 
>>> On Mon, Apr 20, 2020 at 11:48 AM Ivan Ribakov >> <mailto:i.riba...@zaleos.net>> wrote:
>>> As far as I understand, RFC3261 is not providing any instructions on how to 
>>> deal with forked INVITES specifically. It just says that forking can result 
>>> in multiple dialogs that are part of the same original call. I couldn’t 
>>> find any prescriptions on how/when to deal with these multiple dialogs 
>>> specifically which makes me think it depends on the application. Once 
>>> again, please correct me if I’m wrong.
>>> 
>>> So, in the same way as RFC3261 is not talking about forked INVITE 
>>> priorities or parallelism, but Kamailio (TM module) is providing a 
>>> mechanism for forking in parallel/serial modes (advanced feature that is 
>>> not part of RFC3261, but is built on top of it), I’m wondering whether 
>>> Kamailio (TM module) is providing any advanced features for dealing with 
>>> forked INVITE responses.
>>> 
>>> Thanks,
>>> Ivan
>>> 
>>> 
>>>> On 20 Apr 2020, at 11:13, Olle E. Johansson >>> <mailto:o...@edvina.net>> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On 20 Apr 2020, at 10:31, Ivan Ribakov >>>> <mailto:i.riba...@zaleos.net>> wrote:
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> What I’m trying to achieve is to have Kamailio fork an INVITE to multiple 
>>>>> endpoints in parallel but only maintain the branch that responds first 
>>>>> (first to respond with 200 OK I guess).
>>>>> 
>>>>> I’ve read the TM module documentation on forking 
>>>>> (https://www.kamailio.org/docs/modules/stable/modules/tm.html#tm.serial_forking
>>>>>  
>>>>> <https://www.kamailio.org/docs/modules/stable/modules/tm.html#tm.serial_forking>)
>>>>>  and as far as I understood a combination of “seturi()” + 
>>>>> “append_branch()” + “t_relay()” command calls will allow me to send 
>>>>> multiple forked INVITEs in parallel. 
>>>>> 
>>>>> What I couldn't find information about in the documentation (please point 
>>>>> me to it in case I missed it) is what controls (if any) do I have over 
>>>>> forked requests. Do I need to keep track of the branches myself and 
>>>>> cancel others when first succeeds or does Kamailio have some kind of 
>>>>> setting for implementing such behaviour?
>>>> 
>>>> It’s all implemented according to the RFC 3261 where you can read all the 
>>>> cool details!
>>>> 
>>>> /O
>>>> 
>>>> ___
>>>> Kamailio (SER) - Users Mailing List
>>>> sr-users@lists.ka

Re: [SR-Users] Parallel forking - first responder wins

[Olle E. Johansson]

> On 20 Apr 2020, at 10:31, Ivan Ribakov  wrote:
> 
> Hi all,
> 
> What I’m trying to achieve is to have Kamailio fork an INVITE to multiple 
> endpoints in parallel but only maintain the branch that responds first (first 
> to respond with 200 OK I guess).
> 
> I’ve read the TM module documentation on forking 
> (https://www.kamailio.org/docs/modules/stable/modules/tm.html#tm.serial_forking
>  
> )
>  and as far as I understood a combination of “seturi()” + “append_branch()” + 
> “t_relay()” command calls will allow me to send multiple forked INVITEs in 
> parallel. 
> 
> What I couldn't find information about in the documentation (please point me 
> to it in case I missed it) is what controls (if any) do I have over forked 
> requests. Do I need to keep track of the branches myself and cancel others 
> when first succeeds or does Kamailio have some kind of setting for 
> implementing such behaviour?

It’s all implemented according to the RFC 3261 where you can read all the cool 
details!

/O

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

[Olle E. Johansson]

If you think about it, if the 200 OK is so close to the 180 it doesn’t really 
matter from a signalling standpoint
if the 180 comes first or if it arrives after the 200 OK. It’s the 200 OK that 
is important. If the 180 comes after, it’s
simply ignored and the dialog is established successfully.

The 1xx is seldom significant (unless you have PRACK but that’s another story).

Or do you really have a situation where the 180 is critical?

/O

> On 8 Apr 2020, at 18:01, Steve Davies 
>  wrote:
> 
> Hi Luis,
> 
> Kamailio architecture isn't going to change I'm sure.  There is no central 
> orchestrator - each worker process just grabs messages as fast as it can.  If 
> your processing is slow for some and fast for others then they can get out of 
> order I reckon.  180s are really neither here nor there if there's a 200 OK 
> right behind it.
> 
> Perhaps a proxy like Drachtio would work better for you?
> 
> Steve
> 
> 
> On Wed, 8 Apr 2020 at 17:44, Luis Rojas G.  > wrote:
> Hello, Henning,
> 
> I am worried about this scenario, because it's a symptom of what may happen 
> in other cases. For instance, I've seen that this operator usually sends 
> re-invites immediate after sending ACK.   This may create race conditions 
> like 3.1.5 of RFC5407
> 
> https://tools.ietf.org/html/rfc5407#page-22 
> 
> 
> I'd understand that one happens because of packet loss, as it's in UDP's 
> nature, but in this case it would be artificially created by Kamailio. if 
> there was no problem at network level (packet loss, packets following 
> different path on the network and arriving out of order), why Kamailio 
> creates it? 
> 
> I'd expect that the shared memory is used precisely for this. If an instance 
> of kamailio receives a 200 OK, it could check on the shm and say "hey, 
> another instance is processing a 180 for this call. Let's wait for it to 
> finish" (*). I know there could still be a problem, the instance processing 
> the 180 undergoes a context switch just after it receives the message, but 
> before writing to shm, but it would greatly reduce the chance.
> 
> In our applications we use a SIP stack that always sends messages to the 
> application in the same order it receives them, even though is multi-threaded 
> and messages from the network are received by different threads. So, they 
> really syncronize between them. Why Kamailio instances don't?
> 
> I am evaluating kamailio to use it as a dispatcher to balance load against 
> our several Application Servers, to present to the operator just a couple of 
> entrance points to our platform (they don't want to establish connections to 
> each one of our servers). This operator is very difficult to deal with. I am 
> sure they will complain something like "why are you sending messages out of 
> order? Fix that". The operator will be able to see traces and check that 
> messages entered the Kamailio nodes in order and left out of order. They will 
> not accept it.
> 
> (*) Not really "wait", as it would introduce a delay in processing all 
> messages. it should be like putting it on a queue, continue processing other 
> messages, and go back to the queue later.
> 
> Well, thanks for your answer.
> 
> Luis
> 
> 
> 
> 
> 
> On 4/8/20 3:01 AM, Henning Westerholt wrote:
>> Hello Luis,
>> 
>>  
>> 
>> as the 1xx responses are usually send unreliable (unless you use PRACK), you 
>> should not make any assumption on the order or even the arrival of this 
>> messages. It can also happens on a network level, if send by UDP.
>> 
>>  
>> 
>> Can you elaborate why you think this re-ordering is a problem for you?
>> 
>>  
>> 
>> One idea to enforce some ordering would be to use the dialog module in 
>> combination with reply routes and the textops(x)  module.
>> 
>>  
>> 
>> About the shared memory question – Kamailio implement its own memory manager 
>> (private memory and shared memory pool).
>> 
>>  
>> 
>> Cheers,
>> 
>>  
>> 
>> Henning
>> 
>>  
>> 
>>  
>> 
>> --
>> 
>> Henning Westerholt – https://skalatan.de/blog/ 
>> 
>> Kamailio services – https://gilawa.com 
>> 
>>  
>> 
>> From: sr-users  
>>  On Behalf Of Luis Rojas G.
>> Sent: Tuesday, April 7, 2020 10:43 PM
>> To: sr-users@lists.kamailio.org 
>> Subject: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER
>> 
>>  
>> 
>> Good day,
>> 
>> I am testing the dispatcher 

Re: [SR-Users] Broken link on https://www.kamailio.org/wiki/cookbooks/devel/selects

[Olle E. Johansson]

> On 7 Feb 2020, at 09:20, Björn Bylander  wrote:
> 
> Hi,
> 
> In the section "Complete Select List" on X there's a link to 
> http://sip-router.org/docbook/sip-router/branch/master/select_list/select_list.html
>  which doesn't exist anymore. Can anyone tell me where the current list is 
> located?

Hej Björn!

https://www.kamailio.org/wiki/cookbooks/5.3.x/selects 


/O___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] kamailio Dispatcher error

[Olle E. Johansson]

> On 20 Nov 2019, at 10:55, Gaurav Bmotra  wrote:
> 
> ERROR: bad config file (4 errors)

Check the syslog for details on these four errors or start kamailio in the 
foreground with "kamailio -c” to see them.

/O___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] CRM / Windows integration

[Olle E. Johansson]

> On 9 May 2019, at 11:37, Daniel Tryba  wrote:
> 
> On Thu, May 09, 2019 at 10:15:16AM +0100, Mark Boyce wrote:
>> We???ve been asked a few times recently if we can do screen-pop of
>> incoming calls (SalesForce CRM / Zoho Support) so that customers
>> details pop up on the display as calls are delivered.  Similarly
>> ???click to dial??? from such systems.
>> 
>> Such integrations exist for many commercial soft switches like 3CX /
>> FreePBX.  We???re wondering if it can be done at the Kamailio layer
>> just above the sip handset.
>> 
>> I haven???t yet dug in to what the APIs are to achieve this for
>> system, equally a google of the subject came up with very little.  So
>> I thought I???d ask here before reinventing the wheel. 
> 
> There is an example click to dial:
> https://github.com/kamailio/kamailio/blob/master/misc/examples/scripts/ctd.sh
> (never tested it myself)
> 
> Implement a http server(can be kamailio) that calls the script with
> arguments. You are only limited by what you can do in your CRM with
> regard to click to dial.

https://kamailio.org/docs/modules/5.2.x/modules/dialog.html#dlg.r.bridge_dlg

There’s also built-in functionality in the dialog module.

Cheers,
/O
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Licensing clarification of Kamailio scripting code

[Olle E. Johansson]

> On 7 Mar 2019, at 22:00, Henning Westerholt  wrote:
> 
> Am Mittwoch, 6. März 2019, 08:43:05 CET schrieb Wei Li Jiang:
>> I am aware the Kamailio itself as well as the native C modules are licensed
>> under the GPL.
>> What is the licensing situation with the Kamailio routing scripts, both
>> native and via KEMI?
> 
> Hello Wei,
> 
> I am not a lawyer, and for a definite answer to your particular case I'd 
> suggest you consult one.
> 
> You are correct, Kamailio is licensed mainly under GPL2 or later. The core is 
> licensed under the BSD license.
My interpretation is that while the core is contributed and the core source 
files are licensed
under BSD; the Kamailio distribution overall, including the core, is licensed 
under GPL2
when we distribute tarballs and distribution packages.

This includes the sample configuration files and the documentation READMEs 
included
in the distribution.

Again, I’m no lawyer either :-)

/O

> 
> About your question: 
> 
> Kamailio interprets the routing script during run-time. This does not enforce 
> a certain license on this particular Kamailio configuration script. You as an 
> author can choose a license that you prefer.
> 
> You will find a more extensive explanation in the GPL FAQ, first paragraph:
> 
> https://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL
> 
> If you e.g. sell a Kamailio script to a customer, the customer can of course 
> access the script and look to it. It is available on the server in the end. 
> But this does not alter your right to choose a license.
> 
> Best regards,
> 
> Henning
> 
> -- 
> Henning Westerholt - https://skalatan.de/blog/
> Kamailio services - https://skalatan.de/services
> Kamailio security assessment - https://skalatan.de/de/assessment
> 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Default memory

[Olle E. Johansson]

> On 19 Dec 2018, at 18:35, Daniel-Constantin Mierla  wrote:
> 
> Hello,
> 
> On 19.12.18 16:11, Duarte Rocha wrote:
>> Greetings,
>> 
>> How can i ibcrease permanently the Kamailio default private and shared
>> memory size?
> 
> you can provide the values via -m (shm) and -M (pkg) command line
> parameters. See also kamailio -h for it.
> 
> If you want to recompile kamailio, then you can change the corresponding
> defines inside src/core/config.h

In some Linux distros there is either a file called /etc/default/kamailio with 
a setting for you or settings in the Systemd/init.d scripts.

/O
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] [sr-dev] RFC: updates to some core functions

[Olle E. Johansson]

> On 19 Dec 2018, at 12:26, Daniel-Constantin Mierla  wrote:
> 
> 
> On 19.12.18 09:47, Olle E. Johansson wrote:
>> 
>>> On 19 Dec 2018, at 09:41, Daniel-Constantin Mierla  
>>> wrote:
>>> 
>>> corex module was added to hold the functions that otherwise would be
>>> more or less "in the core", like those that were updated to support
>>> variables in the parameters, so this is the one to take the place of
>>> core in regard to exporting functions.
>>> 
>>> tmx was added because tm module became very big, but also to try to
>>> separate a bit between transaction management code and some functions in
>>> top of it, in the way that tmx can work only with exported api by tm, so
>>> if one adds a function there doesn't get access to all internals of
>>> transaction and it is safer not to mess up things there. It is more or
>>> less like usrloc and registrar, usrloc does internal management of
>>> location records, registrar is the interface to configuration file (but
>>> there are other modules on top of usrloc, like pua_usrloc, dmq_usrloc, ...).
>>> 
>>> kex is the one that collected some functions that use to be in kamailio
>>> (or better said openser at that time) but not in ser during 2005-2008
>>> and can be a module that be analyzed to see if can be merged into other
>>> modules. A big chunk of it used to be related to MI commands, but as we
>>> got rid of MI, might be easier now to split parts of it and relocate.
>>> 
>> Ok, so removing kex is a good first step for the coming release.
>> 
>> It’s really hard explaining TMX and TM for new Kamailians.
> 
> We can add a note at the top of docs for each of these modules to refer
> to the other.
> 
> On the other hand, I do not like to have a huge module. It is not
> suitable for small embedded systems. Also, there are other modules using
> the tm api, so it is a common approach. The tmx is exporting mostly
> functions at higher level of transaction interaction, one can build a
> transaction stateful sip routing without it, only using tm.
> 
Damn it. My campaign for exit of the x modules just died. Sad story.

Thanks for all the responses!

/O
> Cheers,
> Daniel
> 
>> 
>> /O :-)
>> 
>>> Cheers,
>>> Daniel
>>> 
>>> On 19.12.18 09:25, Olle E. Johansson wrote:
>>>> Going back one step, are there any reasons to keep tmx, kex and corex 
>>>> modules at all?
>>>> 
>>>> At this point in the project I think many of the functions should be 
>>>> merged into 
>>>> the main modules and core. 
>>>> 
>>>> If I remember correctly, they exist because of a multi-brand history that 
>>>> is not
>>>> really the case any more.
>>>> 
>>>> /O
>>>> “The campaign to remove Kamailio extensions to Kamailio”
>>>> 
>>>> 
>>>>> On 19 Dec 2018, at 09:11, Henning Westerholt  wrote:
>>>>> 
>>>>> Am Mittwoch, 19. Dezember 2018, 09:03:26 CET schrieb Sergey Safarov:
>>>>>> I prefer second way. Without any duplication.
>>>>>> For old configs branches 4.4, 5.0, 5.1 is always available.
>>>>> Hello,
>>>>> 
>>>>> I would prefer also the second way, for the same reason: less duplicated 
>>>>> functions.
>>>>> 
>>>>> Best regards,
>>>>> 
>>>>> Henning
>>>>> 
>>>>> 
>>>>>> ср, 19 дек. 2018 г. в 10:50, Daniel-Constantin Mierla 
>>>>>> :
>>>>>>> Hello,
>>>>>>> 
>>>>>>> it was brought into discussions several times in the past about core
>>>>>>> functions not accepting variables in the parameters. I think it is time
>>>>>>> to update them during the 5.3 release development. For few of them, I
>>>>>>> added in the past some alternative function in the corex module (e.g.,
>>>>>>> force_send_socket() in core and set_send_socket() in corex module).
>>>>>>> 
>>>>>>> So, I see two options:
>>>>>>> 
>>>>>>> 1) add a function with similar name in corex module and same behaviour
>>>>>>> like the one from core
>>>>>>> 
>>>>>>> 2) remove the function export from the core and export one with the same
>>>>>>>

Re: [SR-Users] [sr-dev] RFC: updates to some core functions

[Olle E. Johansson]

> On 19 Dec 2018, at 09:41, Daniel-Constantin Mierla  wrote:
> 
> corex module was added to hold the functions that otherwise would be
> more or less "in the core", like those that were updated to support
> variables in the parameters, so this is the one to take the place of
> core in regard to exporting functions.
> 
> tmx was added because tm module became very big, but also to try to
> separate a bit between transaction management code and some functions in
> top of it, in the way that tmx can work only with exported api by tm, so
> if one adds a function there doesn't get access to all internals of
> transaction and it is safer not to mess up things there. It is more or
> less like usrloc and registrar, usrloc does internal management of
> location records, registrar is the interface to configuration file (but
> there are other modules on top of usrloc, like pua_usrloc, dmq_usrloc, ...).
> 
> kex is the one that collected some functions that use to be in kamailio
> (or better said openser at that time) but not in ser during 2005-2008
> and can be a module that be analyzed to see if can be merged into other
> modules. A big chunk of it used to be related to MI commands, but as we
> got rid of MI, might be easier now to split parts of it and relocate.
> 
Ok, so removing kex is a good first step for the coming release.

It’s really hard explaining TMX and TM for new Kamailians.

/O :-)

> Cheers,
> Daniel
> 
> On 19.12.18 09:25, Olle E. Johansson wrote:
>> Going back one step, are there any reasons to keep tmx, kex and corex 
>> modules at all?
>> 
>> At this point in the project I think many of the functions should be merged 
>> into 
>> the main modules and core. 
>> 
>> If I remember correctly, they exist because of a multi-brand history that is 
>> not
>> really the case any more.
>> 
>> /O
>> “The campaign to remove Kamailio extensions to Kamailio”
>> 
>> 
>>> On 19 Dec 2018, at 09:11, Henning Westerholt  wrote:
>>> 
>>> Am Mittwoch, 19. Dezember 2018, 09:03:26 CET schrieb Sergey Safarov:
>>>> I prefer second way. Without any duplication.
>>>> For old configs branches 4.4, 5.0, 5.1 is always available.
>>> Hello,
>>> 
>>> I would prefer also the second way, for the same reason: less duplicated 
>>> functions.
>>> 
>>> Best regards,
>>> 
>>> Henning
>>> 
>>> 
>>>> ср, 19 дек. 2018 г. в 10:50, Daniel-Constantin Mierla :
>>>>> Hello,
>>>>> 
>>>>> it was brought into discussions several times in the past about core
>>>>> functions not accepting variables in the parameters. I think it is time
>>>>> to update them during the 5.3 release development. For few of them, I
>>>>> added in the past some alternative function in the corex module (e.g.,
>>>>> force_send_socket() in core and set_send_socket() in corex module).
>>>>> 
>>>>> So, I see two options:
>>>>> 
>>>>> 1) add a function with similar name in corex module and same behaviour
>>>>> like the one from core
>>>>> 
>>>>> 2) remove the function export from the core and export one with the same
>>>>> name from the corex module
>>>>> 
>>>>> First one will ensure that configs using the functions right now keep
>>>>> working without any update.
>>>>> 
>>>>> The second one will be better in long term from the point of
>>>>> documentation (no duplicated docs), but there might be few cases that
>>>>> would require updates in the config -- iirc, there are some functions
>>>>> that can get special tokens in the parameters (like forward(uri:host,
>>>>> uri:port)), they will get an equivalent with variables, but old config
>>>>> will not be compatible.
>>>>> 
>>>>> Obviously the reason for this email is to ask the developers and users
>>>>> what would be the preferred way from own point of view.
>>>>> 
>>>>> Cheers,
>>>>> Daniel
>>> 
>>> -- 
>>> Henning Westerholt - https://skalatan.de/blog/
>>> Kamailio services - https://skalatan.de/services
>>> Kamailio security assessment - https://skalatan.de/de/assessment
>>> 
>>> ___
>>> Kamailio (SER) - Development Mailing List
>>> sr-...@lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
>> 
>> ___
>> Kamailio (SER) - Development Mailing List
>> sr-...@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
> 
> -- 
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
> Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in 
> Washington, DC, USA -- www.asipto.com
> 


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] [sr-dev] RFC: updates to some core functions

[Olle E. Johansson]

Going back one step, are there any reasons to keep tmx, kex and corex modules 
at all?

At this point in the project I think many of the functions should be merged 
into 
the main modules and core. 

If I remember correctly, they exist because of a multi-brand history that is not
really the case any more.

/O
“The campaign to remove Kamailio extensions to Kamailio”


> On 19 Dec 2018, at 09:11, Henning Westerholt  wrote:
> 
> Am Mittwoch, 19. Dezember 2018, 09:03:26 CET schrieb Sergey Safarov:
>> I prefer second way. Without any duplication.
>> For old configs branches 4.4, 5.0, 5.1 is always available.
> 
> Hello,
> 
> I would prefer also the second way, for the same reason: less duplicated 
> functions.
> 
> Best regards,
> 
> Henning
> 
> 
>> ср, 19 дек. 2018 г. в 10:50, Daniel-Constantin Mierla :
>>> Hello,
>>> 
>>> it was brought into discussions several times in the past about core
>>> functions not accepting variables in the parameters. I think it is time
>>> to update them during the 5.3 release development. For few of them, I
>>> added in the past some alternative function in the corex module (e.g.,
>>> force_send_socket() in core and set_send_socket() in corex module).
>>> 
>>> So, I see two options:
>>> 
>>> 1) add a function with similar name in corex module and same behaviour
>>> like the one from core
>>> 
>>> 2) remove the function export from the core and export one with the same
>>> name from the corex module
>>> 
>>> First one will ensure that configs using the functions right now keep
>>> working without any update.
>>> 
>>> The second one will be better in long term from the point of
>>> documentation (no duplicated docs), but there might be few cases that
>>> would require updates in the config -- iirc, there are some functions
>>> that can get special tokens in the parameters (like forward(uri:host,
>>> uri:port)), they will get an equivalent with variables, but old config
>>> will not be compatible.
>>> 
>>> Obviously the reason for this email is to ask the developers and users
>>> what would be the preferred way from own point of view.
>>> 
>>> Cheers,
>>> Daniel
> 
> 
> -- 
> Henning Westerholt - https://skalatan.de/blog/
> Kamailio services - https://skalatan.de/services
> Kamailio security assessment - https://skalatan.de/de/assessment
> 
> ___
> Kamailio (SER) - Development Mailing List
> sr-...@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users