Branches - Configuring sipXcom for Small and Medium Business


The Branches feature in sipXcom allows users to map to gateways and servers. A branch is normally associated with a physical location. For small and medium business (SMB) configurations, there is almost always one sipXcom server - therefore mapping of users to servers is not needed. The purpose of this page is to illustrate usage of the Branches feature using a simple, lab-tested, reference network topology found in SMB business configurations with multiple locations.

 A business has two small offices in nearby cities with 2 phones in each office. Because the offices are small, the phones will be serviced off a centralized sipXcom server. Each office is assigned one DID (or billing telephone number (BTN) that is answered by an AutoAttendant that instructs the user to press 1 for phone 1 and 2 for phone 2. The CFO wants each branch to pick up its own PSTN costs, so separate SIP trunks are ordered for each office.

The following diagram represents the reference network topology for this business that will used to illustrate the sipXcom Branches feature for normal calls and emergency calling - some observations on the requirements:

The remainder of this page will describe the steps needed to provision the reference network topology in sipXcom using the Branches feature, Phantom SIP trunks, and dialplan functionality. The creation of the Autoattendant will not be covered,  nor will core networking requirements such as DHCP to branch offices, broadband access, branch NAT router, VPN definitions, traffic shaping, etc.                                                                                              

Step 1 - Define Branches in sipXcom

Go to System -> Branches and create Branches for each office location.

Step 2 - Define Users and Assign to Branches

Define user extensions for the reference network topology and assign to branches using the Users -> 2xx -> Identification > Branches pull-down menu. Go to System -> Branches summary to sanity-check that user extensions are assigned to the right branches through the Users column.

Step 3 - Define Primary SIP Trunk Gateways

Before describing the steps to define the SIP trunk gateways for Branch A and B in the reference network topology, it is important to understand a design assumption with the current internal Sipxbridge Session Border Controller (SBC) - Sipxbridge has been built  assuming that each  Internet Telephony Service Provider (ITSP) SIP trunk  maps to one unique PSTN IP gateway address - this thread provides insights on the history All ITSPs support multiple peering points into their networks - when ordering the primary SIP trunks from the same ITSP, ascertain that the SIP registration information for each trunk has a unique ITSP gateway IP address.

(warning) Caution - sipXcom will allow configuration of multiple SIP trunks to the same ITSP peering point and the trunks will register, but unpredictable behavior will be observed on certain call flows as well as SIP trunk in-stability after restarts. This configuration only works reliably when the primary SIP trunks are terminated on unique ITSP gateway peering points (i.e the IP address or FQDN for each SIP trunk gateway is unique).

The above diagram illustrates the steps (1-10) to configure the primary SIP trunk for Branch A  - the same steps are followed for Branch B  (each point below maps to a yellow bubble in the above diagram):

  1. Assign a unique name to the SIP trunk and ascertain the trunk is enabled.
  2. Ascertain the built-in SBC option is checked (this is the default)
  3. Configure the ITSP gateway address - in the reference network topology the Branch A address is, and the Branch B address is Per the caution at beginning of this Step 3 section - if these addresses are the same, go back to your ITSP and have them terminate one of the SIP trunks on a different ITSP gateway peering point.
  4. Most ITSPs use port 5060 for SIP signaling to their peering - provision for both Branch A and B primary SIP trunks
  5. Most ITSPs use  UDP Transport for SIP signaling to their peering - provision for both Branch A and B primary SIP trunks
  6. Assign the location of the City A primary SIP trunk to CityABranch (created in the previous step). This instructs the phones in City A branch to first use the City A primary SIP trunk when placing outgoing calls. Assign the location of the City B primary SIP trunk to CityBBranch.
  7. Ascertain the shared box is selected (default) for both City A and B primary SIP trunks - with a shared gateway, an outgoing call from City A can use the City B primary SIP trunk if the City A primary SIP trunk is unavailable.
  8. When hitting Apply, the primary SIP trunk gateway is created and three configuration menus appear.
  9. Select the Caller Id menu, and provision the appropriate BTN number for each primary SIP trunk. Use 444-555-2292 for the City A primary SIP trunk, and 444-777-5957 for the City B primary SIP trunk.
  10. Go to the ITSP Account menu and configure the appropriate account information provided by the ITSP for City A and B primary SIP trunks. Ascertain the Register on Initialization option is selected so that the City A and B primary SIP trunks automatically register to the ITSP whenever Sipxbridge restarts or sipXcom is rebooted. 
  11. Go to the Diagnostics -> SBC Trunk Statistics menu to ascertain that both SIP trunks register to the ITSP. Double-check that the ITSP identifier information specifies a unique ITSP gateway address ( and If those ITSP gateway IP addresses are identical, then re-read the cautionary note at the beginning of step 3.

As a final sanity check, go to the System -> Branches summary display - based on the reference network topology ascertain that there is 1 SIP trunk gateway assigned to each branch in the gateway column.

Step 4 - Configure Dialplans for City A and B Primary SIP Trunks

The following above diagram illustrates how the primary SIP trunks for City A and B are applied to the long-distance dialplan rule:

Repeat these steps for local (if enabled), toll-free, international, and custom  dialplans. If local 7-digit dialing is required and the NPA and/or NXXs are different, then create appropriate custom dialplan rules with prefixes to identify the appropriate NXXs for each branch location, and the 1+NPA prefix that is applied to the 7-digit number dialed by the user. Using the reference network topology, a local-555 custom rule was created that is applied against any outgoing 7-digit call that begins with 555. The rule then translates the 555-xxxx number to 1444555xxxx and sends to the right SIP trunk gateway based on whether the call was made from a CityABranch or CityBBranch office.

For normal outgoing PSTN calls,The Branches feature routes the call in the following manner:

  1. If the call is placed from a user that is a member of the CityABranch, the call is sent to the PSTN using the CityA_Trunk. If CityA_Trunk is not available, then CityB_Trunk is used.
  2. If the call is placed from a user that is a member of the CityBBranch, the call is sent to the PSTN using the CityB_Trunk. If CityB_Trunk is not available, then CityA_Trunk is used.
  3. If neither City A or B SIP primary trunks are available (e.g. disabled) or call permissions are not correctly applied to the dialplan, the user receives a fast busy.

(warning) Normal incoming and outgoing calls should be thoroughly tested using the Branches feature before implementation in a production network.

Step 5 - Configuring Phantom SIP Trunks for Emergency Calling

A very brief high-level overview of how enhanced 911 works as follows for IP Phones in the United States and Canada:

The community edition of sipXcom has no functionality today that maps an individual user extension to an emergency Callerid used for outgoing 911 calls. However, the combination of the sipXcom Branches feature and Phantom SIP trunks allows the engineer to determine the location of the phone placing the emergency call, assign the correct Callerid, and route the call down the proper trunk to the PSAP. For small and medium business deployments such as the reference network topology, this is manageable.

A phantom SIP trunk is simply a SIP trunk to the ITSP with a separate Callerid that can be used for applications such as outgoing Emergency calls and Callbacks. From step 3 there is a design assumption in the current version of Sipxbridge that one ITSP account can map to one ITSP peering point address. In the reference network topology, there are two branch offices with primary SIP trunks to and Let's assume that the ITSP has 10 unique gateways into their network - through Let's also assume that this ITSP has a billing and routing restriction that prevents a SIP trunk from being terminated on multiple gateways in their network. Given these two assumptions,  one approach to implement 911 calls and callbacks for the reference network topology is as follows:

With this approach, the 911 calls and callbacks are placed on the dedicated SIP trunk that is terminated on a unique ITSP gateway and supports the Sipxbridge current design. Using the reference network topology, the sipXcom implementation with this ITSP can grow to 5 branch locations before all 10 ITSP gateways are exhausted (one primary SIP trunk plus 1 phantom SIP trunk for 911 calling per branch location). 

There is a workaround that has been successfully tested that allows the creation of a phantom SIP trunk using the authentication credentials for the primary SIP trunk. The workaround uses the FQDN (e.g. as the ITSP peering point address for the primary SIP trunk and the public IP address for the phantom SIP trunk for the ITSP peering point (e.g. The uniqueness of the ITSP gateway address gets around how Sipxbridge defines and summarizes  itsp-account  information - further details are discussed in the last section of this wiki page This approach is more cost-effective and doubles the number of branch offices that can be supported from the same ITSP using the reference network topology - this approach will be used for phantom SIP trunk setup using the reference network topology.

Defining the phantom SIP trunks for 911 is similar to Step 3 except for the following:

  1. The name of the SIP trunk gateway is CityA_911Trunk or CityB_911Trunk
  2. Instead of specifying the FQDN for the ITSP gateway address, the public IP addresses ( and should be used for City A/B 911 Phantom SIP trunk Gateways
  3. Make sure these phantom SIP trunk gateways are not shared - the 911 call will be routed to the wrong PSAP if one of the phantom SIP trunk gateways is disabled
  4. Use 444-555-7702 as the Callerid for outgoing 911 calls from the City A office, and 444-777-6519 as the Callerid for outgoing 911 calls from the City B office
  5. Use the same account information for the primary SIP trunk when configuring the phantom SIP trunk. Uncheck the register on initialization option for the phantom SIP trunks for emergency calling - otherwise the ITSP gateway will get confused on which SIP trunk to use for incoming calls. Because the phantom SIP trunks are not registered on initialization, these trunks do not appear on the Diagnostics -> SBC Trunk Statistics output. When an emergency call is placed, the authentication credentials are passed to the ITSP via the SIP Invite for the call.
  6. Go the Devices -> Gateways summary and ascertain  that the CityA_911Trunk and CityB_911Trunk  trunks are not shared. 

Step 6 - Configure the Emergency DialPlan

Add the two phantom SIP trunks for City A and B locations to the System -> Dialplan -> Emergency  menu and enable the dialplan. Provided that the users and phantom SIP trunk gateways are properly assigned to their locations, the sipXcom Branches feature will route emergency calls from users 200 and 201(City A Branch in the reference network topology) out the CityA_911Trunk phantom SIP trunk using the Callerid of 444-555-7702 to the PSAP in City A. Similarly, emergency calls from users 250 and 251 (City B Branch) will be routed through the ITSP to the PSAP in City B using the CityB_911Trunk phantom SIP trunk with the Callerid of 444-777-6519.

Step 7 - Configure Hunt Groups for Emergency Callbacks

In the reference network topology, a requirement was that incoming calls to the branch are answered by an AutoAttendant - this is not advisable for Callback calls from the PSAP (a live person should answer the 911 Callback call whenever possible). In a small and medium business environment, one suggested best practice for emergency Callback calls is to ring all phones in the Branch for 60 seconds - if no one answers the call, then ring a manned telephone number such as the receptionist or Security Desk.

The following diagram illustrates the two hunt groups for 911 Callbacks using the reference network topology. It should be noted that outgoing emergency calls are sent to the ITSP using the phantom SIP trunks; however incoming 911 Callbacks arrive via the primary SIP trunks as the DIDs are attached to the primary SIP trunks.

Summary Observations

When using the Branches feature in sipXcom, the importance of planning your network and testing the configuration - both for normal and emergency calls, cannot be understated. Suggested call flows using the reference network topology to test include:

Registered SIP trunks to the ITSP was used in the reference network topology. There may be some differences in behavior when nailed-up SIP trunk connections to the ITSP are used - nailed-up SIP trunk connections was not tested in the reference network topology.

The E911 work in this page covers only one suggested implementation using the reference network topology - there are several other approaches when implementing E911. Further discussion E911implementation using sipXcom is found here