Tech

Hosted PBX and SIP-ALG

Published on:

April 2, 2014

In 5.2.2 we’re addressing a common challenge for SIP phones in LANs that need an outbound proxy based on their location. To provide the required quality of service, devices like Edgewater VoIP routers, or even simpler routers, route SIP traffic separately from other office data. To offer more flexibility, we’ve introduced a pattern-based list for specifying outbound proxies. This allows you to define specific IP addresses, ports, and transport types for different networks. For example, if a tenant has two offices with different network setups, the domain setting allows administrators to configure outbound proxies for each office using patterns like "1.2.3.4/32/10.0.0.2" or "10.43.0.0/24/edge43.company.com:5061/tls".

Another piece in the hosted PBX puzzle we are addressing in 5.2.2 is that SIP phones in LAN often need an outbound proxy that depends on the location.

It is actually a scenario that makes sense. Using a local SIP-aware device is the ticket to providing a quality of service required by many offices. The device can be a full-blown device like an Edgewater VoIP router, but it can also be a trivial router using another DSL line. The point is the VoIP phones need to send their traffic to a specific IP address which will make sure the traffic will be routed differently from the other data traffic in the office.

To offer maximum flexibility, we are introducing a list of patterns in 5.2.2 that looks like this: src/mask/adr[:port[/transport]]. If the phone to be provisioned matches the source address src with the netmask mask, it will use the outbound proxy made of the adr:port and transport parameters. The port and the transport are optional. If they are not present, they will be replaced with 5060 and udp.

The setting is a domain setting so that customers can service themselves in hosted environments. The setting can be found in the PnP settings on the domain.

So let’s say that a tenant has two offices which have a VoIP router. The first office is at 1.2.3.4, and all traffic needs to be sent to 10.0.0.2. The first pattern would be “1.2.3.4/32/10.0.0.2”.

The second office would be in the VPN of the company using IP addresses 10.43.0.x, and the internal gateway is at edge43.company.com, using TLS on port 5061. Then the second pattern would be “10.43.0.0/24/edge43.company.com:5061/tls”. In the domain setting the administrator would have to enter “1.2.3.4/32/10.0.0.2 10.43.0.0/24/edge43.company.com:5061/tls”.

Derniers articles

Voir tous

Introducing the Vodia Partner Program: higher discounts as you grow

The Vodia Partner Program and new Vodia Partner Portal give service providers, MSPs, system integrators, and technology partners a clearer way to grow their Vodia business. Partners can earn status points through revenue, certifications, customer acquisition, referrals, and other activities, then use those points to progress through partner levels and unlock higher discounts. The launch also includes a limited-time Summer Launch Promotion, giving new partners a faster path toward Gold status and a 20% discount.

June 18, 2026

Using service flags in V70 of the Vodia PBX

V70 of the Vodia PBX introduces flexible service flags that help organizations automate call routing, scheduling, queue management, announcements, and communication workflows throughout the day. Service flags can be configured manually or automatically to control how calls are handled during business hours, after hours, holidays, or special events. They can also be chained together for more advanced routing logic and integrated with external calendars such as Google Calendar to support dynamic scheduling and operational flexibility across business environments.

May 12, 2026

Keycloak OpenID Connect Integration for the Vodia PBX

Vodia’s PBX now integrates with Keycloak OpenID Connect, providing secure single sign-on for users so they can access all connected applications without repeated authentication. Logging out from one application automatically logs the user out of all connected systems, simplifying user management and improving security. Keycloak, a Cloud Native Computing Foundation project, supports standard protocols including OpenID Connect, OAuth 2.0, and SAML, offering enterprise-grade identity and access management. To ensure proper integration, Keycloak user emails must match the corresponding PBX extension emails. Complete guidance is available in the Vodia Keycloak integration guide, with additional details in the Keycloak official documentation.

September 12, 2025