CUSTOMER CONNECTIVITY
The customer's internet, local network, power and endpoint path.
NETWORK + RESILIENCE
The phone system should not live in one place.
JFM operates communications across multiple Australian locations so the platform is not designed around one physical site.
PLATFORM / INFRASTRUCTURE
A communications platform is infrastructure.
A business phone system depends on more than the PBX application visible to a user. Call ingress, platform location, routing, connectivity and destinations all contribute to the service outcome.
Treating voice as infrastructure changes the design question. Instead of asking only where an extension is registered, JFM considers how calls enter the environment, which platform services handle them, which business rules apply and which endpoint should receive the result.
Those layers remain related without being identical. A distributed platform can reduce dependence on one infrastructure location, while the complete call still depends on the configured route, the customer's connectivity, the destination and the upstream voice path.
ACTIVE LOCATIONS
Two active locations. One communications platform.
Perth and Melbourne are equal active members of the JFM platform. Neither is presented as the normal primary site or as a passive standby for the other.
PERTH
ACTIVEAvailable as an active ingress location and a peer within the distributed communications platform.
MELBOURNE
ACTIVEAvailable as an active ingress location with the same architectural authority as Perth.
Calls can be presented to the JFM environment through either active Australian location where the surrounding voice routing permits it. Each call follows the location and configured route carrying that session; the design does not depend on a duplicate live session at both sites.
The relationship is a distributed logical fabric, not a central physical controller that both locations depend upon. Routing and communications services operate across the platform while each active location remains a genuine ingress-capable member.
CALL INGRESS / ARCHITECTURE
The number is not tied to one PBX in one building.
A call can enter an active platform location and then be handled according to the communications design. Infrastructure location and call logic are separate decisions.
INGRESS
Calls enter through the upstream voice environment and can be presented to an available active JFM location.
LOCATION
Perth and Melbourne are equal active members of the communications platform, not primary and standby sites.
ROUTING
Call logic applies the organisation's hours, availability, queue, escalation and workflow requirements.
DESTINATION
The selected route reaches a person, queue, mobile, workflow or other configured destination.
After ingress, Call Flow Engineering can apply hours, queue logic, department selection, mobile or on-call routing, an optional AI branch and the final destination. The platform location carrying the service does not replace those business decisions.
The upstream voice fabric is distributed across locations. This describes multi-location ingress, while provider diversity and other upstream dependencies remain part of the designed service boundary.
LOCATION-RESILIENCE EXAMPLE
Route around an unavailable location.
This example illustrates one defined failure case: a new call uses an available active location when another JFM location is unavailable and the surrounding voice route supports the alternate path.
NORMAL / DISTRIBUTED INGRESS
PERTH ACTIVEMELBOURNE ACTIVE
AVAILABLE PLATFORM PATHS
ARCHITECTURE EXAMPLE / LOCATION EVENT
PERTH UNAVAILABLEMELBOURNE ACTIVE
CALL → AVAILABLE PATH → DESTINATION
In the illustrated event, Perth is unavailable while Melbourne remains active. The incoming call follows the available path into the platform and continues toward its configured destination. The architecture concept also applies in reverse; neither city is reserved as the permanent failover site.
The example focuses on location availability. Upstream services, customer connectivity, endpoints and configured destinations remain separate dependencies in the complete call path.
RESILIENCE / BOUNDARIES
Resilience is about removing unnecessary dependencies.
A distributed design can reduce reliance on one application host, one hypervisor, one physical location or one ingress location where the implemented architecture supports that separation.
Defined failure cases can have an alternate path.
The objective is to keep the service design understandable while giving traffic more than one appropriate place to enter and operate. Monitoring and service visibility help operators understand platform state; they are not a substitute for sound routing and tested dependencies.
Distributed does not mean invulnerable.
Calls may still depend on public networks, upstream voice services, customer connectivity, power, endpoints, external destinations and correct routing configuration. Location resilience is designed for specific infrastructure events; it is not a promise that every external dependency can never fail.
LOCATION / EXTENSIBILITY
Sydney is planned. The distinction matters.
The platform is designed to extend to additional locations. Sydney is the next planned Australian platform location, but it is not shown carrying traffic today.
JFM / LOCATION 03
SYDNEY
PLANNEDPlanning status carries no launch date, facility, capacity, carrier or active route.
Customer sites are a different layer.
An office, warehouse, branch, home worker or mobile user is part of the customer's operating footprint. Perth and Melbourne describe JFM's active platform locations. Connecting several customer sites through Business Voice does not itself create infrastructure clustering.
Keeping that distinction clear allows customer endpoints, distributed platform infrastructure, call logic and security policy to be designed as related parts without conflating their system boundaries.
START A CONVERSATION
Design voice around distributed infrastructure.
Start with the locations, ingress paths, customer connectivity and call behaviour that matter. JFM can design the platform and routing boundaries around the actual requirement.