© 2024 Ribbon Communications Operating Company, Inc. © 2024 ECI Telecom Ltd. All rights reserved. The compilation (meaning the collection, arrangement and assembly) of all content on this site is protected by U.S. and international copyright laws and treaty provisions and may not be used, copied, reproduced, modified, published, uploaded, posted, transmitted or distributed in any way, without prior written consent of Ribbon Communications Inc.
The trademarks, logos, service marks, trade names, and trade dress (“look and feel”) on this website, including without limitation the RIBBON and RIBBON logo marks, are protected by applicable US and foreign trademark rights and other proprietary rights and are the property of Ribbon Communications Operating Company, Inc. or its affiliates. Any third-party trademarks, logos, service marks, trade names and trade dress may be the property of their respective owners. Any uses of the trademarks, logos, service marks, trade names, and trade dress without the prior written consent of Ribbon Communications Operating Company, Inc., its affiliates, or the third parties that own the proprietary rights, are expressly prohibited.
This document outlines the Trunk-based Routing configuration for the Ribbon SBC SWe Edge HA environment when deploying on Microsoft Hyper-V hypervisor.
In this demonstration, the SBC SWe Edge HA environment is installed on Microsoft Hyper-V hypervisor and it uses the following signaling groups:
UDP / RTP:
TLS / SRTP:
The Ribbon Session Border Controller Software Edition Edge (SBC SWe Edge) provides best-in-class communications security with the convenience of deployment from popular virtual machine platforms as well as the Azure Marketplace and AWS. The SBC SWe Edge delivers:
The SBC SWe Edge dramatically simplifies the deployment of robust communications security services for SIP trunking, Direct Routing, and cloud UC services. Organizations can deploy the software instantly from virtual machine platforms including Microsoft Hyper-V, VMware, and Linux KVM as well as the Azure Marketplace and AWS. The SBC SWe Edge protects SIP trunks, SIP endpoints, cloud contact centers, and cloud UC services, including Microsoft Teams and Zoom Phone. Since SBC SWe Edge is software, it easily scales up or down based on the cloud environment or platform attributes you choose. Deploy it as a single instance or configure two instances in a high-availability model that maintains active calls in the event of a failure. It also includes support for a number of important media services, such as transcoding, that are critical for interoperability. The SBC SWe Edge supports up to 1,200 concurrent calls and 5,000 devices. It boasts an intuitive user interface with templates for popular platforms and telecom providers.
SBC SWe Edge has been independently verified to deliver full protection and performance, even during severe security attacks, which should come as no surprise since Ribbon SBCs are widely deployed across the globe in many of the world’s largest telecom provider networks. Ribbon’s engineering teams understand the importance of scale and resiliency.
The Ribbon SBC SWe Edge is certified for Direct Routing with Microsoft Teams, Zoom Phone BYOC, Webex Local Gateway, and Google Voice SIP Link. More importantly, Ribbon has tens of thousands of deployments across the globe with industry-leading cloud UC services, cloud contact center services, IP-PBXs, and telecom providers on six continents.
For additional information about the Ribbon Edge product, refer to Ribbon Product Documentation Home
Cisco Unified Communications Manager (UCM) is the core of Cisco’s collaboration portfolio. UCM has a rich feature set that supports calling, mobility, conferencing, messaging, and features for remote workers.
For additional information about Cisco Unified Communications Manager (UCM) , refer to Cisco Unified Communications Manager (CallManager).
This document provides configuration best practices for deploying a Trunk-based Routing configuration for the Ribbon SBC SWe Edge HA environment when deploying on Microsoft Hyper-V hypervisor. Note that these are configuration best practices and each customer may have unique needs and networks. Ribbon recommends that customers work with network design and deployment engineers to establish the network design that best meets their requirements.
It is not the goal of this guide to provide detailed configurations that meet the requirements of every customer. Use this guide as a starting point, and build the SBC configurations in consultation with network design and deployment engineers.
This is a technical document intended for telecommunications engineers with the purpose of configuring the Ribbon SBC SWe Edge.
To perform this interop, you need to
This configuration guide is offered as a convenience to Ribbon customers. The product information and specifications in this guide are subject to change without notice. All statements, information, and recommendations in this guide are believed to be accurate, but are presented without warranty of any kind, express or implied, and are provided “AS IS”. Users must take full responsibility for the application of the specifications and information in this guide.
The following are required before proceeding with the interop:
The configuration uses the following equipment and software:
Table Requirements
Product | Appliance/ Application/ Tool | Software Version |
---|---|---|
Hypervisor | Microsoft Hyper-V | Windows Server 2022 Datacenter |
Ribbon SBC | Ribbon SBC SWe Edge | V12.1.1b38 |
SIP UA simulators | SIPP | V3.6-Dev-3.0A01 |
SoftPhone | PhonerLite | V3.25 |
Third-party IP PBX | CISCO CUCM | V12.0 |
Administration and Debugging Tools | LX Tool | 2.1.0.4 |
The sections in this document follow the sequence below. The reader is advised to complete each section for successful configuration.
To deploy the Ribbon SBC SWe Edge instance, refer to Installing SBC SWe Edge on Microsoft Hyper-V.
To enable high availability on an SBC SWe Edge, refer to Enabling High Availability on an SBC SWe Edge.
All configuration changes must be done on the active node.
Open a browser and enter the Admin IP address of the active node.
In this demonstration, the IP address to access the user interface is 10.35.150.210 (Active node). This is the address assigned to the Admin IP Interface.
Log in with a valid User ID and Password.
This section describes how to view the status of each license along with a copy of the license keys installed on your SBC SWe Edge. The Feature Licenses panel enables you to verify whether a feature is licensed, along with the number of remaining licenses available for a given feature at run-time.
From the Settings tab, navigate to System > Licensing > Current Licenses.
From the Settings tab, navigate to Security > SBC Certificates > Generate SBC Edge CSR.
After generating the CSR on the Ribbon SBC, provide the CSR to the Certificate Authority (CA). The CA will generally provide the following certificates:
From the Settings tab, navigate to Security > SBC Certificates > SBC Primary Certificate to import the SBC Primary Certificate.
To import an X.509 signed certificate:
A Trusted CA Certificate is a certificate issued by a Trusted Certificate Authority. Trusted CA Certificates are imported to the SBC SWe Edge to establish its authenticity on the network.
From the Settings tab, navigate to Security > SBC Certificates > Trusted CA Certificates.
When the Verify Status field in the Certificate panel indicates Expired or Expiring Soon, replace the Trusted CA Certificate. You must delete the old certificate before importing a new certificate successfully.
Most Certificate Vendors sign the SBC Edge certificate with an intermediate certificate authority. There is at least one, but there could be several intermediate CAs in the certificate chain. When importing the Trusted Root CA Certificates, import the root CA certificate and all Intermediate CA certificates. Failure to import all certificates in the chain causes the import of the SBC Edge certificate to fail. Please refer to Unable To Get Local Issuer Certificate for more information.
This section contains information about how to manage the way the SBC SWe Edge interfaces with the network. The SBC SWe Edge supports system-created logical interfaces (known as Admin IP, Ethernet 1 IP, Ethernet 2 IP, Ethernet 3 IP and High Availability) for the SBC SWe Edge function. In addition to the system-created logical interfaces, the SBC SWe Edge supports user-created VLAN logical sub-interfaces.
In this demonstration:
Navigate to Networking Interfaces > Logical Interfaces
In this demonstration, the Logical Interfaces were configured as follow:
Static routes are used to create communication to remote networks. In a production environment, static routes are mainly configured for routing from a specific network to another network that you can only access through one point or one interface (single path access or default route).
Destination IP
Destination IP specifies the destination IP address.
Mask
Mask specifies the network mask of the destination host or subnet. If the 'Destination IP Address' field and 'Mask' field are both 0.0.0.0, the static route is called the 'default static route'.
Gateway
Gateway specifies the IP address of the next-hop router to use for this static route.
Metric
Metric specifies the cost of this route and therefore indirectly specifies the preference of the route. Lower values indicate more preferred routes. The typical value is 1 for most static routes, indicating that static routes are preferred to dynamic routes.
From the Settings tab, navigate to Protocols > IP > Static Routes. Click the icon to add the entries.
In this demonstration:
SIPP UA and the SBC SWe Edge Ethernet 1 are in the same subnet, therefore no static route is needed in this case.
The SIP Phones over TLS and the SBC SWe Edge Ethernet 1 are in different subnets, therefore a static route is needed to get connectivity.
CISCO CUCM and SBC SWe Edge Ethernet 2 are in different subnets, therefore a static route is needed to get connectivity.
Media Profiles allow you to specify the individual voice and fax compression codecs and their associated settings, for inclusion in a Media List. Different codecs provide varying levels of compression, allowing one to reduce bandwidth requirements at the expense of voice quality.
From the Settings tab, navigate to Media > Media Profiles. From the Create Media Profile drop-down, select Voice Codec Profile.
For G729:
The codecs G711A and G711U are configured on the SBC SWe Edge by default
Media Profiles are used in the Media Lists.
The SDES-SRTP Profiles configuration defines a cryptographic context used in SRTP negotiation. SDES-SRTP Profiles required to enable encryption and SRTP are applied to Media Lists.
From the Settings tab, navigate to Media > SDES-SRTP Profiles to create new SDES-SRTP Profiles. Click the icon to add the entries.
SDES-SRTP Profiles are used in the Media Lists.
SIPP UA does not support MKI, hence the Key Identifier Length must be set to 0 on the Ribbon SBC SWe Edge.
Specifies a list of Media Profiles for use with Media Lists.
Codec profile order determines the order in which codecs are specified in SIP message(s) sent to a peer. Consider user preferences when ordering codec profiles, placing the more desirable codecs above the less desirable ones.
From the Settings tab, navigate to Media > Media List to create new Media List. Click the icon to add the entries.
The Default Media List is configured on the SBC SWe Edge by default
Media Lists are used in the Signaling Groups.
Tone tables allow the SBC SWe Edge Portfolio administrator to customize the tones a user hears when placing a call. You can modify the tone to match your local PSTN or PBX. The default tone table is configured for the values used in the United States for the following categories: Ringback, Dial, Busy, Congestion, Call Waiting, Disconnect, and Confirmation.
From the Settings tab, navigate to Tone Tables to create new tones profiles. Click the icon to add the entries.
The Default Tone Table is configured on the SBC SWe Edge by default. Feel free to configure additional Tone Tables using the procedure described in this link.
Tone Tables are used in the Signaling Groups.
SIP Profiles control how the SBC SWe Edge device communicates with SIP devices. They control important characteristics such as: session timers, SIP header customization, SIP timers, MIME payloads, and option tags.
From the Settings tab, navigate to SIP > SIP Profiles to create new SIP Profiles. Click the icon to add the entries.
The Default SIP Profile is configured on the SBC SWe Edge by default. Feel free to configure additional SIP Profiles using the procedure described in this link.
SIP Profiles are used in the Signaling Groups.
After the Ribbon SBC SWe Edge obtains the required certificates, configuration of several options/attributes on both the server and client is necessary before TLS can employ the certificate(s) in establishing a secure connection. The attributes are configured in TLS profiles. Attributes include, but are not limited to, items such as Client Ciphers, and inactivity timeouts.
TLS Profiles are used by SIP Signaling Groups when the TLS transport type is selected for incoming and outgoing SIP trunks (Listen Ports), and in SIP Server Tables when TLS is selected as the Server Host protocol.
From the Settings tab, navigate to Security > TLS Profile to create new TLS Profiles. Click the icon to add the entries.
The Default TLS Profile is configured on the SBC SWe Edge by default. Feel free to configure additional TLS Profiles using the procedure described in this link.
TLS Profiles are used in the Signaling Groups and SIP Server tables when TLS is selected as the transport type.
SIP Server Tables contain information about the SIP servers connected to the SBC SWe Edge. The entries in the tables provide information about the IP Addresses, ports, and protocols used to communicate with each server. The Table Entries also contain links to counters that are useful for troubleshooting. The SIP Server supports either an FQDN or IP Address (V4 or V6).
The SIP Server tables contain the IP address or FQDN of one or more SIP servers where INVITE messages can be sent for egress calls on a Signaling Group.
From the Settings tab, navigate to SIP > SIP Server Tables to create new SIP server tables. Click the icon to add the entries.
SIP Server tables are used in the Signaling Groups.
SIP provides a registration function that allows users to upload their current locations for use by proxy servers. Registration creates bindings in a location service for a particular domain that associates an address-of-record URI with one or more contact addresses.
Registration entails sending a REGISTER request to a special type of UAS (User-Agent Server) known as a registrar. A registrar acts as the front end to the location service for a domain, reading and writing mappings based on the contents of REGISTER requests. This location service is then typically consulted by a proxy server that is responsible for routing requests for that domain.
From the Settings tab, navigate to SIP > Local Registrars. Click the icon to create a Local Registrar.
Transformation Tables facilitate the conversion of names, numbers, and other fields when routing a call. They can, for example, convert a public PSTN number into a private extension number, or into a SIP address (URI). Every entry in a Call Routing Table requires a Transformation Table. In addition, Transformation tables are configurable as a reusable pool that Action Sets can reference.
From the Settings tab, navigate to Call Routing > Transformation. Click the icon to create a Transformation Table.
The Passthrough Untouched table is configured on the SBC SWe Edge by default. Feel free to configure additional link. using the procedure described in this
Signaling groups allow telephony channels to be grouped together for the purposes of routing and shared configuration. They are the entity to which calls are routed, as well as the location from which Call Routes are selected. They are also the location from which Tone Tables and Action Sets are selected.
From the Settings tab, navigate to Signaling Groups. In the right panel, click on the Add SIP SG icon to add a new SIP Signaling Group.
Attach the Default Route Table in the Call Routing Table field.
The Call routing table field will be modified on the Signaling Groups once the Call Routing tables are configured on the SBC SWe Edge. For now use the Default Route Table as shown in the pictures.
The SIP Trunk Group Table enables you to configure trunk groups in a profile that can be associated with specific SIP Signaling Groups. The SBC provides interoperability with different servers by transporting, identifying, and processing the trunk group (list of signaling groups) via enterprise trunking parameters. The trunk group helps provide a way to identify/choose the carrier at the gateway for a proxy or service provider.
Configuration for SIP Trunk groups consists of configuration in the following areas:
Trunk Group Profiles (create/modify SIP Trunk Groups)
Call Routing Tables (configure Trunk Group as a destination type for a call route)
Transformation Tables (select destination Trunk Group ID for a call route)
From the Settings tab, navigate to SIP > Trunk Groups to create new Trunk Groups. Click the icon to create a Trunk Group.
The Trunk Group ID (TOCUCM) must be present in the Ingress INVITE as the tgrp or dtg parameter in the Request-URI to route the call using trunk-based routing.
Ingress INVITE message examples:
Feel free to configure additional link. using the procedure described in this
Call Routing allows calls to be carried between Signaling Groups, thus allowing calls to be carried between ports. Routes are defined by Call Routing Tables, which allow flexible configuration of how calls are to be carried and how they are translated. These tables are the central connection points of the system, linking Transformation Tables, Message Translations, Cause Code Reroute Tables, Media Lists, and the Signaling Groups.
Every call enters through an ingress Signaling Group, traverses through a Call Routing Table and its associated Transformation Table or Tables, and exits through an egress Signaling Group. In this demonstration, two Signaling Groups are defined: one serving the SIPP UA, and one serving the CISCO CUCM. A SIP Server Table for each Signaling Group defines where the call should go on egress.
The following flow chart describes the SIP/RTP to SIP/RTP routing process used in this demonstration.
From the Settings tab, navigate to Call Routing > Call Routing Table. Click the to create a Call Routing Table.
The following figures depict the From UA1 UDP routing table associated with the To/From UA1 UDP signaling group.
Feel free to configure additional link. using the procedure described in this
Calls matching the 525501 Transformation Table and with the TGRP or DTG parameter equal to TOCUCM will be routed to the To/From CUCM UDP Signaling Group.
From the Settings tab, navigate to Signaling Groups and click on the To/From UA1 UDP Signaling Group.
Signaling groups allow telephony channels to be grouped together for the purposes of routing and shared configuration. They are the entity to which calls are routed, as well as the location from which Call Routes are selected. They are also the location from which Tone Tables and Action Sets are selected.
From the Settings tab, navigate to Signaling Groups. In the right panel, click on the Add SIP SG icon to add a new SIP Signaling Group.
Attach the Default Route Table in the Call Routing Table field.
The Call routing table field will be modified on the Signaling Groups once the Call Routing tables are configured on the SBC SWe Edge. For now use the Default Route Table as shown in the pictures.
The SIP Trunk Group Table enables you to configure trunk groups in a profile that can be associated with specific SIP Signaling Groups. The SBC provides interoperability with different servers by transporting, identifying, and processing the trunk group (list of signaling groups) via enterprise trunking parameters. The trunk group helps provide a way to identify/choose the carrier at the gateway for a proxy or service provider.
Configuration for SIP Trunk groups consists of configuration in the following areas:
Trunk Group Profiles (create/modify SIP Trunk Groups)
Call Routing Tables (configure Trunk Group as a destination type for a call route)
Transformation Tables (select destination Trunk Group ID for a call route)
From the Settings tab, navigate to SIP > Trunk Groups to create new Trunk Groups. Click the icon to create a Trunk Group.
The Trunk Group ID (TOCUCM) must be present in the Ingress INVITE as the tgrp or dtg parameter in the Request-URI to route the call using trunk-based routing.
Ingress INVITE message examples:
Feel free to configure additional link. using the procedure described in this
Call Routing allows calls to be carried between Signaling Groups, thus allowing calls to be carried between ports. Routes are defined by Call Routing Tables, which allow flexible configuration of how calls are to be carried and how they are translated. These tables are the central connection points of the system, linking Transformation Tables, Message Translations, Cause Code Reroute Tables, Media Lists, and the Signaling Groups.
Every call enters through an ingress Signaling Group, traverses through a Call Routing Table and its associated Transformation Table or Tables, and exits through an egress Signaling Group. In this demonstration, two Signaling Groups are defined: one serving the TLS User Agents, and one serving the CISCO CUCM. SIP Server Tables or Local Registrars define where the call should go on egress.
The following flow chart describes the TLS/SRTP to UDP/RTP routing process used in this demonstration.
From the Settings tab, navigate to Call Routing > Call Routing Table. Click the to create a Call Routing Table.
The following figures depict the From SoftPhone TLS routing table associated with the To/From SoftPhone TLS signaling group.
Feel free to configure additional link. using the procedure described in this
Calls matching the Passthrough Untouched Transformation Table and with the TGRP or DTG parameter equal to TOCUCM will be routed to the To/From CUCM UDP Signaling Group.
From the Settings tab, navigate to Signaling Groups and click on the To/From SoftPhone TLS Signaling Group.
Unified CM is the core of Cisco’s collaboration infrastructure. It is an IP-based communications system that allows you to contact your coworkers or customers through audio or video regardless of physical location.
The primary function of CUCM is call processing and phone registration. Essentially, it is the brain of the phone; the physical handsets are just endpoints.
Unified CM is what processes your calls (both video and audio). It’s the application that provides services such as hold, transfer, conference, etc.
The following steps describe the CUCM configuration used in this demonstration.
Open a browser and enter the CUCM IP address.
Log in with a valid User ID and Password.
From the Device tab, navigate to Trunk to create a new Trunk. Click the icon to create a new Trunk.
From the User Management tab, navigate to End User. Click the icon to create a new End User.
From the Device tab, navigate to Phone to create new Phone devices. Click the icon to create a new Phone.
The Third-party SIP Device (Basic) Phone Type is used in this demonstration.
From the Device tab, navigate to Phone.
Click Find to list the Phone devices on the CUCM.
Click on the Device Name you want to edit.
On the left menu, click on Line 1.
Repeat the previous steps to add additional phones and lines.
For further information regarding CISCO CUCM configuration, visit the following link.
The following checklist depicts the set of services/features covered through the configuration defined in this Interop Guide.
This document includes both TLS and UDP configurations. However, supplementary services testing was conducted exclusively using the TLS/SRTP to UDP/RTP Configuration. The UDP/RTP to UDP/RTP configurations are provided only for reference.
Sr. No. | Supplementary Services/ Features | Coverage |
---|---|---|
1 | Cancel Call | |
2 | No Answer (Timeout) | |
3 | Busy Call | |
4 | Call Rejection | |
5 | Call Forward Unconditional | |
6 | Call Forward Busy | |
7 | Call Forward No Answer | |
8 | Call Transfer (Blind/Unattended) | |
9 | Call Transfer (Attended) | |
10 | Call Hold and Resume | |
11 | Long Duration Call (A to B) |
Legend
Supported | |
Not Supported |
The following items should be noted in relation to this Interop - these are either limitations, untested elements, or useful information pertaining to the Interoperability.
S.No | Caveats | Description |
---|---|---|
For any support related queries about this guide, please contact your local Ribbon representative, or use the details below:
For detailed information about Ribbon products & solutions, please visit:
https://ribboncommunications.com/products
For detailed information about Cisco products & solutions, please visit:
This Interoperability Guide describes successful configuration of interop involving SBC SWe Edge using Trunk-Based Routing and the CISCO CUCM.
All features and capabilities tested are detailed within this document - any limitations, notes, or observations are also recorded in order to provide the reader with an accurate understanding of what has been covered, and what has not.
Configuration guidance is provided to enable the reader to replicate the same base setup - there may be additional configuration changes required to suit the exact deployment environment.
© 2024 Ribbon Communications Operating Company, Inc. © 2024 ECI Telecom Ltd. All rights reserved.