This use case will show how to implement Hosted PBX Services for Service providers using an Access SBC in Front of the Hosted PBX platform and an SMB SBC at customer premises to provide Security, Transcoding and Local Survivability to existing endpoints (IP Phones).

The case can be used also as a sample for Large enterprises with Centralized IPPBX (Data center)  and remote branch offices.

We will also explain how to enable remote users roaming on Public Networks in a secure manner (Smart Phones, Home Offices, Employees on the field ...)

The following diagram shows the scenario:

As we can see:

In more detail here are the specifications of what we will configure in the Access SBC:

Let's Start!!!!!

First we will create 2 Sip Profiles in our Access SBC, one internal, in the Private Subnet, facing the IPPBX/Softswitch located at

Now, lest see what is needed in the External Sip Profile:

First we need to associate a domain ( for upper registration:

As we can see:

Now our External SIP Profile nedds to bind the new domain:

At this point is importnt to note that the domaing is a full FQDN alse which resolves the public IP of the SBC in the internet. We will autodiscover that IP by using the prefix "host:" in the Sip Profile. Please note:

Notice that  all authentications are disabled, as it is being delegated to the IPPBX.

We are also enabling all Far End NAT Transversal techniques and will aneable Full Idenification in session routing:

Notice we have associated a Routing plan called Inbound_to_PBX.

Here it is:

So any inbound call coming in the External Profile will be routed to the IPPBX ( in the Private network via the Internal Profile (Internal_SIP_Interface)

Now, we need to configure the Internal Profile, which will deliver calls to the PBX coming from Extensions at customer's premises, and receive calls from the IPPBX going out to those extensions.

Now profiles with non default values:

Now, let look at the Header Manipulation rules:

In thie manipulation, as an FQDN is used as the domin, and call will be routed to the external network to the customer on premise SMB-SBC, we need to asure the domain is properly passed. So, we will capture the domain name in a variable to be used on the Routing plan.

We will use in this case Basic technique:

We will capture in kdomain the value "" if the call is coming from the host at (IPPBX)

Now let's see the Routing Plan "Outbound_All_Extensions":



In terms of coec we are only using PCMA and PCMU at this point. So Default media profile is as follows:

At this point we have finished configuring the Access SBC at the Data Center or Enterprise central Site. Let's now do the configuration for the local SBC at customer premises.

The setup for the Branch office will like like this:


As we can see we will be using a local domain in addition to the domain form upper registration to the data center.

A total of 3 Sip Profiles will be needed:

A Local Domain with local authentication is needed:

We will also create the USer Credential Information. In this case, just for two extensions (505 and 506)

Now we will show configuration for each sip profile:

Internal_Phones Profile:



Header Manipulation:

Routing Rules:

<extension name="From_local_to_PBX">
  <condition field="caller_id_number" expression="^5..">
  <condition field="destination_number" expression="^(.*)@.*">
    <action application="export" data="dialed_extension=$1"/>
    <action application="export" data="sip_secure_media=true"/>
    <action application="export" data="domain_name=${kdomain}"/>
    <action application="bridge" data="{sip_invite_domain=${domain_name}}sofia/External_to_Carrier/${dialed_extension}@${domain_name}:15061;transport=tls"/>

Will look like this:



Now, let's present what to do with the external profile:



 Here we are showing the Inbound dial plan associated to this external profile:


 At this point Any Endpoint at the Branch Office should be able to register in the central IPPBX and also be able to make calls between extensions.

Any VoIP Trafic in the Internet will be tatlly secure with TLS/SRTP

TLS and SRTP functionalities are jept at the SBC's levels and no need for any considertion at the IPPBX level or endpoint is needed.

Now, we will add one more level of complexity by implementing dual registration at the endpoints in the Branch Office

On this excercise we will use SNOM 870 SIP Phones, but it can be implemented in any phone supporting Dual Registration (Polycom, Yealink, AASTRA and Grandstream has been tested. Call for details if needed)

So, we will use the secondary domain ( for the prupose of secondary registrar for the End Points.

The way SNOM implements Dual Registration, is by using what they call "Failover identity". So, for example for extension 505 we will create an identity to upper register on the PBX via the local SBC as follows:



The Failover Identity will look like this:



This new profile will have the following configuration:


Routing rules associated to this profile is the ona named Local_Calls, which will look like this:


At this point, you can test by blocking connectivity to the central site and you will notice on the phone that Identity 1 (Extensions 505 and 506) become red to make clear registration have failed. Even so, you can still test calls between the two extensions as the SNOM will start using automatically Identity 2 for the failed Identities.


Now are are going to enable users to directly register on the PBX via the access SBC on the central site. This is a typical situation for employees traveling with Softphones on their Laptops or SmartPhones, or even very small braches or home offices, with a few extensions.

So, what we will need, as we don't have in this situation an SMB-SMB on premise, is to configure the endpoint to support TLS/SRTP and we will point them directly to the corporate/Central  SBC for upper registration and SIP requests.

No need to make any changes at any of the SBC's as we are going to take advantage of the same domain "" and the External SIP Profile we created for Branch offices. Conceptually this is because from the perspective of the Access SBC there is no difference between and end point coming from a branch (As the local SBC takes the personality of all endpoint behind him), and an isolated end point in the public internet. In both cases the Access SBC will only accept TLS/SRTP traffic.

So, let's show how an extension confiuration on the pubic internet will look like, using a SNOM 870, extension 506:





At this point you can test between Branch Office extensions and Extension on the Internet.

We have acomplished the goals for the use case.

Any question, suggestions or comments feel free to email me: