Hi Daniel,

thanks for your quick reply and your questions!

What I‘m aiming for is a SaaS solution where users can build audio on demand flows (like Podcasts, Audio Books, Audio guides etc.) via phone. Currently, they bring their VoIP providers, which require registering with username and password. I also wasn’t aware that usually it works via trusted IPs, thanks for that hint. Already learning a lot here!

As our users usually want to have a local phone number to promote, I think also in the future we will not go with blocks of numbers. But as of now I cannot say for sure.

I think outgoing will be a feature we want to provide later on, e.g. to be connected to someone.

Thanks again!

Philipp

On 11. Aug 2021, at 12:28, Daniel-Constantin Mierla miconda@gmail.com wrote:

 Hello,

couple of questions to see where to guide you:

• are the VoIP providers requesting you to register to their SIP servers? The usual interconnect for a proxy like Kamailio is based on trusted IP addresses, saving roundtrips for traffic authentication using user/password. It is also easier to protect with firewalls and safer when employees leave the company (can't take IP with them, as opposite of knowing the user/pass).

• do you have a block of numbers and asterisk does a single registration to each provider, or right now the asterisk register all the numbers to providers?

• now you mention having incoming calls only, do you plan to support outgoing calls as well?

Cheers, Daniel

...

On 11.08.21 11:50, Philipp Trenz wrote: Hey there,

I’m Philipp, an IT Systems Engineer from Potsdam, Germany and want to deepen my knowledge in SIP communication on scale.

Currently, my setup is quite simple: A single stateless Asterisk instance, fully managed via ARI, which registers to multiple VoIP providers, only processes incoming calls to play audio files (no outgoing or conference calls).

Now, with growing load on the single Asterisk instance, I would like to have one or two Kamailio instances, which will balance the load of incoming calls to multiple Asterisk instances. On which Asterisk instance they end up is irrelevant for me, as the calls can be processed on every instance.

I looked into some Kamailio and Astricon conference speeches and checked out some tutorials. But still I’m not quite sure where to start. So here are some basic questions which would really help me out to get going:

As I don’t want to have registrations of all my Asterisk instances at the VoIP providers, I should use the UAC module to let Kamailio do the registering to the VoIP providers and register my Asterisk instances to Kamailio, right? Will Kamailio automatically apply new outbound registrations when added to the database or do I have to trigger that manually? Should I use one or two instances of Kamailio, how hard is it to configure them fail-safe? For writing my first config file, should I start blank or from the standard config, what’s best practice?

Thanks in advance, looking forward to your replies!

Philipp

---

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

Hello,

answering another of your earlier questions – I’d suggest starting with the standard configuration in the kamailio package/source code. You will find several standard code blocks there, e.g. to authenticate users, handle PSTN calls and other. Sometimes its also a good idea to just setup an kamailio with the default cfg on some system and get some experience with different functionality and some softphones, especially for newcomers. Regarding the balancing of incoming calls to the asterisk, you find an example cfg e.g. in the dispatcher module docs that should provide a starting point.

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 Philipp Trenz Sent: Tuesday, August 17, 2021 2:10 PM To: miconda@gmail.com Cc: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: Re: [SR-Users] Kamailio as basic dispatcher for load balancing

Hi Daniel,

I would be very grateful for your assessment and a little directional advice.

Many thanks! Philipp

Am 11.08.2021 um 17:59 schrieb Philipp Trenz <mail@philipptrenz.demailto:mail@philipptrenz.de>:

Hi Daniel,

thanks for your quick reply and your questions!

What I‘m aiming for is a SaaS solution where users can build audio on demand flows (like Podcasts, Audio Books, Audio guides etc.) via phone. Currently, they bring their VoIP providers, which require registering with username and password. I also wasn’t aware that usually it works via trusted IPs, thanks for that hint. Already learning a lot here!

As our users usually want to have a local phone number to promote, I think also in the future we will not go with blocks of numbers. But as of now I cannot say for sure.

I think outgoing will be a feature we want to provide later on, e.g. to be connected to someone.

Thanks again!

Philipp

On 11. Aug 2021, at 12:28, Daniel-Constantin Mierla <miconda@gmail.commailto:miconda@gmail.com> wrote:  Hello, couple of questions to see where to guide you: * are the VoIP providers requesting you to register to their SIP servers? The usual interconnect for a proxy like Kamailio is based on trusted IP addresses, saving roundtrips for traffic authentication using user/password. It is also easier to protect with firewalls and safer when employees leave the company (can't take IP with them, as opposite of knowing the user/pass). * do you have a block of numbers and asterisk does a single registration to each provider, or right now the asterisk register all the numbers to providers? * now you mention having incoming calls only, do you plan to support outgoing calls as well? Cheers, Daniel On 11.08.21 11:50, Philipp Trenz wrote: Hey there,

I’m Philipp, an IT Systems Engineer from Potsdam, Germany and want to deepen my knowledge in SIP communication on scale.

Currently, my setup is quite simple: A single stateless Asterisk instance, fully managed via ARI, which registers to multiple VoIP providers, only processes incoming calls to play audio files (no outgoing or conference calls).

Now, with growing load on the single Asterisk instance, I would like to have one or two Kamailio instances, which will balance the load of incoming calls to multiple Asterisk instances. On which Asterisk instance they end up is irrelevant for me, as the calls can be processed on every instance.

I looked into some Kamailio and Astricon conference speeches and checked out some tutorials. But still I’m not quite sure where to start. So here are some basic questions which would really help me out to get going:

· As I don’t want to have registrations of all my Asterisk instances at the VoIP providers, I should use the UAC module to let Kamailio do the registering to the VoIP providers and register my Asterisk instances to Kamailio, right? · Will Kamailio automatically apply new outbound registrations when added to the database or do I have to trigger that manually? · Should I use one or two instances of Kamailio, how hard is it to configure them fail-safe? · For writing my first config file, should I start blank or from the standard config, what’s best practice?

Thanks in advance, looking forward to your replies!

Philipp

__________________________________________________________

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