Hello,

you are right, the maximum setting is still the compile time value. The default value for max_branches is 12.

Regarding the increase, the obvious advice applies, just raise it that much as you need. It will increase memory usage for transaction and decrease some run-time performance. But if you are not getting excessive, it should be ok.

Cheers,

Henning

-- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.comhttps://gilawa.com/

From: sr-users sr-users-bounces@lists.kamailio.org On Behalf Of Lars Jansson Sent: Sunday, December 11, 2022 8:24 PM To: sr-users@lists.kamailio.org Subject: Re: [SR-Users] Increase MAX_BRANCHES_LIMIT

Hi Patrick,

Thanks for your reply. I'm aware of the max_branches parameter in the config file, but my understanding from trial and error is that the bounds of the max_branches parameter is set by MAX_BRANCHES_LIMIT in config.h.

Regards, Lars Den 2022-12-10 kl. 14:55, skrev Patrick Karton: Hello there is already max_branches parameter you can set in config file.

Le 10 déc. 2022 13:02, Lars Jansson lars.jansson@solstiernan.numailto:lars.jansson@solstiernan.nu a écrit :

Hi,

I am building a configuration script where for some traffic flows parallel forking will be needed, and in this case I need to go beyond the default max limit of the max amount of branches.

Apart from this specific case the traffic load that kamailio will need to handle is very low, let's say just one second here and there with up to 5 concurrent calls at most.

This limit is as far as I understand set here: usr/local/src/kamailio-5.6/kamailio/src/core/config.h

And the default limit is: #define MAX_BRANCHES_LIMIT 32 /*!< limit of maximum number of branches per transaction */

Here are the questions I have related to this:

1) If I increase the value of this constant in config.h, how high is it reasonable to set this value and still have a stable system?

2) If I increase MAX_BRANCHES_LIMIT beyond 32, are there also other parameters that needs to be changed for the system to be able to cope, and if so which parameters?

Regards, Lars

__________________________________________________________

Kamailio - Users Mailing List - Non Commercial Discussions

sr-users@lists.kamailio.orgmailto: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

Hi Daniel,

thanks for the clarification, I was seeing that it’s used in TM, but did not check about the allocation/internal data structure topic.

Cheers,

Henning

-- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.comhttps://gilawa.com/

From: sr-users sr-users-bounces@lists.kamailio.org On Behalf Of Daniel-Constantin Mierla Sent: Monday, December 12, 2022 8:32 AM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: Re: [SR-Users] Increase MAX_BRANCHES_LIMIT

Hello,

this suggestion to increase MAX_BRANCHES_LIMIT is wrong, its value is constrained to be 32 because of some tm internals which uses a 32 bitmap for cancelled branches in transactions. Might be used for other things, this came in my mind without looking at the code. Going over 32 will require changes in tm module, otherwise it will result in malfunctioning/crashes.

Also, MAX_BRANCHES_LIMIT alone has no impact in memory usage, that is a matter of the global parameter max_branches, MAX_BRANCHES_LIMIT is only used to check that does not exceed it.

Cheers, Daniel On 12.12.22 08:14, Henning Westerholt wrote: Hello,

you are right, the maximum setting is still the compile time value. The default value for max_branches is 12.

Regarding the increase, the obvious advice applies, just raise it that much as you need. It will increase memory usage for transaction and decrease some run-time performance. But if you are not getting excessive, it should be ok.

Cheers,

Henning

-- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.comhttps://gilawa.com/

From: sr-users sr-users-bounces@lists.kamailio.orgmailto:sr-users-bounces@lists.kamailio.org On Behalf Of Lars Jansson Sent: Sunday, December 11, 2022 8:24 PM To: sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org Subject: Re: [SR-Users] Increase MAX_BRANCHES_LIMIT

Hi Patrick,

Thanks for your reply. I'm aware of the max_branches parameter in the config file, but my understanding from trial and error is that the bounds of the max_branches parameter is set by MAX_BRANCHES_LIMIT in config.h.

Regards, Lars Den 2022-12-10 kl. 14:55, skrev Patrick Karton: Hello there is already max_branches parameter you can set in config file.

Le 10 déc. 2022 13:02, Lars Jansson lars.jansson@solstiernan.numailto:lars.jansson@solstiernan.nu a écrit :

Hi,

I am building a configuration script where for some traffic flows parallel forking will be needed, and in this case I need to go beyond the default max limit of the max amount of branches.

Apart from this specific case the traffic load that kamailio will need to handle is very low, let's say just one second here and there with up to 5 concurrent calls at most.

This limit is as far as I understand set here: usr/local/src/kamailio-5.6/kamailio/src/core/config.h

And the default limit is: #define MAX_BRANCHES_LIMIT 32 /*!< limit of maximum number of branches per transaction */

Here are the questions I have related to this:

1) If I increase the value of this constant in config.h, how high is it reasonable to set this value and still have a stable system?

2) If I increase MAX_BRANCHES_LIMIT beyond 32, are there also other parameters that needs to be changed for the system to be able to cope, and if so which parameters?

Regards, Lars

__________________________________________________________

Kamailio - Users Mailing List - Non Commercial Discussions

sr-users@lists.kamailio.orgmailto: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.orgmailto: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.comhttp://www.asipto.com

www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda

Hi Daniel and Henning,

Thanks a lot for your answers, this will save me from wasting time on a dead end. 31x31 is plenty, so this is a way forward to workaround the current limitation in tm.

Just to see if I understand you correctly, Daniel, regarding the record-routing bit: At first record routing is applied as usual, but when a looped request is received and forked to targets no record routing shall be applied?

As a side note I tried setting max_branches=31, but that was not accepted, so I changed to max_branches=30. Perhaps this simply implies that the first branch is enumerated as branch #0 ?

Cheers, Lars

Den 2022-12-12 kl. 09:04, skrev Daniel-Constantin Mierla:

Hello,

the value 32 forMAX_BRANCHES_LIMIT is a constraint of tm internals which uses a 32 bitmap for some operations, going higher will require coding in tm module.

The variant now is to loop one more through kamailio and you can get to 32x32 branches. By doing record route only on one step of looping, then you have this looping only for initial INVITE transaction, the re-INVITE, BYE, etc. will go straight.

One more note, I am not sure and no time to check the code, one bit might be reserved in the bitmap, so it can be 31x31 branches after one local loop.

Cheers, Daniel

On 10.12.22 13:02, Lars Jansson wrote:

...

Hi,

I am building a configuration script where for some traffic flows parallel forking will be needed, and in this case I need to go beyond the default max limit of the max amount of branches.

Apart from this specific case the traffic load that kamailio will need to handle is very low, let's say just one second here and there with up to 5 concurrent calls at most.

This limit is as far as I understand set here: usr/local/src/kamailio-5.6/kamailio/src/core/config.h

And the default limit is: #define MAX_BRANCHES_LIMIT              32      /*!< limit of maximum number of branches per transaction */

Here are the questions I have related to this:

1. If I increase the value of this constant in config.h, how high is

it reasonable to set this value and still have a stable system?

2. If I increase MAX_BRANCHES_LIMIT beyond 32, are there also other

parameters that needs to be changed for the system to be able to cope, and if so whichparameters?

Regards, Lars

---

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

Hi again,

Since I last posted on this topic I now have a working configuration script, including the route blocks I use for the parallel forking flows.

* For the parallel forking flow I use the dispatcher module, pointing directly at the targets with sip:IP:port - so no DNS lookups invoved here

* In the low latency network the solution is working in I also use the function t_set_fr(0, 125);to quickly discard unreachable targets

* For the traffic flow in question I know there will only be one UAS that will respond among all of the parallel targets

So now I'm thinking that an alternative solution would be to use in the route block I use for the parallel forking one destination set in the dispatcher config that points to "the first 31 targets" and as a failure_route another destination set that points to "the next 31 targets".

- Is there any theoretical objection to this?

Cheers, Lars

Den 2022-12-12 kl. 09:04, skrev Daniel-Constantin Mierla:

Hello,

the value 32 forMAX_BRANCHES_LIMIT is a constraint of tm internals which uses a 32 bitmap for some operations, going higher will require coding in tm module.

The variant now is to loop one more through kamailio and you can get to 32x32 branches. By doing record route only on one step of looping, then you have this looping only for initial INVITE transaction, the re-INVITE, BYE, etc. will go straight.

One more note, I am not sure and no time to check the code, one bit might be reserved in the bitmap, so it can be 31x31 branches after one local loop.

Cheers, Daniel

On 10.12.22 13:02, Lars Jansson wrote:

...

Hi,

I am building a configuration script where for some traffic flows parallel forking will be needed, and in this case I need to go beyond the default max limit of the max amount of branches.

Apart from this specific case the traffic load that kamailio will need to handle is very low, let's say just one second here and there with up to 5 concurrent calls at most.

This limit is as far as I understand set here: usr/local/src/kamailio-5.6/kamailio/src/core/config.h

And the default limit is: #define MAX_BRANCHES_LIMIT              32      /*!< limit of maximum number of branches per transaction */

Here are the questions I have related to this:

1. If I increase the value of this constant in config.h, how high is

it reasonable to set this value and still have a stable system?

2. If I increase MAX_BRANCHES_LIMIT beyond 32, are there also other

parameters that needs to be changed for the system to be able to cope, and if so whichparameters?

Regards, Lars

---

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