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.
Go to System -> Branches and create Branches for each office location.
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.
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 http://www.sipfoundry.org/forum/-/message_boards/message/657814. 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.
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):
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.
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:
Normal incoming and outgoing calls should be thoroughly tested using the Branches feature before implementation in a production network.
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 pbx1.itsp.com and pbx2.itsp.com. Let's assume that the ITSP has 10 unique gateways into their network - pbx1.itsp.com through pbx10.itsp.com. 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. pbx1.itsp.com) 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. 22.214.171.124). 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 http://wiki.sipfoundry.org/display/sipXcom/Receipe%3A+Local+Call+Forward+With+sipXcom+and+Polycom+Phones. 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:
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.
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.
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 http://wiki.sipxcom.org/display/sipXcom/e911+Dialing.