Child pages
  • Sangoma SBC Interoperability with SipXcom and Skype for Business (Lync)
Skip to end of metadata
Go to start of metadata


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:

  • The SipXcom user extensions are 3 digits in length while Skype for Business extensions are 4 digits
  • SipXcom users can call Skype users, and vice-versa through the SBC.
  • The ITSP SIP trunk registers to the SBC and routes incoming calls to SipXcom
  • There are two remote phones - one is a Polycom VVX400 phone behind a Pfsense firewall. The second remote phone is a Bria softclient. Both remote phones access Sipxcom using the upper registration feature of the Sangoma SBC.
  • The Sangoma SBC, SipXcom voice server, and Skype for Business server reside behind a Pfsense firewall.
  • The hostname for the SipXcom voice server is and has internal IP address of The SIP realm of is also given a public FQDN with a  IP address of - this is the address of the Pfsense WAN interface front-ending the Sangoma SBC.

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:

  • Private line calling between local and remote phones
  • Basic incoming and outgoing calls to the PSTN from both local and remote phones
  • Voicemail and message waiting
  • Autoattendants
  • DISA
  • One-touch transfers from local phone to another local phone using Polycom Enhanced Function Key macros to test the REFER programming on the SBC.

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 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
Description and Requirements
SBCtoITSPExternalSBCtoITSPLocalExternalpbx6.acepbx.comIncomingITSPtoSBCeth0 - 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 - Trunk to SipXcom - disable registration on SBC trunk. Incoming SIP traffic from SipXcom is processed by this routing plan
RemotePhonetoSBCRemoteRouter47.47.47.44IncomingRemotePhonetoSBCeth0 - 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 - SIP traffic from SipXcom to the remote phone is processed by this routing plan. Trunk definition required for upper registration.
SkypeForBusinessSkypeTrunk10.10.12.12IncomingSkypetoSBCeth0 - 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 to the SBC
  • Assign the unmanaged gateway to a dial plan
  • Change NAT Traversal settings

Creation of Unmanaged Gateway

Create an unmanaged gateway to the SBC at 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. 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 - 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 The public address assigned to the DNS hostname was, 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
  • Validate list of IP subnetworks where intrusion detection will not be reported
  • Configure port information for the media interface - this is important for configuring the office Pfsense firewall to allow traffic from remote phones using upper registration
  • Configure the media profiles to use G711 codecs only and H.264 for video
  • Build the SIP profiles for the ITSP to PBX calls, remote phones using upper registration, and Skype for Business calls
  • Build the SIP trunks for the ITSP to PBX calls, remote phones using upper registration, and Skype for Business calls. Assign the SIP trunks to SIP Profiles
  • Build the call routing plans and assign to the SIP profiles
  • Build the header manipulation plan for the remote phones
  • Build the Domain Name, Enable Upper Registration, and Bind Domain to SIP Profile

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 with a /24 subnet mask, IPV4 defauly gateway address of, and DNS address of 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, and a second SIP profile would use port 5060 and IP address

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:

  • SIP Profiles facing the office Pfsense and the public Internet - in the network topology, these profiles are SBCtoITSPExternal and RemotePhonetoSBC
  • SIP Profiles facing SipXcom - in the network topology, these profiles are SBCtoPBXInternal and RemotePhoneInternal
  • SIP Profile facing the Skype for Business Server.


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 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
  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 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 A useful tool for parsing regex expressions is found here

The IncomingITSPtoSBC call routing plan is shown in the following diagram and gets invoked in the following call scenarios:

  • An incoming external call from the ITSP arrives at the SBC and is routed to SipXcom.
  • An incoming external call from the ITSP arrives at the SBC and is routed to SipXcom. The call is answered by SipXcom and during the call flow, a REFER is generated by SipXcom back to the SBC for the active call.
  • An incoming external call from the ITSP arrives at the SBC with a DID destined for a remote phone or softclient. Rather than sending the call to SipXcom, the call is directly routed to the remote phone.

The IncomingITSPtoSBC call routing plan logic is as follows:

  • The first rule 10 is a best practice - if the invite did not come from the ITSP (, then return a 403 forbidden response back to the user.
  • Rule 11 checks to see whether there is a REFER header (sip_refer_to variable is populated). If the variable is populated the regex used by the SBC parses the <user> information in front of the @ sign and assigns it to the $1 variable. To work around the regex processing a REFER-TO variable is defined and assigned the <user> information found in $1. More details are found here
  • In rule 12, if a <user> information is a 3-digit number or 4-digit beginning with 8, then the REFER came from a Polycom phone transferring an active call to either another extension or to voicemail using an EFK macro. The call is then routed back to SipXcom and the call routing plan terminates.
  • In rule 13, the assumption is made that the REFER came as a result of a DISA call - the numbers entered after the authorization code is validated is sent back to the ITSP and the call routing plan is terminated.
  • Rule 15 does a check of the destination address to determine if it should be routed to a remote phone - if so, then route the call directly to the remote phone using the assigned user extension. This rule needs to be duplicated for every remote phone attached to SipXcom that uses the SBC upper registration feature. A method has not been found to-date to have the external call routed to through SipXcom to the remote phone.
  • Rule 20 sends the call to SipXcom if there are no matches to the previous rule.

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 first rule 10 is a best practice - if the invite did not come from SipXcom, then return a 403 forbidden response back to the user.
  • Rule 11 checks to see whether there is a REFER header (sip_refer_to variable is populated). The regex used by the SBC parses the <user> information in front of the @ sign and assigns it to the $1 variable. To work around the regex processing a REFER-TO variable is defined and assigned the <user> information found in $1. More details are found here
  • In rule 13, the assumption is made that the REFER came from the ITSP side - it takes the <user> part in the REFER and sends the Invite back to the ITSP.
  • In rule 20,  if a 4-digit 2xxx extension was specified in the destination address, then route call to the Skype for Business server.
  • Rule 20 assumes that the call is destined for the ITSP and routes the call down the ITSP trunk.

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:

  • Check that the call came from Skype for Business
  • If the dialed number from Skype is 3-digits in length and begins with 2, then route the call to SipXcom
  • For any other dialed numbers, route the call to the ITSP

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:

  • Check that the call came from the remote phone
  • If the dialed number from the remote  is 4-digits in length and begins with 2, then route the call to Skype
  • For any other dialed numbers, route the call to SipXcom

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 In step 2 the hostname for the SipXcom voice server was  - this means the SIP realm is, 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 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:

  • Port 5170 for SIP signaling between the remote phones or softclients to the SBC using the RemotePhonetoSBC SIP Profile
  • Ports 14000-15000 for used for audio and video media (RTP) traffic
  • Port 512 for storing of phone syslog records on SipXcom

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 to open additional ports on the firewall. In the port forwarding table, provision 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.

Phone GUI
SipXcom Provisioning
Server AddressSettings->SyslogDevices->Phone->Logging (Advanced) 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- Phone DNS to public DNS server (e.g. Google) - When phone queries DNS for address when registering line or sending Invites, the Office Pfsense 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 domain name should be the SipXcom SIP realm; in this case
  • Use the Domain Proxy Proxy setting, setting the address to Note that with Bria, destination port numbers on Domain addresses are specified by appending the :5xxx (port number) to the IP address.

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:

  • IInbound ITSP call arrives on the SBCtoITSPExternal SIP Profile of the SBC. The call routing plan for this profile has a condition checking whether the destination address is 9144172295 - if true, then send the call directly sends the call out directly to the remote phone using the RemotePhonetoSBC profile, bypassing SipXcom. That is why there is only two active calls in the SipXcom active calls report shown above.

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:

  • Outbound ITSP call from SipXcom arrives on the SBCtoPBXInternal SIP profile.
  • The call routing plan sends the call out of the SBC using the SBCtoITSPExternal SIP profile.

When x206 on SipXcom places a call to x2280, the follow call flow should appear on the SBC:

  • Outbound  call from SipXcom arrives on the SBCtoPBXInternal SIP profile.
  • The call routing plan sends the call out of the SBC using the SkypeforBusiness SIP profile.

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 outgoing call from the remote phone arrives on the RemotePhonetoSBC SIP Profile on the SBC
  • The call routing plan sends the call to SipXcom using the RemotePhoneInternal SIP Profile
  • The SipXcom dialplan determines that the number is an external call and sends the call back to the SBC through the un-managed gateway. The SBC processes the call using the call using the SBCtoPBXInternal SIP Profile and the header manipulation rule assigned to profile changes the callerid from x204 to 9144172270.
  • The call leaves the SBC using the SBCtoITSPExternal SIP Profile for the ITSP.

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

  • SIP Profile Status - displays the profile attributes
  • SIP Profile Registrations - users registered via upper registration. From the network topology User 204 at IP address is the Polycom phone behind the remote Pfsense firewall. User 203 at IP address is Android Bria client registered to the SBC and SipXcom via an LTE mobile access network.
  • SIP trunk status - the Remoterouter SIP trunk is mapped to the RemotePhonetoSBC SIP Profile.

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

  • Office uses SipXcom and  Sangoma SBC - they have requirement to have people in the field frequently reach back to office experts for assessing field situations, troubleshooting, etc The business would benefit from on-demand point-point video between field staff and experts in the office.
  • Field staff install SIP clients on their mobile appliances with video capability that have the ability to place a call to an expert in the office with a soft client on their desktop an large screen. Field user streams video and points their appliance at the problem situation. The expert sees the video on a large screen and is able to provide a response more quickly and accurately than with other communications mechanisms.

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. 

  • No labels