Ringfree Datacenter Design
It’s often beneficial to understand how the Ringfree datacenter servers are deployed to troubleshoot various issues (such as an upstream carrier outage) or just generally understand the service you’re offering to customers.
Below is a an outline pointing out service availability and what service handles what type of traffic and how that is reconciled with the concept of a hosted cloud PBX.
To access any customer portion of the infrastructure, one must first pass one of two proxy services (of which there are multiple instances of for failover purposes).
The first class is known inhouse as REVNAT (Reverse NAT proxy). This service proxies access to pbxuser and pbxadmin interfaces, FOP2 websocket traffic, and Asterisk AMI access.
Any non-voice protocol will be handled by REVNAT. All REVNAT traffic is routed based on hostname rendered to the various proxy service (Apache, haproxy, Prosody, etc).
An SBC (Session Border Controller) exists in all Ringfree datacenters. It handles any traffic related to voice. Ringfree uses the open standard of SIP to provide voice service to its customers as well as trunk voice traffic back and forth between inbound and outbound carriers.
All SBC SIP registration and endpoint traffic is routed based on hostname rendered to the Sansay SBC. Call termination traffic (outbound) is first passed through a calling plan which exposes a set of prefixes allowed to be called. The calling plans (US48, US48 + Ext, US48 + Ext + International) route calls based on prefixes through our termination provider (Thinq). Call origination traffic (inbound) is routed based on DNIS and routed to the appropriate PBX by hostname per configuration.
Keeping our traffic organized provides us with not only better performance, but better security as well. It also provides us the ability to run the majority of our services behind our own private networks and exposing only the services required in a controlled manner.
So you want to register a phone and make a call. To do this you would first create the extension by accessing the PBX’s web gui. This traffic hits REVNAT, then is passed by hostname through the node and to the appropriate PBX you are registering the phone to. After the PBX has been configured with that extension you register a phone to it using the SBC as the phone’s proxy. The phone hits the proxy and by the hostname it provides for the PBX the SBC acts as a registrar validating the credentials for the phone. When you make a call out the PBX from that phone, you are making a call through the SBC, to the PBX, and then back out the SBC to the upstream carrier. This is handled by the SIP Trunk that the PBX is configured for.
Likewise, for an inbound call to a customer’s DID, when the number is dialed it hits the upstream carrier who routes the call to our SBC where it is then routed the PBX after the DID is matched against a route and then checked against a PBX hostname that it was paired with when the DID was entered into the SBC. When the PBX hostname is matched, the call then hits the PBX where its call flow can be configured in any number of ways including hitting an IVR (Interactive Voice Recording), direct route to extension, or ring groups that ring several phones at once.