Using Voxbone with Cisco CUBE

Introduction

We believe setting up business communications should be a straightforward, painless process. That’s why we build our SIP services to play well with whichever communications platform you might use – whether it’s hardware-based or hosted in the cloud, built internally or bought from a third-party vendor.

What you’ll need to get started:

  1. A registered Voxbone account with assigned numbers. (Create your account here)
  2. Your Cisco CUBE configured with any internal setup to your Cisco Call Manager and any network connectivity you need to allow your users to dial.

Note: For Voxbone, a free test account is enough for you to follow the steps in this guide and complete a technical validation of the integration of our voice services and Cisco CUBE.

How it works

cisco CUBE and Voxbone
When a call is received on our platform, we deliver this call to your designated SIP interface through voice URIs. Behind the scenes, we take care of complex things like least-cost routing, finding the best provider and optimising for maximum call quality. To connect your Voxbone numbers to your Cisco CUBE, we need to establish a SIP interface between the platforms.

This can be done in 2 steps:

  1. Setting Up Inbound Call Routing
  2. Setting Up Outbound Call Routing

1. Setting Up Inbound Call Routing

To set up inbound calls, we need to configure some settings in Cisco CUBE. Once the destination address is set up there, we can set up a number and direct traffic to this source within the Voxbone platform.

Setting Up IP Whitelisting

First, we need to whitelist Voxbone’s signaling IPs within Cisco CUBE. You can find a list of signaling IPs for all our Points of Presence (PoPs) here.

This goes into the [Voice Service] part of the Cisco configuration. I’ve named the Voice Service related to us as VOXBONE. The Voxbone addresses you need are in bold.

Please note that general good practise considerations are in here. Such as required RTP port ranges to match to our network. Take the bits that you need into this section of your configuration.

voice service VOXBONE ip address trusted list
 ipv4 185.27.148.0
 ipv4 81.201.82.0
 ipv4 81.201.86.0
 ipv4 81.201.83.0
 ipv4 81.201.84.0
 ipv4 81.201.85.0
 ipv4 81.201.89.110 255.255.255.255
 no ip address trusted authenticate
 rtcp keepalive
 rtp-port range 10000 24000
 address-hiding
 mode border-element license capacity 2000
 allow-connections h323 to h323
 allow-connections h323 to sip
 allow-connections sip to h323
 allow-connections sip to sip
 no supplementary-service sip refer
 supplementary-service media-renegotiate
 signaling forward none
 fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
 sip
 header-passing
 error-passthru
 conn-reuse
 early-offer forced
 no silent-discard untrusted
 midcall-signaling passthru
 privacy-policy passthru
 sip-profiles inbound
 no call service stop
 !

Setting up a SIP URI

Next you’ll need to setup a URI for Voxbone to use. What this looks like will depend on your business setup, how many Cisco CUBEs you have and the level of resiliency you require.

  1. We recommend working with the owner of your company’s firewall to provide an External IP address that can then be mapped to the internal addresses you’ve setup in this section of your Cisco CUB Configuration.
    sccp local GigabitEthernet1
    
    sccp ccm 10.0.0.1 identifier 1 version 7.0 
    
    sccp ccm 10.0.0.2 identifier 2 version 7.0
  2. If you’re unsure on the level of resilience you require, we recommend reading this article from our Knowledge Base.
  3. The final step in setting up a SIP URI is to ensure you’ve configured your dial peer for inbound, which will look something like this.
    dial-peer voice 1 voip
     description incoming calls from Voxbone
     session protocol sipv2
     session target sip-server
     incoming called-number .T
     voice-class sip profiles 777   ! - Add Translations you need up to your own configuration
     voice-class sip bind control source-interface GigabitEthernet1  ! - Bind the incoming to your network
     voice-class sip bind media source-interface GigabitEthernet1 ! - Bind the incoming to your network
     dtmf-relay h245-alphanumeric  
     codec g711alaw ! Ensure you are setting codecs aligned to what you configure in Voxbone 
     no vad
     !

Configuring a SIP URI To Point At Cisco CUBE

Next, we will set up the SIP interface from Voxbone to Cisco CUBE. In Voxbone’s platform, this is done via Voice URIs.

In order to differentiate between different Voice URIs that might be pointing at your Cisco CUBE, we’ll use a reserved keyword on our platform, “{E164}”, so that we can use the same voice URI for many different numbers and detect what number is called/who’s calling.

  1. Log in to your Voxbone account.
  2. Go to Configure > Configure Voice URIs or, if you’re logged in, click here. Then click “New” to create a Voice URI for your Cisco Cube
  3. Specify the Voice URI as {E164}@YourCiscoCUBE.com  or {E164}@YourCiscoExternalIP

Adding a Number to the URI So You Can Call it, and Adding an Audio Codec

Now, we need to link one of our phone numbers to the Cisco Cube URI we just created.

  1. Go to Configure > Configure DIDs or, if you’re logged in, click here.
  2. Use filters to pick a number of your choice to assign for testing and hit “Search”.
  3. Once you’ve picked your number, under the Configuration menu, go to the “Voice” tab and click “Voice URI”. Also, make sure to pick the codecs we set in the dial peer above to prevent any SDP or media-related errors under the “Codecs” menu. Configure DID
  4. Select the voice URI you created from the previous step, from the popup window.
  5. Hit “Apply” and “Continue”, then finally, “Confirm.”
  6. All set! Now place a call to the number you are using for testing. It should reach your Cisco CUBE

Testing Calls

Any calls placed to the numbers associated with your URI are now delivered by Voxbone to your Cisco CUBE. If you used the {E164} keyword, your CUBE should see them as calls received to URI (called Voxbone DID)@YourCiscoDomain. You should be able to do a packet capture within your CUBE to capture the traffic and see the incoming call.

2. Setting Up Outbound Call Routing

For security reasons, it’s important to look at number permissions and SIP digest headers when setting up outbound calling. These will allow you to use a number for multiple applications.

But there are a few steps to take before we get there.

Enabling Outbound

Before you start, make sure you have an online account with Voxbone and that Voxbone’s service interoperates with your network by following the inbound guide above.

Then check the following:

  • That your Account Manager or Customer Success Manager has activated Voxbone’s outbound service for your account, and for your country of choice
  • That you’ve got 2 test numbers for outbound calling. These are test numbers in countries that have our outbound service available. Our team will confirm that access has been granted for these numbers.
  • If the country you are using requires Emergency Services to be enabled, please ensure you speak to our team about getting this set up at the same time, as otherwise it might delay this process.

Go to ‘Configure DIDs’ in the Voxbone platform, and select the numbers you wish to set up for outbound service. Find ‘VoxOut National’ and click it to enable outbound calls. Be, and then be sure to hit ‘Apply’ to update the configuration.

Voxbone Voice URI - Ribbon SBC
This allows you to use this number as an outbound presentation number across any number of integrations.

Enabling SIP Digest Security

The next thing that needs to be set up is the security configuration that Voxbone requires for outbound calling. Voxbone uses SIP Digest headers. To set up the credentials, please go to ‘Configure Outbound Voice’.

Here you can add the username and password used on the system.

Voxbone configure - Ribbon SBC

Note: We strongly recommend you use the generation tool to create a large, complex key for use within the system. This is a central configuration and only needs setting up once.

Setting Up Call Diversion

To allow call forwarding or call diversion to support passing or presenting third-party call IDs, the system needs to have the following setup.

  • The number listed in the ‘FROM’ field can be either a Voxbone or third-party number
  • The number in the ‘TO’ field can be a number listed in our routing prefix table
  • The number in the ‘DIVERSION’ field must be a Voxbone number activated for outbound voice

Cisco CUBE Settings

As Voxbone uses different IP addresses for inbound and outbound calls, we need to add a second dial peer. In the below example I’m using the “Voice Class Tenant
option”, which allows you to specify a configuration centrally.

dial-peer voice 4 voip
 description outgoing calls to Voxbone
 destination-pattern .T
 session protocol sipv2
 session target sip-server
 session transport udp
 voice-class sip profiles 100
 voice-class sip tenant 1
 voice-class sip bind control source-interface GigabitEthernet1
 voice-class sip bind media source-interface GigabitEthernet1
 dtmf-relay rtp-nte
 codec g711alaw
 !

voice class tenant 1
 registrar ipv4:81.201.89.110 expires 3600 (Or Use outbound.voxbone.com)
 credentials username {YourUsername} password 7 {Your Password} realm voxbone.com
 authentication username {YourUsername} password 7 {Your Password} 
 sip-server ipv4:81.201.89.110  !(Or Use outbound.voxbone.com)
 no pass-thru content custom-sdp
 !

Alternatively you can manage this with the sip-ua configuration against the dial peer.

sip-ua
 authentication username {YourUsername} password 7 {Your Password} realm voxbone.com
 retry invite 2
 retry bye 2
 timers trying 200
 timers expires 60000
 sip-server ipv4:81.201.89.110 !(Or Use outbound.voxbone.com)
 reason-header override
 !

Cisco CUBE will require additional configuration to ensure it complies with our rules on From headers.

voice class sip-profiles 100
 request INVITE sip-header From modify "FROM: (.*)>" "FROM: <sip:[email protected]>"

or

request INVITE sip-header From modify "FROM: (.*)>" "FROM: <sip:[email protected]>"

We need you to modify the From header, to remove your internal credentials. Stripping the header as you need based on your own numbering plan means this section is down to you, but the format of the request will be similar to the above.

The sample Partial CUBE Config is attached here.

For any questions, please contact us