For some time, the link to reach the demonstration platform is no longer functional. The VPS hosting PyFreeBilling Demo Service is no longer active.
As soon as I have a little time (my priority being to finalize the version 3), I will go back on one of my waiters a functional demonstration of the interface of management of version 3.
In order to test the VoIP part, I foresee an installable docker in one command. This docker will quickly test PyFreeBilling but also deploy small servers!
Have a lovely day everybody !
PyFBv3 : Routing outgoing calls
The outbound calls routing from customer SIP endpoint to carrier partner networks is determined by routing rule tables. These rules allow you to define for the number called and the number calling which rules to use and in which order !
Explanation of notions
In order to understand the documentation, it is necessary to explain the basic concepts used:
- Routing table : logical group grouping a set of rules to determine the operator (s) to end the call.
- Routing rule : rule defining for a given destination an ordered list of operators to use.
- Destination : represents the destination determined by the longest prefix of the called number. For example, * France Orange Mobile *.
- Routing Type : Determines how to distribute calls between a list of providers
- Rate grid : groups together a tariff set for a given destination
Routing logic
An outgoing call from the PyFreeBilling platform to the outside world follows the following logic:
- 1: normalization of called and calling numbers to conform to E.164 without the +
- 2: from the client ID, the routing table to use is retrieved
- 3: search in the routing table, the corresponding rules by category. Each category is inspected in the following order: prefix, destination, country and type, country, region and type, region, and then the default routing category.
- 4: as soon as in a given category, a corresponding rule is found (several rules in the same category can match), the search stops
- 5: a list of tariffs of suppliers is recovered. This list is ordered according to the type of routing: the cheapest cost, the quality, the priority or the weight
- 6: From this list of supplier tariffs, a list of gateways is constructed and ordered according to the type of routing
- 7: the parameters related to the gateways (codec, prefix …) are recovered
- 8: the call is then sent sequentially in case of error to the gateways of the list
- 9: at each attempt and at the end of the call, the SIP messages are archived to facilitate the search for anomaly and the calculation of statistics
Examples of routing rules
A routing table includes one or more routing rules. The basic routing table includes a single rule of type “default”.
Rule “default”
Routing table | Type | Priority | Weight | Status | Grid supplier | List of footbridges |
---|---|---|---|---|---|---|
MaTableRoutage | LCR | 1 | 1 | activated | OBS | GW_63 GW64 |
MaTableRoutage | LCR | 1 | 1 | activated | BT | BT1 |
In our example, we chose a rule type based on the cheapest cost (LCR). Weight and priority do not matter. We have in our example tariff grids called “OBS” and “BT” (we can quite rightly think that they refer to the eponymous operators). We have for “OBS” 2 gateways and for “BT” a defined one (it is quite possible that for “BT” several gateways are defined, but for specific reasons, we only want to use “BT1”).
Since the rule is “default “, all calls will use it.
Rule “destination”
Now, I want to route the calls from the destination “France Mobile SFR” to my interconnection with SFR. For that, I’m going to create a destination rule in addition to my previous rule. This gives us the following 2 tables:
Rule “destination”:
Routing table | Destination | Type | Priority | Weight | Status | Grid supplier | List of footbridges |
---|---|---|---|---|---|---|---|
MaTableRoutage | France Mobile SFR | LCR | 1 | 1 | activated | SFR | GW_SFR |
Rule “default “:
Routing table | Type | Priority | Weight | Status | Grid supplier | List of footbridges |
---|---|---|---|---|---|---|
MaTableRoutage | LCR | 1 | 1 | activated | OBS | GW_63 GW64 |
MaTableRoutage | LCR | 1 | 1 | activated | BT | BT1 |
How is the routing table determined?
The routing table is assigned to the customer account. Thus, upon receipt of an outgoing call from a client SIP account, the system retrieves the identifier of the routing table to be used.
A routing table can be assigned to multiple clients, but in this case a modification of the latter will have an impact on all the clients using this table.
What are the different rule categories?
Categories are listed in order of priority of analysis (from the most accurate to the most general):
- prefix
- destination
- country and type
- country
- region and type
- region
- the default routing category
What are the search criteria for a rule?
First, the rules are analyzed in order of categories. In each category, the system will determine which rules correspond to the calling number: for the category “prefix”, the rules with the longest prefix will be retained, for the category “destination”, the rules with the corresponding category will be withholdings … and so on.
Then, for each rule obtained, the following points are analyzed:
- the status of the rule: the rule should not be disabled
- the purchase price to the supplier must be lower than the selling price to our client (unless we have authorized the sale at a loss in the price list of our client)
- the calling number must not be part of the list of excluded numbers (this allows the use of tariff grids from the same supplier according to the calling number and therefore to apply different purchase prices). This rule is managed at the level of the supplier’s fee schedule.
What are the statuses of a routing rule?
A routing rule can have 3 statuses:
- active: the rule can be used for the routing decision
- inactive: the rule is disabled and can not be used for the routing decision
- blocked: the rule thus defined blocks the routing of the call and terminates it.
Be careful, only define a “blocked” rule, or all rules in the same category for a given destination must be on “blocked”. If an “active” rule exists, calls will be routed. This allows you to block a route, for example calls to satellites.
What are the routing criteria between the selected suppliers?
The routing criteria are as follows:
- the lowest cost (LCR): the cheapest operator will be tested first, in case of failure, the next cheapest will be tested and so on
- by priority: the operator with the highest priority (1) will be tested first
- by weight: a destination has several rules with the same priority: the weight will divide the calls according to the desired ration
- by quality: at a supplier price scale, a grade of 10 corresponding to the quality is assigned by the administrator (10 being the highest value). The operator with the highest fee schedule will be tested first.
It is interesting to note that the use of the “quality” criterion makes it possible to manage the routing of calls between two different price grids of the same provider: for example, it is possible to route the calls via the GOLD grid. then priority to the SILVER grid in case of failure (we can imagine a limitation of capacity for example). In the case of routing according to the criterion “the cheapest cost”, the SILVER grid will be tested before the GOLD grid!
How is the list of gateways to be determined?
A routing rule is used to link a supplier fee schedule with a routing table. It is possible to define in this rule the gateways of our provider to use: all or just a few.
The distribution of calls between the selected gateways of our provider will be balanced.
How do you deploy your telephony software?
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
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
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.
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