Child pages
  • Sangoma SBC Interoperability with Sipxcom High Availability

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Step 1 - Plan Your SBC Configuration

Image RemovedImage Added

Per the above reference diagram, the Sangoma SBC sits behind Pfsense  in a private network. Given that the Pfsense firewall protects the private network from malicious public Internet traffic, the SBC firewall was turned off. The Sangoma SBC has several high availability and clustering settings - those settings were not tested or validated with the Sipxcom HA configuration.

...

For outbound traffic from the SBC to the ITSP, Pfsense must be programmed to NAT outgoing traffic from 10.20.2.25 to the public IP address reserved for SBC traffic - this is done via a mapping entry on the Psense Firewall->NAT->Outbound menu. 

Image RemovedImage Added

Step 3 - Sipxcom Configuration to Support SBC

...

Create an unmanaged gateway to the SBC at 10.20.2.25 using TCP transport and port 5063.

Image RemovedImage Added

Assign the SBC Unmanaged Gateway to Dial Plan

Assign the SBC unmanaged gateway to the appropriate dial plans such as the Long Distance Dialplan.

Image RemovedImage Added

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 and provision the Public IP address with the IP address of the SipXcom primary voice server. Repeat this step for each of the secondary servers (10.20.2.35 and 10.20.2.36).

Image RemovedImage Added

Change Firewall Settings for SAA/BLA

By default, the firewall settings to allow 5170 traffic from the phones to Sipxcom are disabled - this is used by bridge line appearance (BLA) lines on Sipxcom. Go to the System->Firewall menu and change the SAA/BLA TCP and UDP firewall settings from CLUSTER to PUBLIC. This change allows BLA to work on shared lines using Polycom phones in order to perform interoperability testing with the Sangoma SBC.

Image RemovedImage Added

Step 4 - Configuring the Sangoma SBC

...

Go to the Configuration->IP Settings->Network menu on the SBC and validate the IP Address assigned to the Eth0 interface and default gateway from the installation. Point the SBC DNS addresses to the three Sipxcom HA servers.

Image RemovedImage Added

Create G.711 Media Profile for the ITSP

The ITSP used for interoperability testing with the PSTN only supports G.711 codecs. Go into the Configuration->Media->Media Profiles menu of the SBC and create an ITSP profile that only supports PCMU and PCMA codecs.The aceprofile will be assigned to the ITSP and PBX SIP profiles of the SBC.

Image RemovedImage Added

Build the SIP Profiles

...

These two profiles are first created so that they can then be linked to the SIP trunks. The SIP profiles will then be updated after the corresponding Call Routing dialplans have been created.

Image RemovedImage Added

Create the ITSPtoSBC profile using the default SBC profile settings except for the following fields:

  • External SIP and RTP IP address fields are provisioned to 108.xx.yy.zzz this is the public IP address assigned by Pfsense for the SBC. This is required as the SBC is sitting behind the firewall and not directly connected to the Internet. The SBC will replace the source IP address for outgoing SIP packets to the ITSP with the public 108.xx.yy.zzz IP address assigned to the SBC.
  • Port number is 5062 (see archiecture diagram in step 1 again)
  • Transport is UDP+TCP
  • Inbound and outbound media profiles are set to aceprofile (previous step) as the ITSP only supports G.711 codecs
  • Validate that the Inbound bypass Media option is disabled - this means that all media goes through the SBC and simplifies troubleshooting.
  • Enable the Accept Blind Authentication option

Image RemovedImage Added

Create the SBCtoPBX profile using the default SBC profile settings except for the following fields:

  • Port number is 5063 (see architecture diagram in step 1 again)
  • Transport is UDP+TCP
  • Inbound and outbound media profiles are set to aceprofile (previous step) as the ITSP only supports G.711 codecs
  • Validate that the Inbound bypass Media option is disabled - this means that all media goes through the SBC and simplifies troubleshooting
  • .Enable the Accept Blind Authentication option

Image RemovedImage Added

Build the SIP Trunks

...

  • ITSPTrunk - points to the ITSP nodes defined at csp1.acepbx.com. The Ace Innovative ITSP actually presents two SRV records when queried by DNS - the primary server at 66.114.83.74 and the secondary server  at 66.114.83.75.
  • PBXTrunk - points to the Sipxcom HA cluster with the SIP realm of lvtest.com. The Sangoma SBC is able to process DNS SRV records.

Image RemovedImage Added

The SBC must be stopped prior to building the SIP Trunks and assigning the SIP Profile to the Trunk. The following configuration parameters are defined on the ITSPTrunk SIP Trunk:

...

Go to the Configuration->Call Routing menu and build these two dialplans.

Image RemovedImage Added

 

Once the call routing dialplans have been defined, they need to be mapped to the correct SIP profile as follows:

...

Once these configurations are applied to the SBC, the rules for each dialplan can be defined and tested.

Image RemovedImage Added

Before working through the details of the call routing dialplan rules, some simple call flow examples will provide clarity on the dialplan logic. Let's start with an incoming external call to 914-417-2292 (see architecture diagram in step 1), which is a Polycom phone behind Sipxcom. Because the call originated from the ITSP, the SBC processes the call using the ITSPtoSBC SIP Profile and corresponding ITSPRoute dialplan. The 19144172292 user answers the call and transfers the call to 2293 (which is an alias of 19144172293). To complete the transfer, Sipxcom issues a SIP REFER back to the SBC. Because the call being transferred originated from the ITSP, the ITSPRoute dialplan will process the REFER even though the REFER came from Sipxcom. The REFER from Sipxcom will have a Refer-To: header that begins with sip:2293@lvtest.com;user=phone; the SBC dialplan regex must parse this header, look at the 2293 destination address, and instruct the SBC to send an INVITE to 2293@lvtest.com back to Sipxcom in order to complete the call transfer.

...

Final example - Sipxcom user 19144172292 has a call forwarding rule that forwards incoming calls to 16465551212 after 1 secondAn external ITSP 9145551212 caller places a call to 19144172292. Sipxcom after 1 second sends an INVITE back to the SBC with a Request-line URI of INVITE sip:16465551212@10.20.2.25:5063 but the SIP TO: header has the original sip:9144172292@lvtest.com URI. Almost all SIP INVITES have Request-line URIs that are identical to the TO: header URI. However when call forwards are initiated by Sipxcom due to a call forwarding rule, the telephone numbers in the R-URI header and To: headers are different - the SBC must account for this when a call forwarding rule is applied to a Sipxcom user.

Image RemovedImage Added

The Call Routing dialplan rules for both the ITSPRoute and PBXRoute dialplans are identical except for dialplan rule 9. In the following dialplan rule illustration, rule number 4 is a best practice and checks that SIP signaling comes from either the Sipxcom high availability servers or the ITSP - if not, processing stops with a SIP 405 error message and further dialplan processing terminates. 

...

The final dialplan rule 9 forwards an incoming call from the ITSP to the Sipxcom PBX, and vice-versa. In the ITSPRoute dialplan rule (illustrated), the called number is custom bridged to the PBXTrunk  which connects to Sipxcom. For an incoming call from Sipxcom to the ITSP, the PBXRoute dialplan would custom bridge the call to the ITSPTrunk in rule 9. Image RemovedNote that in the conditional query for the SIP INVITE packet, the request-line URI is queried and populated in the $1 variable by the underlying regex..

Image Added

Step 7 - Test Your SBC Configuration

...