sipXcom
Child pages
  • Branches - Configuring sipXcom for Small and Medium Business
Skip to end of metadata
Go to start of metadata

Branches - Configuring sipXcom for Small and Medium Business

Introduction

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:

  • Because the main line for each location is answered by an IVR, this makes callbacks from the 911 Public Safety Access Pint (PSAP) using the BTN number problematic in an emergency situation. A second DID is ordered with each SIP trunk for E911 calls and callbacks. All phones in the office will ring for 60 seconds when sipXcom receives a 911 callback from the PSAP. 
  • The office locations are serviced by separate 911 PSAPs, so care must be taken not to route an emergency call to the incorrect PSAP.
  • For normal outgoing PSTN calls, the primary SIP trunk of the other office should be used to place the call in the event that the local office primary SIP trunk is unavailable. 

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 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.

(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 pbx1.itsp.com, and the Branch B address is pbx2.itsp.com. 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 (pbx1.itsp.com and pbx2.itsp.com). 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:

  • Add each primary SIP trunk gateway to the long-distance rule.
  • Ascertain that the shared gateway icon appears in front of each primary SIP trunk. If this does not appear, then the SIP trunk gateway is not shared. Go back to the Devices -> Gateway summary menu, click on the primary SIP trunk gateway that is not shared, enable sharing, and then apply. Go back to the long-distance rule and validate that each primary SIP trunk gateway has the shared icon.

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 ITSP takes one or DIDs  assigned to a SIP trunk for emergency calling, maps a name and address of where that phone or phone system is located, and provisions this information in the Automated Line Identification (ALI) database which is accessible by all Public Safety Access Points (PSAPs) answering emergency 911 calls.
  • When a 911 call is placed, the emergency response system in the PSAP takes the Caller-id associated with the 911 call and places a query into the ALI database. The ALI database  returns the name and address of where the IP Phone or system is located that placed the 911 call - this name and address is displayed on the PSAP dispatcher's computer screen. If the caller hangs up suddenly before all details of the emergency is captured, the PSAP dispatcher will  (Callback) the phone or phone system that placed the 911 call in an attempt to obtain more details about the emergency. The PSAP dispatcher may also send a patrol vehicle to the location if no one answers the emergency Callback call.
  • In the United States there are over 6000 PSAPs. It is the responsibility of the ITSP to assign a E911 DID to the SIP trunk that can be routed by the PSTN to the correct PSAP.
  • It is the responsibility of the engineer configuring sipXcom to correctly determine the location of the IP Phone and assign the correct Callerid to the outgoing emergency call so that the PSAP dispatcher sees the correct name and address displayed on their  screens.
  • It is the responsibility of the engineer configuring sipXcom to route the outgoing 911 call down the correct SIP trunk to the public PSTN.
  • It is the responsibility of the engineer configuring sipXcom to provide the ITSP with the correct name and address of each DID used for outgoing emergency calls. 
  • It is the responsibility of the ITSP to correctly provision the ALI database with the DID number used for emergency calls and the corresponding name and address information.
  • It is the responsibility of the engineering configuring sipXcom to place test 911 calls, validate that the call is reaching the correct PSAP, and that the ALI database has been correctly provisioned.

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:

  • Order 2 separate SIP trunks - one for CityABranch and the other for CityBBranch. Request that the CityABranch trunk be terminated on pbx3.itsp.com and CityBBranch trunk be terminated on pbx4.itsp.com. Have the ITSP assign the respective E911 DID to each trunk
  • Assign the E911 DID for each office to the Callerid field of the SIP trunk
  • Assign the two 911 phantom SIP trunks to their respective branches and disable sharing to prevent a 911 call from being routed to the wrong PSAP
  • Ascertain both 911 phantom SIP  trunks are defined in the emergency calling Dialplan

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. 66.11.22.33). 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:

  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 (66.11.22.33 and 66.11.22.44) 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:

  • Incoming calls to the correct Autoattendant or direct line for each branch
  • Outgoing calls from each branch - ascertain Callerid for the primary SIP trunk for each branch is properly used
  • Disable a primary SIP trunk for one branch - ascertain an outgoing call is placed through the alternate primary SIP trunk. Repeat this test for the second branch.
  • Place outgoing 911 call - ascertain call is routed to the correct PSAP. A custom Dialplan and pseudo emergency number (e.g. 999) that rings a cell phone can be used to validate the E911 callerid and routing so that the PSAP is not called until all configuration issues are resolved.
  • Disable a phantom SIP trunk for one branch and place an emergency call from a phone in that branch - the caller should receive a fast-busy signal. Do the same for the other branch to ascertain that phantom SIP trunk gateways are not shared.
  • Simulate a 911 callback by dialing the E911 DID - all phones in the branch should ring for 60 seconds, and then forward to the fallback destination.
  • Restart Sipxbridge and ascertain  primary SIP trunks re-register to the ITSP.
  • Finally, place 911 calls from each branch to the PSAP, and validate that the name and address for the branch location is accurately configured.

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.

 

 

  • No labels