Introduction

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.

Step 1 - Plan Your SBC Configuration

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.

SIP Profile
SIP Trunk
Trunk IP Address
Routing Plan
SIP IP Address
Port
Transport
Description and Requirements
SBCtoITSPExternalSBCtoITSPLocalExternalpbx6.acepbx.comIncomingITSPtoSBCeth0 - 10.10.12.255062UDPSIP 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.
SBCtoPBXInternalSBCtoPBXLocalInternal10.10.12.30IncomingPBXtoSBCeth0 - 10.10.12.255063UDPSIP Trunk to SipXcom - disable registration on SBC trunk. Incoming SIP traffic from SipXcom is processed by this routing plan
RemotePhonetoSBCRemoteRouter47.47.47.44IncomingRemotePhonetoSBCeth0 - 10.10.12.255170UDPIncoming 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.
RemotePhoneInternalSBCtoPBX10.10.12.30OutgoingPBXtoRemotePhoneeth0 - 10.10.12.255064UDPIncoming SIP traffic from SipXcom to the remote phone is processed by this routing plan. Trunk definition required for upper registration.
SkypeForBusinessSkypeTrunk10.10.12.12IncomingSkypetoSBCeth0 - 10.10.12.255055TCPIncoming 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.

Step 2 - SipXcom Configuration

The key configuration changes to support the SBC are in the following areas:

Creation of Unmanaged Gateway

Create an unmanaged gateway to the SBC at 10.10.12.25 using UDP transport and port 5063.

Assign the SBC Unmanaged Gateway to Dial Plans

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.

NAT Traversal Settings

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.

SIP Realm for Remote Phones

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.

Step 3 - Skype for Business (Lync 2013) Server Configuration

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. 

Step 4 - Public DNS Hostname

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 108.100.200.222, which is the static public IP address defined on the WAN interface for the office Pfsense firewall.

Step 5 - Configure Sangoma SBC

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:

Validate Network Configuration Information from the SBC Installation

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

Validate List of IP Subnetworks Where Intrusion Detection Will not be Performed

Double-check the list of IP Subnetworks where intrusion detection will not be performed by the SBC.

Configure Port Information for the Media Interface on 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.

Configure G.711 Media Profile for ITSP Voice Communication and H.264 for Video from Softclients

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.

Build the SIP Profiles

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

  1. When first defining a SIP profile, the SBC allows provisioning of the SIP IP address, Port, and Transport fields. Once the SIP profile has been created, the fields can only be changed when the SBC is stopped.
  2. For the SIP profiles facing the office Pfsense (SBCtoITSPExternal and RemotePhonetoSBC), provision the external SIP IP address and External RTP IP address with the public IP address assigned to the WAN interface of the office Pfsense firewall - from the network topology diagram, that address is 108.100.200.222. For all other SIP profiles, leave these fields empty.
  3. Like SipXcom, the SBC is a SIP proxy and allows the option in the SIP profile to have inbound media to bypass the SBC. Disable this option and have the media anchored through the SBC. As well, specify the ISTP Media profile for inbound and outbound media.
  4. The SIP Trace option should be enabled at first and displays detailed log information in the NSC.log file. This option can be disabled when SIP profiles and call routing plans are fully tested. More information on setting up debugging in SIP Profiles and calling routing plans can be found here http://wiki.sangoma.com/Troubleshooter-SBC.
  5. For all SIP profiles that that interact with SipXcom, set the Authenticate Calls and Authenticate Requests options to disabled and enable the Accept Blind Authentication option. For the Skype for Business SIP profile, all authentication options are disabled.
  6. For the SBCtoITSPExternal, SBCtoPBXInternal, and SkypeforBusiness profiles, leave the Symmetric Response Routing option at its default Enabled setting. Because of the amount of network address translation between the remote phones and SipXcom, the Symmetric Response Routing option for the RemotePhonetoSBC and RemotePhoneInternal SIP profiles must be set to Force Always.
  7. When first creating the SIP Profiles, there is only a default routing plan - the call routing plans listed in step 1 have not been created. Use the Default setting  when creating each SIP Profile initially. After the routing plans have been created, the SIP Profiles can be be assigned to their corresponding routing plan.
  8. There are one header manipulation plan required for remote phones. When this plan is built, the remote phone SIP profiles will be updated here (more details to follow in the header manipulation plans).
  9. On the Skype for Business SIP profile, enable the Lync Interoperability option.

Build the SIP Trunks

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

  1. The domain name can be an IP address or FQDN (it's the Trunk IP address column in the table in step 1)
  2. Depending on the ITSP, authentication information is required - it is specified here. There is no authentication information required for unmanaged trunks to SipXcom or Skype For Business
  3. Use TCP transport for the Skype for Business trunk (Skype only supports TCP transport) Use UDP transport for all other trunks.
  4. When the remote Polycom phone behind the Pfsense firewall with WAN IP address of 47.47.47.444 registers to SipXcom, the firewall state will age out in less than 60 seconds if there is no activity to the phone. By setting the OPTIONS ping frequency attribute to 30 seconds on the RemoteRouter trunk, it keeps the firewall state for the remote phone active and incoming calls are not blocked.
  5. The SIP Profile  option assigns the SIP trunk being created to its corresponding SIP profile as defined in Step 1.
  6. Enable the Registration option if the SIP trunk is registered.
  7. The default Register Expire Seconds value is 60 seconds - if the Registration option in step 6 is enabled, then the SBC will issue a SIP register message every 60 seconds to the ITSP and keeps the office Pfsense firewall active for  external incoming calls arriving from the ITSP.

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.

Build Call Routing Plans and Then Assign to SIP Profiles

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

Build the Header Manipulation Plan for the Remote Phone Using Upper Registration

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.

Build the Domain Name, Enable Upper Registration, and Bind Domain to 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):

  1. Create a domain called testsbcsipxcom.dyndns.org. In step 2 the hostname for the SipXcom voice server was pbx.testsbcsipxcom.dyndns.org  - this means the SIP realm is testsbcsipxcom.dyndns.org, and when lines are created to Polycom phones, that is the SIP realm used by the phone to register a line. After the domain has been defined, enable Forward Registration.
  2. Use the RemotePhoneInternal SIP Profile when sending the register message to the PBX.
  3. Use the SBCtoPBX gateway IP address when forwarding the registration message.
  4. Finally, go to the RemotePhonetoSBC SIP Profile and bind the testsbcsipxcom.dyndns.org to this SIP profile.

Step 6 - Build the NAT Forwarding and Firewall rules in Pfsense for Remote Phones

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.

Step 7 - Configure Polycom Remote Phones and Bria Soft Clients

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.

Field
Phone GUI
SipXcom Provisioning
Value
Comments
Server AddressSettings->SyslogDevices->Phone->Logging (Advanced)108.100.200.222Point syslog server to public IP address of Office Pfsense firewall
IP AddressSettings->Network->NATDevices->Phone->NAT47.47.47.44Have SBC send RTP traffic to the IP address of the remote Pfsense firewall. Firewall state will forward traffic to remote phone
DNS AddressSettings->Network->Ethernet-8.8.8.8Point 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 108.100.200.222 WAN address will be returned
AddressSettings->SIP->Outbound ProxyDevices->Phones->SIP Servers108.100.200.222Point proxy address to the WAN interface of the Office Pfsense firewall
PortSettings->SIP->Outbound ProxyDevices->Phones->SIP Servers5170Point proxy port to the SBC port used by the RemotePhonetoSBC SIP Profile
TransportSettings->SIP->Outbound ProxyDevices->Phones->SIP ServersUDPChange SIP Proxy transport to use UDP
TransportSettings->Lines->Line 1Devices->Phones->Lines->204->Outbound Proxy TransportUDP

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.

 

Step 8 - SipXcom and Sangoma Network Topology

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:

  1. An incoming call from 914-417-2270 is placed to 914-417-2295, which rings x203 registered to the remote phone
  2. Extension 201 on SipXcom places an external call to 914-417-2xxx
  3. Extension 206 on SipXcom places an internal call to extension 2280, which is a Skype for Business user.

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.

Strawman SBC Upper Registration Video Application for Small and Medium Business

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.