All Archives - Page 2 of 10 - PyFreeBilling : Open source billing platform for FreeSwitch

How do you deploy your telephony software?

January 18, 2019 by Mathias

What technologies do you use to deploy your VoIP applications in production: physical server, virtual machine (VMWare, KVM …), container (Docker, LXC, LXD …)?
Can you explain your choices?

Why this question ?
PyFB v3 is in the finalization phase, the next step being the development of the deployment and installation process. I want the installation to be as simple as possible especially for a single-server deployment.
Development is done using docker technologies, but production is currently done on physical servers or virtual machines.
But does a docker deployment or other cloud technologies in production make sense to you?

Thank you for your comeback in comment

Historique de PyFreeBilling et introduction de la version 3

November 14, 2018 by Mathias

Dans la première version, seul FreeSwitch était utilisé. Il avait un rôle central, fonctionnait bien (il reste des v1 en production) mais posait quelques problèmes : la montée en charge était limitée et ne pouvait fonctionner que dans un environnement avec un seul serveur.

Pour répondre à cette problématique, un serveur SIP basé sur Kamailio a été introduit en amont du FreeSwitch. Cette évolution permit une architecture multi serveurs, une sécurité accrue, une meilleure performance ainsi qu’une montée en charge illimitée sans coupure de service. Cette architecture couplée avec des technologies d’infrastructure as code et des outils d’automatisation tels que Ansible permet de mettre en place des solutions complexes automatisées.

Maintenant, je vais rapidement introduire la v3. Les flux SIP seront entièrement gérés par Kamailio tandis que les flux RTP par RTPEngine. FreeSwitch ou Asterisk ne seront utilisés que pour les services de class 5. Cela va permettre une meilleure performance intrinsèque et la possibilité d’ajoût de nouveaux services via de simples APIs.

PyFreeBilling évolue chaque jour afin de proposer une solution complète de téléphonie sur IP aux petits opérateurs toujours plus fiable et évolutive.

Merci

Mathias

History of PyFreeBilling and introduction of version 3

November 14, 2018 by Mathias

In the first version, only FreeSwitch was used. It had a central role, worked well (there are still v1 in production) but posed some problems: the scalability was limited and could only work in an environment with a single server.

To answer this problem, a SIP server based on Kamailio was introduced upstream of the FreeSwitch. This evolution enabled a multi-server architecture, increased security, better performance and unlimited scalability without service interruption. This architecture coupled with infrastructure technologies as code and automation tools such as Ansible allows to set up complex automated solutions.

Now, I will quickly introduce the v3. SIP streams will be fully managed by Kamailio while RTP streams by RTPEngine. FreeSwitch or Asterisk will only be used for class 5 services. This will allow for better intrinsic performance and the possibility of adding new services via simple APIs.

PyFreeBilling evolves every day in order to offer a complete IP telephony solution to small operators, always more reliable and scalable.

Thank you

Mathias

Historia de PyFreeBilling e introducción de la versión 3.

November 14, 2018 by Mathias

En la primera versión, solo se utilizó FreeSwitch. Tenía un rol central, funcionaba bien (todavía hay v1 en producción) pero planteaba algunos problemas: la escalabilidad era limitada y solo podía funcionar en un entorno con un solo servidor.

Para responder a este problema, se introdujo un servidor SIP basado en Kamailio antes del FreeSwitch. Esta evolución permitió una arquitectura de varios servidores, mayor seguridad, mejor rendimiento y escalabilidad ilimitada sin interrupción del servicio. Esta arquitectura, junto con las tecnologías de infraestructura como código y herramientas de automatización, como Ansible, permite configurar soluciones automatizadas complejas.

Ahora, voy a presentar rápidamente la v3. Kamailio gestionará completamente los flujos SIP mientras que RTPEngine gestionará los flujos RTP. FreeSwitch o Asterisk solo se utilizarán para servicios de clase 5. Esto permitirá un mejor rendimiento intrínseco y la posibilidad de agregar nuevos servicios a través de API simples.

PyFreeBilling evoluciona todos los días para ofrecer una solución completa de telefonía IP a pequeños operadores, siempre más confiable y escalable.

Gracias

Mathias

Pyfreebilling v3 version is coming

November 13, 2018 by Mathias

I am very excited by the arrival of the new version of pyfreebilling, version 3 of the voip softwitch application.

—

je suis très excité par l’arrivée de la nouvelle version de pyfreebilling, la version 3 de l’application de softwitch voip.

Securing the web administration interface

February 20, 2018 by Mathias

It is essential to secure access to the administration interface. Sensitive data such as tariffs, SIP accounts, suppliers or even statistics must not be distributed outside authorized persons.

PyFreeBilling natively integrates several security processes.

First of all, the interface is only accessible via the HTTPS protocol with a default configuration that excludes SSL / TLS versions that are not sufficiently robust. It is essential to use a valid certificate to assure the administrator that he is logging onto the correct site and not a hacker page. A script is provided to generate Let’s Encrypt certificates. This script also manages the renewal.

Then, PyFreeBilling integrates a honeypot to automatically block robots or other malicious people.

Finally, after 3 attempts, the user is permanently blocked. The only way to unlock it is to use the command line. For this, a script is provided to simplify the operation.

All connections, successful or not, are logged in database. Thus, an audit is possible to ensure that an unwanted person tries to connect. The logs contain the information of IP addresses, the country of attempted connection but also data concerning the machine used (OS, browser …).

User passwords are not stored in a database but only a hash. In addition, the hash method follows the security recommendations of the Django project. In the event of an update, each time a user logs in, the hash is updated according to the changes.

The addition of a firewall in order to expose the machine only on the necessary ports (in the case of a dedicated machine, only TCP port 443) is also recommended to protect itself from 0day.

It is possible to use for the most cautious a reverse proxy. Be careful to set this one. I urge you to read the recommendations of your reverse proxy to work well with the Django framework.

« Previous Page

Tags

Newsletter