The purpose of this cookbook is describe how to configure a Sangoma Session Border Controller to work with SipXcom and Microsoft Skype for Business using the following network topology:
The dialplan is as follows:
This topology was chosen to demonstrate basic capabilities of the Sangoma SBC and interopability with SipXcom - it does not necessarily represent best practices for deployment in production networks. For example, remote Polycom phones may be easier to deploy over VPN tunnels to a central SipXcom server because of provisioning and security issues. With the increased use of mobile clients in voice and video communications for enterprises, there is emphasis in this document on how to make these pieces work together using the Sangoma SBC, SipXcom voice server, and remote phones and soft clients.
SipXcom features that were tested with the SBC includes the following:
Bridged Line Appearance extensions and intercom between local and remote phones was tested but did not work - these issues are being worked with Sangoma.
The integration of an SBC with SipXcom, ITSP, phones (both local and remote), and firewalls is dependent on a number of assumptions, including which signaling transport is used, features, etc. The intent of this cookbook is allow a knowledge SipXcom individual familiar with firewalls and phones to bring up a working Sangoma Session Border Controller - it does not cover all call flows, features, or capabilities available on the SBC or SipXcom. Interoperability testing is strongly recommended after significant changes to any network component (e.g. software hardware), new features, or protocol changes (e.g. TCP versus UDP) is implemented.
The Sangoma SBC uses Freeswitch internally, and has built a set of menus to facilitate configuration of the system - be prepared to learn some Freeswitch basics as you work with this SBC. Sangoma has good online documentation and technical support for the SBC - the online documentation is found here http://sbc.docs.sangoma.com/?v=2.2&l=en. The following diagram illustrates the SIP profiles, trunks, and call routing plans defined in the SBC for the network topology:
The following table summarizes provides a general description of each of the profiles and mapping to trunks and routing plans.
Trunk IP Address
SIP IP Address
Description and Requirements
|SBCtoITSPExternal||SBCtoITSPLocalExternal||pbx6.acepbx.com||IncomingITSPtoSBC||eth0 - 10.10.12.25||5062||UDP||SIP Trunk to ITSP - when trunk registers, source port for responses is 5062. Trunk registration expiry is 60 seconds - keeps office firewall state active. Incoming SIP traffic from the ITSP is processed by this routing plan.|
|SBCtoPBXInternal||SBCtoPBXLocalInternal||10.10.12.30||IncomingPBXtoSBC||eth0 - 10.10.12.25||5063||UDP||SIP Trunk to SipXcom - disable registration on SBC trunk. Incoming SIP traffic from SipXcom is processed by this routing plan|
|RemotePhonetoSBC||RemoteRouter||126.96.36.199||IncomingRemotePhonetoSBC||eth0 - 10.10.12.25||5170||UDP||Incoming SIP traffic from the remote phone to this SBC is processed by this routing plan. Enable Options Ping frequency on SIP trunk to 60 seconds to keep firewall state at remote router active.|
|RemotePhoneInternal||SBCtoPBX||10.10.12.30||OutgoingPBXtoRemotePhone||eth0 - 10.10.12.25||5064||UDP||Incoming SIP traffic from SipXcom to the remote phone is processed by this routing plan. Trunk definition required for upper registration.|
|SkypeForBusiness||SkypeTrunk||10.10.12.12||IncomingSkypetoSBC||eth0 - 10.10.12.25||5055||TCP||Incoming SIP traffic from Skype to SipXcom is processed by this routing plan. Skype for Business only supports TCP transport on its trunk gateways.|
It should be noted that TCP transport end-end was attempted for all the profiles but there were issues with some of the call flows - these issues are being investigated.
The key configuration changes to support the SBC are in the following areas:
Create an unmanaged gateway to the SBC at 10.10.12.25 using UDP transport and port 5063.
Assign the SBC unmanaged gateway to the long distance dial plan for PSTN calling and the 4-digit custom dialplan for calls to Skype for Business.
Be aware of 7-digit custom dial plans used for PSTN connectivity when working with the Sangoma SBC. The SipXcom custom dialplan will add the 1+area code prefix to the dialed number and insert into the SIP Request-Line header but leaves the TO: header with the original dialed 7-digits. The Sangoma / Freeswitch standard mechanisms for retrieving called numbers (e.g. $1) uses the 7-digit number when placing calls using a custom bridge macro required for REFER processing. This issue is being worked with Sangoma.
There is a variation of this issue that prevents SipXcom from routing an external incoming call to a remote phone when the SBC upper registration feature is used. The request line has a SIP URI with the remote phone's user extension but the TO: SIP header specifies the DID of the called number. The SBC rejects the call (480 unavailable) as it uses the DID in the TO header of the SIP Invite from SipXcom rather the request URI when placing the call to the remote phone. The workaround is to build an SBC call routing rule for the incoming external call (see IncomingITSPtoSBC call routing plan rule 15) that routes the call directly to the remote phone.
In the System -> Nat Traversal Settings menus, disable the Enable NAT Traversal and Server Behind NAT options. Also change Address Type to Specify IP address provision the Public IP address with the IP address of the SipXcom voice server.
Double-check the SipXcom host name and ascertain that the SIP realm (e.g. testsbcsipxcom.dyndns.org) will correspond to the FQDN that will be published in DNS. The primary registration server for lines defined on the phones, including remote phones, uses that SIP realm when SipXcom builds its phone profiles.
The Lync Topology Builder was used to create a new PSTN Trunk and Gateway using TCP transport, port 5055, and pointing to the SBC at 10.10.12.25 - the new topology was then published. In the Lync 2013 voice routing section, 3-digit extension calls were routed to the SBC, while 4 digit incoming calls from the SBC were normalized into E.164 internal numbers and forwarded to the appropriate Skype for business phone.
The DYNDNS service was used to define a new public DNS hostname called testsbcsipxcom.dyndns.org. The public address assigned to the DNS hostname was 188.8.131.52, which is the static public IP address defined on the WAN interface for the office Pfsense firewall.
The Sangoma SBC used for this interoperability testing is running as a virtual machine (Vmware) with software transcoding only - there is no D1xx media processing card attached to the system. The steps to configure the SBC are as follows:
The Sangoma SBC installation uses a procedure similar to Sipxcom to assign an initial IP address to the eth0 interface. The SBC IP address is 10.10.12.25 with a /24 subnet mask, IPV4 defauly gateway address of 10.10.12.1, and DNS address of 184.108.40.206. As a sidenote, the SBC allows multiple IP addresses to be assigned to an interface (e.g. eth0). This allows the same port number (e.g. 5060) to used for certain call flows - for example one SIP profile would use port 5060 and the IP address of 10.10.12.25, and a second SIP profile would use port 5060 and IP address 10.10.12.26.
Double-check the list of IP Subnetworks where intrusion detection will not be performed by the SBC.
Specify the first and last UDP ports for RTP traffic on the SBC. This range will be required in Step 6 to open up ports in Pfsense to allow media to be passed through the firewall for remote phones.
Define an ITSP media profile with G.711 codecs for voice - leave more complex transcoding for after the initial SBC has been configured and tested. The H.264 codec was enabled to allow testing of video from Counterpath Bria clients installed on Android and Windows platforms.
The SBC SIP Profiles define the attributes (e.g. interface, port number, media bypass) of the SIP User Agent - for this network topology, there are three different flavors of SIP profiles that are used:
The above diagram shows most attributes that can be configured in a SIP profile - key points that deviate from the default SIP Profile settings include the following (each point references a yellow bubble in the diagram):
The SBC SIP trunk defines the other end of the User Agent that the SBC is communicating with and which SIP Profile it is associated with.
The above diagram represents the SIP trunk definition from the SBC to the ITSP - key points that deviate from the default SIP Trunk settings include the following (each point references a yellow bubble in the diagram):
The following diagram shows firewall state information from the Pfsense firewall in front of the remote phone - this state is created whenever the remote phone talks to the SBC. Similar state information is maintained on the office Pfsense firewall for communication to the ITSP and remote phones. Without the OPTIONS Ping frequency and Register Expire Seconds attributes set correctly, the state information would expire and incoming calls to remote phones or from the ITSP to the SBC would be blocked by the firewall.
SipXcom features such as DISA and implementation of Polycom one-touch EFK macros using $REFER capabilities generate SIP REFERs when processing ITSP incoming calls. The REFER capability needs to built into the SBC call routing plans for calls arriving from the ITSP and SipXcom and it's the most complex part. There is a good Sangoma document on REFER handling and construction of a call routing plan in general - it is found here http://wiki.sangoma.com/NSC-SIP-Refer-Handling. A useful tool for parsing regex expressions is found here https://regex101.com/.
The IncomingITSPtoSBC call routing plan is shown in the following diagram and gets invoked in the following call scenarios:
The IncomingITSPtoSBC call routing plan logic is as follows:
The IncomingPBXtoSBC call routing plan is shown in the following diagram has similar logic to the previous plan buts assumes the incoming call came from the PBX and the REFER was generated by the ITSP side of the call.
The IncomingPBXtoSBC call routing plan logic is as follows:
The IncomingSkypetoBusiness call routing plan is simpler than the previous call routing plans as there is no testing of REFER support todate. There are three rules in in the call routing plan:
SIP Refers was not tested with Skype to Business.
The IncomingRemotePhonetoSBC call routing plan looks similar to the the Skype for Business call routing plan:
SIP Refer has not been tested to-date with remote phones issuing the REFER to SipXcom via a Polycom EFK macro.
The OutgoingPBXtoRemotePhone call routing plan is the simplest and simply routes all digits to the remote phone extension. A REFER issued from a local phone to the remote phone using a Polycom EFK macro was tested and worked.
Once all the call routing plans are built, they need to be mapped to their corresponding SIP profiles (point 7 in the Build the SIP Profiles section).
When the remote phone dials an external number, the call comes into SipXcom from the SBC and then hairpins out the unmanaged gateway back into the SBC - in this situation, SipXcom ignores the callerid overrides at the user or gateway level and preserves original caller's number, which is the user extension of the remote phone. To apply a valid 10-digit callerid, a header manipulation rule called RemotePhoneCallerid is created which checks for a 3-digit extension - if true, the the remote Display and URI fields are replaced with company name and telephone number before the call is sent to the ITSP by SipXcom.
Apply this header manipulation rule to the ingress side of the SBCtoPBXInternal SIP Profile.
When using upper registration for remote phones, a domain name is created and that domain is then bound to a SIP Profile. When the SIP Profile sees a Register message, it uses the SIP trunk and SIP profile defined in the domain to forward the register message to the PBX.
The steps to enable upper registration are as follows (see above diagram):
The following diagram details the minimum number of NAT forwarding and firewall rules necessary to get remote phones working on the Office Pfsense firewall:
Opening up other ports is dependent on the strategy for provisioning Polycom phones - if the approach is to use SipXcom automatically for provisioning remote Polycom phones like local phones, then use this reference http://community.polycom.com/t5/VoIP/FAQ-What-Ports-Protocols-are-being-used-need-to-be-open-in-a/td-p/49047 to open additional ports on the firewall. In the port forwarding table, provision 10.10.12.30 as the NAT IP address - upon restart, the remote phones will pull their provisioning files from SipXcom.
There are multiple ways to configure remote Polycom phones - for this cookbook, remote Polycom phones were first provisioned locally, and then the phone GUI was used to change specific fields that registers the phone to SipXcom. The Bria Windows and Android soft clients were manually provisioned.
The following table describes how to covert a working local Polycom phone to a remote Polycom Phone, using both the Polycom GUI and SipXcom phone provisioning template - this prepares the remote phone to register to SipXcom via the SBC upper registration capability.
|Server Address||Settings->Syslog||Devices->Phone->Logging (Advanced)||220.127.116.11||Point syslog server to public IP address of Office Pfsense firewall|
|IP Address||Settings->Network->NAT||Devices->Phone->NAT||18.104.22.168||Have SBC send RTP traffic to the IP address of the remote Pfsense firewall. Firewall state will forward traffic to remote phone|
|DNS Address||Settings->Network->Ethernet||-||22.214.171.124||Point Phone DNS to public DNS server (e.g. Google) - When phone queries DNS for testsbcsipxcom.dyndns.org address when registering line or sending Invites, the Office Pfsense 126.96.36.199 WAN address will be returned|
|Address||Settings->SIP->Outbound Proxy||Devices->Phones->SIP Servers||188.8.131.52||Point proxy address to the WAN interface of the Office Pfsense firewall|
|Port||Settings->SIP->Outbound Proxy||Devices->Phones->SIP Servers||5170||Point proxy port to the SBC port used by the RemotePhonetoSBC SIP Profile|
|Transport||Settings->SIP->Outbound Proxy||Devices->Phones->SIP Servers||UDP||Change SIP Proxy transport to use UDP|
|Transport||Settings->Lines->Line 1||Devices->Phones->Lines->204->Outbound Proxy Transport||UDP|
Change Line 1 x204 Transport to use UDP
The following diagram illustrates how to provision a Counterpath Bria Windows client to register to SipXcom using the SBC upper registration capability using public internet access - key points:
The following diagram illustrates how to provision a Counterpath Bria Android client to register to SipXcom using the SBC upper registration capability using public internet access or mobile LTE - fields to provision are highlighted in red.
When SipXcom and the Sangoma SBC has been configured, a good first place to check is the SBC trunk status menu shown in the following diagram.
When the SIP trunks were defined in the SBC, a registered SIP trunk to the ITSP was defined. The SBCtoITSPLocalExternal trunk shows registered so incoming/outgoing calls to the ITSP can now be processed. The other trunk to check is the RemoteRouter trunk - it pings the remote Pfsense firewall every 30 seconds using a SIP OPTIONS packet to keep the firewall state active for the remote Polycom phone. When the RemoteRouter status is UP, the remote Pfsense firewall is responding to SIP OPTIONS packets; when the state is DOWN, the SBC is not receiving responses to the SIP OPTIONS packets, and incoming calls to the remote phone from SipXcom will not be blocked.
3 test calls were placed to test the SBC routing plans as well as upper registration:
The active call report on SipXcom looks as follows - note that because an unmanaged gateway is used to communicate with the SBC, no active calls are shown in the SIP Trunks SBC Statistics menu.
When the first call is placed from 914-417-2270 to 914-417-2295 on SipXcom which is mapped to a user on the remote phone, the following call flow should appear on the SBC:
When a local phone on SipXcom (callerid on unmanaged gateway is 914-417-2295) places an external call to 914-417-2xxx, the following call flow should appear on the SBC:
When x206 on SipXcom places a call to x2280, the follow call flow should appear on the SBC:
Attached is the SBC SIP Sessions Status report for the 3 active calls described above.
The following diagram shows the SBC session status for an outgoing external call from 914-417-2295 on the remote phone to 914-417-xxxx - there are four call legs:
The SIP Profiles status displays the Profiles on the SBC that have been defined - the top of the following diagram shows the output from the SIP Profiles status. The RemotePhonetoSBC SIP Profile is where the remote users accessing SipXcom using upper registration arrive at the SBC. When the RemotePhonetoSBC SIP profile is displayed, there are three sections displayed (bottom left of diagram):
On the side of the diagram is the active users registration page for the SipXcom server used in this network topology. Note that users 203 and 204 are registered via the SBC (IP address 10.10.12.25) from port 5064 - SIP messages from SipXcom or local phones to these users are sent to the SBC using port 5064, which maps to the RemotePhoneInternal profile.
Mobile appliances (e.g. smart phones, tablets) with SIP softclients are certainly a good application for leveraging SBC upper registration wanting to access their SipXcom voice server remotely. The popularity of these applances with cameras that can stream video, combined with pervasive availability of public WIFI and LTE data access enables the capability for delivering point-point video at a cost-competitive price point. Many businesses have technicians, engineers, installers, and sales people (e.g. real estate) in the field who run into onsite issues that require specialized expertise to assess and resolve. Today, these issues are communicated to an expert back in the office on a voice call where the situation is described - sometimes, pictures are taken from a mobile appliance and emailed back to office expert. A real-time point-point video conversation would improve productivity in many situations if delivered with reliable quality. The service offering works as follows:
The network topology was used to test this point-point video application using private WIFI, public WIFI (cable), and LTE access from an Android client running Counterpath Bria to a Windows lab laptop running Bria. The video quality with private and public WIFI was excellent in almost all testing - LTE access (WIFI was turned off on the Android smartphone) delivered good quality video 80 percent of the time.