Best Practice - Configure SBC Edge Portfolio for Yealink Teams Client Local Survivability

Introduction to Yealink Teams Client Local Survivability

Ribbon Communications and Yealink® support uninterrupted voice services if a connectivity loss occurs between an enterprise site hosting Yealink Teams, voice-related clients, and the Microsoft® Phone System hosted in the Microsoft Azure™ cloud.

Support for Teams Client Survivability

The benefits of voice service survivability between enterprise sites hosting Yealink Teams voice-related clients and Phone Systems hosted in the Azure cloud include the following:

• Enabling continued employee communication and collaboration with each other and with customers (that is, support employee capabilities to place and receive intra-office and inter-office voice calls and access backup call routing) regardless of Phone System availability
• Increasing the ease of adoption for Phone System services at enterprise locations where such services are not yet rolled out

This best practice describes the Teams client survivability services available using Ribbon and Yealink products. The best practice also provides instructions for configuring, activating, and validating the services. For details of the Yealink and Ribbon collaboration, refer to the integrated solution announcement and related links.

Applicable Products

The following Yealink Teams clients collaborate with Ribbon Communications SBC Edge Portfolio to support survivability:

• Conference Phone CP960
• Desk Phone T58A
• Desk Phone T56A
• Desk Phone T55A (available Q3 2019)

Yealink Teams Clients

Yealink Teams Clients - Conference and Desk Phones

For details about devices that support Teams voice services, refer to the Yealink Teams client products page for the latest feature descriptions and specifications for available models. 

Ribbon Communications SBC Edge Portfolio

The following SBC Edge Portfolio offerings support Yealink Teams Client Local Survivability:

• SBC SWe Edge, in both enterprise on-premises and Microsoft Azure-based deployments
• All SBC 1000 hardware permutations
• All SBC 2000 hardware permutations

Teams Client Survivability Operation

The survivability capabilities available to Teams clients vary based on the accessibility of the Phone System and the deployment type (on-premises or Azure).

Network Operation when the Phone System is Accessible

When the Phone System is accessible, the Yealink Teams and SBC Edge Portfolio operate as designed for the integrated solution.

SBC Edge Portfolio on Enterprise Premises

When the SBC Edge Portfolio is deployed on-premises, operation with the Yealink Teams clients is as follows with the Phone System accessible:

• Both the Yealink Teams clients and the SBC Edge Portfolio have continued Phone System access for signaling and media control.
• Yealink Teams clients use the Phone System (the "Primary Call Server") to establish intra-office, inter-office, and calls into the PSTN.
• SBC Edge Portfolio acts as a Teams Direct Routing certified SBC in support of Teams client access to the PSTN or to third-party, non-Teams voice infrastructure.
• As a supplement to the Teams Phone System call services, the Yealink Teams clients register with the SBC Edge Portfolio (the "Secondary Call Server") via SIP signaling.
  
  
  
  

Normal Operation when Teams Phone System is Accessible (SBC on enterprise premises)

 SBC SWe Edge in Azure

When the the SBC SWe Edge is deployed in Azure, operation with the Yealink Teams clients is as follows with Phone System accessible:

• Both the Yealink Teams clients and the SBC SWe Edge access Phone System in Azure for signaling and media control.
• The Yealink Teams clients use the Phone System ("Primary Call Server") to establish intra-office, inter-office and calls into the PSTN.
• The SBC SWe Edge acts as a Teams Direct Routing certified SBC in support of Teams client access to the PSTN or third-party non-Teams voice infrastructure.
• As a supplement to Phone System call services, the Yealink Teams clients register with the SBC SWe Edge ("Secondary Call Server") via SIP signaling. 

Normal Operation when Teams Phone System is Accessible (SBC SWe Edge) in Azure)

Network Operation when the Phone System is Not Accessible

SBC Edge Portfolio on Enterprise Premises

Operation of the Yealink Teams clients and the SBC Edge Portfolio (deployed on-premises) when the Phone System is not available (e.g. WAN outage, etc.) is characterized by:

• The Phone System in Azure is no longer accessible for signaling and media control to the Yealink Teams clients and the SBC Edge Portfolio.
• The Yealink Teams clients use the services of the SBC Edge Portfolio ("Secondary Call Server") via SIP signaling to establish intra-office, inter-office, and public calls into the PSTN.

Operation when Teams Phone System is Not Accessible (SBC on enterprise premises)

SBC SWe Edge in Azure

Operation of the Yealink Teams clients and the SBC Edge Portfolio (deployed in Azure) when the Phone System is not available is characterized by:

• The Phone System in Azure is no longer accessible for signaling and media control to the Yealink Teams clients.
• The Yealink Teams clients use the services of the SBC SWe Edge in Azure ("Secondary Call Server") via SIP signaling to establish intra-office, inter-office, and public calls into the PSTN.

Operation when Teams Phone System is Not Accessible (SBC on enterprise premises)

Initiating Survivability Operation From Yealink Devices

Outgoing Calls

To place outgoing calls using instead of using the Phone System ( for example, if the Phone System is temporarily unavailable), the Teams client user must access the Survivability (SIP) display of the Yealink device UI using the SIP "Quick Ball" icon. From the survivability UI, the user can place calls that route to their intended destination via the SBC Edge Portfolio. 

"Quick Ball"-enabled Survivability on Yealink Teams Devices

Incoming Calls

The Yealink device UI automatically presents the appropriate UI (whether the Teams Client or Survivability) depending upon the originator of the incoming call (Phone System in the former case, and the SBC Edge Portfolio in the latter). The user simply needs to answer the incoming call to engage in the call. 

SBC Edge Portfolio Survivability Operation

When call routing is configured appropriately post-deployment, the SBC Edge Portfolio automatically offers survivability services with no additional intervention. 

• When incoming calls (intended for a Teams client) from the PSTN or a non-Team client arrive at the SBC, the SBC validates the availability of the Phone System (the latter being of the highest priority within the route list). If the Teams System is recognized as being unavailable, the SBC routes the call directly to the subtended registered Yealink Teams client via SIP, as opposed to the Phone System. For such an action to occur, the intended call recipient (the Yealink Teams client) must be mapped by the SBC as having a resolvable SIP-based client address. This resolution is possible through the subsequent SBC provisioning instructions.
• Incoming SIP-based calls that arrive from the subtended Yealink Teams client are routed by the SBC as a standard SIP-based registered endpoint. These calls will be routed either to another subtended Yealink client or into the PSTN, provided such routes are active and available. If no route is found, the SBC routes the call to the appropriate configured treatment.

Enabling Yealink Teams Client Local Survivability

Yealink Teams Client Device Prerequisites

Yealink Teams client-supporting devices (phones, etc.) must fulfill the following prerequisites prior to undertaking further actions:

1. Devices must be configured and support Phone System voice services. To confirm support, please place a call from the Teams client UI to another Teams client within the enterprise. If such a call is successfully completed, the device is configured to offer phone system services.
2. Devices must be configured with a firmware release that supports survivability for Teams deployments.
   

3. Optionally, Yealink devices may be configured to communicate with the SBC Edge Portfolio using TLS (Transport Layer Security, used for SIP signaling encryption) and SRTP (Secure Real-time Transport Protocol, used for media encryption).

   Use of Signaling and Media Encryption Strongly Recommended for Azure-based SBC Deployments

   Ribbon Communications and Yealink strongly recommend the use of TLS and SRTP for secure encrypted communication between the Yealink devices and the SBC, especially when the latter is deployed in the Azure public cloud. When the SBC is deployed in Azure, the use of encryption safeguards the communication that transits the public Internet. Please refer to the following links to configure the Yealink devices and the SBC for secure communication:

   • For the Yealink devices, refer to the relevant administrator guide, and undertake the configuration as a prerequisite step (now). An example administrator guide with encryption configuration instructions (for the desk Phone T58A) is available at support.yealink.com.

   • For the Ribbon SBC Edge Portfolio, configure TLS & SRTP encryption later, within the SIP Local Registrar step and the Signaling Group configuration step. Note the following:
     • The SBC Edge Portfolio should possess an X.509 certificate that is acquired during the Teams Direct Routing prerequisite step, including the CA (Certificate Authority) chain of trust. Refer to Configure a Certificate for the SBC Direct Routing Interface for more information regarding the certificate assignment during the Teams Direct Routing setup. 
     • The SBC Edge Portfolio X.509 certificate, exchanged during the TLS handshake with the Yealink device, must be signed by a CA that the Yealink devices will trust for successful communication. 
       • The list of recognized CAs is found in the relevant Yealink device administrator guide posted at support.yealink.com;
       • If the certificate is signed by an unrecognized CA, you must load the relevant sections of the certificate's chain of trust from the SBC into the Yealink devices so that the certificate is subsequently trusted. Refer to Working with Certificates for certificate chains within the SBC.

Assuming the conditions are fulfilled, the Yealink devices are ready for Teams-related survivability configuration and should be updated only after the SBC Edge Portfolio prerequisites and configuration are complete.

Ribbon SBC Edge Portfolio Prerequisites

In all cases, the SBC Edge Portfolio product must be deployed with a supporting firmware image. Once such an image is in place, please also ensure the following conditions are met depending upon the location (enterprise premises or Azure) of the SBC in the network topology.

SBC Edge Portfolio Deployed On-Premises

For SBC Edge Portfolio devices deployed on-premises, confirm the following:

1. The initial setup is complete.

   • SBC 1000 and SBC 2000 initial setup steps

   • SBC SWe Edge on-premise deployment initial steps

     SBC SWe Lite Deployed On-Premises Initial Setup Clarifications

     The SBC SWe Edge initial setup instructions include content related to feature licensing, trials, and easy configuration. Note the following:

     1. You can choose to undertake feature licensing under the initial setup instructions, please ensure the minimum licensing requirements listed in step 2 are addressed;

     2. You can choose to configure the SBC SWe Edge for Yealink Teams Client Local Survivability with a trial license and, as such, temporarily disregard the instructions in step 2; however, there are considerations:

        • Note the number of registered Yealink devices and session capacity will be limited to the capabilities of the trial license;

        • Ribbon does not support the use of trial licenses for live traffic (production) deployments.

     3. Please do not undertake any Easy Configuration Wizard actions at this time; the easy configuration actions in a Teams-related deployment have additional considerations, as defined in Step 3

2. Licensing has been acquired and properly assigned.

   • The following SIP registration license(s) are required for registering Yealink devices:

     • SBC 1000 and SBC 2000 registration licenses

     • SBC SWe Edge licenses for on-premises deployments
   • The following SIP session licenses may be required if the SBC Edge Portfolio connects the IP-based SIP signaling and RTP media to and from subtended Yealink clients to an IP-based client (for example, a SIP trunk or a SIP-based IP PBX) instead of a legacy TDM connection (for example, a PRI/BRI trunk or an analog FXS/FXO destination):

     • SBC 1000 and SBC 2000 SIP session licenses;

     • SBC SWe Edge licenses for on-premises deployments.

       For instructions on how to obtain and apply licenses, refer to Node-Locked Licensing.

3. Teams Direct Routing (DR) basic configuration has been undertaken. Teams DR basic configuration is documented in the on-premises best practice. Please ensure all instructions are executed as documented in the following sections of that best practice:

   • Configuration Prerequisites

   • Configure Direct Routing For Greenfield Deployment, including the execution of one of the following easy configuration wizard scenarios related to Teams DR:
     • SIP trunks ↔ Microsoft Phone System Direct Routing
     • ISDN PSTN ↔ Microsoft Phone System Direct Routing
     • IP PBX ↔ Microsoft Phone System Direct Routing
   • Refer to the Teams Direct Routing troubleshooting details for final review and testing of the Teams Direct Routing capable SBC Edge Portfolio device.
4. Networking device updates have been applied to permit  SBC Edge Portfolio  ↔ subtended registered Yealink client device communication. The SBC Edge Portfolio and the Yealink clients that will attempt to register may not be in the same office/LAN; they may be located in different offices accessible through the enterprise's WAN, or may only be accessible through the internet. As such, the following devices must be configured to ensure successful communication between the parties:

1. • Any intervening routers undertaking LAN ↔ WAN addressing conversions, such as those related to NAT;

   • Any intervening firewalls undertaking network traffic filtering actions.

     Contact Enterprise IT to Facilitate IP-based Communications

     Please contact your IT administrator to ensure communication can be undertaken between the network segments hosting the Yealink Teams client devices and the SBC Edge Portfolio. The IT administrator should be knowledgeable regarding the private IP addresses assigned to all devices, along with the required routing to achieve inter-device communications.

Once the previous steps have been completed, the SBC Edge Portfolio device is ready for further configuration for Yealink Teams Client Local Survivability.

SBC SWe Edge Deployed in Azure

For an SBC SWe Edge deployed in Azure, confirm the following:

1. Initial setup is complete per the instructions applicable for an Azure deployment.

   SBC SWe Edge Deployed in Azure Initial Setup Clarifications

   The SBC SWe Edge initial setup instructions include content related to feature licensing, trials, and easy configuration. Note the following:

   1. You can choose to undertake feature licensing under the initial setup instructions, please ensure the minimum licensing requirements listed in step 2 are addressed.

   2. You can choose to configure the SBC SWe Edge for Yealink Teams Client Local Survivability with a trial license and, as such, temporarily disregard the instructions in step 2; however, there are considerations:

      • Note the number of registered Yealink devices and session capacity will be limited to the capabilities of the trial license.

      • Ribbon does not support the use of trial licenses for live traffic (production) deployments.
   3. Please do not undertake any Easy Configuration Wizard actions at this time; the easy configuration actions in a Teams-related deployment have additional considerations, as defined below in step 3.

2. Licensing has been acquired and properly assigned.

   • SIP registration license(s) (namely, one or more instances of the SBC-SWELITE-LIC-RG -CLOUD) are absolutely required to enable the registration of Yealink devices. 

   • SIP session licenses are required, as the IP-based SIP signaling and RTP media to/from the subtended Yealink clients is connected by the SBC SWe Edge to an IP-based client (e.g. a SIP trunk, a SIP-based IP PBX, etc.)

     SBC Edge Portfolio License Acquisition

     For instructions on how to obtain and apply licenses, refer to Node-Locked Licensing.

3. Teams Direct Routing (DR) basic configuration has been undertaken. The basic configuration of Teams Direct Routing is documented in the Azure-related best practice. Please ensure all instructions are executed as documented in the following sections of that best practice:

1. • Configuration Prerequisites

   • Configure Azure for Microsoft Teams Direct Routing
   • Run Easy Configuration Wizard for Microsoft Teams Direct Routing
   • Complete SBC SWe Edge Configuration for Microsoft Teams Direct Routing in Azure
   • Place a Test Call.
4. Networking device updates have been applied to permit Azure-based  SBC Edge Portfolio  ↔ enterprise premises-based Yealink client device communication.  The SBC Edge Portfolio and the Yealink clients that will attempt to register will likely communicate across the Internet; as such, the following devices/constructs must be configured to ensure successful communication between the parties:

1. • Any enterprise premises-based routers undertaking LAN ↔ WAN addressing conversions, such as those related to NAT;

   • Any enterprise premises-based firewalls undertaking network traffic filtering actions.

   • The Azure-based virtual network and VM (virtual machine) hosting the SBC SWe Edge, especially the network security group (NSG) security rules.

     Contact Enterprise IT to Facilitate IP-based Communications

     Please contact your IT administrator to ensure communication can be undertaken between the network segments hosting the Yealink Teams client devices and the SBC Edge Portfolio hosted in the Azure cloud. The IT administrator should be knowledgeable regarding the private & public IP addresses assigned to all devices, along with the required routing to achieve inter-device communications.

     Azure Virtual Networking Supplementary Information

     Refer to the following sources of information for basic Azure virtual networking concepts, features and deployment:

     • Azure Products
     • Azure networking
       • Internet Connectivity
       • On-premises connectivity
     • Virtual Network Documentation
     • Security groups
     • Tutorial: Route network traffic with a route table using the Azure portal
     • Tutorial: Filter network traffic with a network security group using the Azure portal
     • Diagnose a virtual machine network traffic filter problem

After you complete the steps above, the SBC SWe Edge in Azure is ready for further configuration for Yealink Teams Client Local Survivability.

Configuration Instructions

SBC Edge Portfolio Configuration to Accept Yealink Devices Registration and Undertake Teams Client-Related Survivability Routing

Introduction

The following instructions detail how to configure the Ribbon SBC to accept Yealink Teams client device registrations and to route calls properly between the devices and the PSTN. Please note the following context prior to the configuration being undertaken:

1. Create a new SIP Local Registrar instance to which the Yealink devices register via SIP, including client registration authentication and potentially a new TLS Profile ID; 

2. Create new call routing for use whenever a Yealink device needs to place calls via the SBC. 

   1. Create a new Call Routing Table instance.

   2. Create two new Transformation Table instances (one for intra-office calling and one for PSTN access), each with an entry to pass the user-dialed digits through for routing purposes;

   3. Specify two new call routing entries to identify the final instructions for intra-office and PSTN routing for a Yealink device-originated call.

      Intra-Office and PSTN Routing Clarifications

      ● A specific call route entry is required to be configured for intra-office calling between one Yealink device and another Yealink device registered with the same SIP Local Registrar instance.

      ●  The PSTN-related signaling group will already have been created through the Easy Configuration wizard, which is undertaken as a prerequisite for the SBC setup.

3. Create a new Signaling Group instance that will be associated with the new local registrar instance you just created;

4. Update the pre-existing Call Routing Table instance (associated with the incoming PSTN trunk) to include updated routing for call processing that uses the newly created Signaling Group instance when the Phone System is unavailable:

   1. Create a new Transformation Table instance and entries to modify the incoming dialed digits received from the PSTN for local routing to the newly created SIP local registrar instance.

   2. Specify a new call routing entry to identify the final instructions for routing to an SBC-subtended Yealink device.

      Pre-Existing Call Route Table Instance Clarifications

      • The pre-existing Call Routing Table instance associated with the incoming PSTN trunk was initially created through the use of the Easy Configuration wizard template undertaken in the prerequisites of the SBC setup. This Call Routing Table instance already has a routing entry to support the routing of an incoming call to the Phone System. Refer to Using the Easy Configuration Wizard.
      • The soon-to-be-added new routing entry will be prioritized below the Teams-related call routing entry; this new routing entry will only be referenced in the event the Phone System is unavailable (i.e., the Yealink Teams Client Local Survivability scenario ).
5. Confirm the new Signaling Group instance associated with the new SIP Local Registrar instance is active.

Example SBC Network Diagram

To aid in the comprehension of the subsequent configuration instructions, please refer to the example network presenting pre-existing attribute values and device identifiers, along with soon-to-be-added (identified in green italic font) attributes and values. Note select values (denoted with an X) are redacted for privacy purposes.

Sample Configuration Attribute Values for Example SBC Network Topology

SBC Configuration

1. Access the WebUI, and click the Settings tab.

   1. In the left navigation page, access SIP > Local Registrars Table.

      1. Click the (Plus icon) to add a row.

      2. In the Create SIP Local Registrar dialog box, type the desired identifier name and maximum number of registering clients for your new SIP local registrar instance. For our example deployment, the entered name is LocalReg.

         Registrar Provisioning Reference Information

         For details on SIP local registrar configuration, refer to Creating and Modifying SIP Local Registrars.

      3. Click OK.

         

   2. In the left navigation page, access SIP > Local/Pass-thru Auth Tables

      1. Click the (Plus icon) to add a local pass-through authorization table.
         

      2. In the Description dialog box, type the desired Local Pass-through Authorization Table  name. For our example deployment, the name specified is Local registration table .

      3. Click OK.

         

         
         

         Local Pass-through Authorization Tables Provisioning Reference Information

         For details on the configuration of Local Pass-through Authorization Tables, refer to Managing Local Pass-through Authorization Tables.

      4. In the left navigation page, access SIP > Local/Pass-thru Auth Tables, and select (click) the new Local Pass-through Authorization Table just created. For example, in deployment, the entered name is the Local registration table. The table displays under the tabs, with the note:   --  Table is empty --

         1. Click the Create Local Pass-through Authorization Entry (Plus icon)

         2. Specify the following values for fields:

            Local Pass-through Authorization Entry Attributes

            Field	Required Entry
            Type of Address of Record	Local, to signify the SBC is the registrant of record.
            Address of Record URI	Specify the acceptable Address of Record (AOR) URI from a potentially valid registering endpoint. In the example deployment, one such AOR URI is  sip:30001.
            User Name	Specify the acceptable user name from the registering endpoint. In the example deployment, one acceptable User Name is 30001.
            Enter Password	Specify the password the registering endpoint must submit for successful registration.
            Confirm Password	Type the same password as entered above for confirmation.

            
            
            Local Pass-through Authorization Table Entries Provisioning Reference Information

            For details on Local Pass-through Authorization Table Entry configuration, refer to Creating and Modifying Entries to Local Pass-through Authorization Tables.

         3. Click OK.

            

         4. Repeat steps 1, 2, and 3 for each remaining possible valid registering endpoints. In the example deployment, steps 2 and 3 are repeated for Yealink device 30003.
            Use of Local Pass-through Authorization Table is Strongly Recommended

            Ribbon and Yealink strongly recommend the use of the optional Local Passthrough Authorization Table, especially for Azure-based SBC deployments. The use of the Local Passthrough Authorization Table deters unauthorized users from fraudulently using your enterprise's SIP trunking services.

      5. Optional Step for encrypted SIP signaling: Create the  TLS profile to define the cryptographic parameters for the SIP signaling between the subtended Yealink devices and the SBC.

         1. In the WebUI, click the Settings tab.

         2. In the left navigation pane, go to Security > TLS Profiles.

         3. Click the CreateTLS Profile (Plus icon) at the top of the TLS Profile page.

         4. Configure the parameters shown below. Leave all other parameters as default.

            New TLS Profile Entry Attributes for Registered Yealink SIP Clients ↔ SBC Communication

            Field	Required Entry
            Description	Specify a descriptive name for the entry. A sample name may be Yealink SIP Client SBC Signaling.
            TLS Protocol	Set the administrative state to TLS 1.0 - 1.2.
            Mutual Authentication	Specify the authentication as Disabled.
            Client Cipher List	Select a cipher value (this value must be supported by the subtended registered Yealink clients). See above for guidelines. Ribbon recommends TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384.
            Validate Server FQDN	Specify the validation as Disabled.
            All other fields	Please leave all default values as-is for basic SIP signaling encryption purposes.

         5. Click OK, and confirm the presence of the new TLS Profile entry. 

            Use of Signaling and Media Encryption Strongly Recommended for Azure-based SBC Deployments

            While optional, Ribbon Communications and Yealink strongly recommend the use of TLS and SRTP for secure encrypted communication between the Yealink devices and the SBC, especially when the latter is deployed in the Azure public cloud. For more information, please refer above.

            TLS Profile Provisioning Reference Information

            For more information about creating new TLS Profile entries, refer to Managing TLS Profiles.

2. To access the WebUI, click the Settings tab.

   1. In the left navigation pane, go to Call Routing > Call Routing Table. 

      1. Click the (Plus icon).

      2. Enter a descriptive name in the Description text field; for this deployment example, the value is From Local SIP EP.

      3. Click OK.

         

         
         

         Call Routing Table Provisioning Reference Information

         For more information about creating call routing tables, refer to Managing Call Routing Tables.

   2. In the WebUI, click the Settings tab.

      1. In the left navigation pane, go to Call Routing > Transformation.

      2. Click the Create (Plus icon).

      3. In the Description dialog box, enter the desired Transformation Table name identifier for calling the PSTN. For our example deployment, the entered name is from SIP to IMS.

      4. Click OK.

         

         Transformation Table Provisioning Reference Information

         For details on Transformation Table configuration, refer to Managing Transformation Tables.

      5. In the left navigation page, go to Transformation, and select (click) the new Transformation Table just created. For example, in deployment, the entered name is from SIP to IMS. The table displays under the tabs, with the note:  --  Table is empty --

         1. Click the Create (Plus icon).

         2. Type or select the following values to specify the passthrough of dialed digits from the subtended registered Yealink Survivability (SIP) client to the PSTN:

            New Transformation Table Entry Attributes for Registered SIP Clients to Reach the PSTN

            Field	Required Entry
            Description	Specify a descriptive name for the entry. In the example deployment, the entered name is  SIP to PSTN .
            Admin State	Set the administrative state to Enabled.
            Type (Input Field)	Specify the type for input as Called Address/Number.
            Value (Input Field)	Specify an asterisk (.*) to indicate acceptance of any digits.
            Type (Output Field)	Specify the type for output as Called Address/Number.
            Value (Output Field)	Specify the value of output as \1 to indicate that digits received will be passed through to the outbound route without any change made.

            
            
            Transformation Table Entries and Digit Manipulation Provisioning Reference Information

            For details on Transformation Table Entry configuration, refer to Creating and Modifying Entries to Transformation Tables. For call digit matching and manipulation through the use of regular expressions, please reference Creating Call Routing Logic with Regular Expressions.

         3. Click OK.

            
   3. In the WebUI, click the Settings tab.

      1. In the left navigation pane, go to Call Routing > Transformation.

      2. Click the  Create (Plus icon).

      3. In the  Description dialog box, enter the desired Transformation Table name identifier for intra-office calling. For our example deployment, the entered name is from SIP to SIP.

      4. Click OK.

         

         Transformation Table Provisioning Reference Information

         For details on Transformation Table configuration, refer to  Managing Transformation Tables.

      5. In the left navigation page, go to Transformation, and select (click) the new Transformation Table just created for intra-office calling. In example deployment, the entered name is from SIP to SIP . The table will appear under the tabs, with a note stating  – Table is empty --

         1. Click the Create (Plus icon).

         2. Enter or select the following values into the pop-up window to specify the pass-through of dialed digits from the subtended registered Yealink Survivability (SIP) client to another subtended registered Yealink Survivability (SIP) client.

            Transformation Table Entry Attributes for Intra-Office Calling

            Field	Required Entry
            Description	Please use a descriptive name for the entry. In the example deployment, the entered name is  SIP to SIP .
            Admin State	Enabled
            Type (Input Field)	Called Address/Number
            Value (Input Field)	Please enter a regular expression to confirm a private dial plan number that conforms to the private dial plan assigned to the registered SIP clients. In the example deployment, the entered expression is ^(3\d{4})$, signifying the called digits must be 5 characters in length, and must start with a 3.
            Type (Output Field)	Called Address/Number
            Value (Output Field)	\1 , signifying matching digits received will be passed through to the outbound route without change.

            
            
            Transformation Table Entries and Digit Manipulation Provisioning Reference Information

            For details on Transformation Table Entry configuration, refer to Creating and Modifying Entries to Transformation Tables. For call digit matching and manipulation through the use of regular expressions, please reference Creating Call Routing Logic with Regular Expressions.

         3. Click OK.

            

   4. In the WebUI, click the Settings tab.

      1. In the left navigation pane, go to Call Routing > Call Routing Table and select the newly created Call Routing Table; for our example deployment, the newly created table is From Local SIP EP. 

         1. Click the  Create Routing Entry (Plus icon) to create the route for calling into the PSTN.

            1. Enter the following values into the pop-up window:

               Call Routing Entry Attributes for Calling from Registered Yealink Devices to the PSTN

               Field	Required Entry
               Description	Enter an informative name in the text field; for our example deployment, the value is  to IMS
               Admin State	Select Enabled
               Number/Name Transformation Table	Select the newly created Transformation Table instance to which calls from a subtended registered Yealink device will be routed to the PSTN. For the example deployment, the value is  from SIP to IMS .
               Destination Type	Select Normal
               Destination Signaling Groups	Select the PSTN-related Signaling Group. For the example deployment, the value is  IMS
               All other fields	Please leave all default values as-is for basic configuration purposes.

               
               
               Call Routing Table Entry Provisioning Reference Information

               For details on call routing table entry configuration, including modification of fields with default values, refer to Creating and Modifying Entries to Call Routing Tables.

            2. Click OK.

               

         2. Click the Create Routing Entry (Plus icon) once again to create the route entry for intra-office calling.

            1. Type or choose the following values:

               Call Routing Entry Attributes for Calling from Registered Yealink Devices to Other Registered Yealink Devices

               Field	Required Entry
               Description	Type a descriptive name in the text field; for the example deployment, the value is  SIP TO SIP.
               Admin State	Select Enabled.
               Number/Name Transformation Table	Select the newly created Transformation Table instance to which calls from a subtended registered Yealink device will be routed when attempting to reach another subtended registered Yealink device. For the example deployment, the value is from SIP to SIP.
               Destination Type	Select Registrar Table.
               Destination Signaling Groups	Select the newly created SIP Local Registrar-related Signaling Group to which the subtended registered Yealink devices are associated. For the example deployment, the value is LocalReg.
               All other fields	Leave all other default values as-is for basic configuration purposes.

            2. Click OK.

               

      2. Review and confirm the two new Call Routing Table entries in the newly created Call Routing Table.

         

3. Access the WebUI, click the  Settings tab.

   1. In the left navigation pane, go to Signaling Groups.

   2. From the top menu bar, click Create Signaling Group and select SIP Signaling Group (note: for the SBC SWe Edge, select Add SIP SG)

   3. Create the SIP Signaling Group using the following configuration:

      SIP Signaling Group Attribute Values for Registered Yealink Devices

      Field	Required Entry
      Description	Enter an informative name in the Description text field; for the example deployment, the value is  LocalReg.
      Admin State	Select Enabled.
      Call Routing Table	Select the recently created Call Routing Table Instance that will define routing for calls that originate from the subtended registered Yealink devices. For the example deployment, the value is from Local SIP EP.
      SIP Mode	Select the Local Registrar value.
      Registrar	Select the recently created SIP Local Registrar instance to which subtended Yealink devices will advertise their presence. For the example deployment, the value is LocalReg.
      Challenge Request	Select Enable
      Local/Pass-thru Auth Table	Select the recently created Local Pass-through Authorization Table that defines the credentials the subtended Yealink devices must present to the SBC to be successfully recognized (registered). For the example deployment, the value is the Local registration table.
      Media List ID (Optional Step for encrypted media)	If you specified a new  TLS Profile ID, please select the Media List ID value associated with the Phone System Signaling Group for SRTP communication with the registered subtended Yealink client devices. The value to be selected should be  MS Teams Media List, originally created through the use of the Teams DR-related easy configuration wizard during the SBC setup. The contains SRTP cryptographic settings that can be used for SBC Edge Portfolio ↔ subtended registered Yealink client device encrypted media exchange. NOTE: For details on Media List-ID configuration, including the setup of attributes related to media encryption, please refer to Managing Media Lists and Managing SDES-SRTP Profiles.
      Listen Port	Click the (Plus icon) to create a new instance of the SIP Listen Port, and update as follows: Option 1: For unencrypted SBC Edge Portfolio  ↔ subtended registered Yealink client device communication, please enter the Port value as 5060, the Protocol value as UDP, and the TLS Profile ID as N/A. Option 2: For encrypted  ↔ subtended registered Yealink client device communication (you must have specified a new TLS Profile ID entry earlier), please enter the Port value as 5061, the Protocol value as TLS, and the TLS Profile ID as the new entry created earlier (e.g. Yealink SIP Client SBC Signaling ) .
      Federated IP/FQDN	Click the (Plus icon) to create a new instance of the Federated IP/FQDN, and specify as follows to identify the networking IP addresses of your Yealink Teams client devices, supplied by the enterprise IT administrator. For our example deployment, the IP/FQDN is entered as XXX .0.0.0, with the Netmask/Prefix as 255.0.0.0, meaning the signaling group will accept communication with any host (i.e. Yealink device) that presents a host IP of anywhere from XXX.0.0.1 → XXX.255.255.254
      All other fields	Please leave all default values as-is for basic configuration purposes.

      
      
      Signaling Group Provisioning Reference Information

      For details on Signaling Group configuration attributes described above, including modification of fields with default values, refer to Creating and Modifying SIP Signaling Groups.

   4. Click OK. The new SIP Signaling Group (in the example deployment, named LocalReg) may be expanded to present the following sample attributes.

      

4. In the WebUI, click the Settings tab.

   1. In the left navigation pane, Call Routing -> Transformation.

      1. Click the Create (Plus icon).

      2. In the Description dialog box, enter the desired Transformation Table name identifier for calls received from the PSTN and destined for a subtended Yealink device. For our example deployment, the entered name is from IMS to SIP.

      3. Click OK.

         

         
         

         Transformation Table Provisioning Reference Information

         For details on Transformation Table configuration, refer to Managing Transformation Tables.

      4. In the left navigation page, go to Transformation, and select (click) the new Transformation Table just created. For example, in deployment, the entered name is from IMS to SIP. The table will appear under the tabs, with a note stating  – Table is empty --

         1. Click the Create (Plus icon).

         2. Enter or select the following values into the pop-up window, to specify the modification of dialed digits from the PSTN to reach a subtended registered Yealink Survivability (SIP) client:

            New Transformation Table Entry Attributes for a PSTN Call to Reach a Specific Registered Yealink Device

            Field	Required Entry
            Description	Please use a descriptive name for the entry. In the example deployment, the entered name is Entry ID 1.
            Admin State	Enabled
            Type (Input Field)	Called Address/Number
            Value (Input Field)	Please enter a regular expression to define the Teams Phone Number assigned to the Yealink device with the survivability. In the example deployment, the entered expression is \+86XXXX604392, the Teams Phone Number assigned to the Yealink device that also carries the SIP phone number 30001 (later used in the Survivability UI).
            Type (Output Field)	Called Address/Number
            Value (Output Field)	Enter a regular expression to replace the Teams Phone Number dialed by the PSTN user with the SIP phone number assigned to the Yealink device with the survivability. In the example deployment, the entered expression is 30001, the Teams Phone Number assigned to the Yealink device that also carries the Teams Phone Number +86XXXX604392 (latter used in the Teams client UI).

            
            
            Transformation Table Entries and Digit Manipulation Provisioning Reference Information

            For details on Transformation Table Entry configuration, refer to Creating and Modifying Entries to Transformation Tables. For call digit matching and manipulation through the use of regular expressions, please reference Creating Call Routing Logic with Regular Expressions.

         3. Click OK.

            

         4. Repeat steps 1, 2 & 3  for each remaining possible registered  Yealink device with both the Teams client and the Survivability (SIP) client. In the example deployment, steps 1, 2, and 3 are repeated for the Yealink device with the SIP phone number 30003.

            

   2. In the left navigation pane, go to Call Routing > Call Routing Table and select the Call Routing Table originally created through the use of the Easy Configuration wizard (refer to Using the Easy Configuration Wizard) template for processing calls originating from the PSTN. For our example deployment, the table requiring the new entry is From IMS .

      1. Click the Create Routing Entry (Plus icon).

      2. Enter the following values into the pop-up window:

         Key Call Routing Entry Attribute Values That Must be Explicitly Submitted by User

         Field	Required Entry
         Description	Enter an informative name in the text field; for our example deployment, the value is from IMS TO SIP.
         Admin State	Select Enabled
         Number/Name Transformation Table	Select the newly created Transformation Table instance to which calls from the PSTN will be routed during survivability scenarios (i.e., when the Phone System is unavailable). For the example deployment, the value is  from IMS to SIP.
         Destination Type	Select Registrar Table
         Destination Signaling Groups	Select the newly created SIP Local Registrar-related Signaling Group to which the subtended Yealink devices are associated. For the example deployment, the value is LocalReg.
         All other fields	Leave all default values as-is for basic configuration purposes.

         
         Call Routing Table Entry Provisioning Reference Information

         For details on call routing table entry configuration, including modification of fields with default values, refer to Creating and Modifying Entries to Call Routing Tables.

      3. Click OK and review the new Call Routing Table Entry related to survivability in the updated PSTN-related Call Routing Table from the left navigation pane.

         

5. Access the WebUI, click the Monitor  tab. Confirm the new SIP Signaling Group instance associated with the new SIP Local Registrar instance is active. For our example deployment, the new SIP Signaling Group instance is LocalReg .

   

Update Yealink Teams Client Devices to Register with the SBC Edge Portfolio for Survivability

Prerequisites

This section assumes the following actions are complete:

1. Yealink client device prerequisites for Phone System Integration;
2. SBC Edge Portfolio Teams DR prerequisites and configuration.

Yealink Teams Client Device Configuration Commands

CLI (Command Line Interface) Instructions

The following general (i.e. not sample) CLI commands may be submitted via the Yealink client devices UI to enable registration with the SBC for Teams client survivability services. 

features.hybrid_mode.enable=1
account.X.sip_server.1.address = <SBC IP Address>
account.X.user_name = <Username>
account.X.password = <Password>     [X ranges from 1 to 16]
features.hybrid_mode.quick_ball.enable=1     [This item is optional]

Sample commands (based on our example deployment) will appear as follows:

features.hybrid_mode.enable=1
account.1.sip_server.1.address = XX.1.10.127
account.1.user_name = 30001
account.1.password = XXXXX
features.hybrid_mode.quick_ball.enable=1  

.cfg (Configuration) File Instructions

The user also has the option to submit instructions via a configuration file (*.cfg) to enable registration with the SBC for Teams client survivability services. To undertake such an operation, please refer to Yealink Teams client reference material. 

Proceed to Testing.

Testing Yealink Teams Client Local Survivability

Summary

Five key tests are required to confirm the Yealink Teams client devices can successfully offer users survivability services in the event that the Phone System is unavailable while defaulting to Teams-related services when the Phone System is available. 

1. Successful registration with the SBC via SIP;
2. Successful call placed from the Yealink device to the PSTN via the SBC, without Phone System participation;
3. Successful call placed from the Yealink device to another Yealink device via the SBC;
4. Successful call placed from the Yealink device to the PSTN via Phone System;
5. Successful call from the PSTN routed to the correct Yealink device via the SBC, when the Phone System is unavailable;
6. Successful call from the PSTN routed to the correct Yealink device when the Phone System is available.

Confirm Yealink Teams Client Devices Registration with SBC Edge Portfolio

Yealink Device Confirmation

Confirm the phone icons in the device's Survivability (SIP) UI are green, signifying successful registration and availability with a remote SIP server (in this case, the SBC's SIP Local Registrar). Note the 30001 phone number assigned to the Yealink device.

Yealink Device Survivability (SIP) UI with Green Phone Icons

SBC Confirmation

Access the WebUI, click the Settings tab.

1. In the left navigation page, access SIP > Local Registrars Table.

2. Confirm the SIP Local Registrar instance created to support survivability appears in the main body of the WebUI. For our example deployment, the SIP Local Registrar instance is identified as LocalReg.

3. From the SIP Local Registrar instance presented in Step 2, click Registered Users. 

   

4. Confirm the presence of the Yealink device. For the example deployment, the correct user name (phone number) is 30001 and is clearly visible in the first row of the table.

   SIP Local Registrar Registered Users Reference Information

   For details surrounding the information available on the registered users, refer to Managing SIP Local Registrars.

Confirm Yealink Device Calling to the PSTN via SBC Edge Portfolio

Place Call from Yealink Device Survivability UI into PSTN

Confirm Yealink Teams Client Devices Calling the PSTN via SBC Edge Portfolio

Place Call from Yealink Device Teams UI into PSTN

Confirm Survivability Operation when the Phone System is Unavailable

Disable the Teams Phone System Signaling Group From SBC

  Access the WebUI by clicking the Settings tab.

1. In the left navigation pane, go to Signaling Groups

2. From the main display, select the check box next to the Teams Phone System-related signaling group (for our example deployment, the Microsoft Teams signaling group) and click the Out of Service icon.

3. Confirm that the Phone System-related signaling group is out of service, through the Down indication in the Service Status field. 

   

   
   

   SIP Signaling Group Operations Reference Information

   Refer to Creating and Modifying SIP Signaling Groups for details on SIP Signaling Group operation, including enablement and disablement.

Place Call from PSTN to Yealink Device

Place a call from PSTN to the Yealink device and confirm call alerting on the Yealink device's Survivability UI and the SBC's WebUI.

Confirm Teams Calling when Phone System is Available

Enable the Phone System Signaling Group From SBC

 Access the WebUI, click the Settings tab.

1. In the left navigation pane, go to Signaling Groups

2. From the main display, select the check box next to the Phone System-related signaling group (for our example deployment, the  Microsoft Teams signaling group) and click the Enable ( ) icon.

3. Confirm the Phone System-related signaling group is active, through the Up indication in the Service Status field. 
   
   

Place Call from PSTN to Yealink Device and Confirm Two-Way Audio

Confirm Call Completion via Phone System From SBC

Access the WebUI, and then click the  Monitor  tab. 

1. Expand the three signaling groups (that pertain to the survivability scenario) so all channels become visible. For our example deployment, the three signaling group identifiers are LocalReg (the signaling group to which the Yealink devices are registered),  IMS (the PSTN-related signaling group), and Microsoft Teams.

2. Review the channel states for each signaling group, and confirm the correct operation:

   1. One channel is seized ( blue ) in the PSTN-related signaling group (for our example deployment, the IMS signaling group).  Double-click the seized channel to ensure consistency between the channel details and the call placed from the Yealink device (e.g., call direction is incoming, the called party number has the same phone number as the Yealink device, the calling party number is the PSTN number from which you made the call, etc.).

   2. One channel is seized ( blue ) in the Phone System-related signaling group (for our example deployment, the Microsoft Teams signaling group).  Double-click the seized channel to ensure consistency between the channel details and the call placed from the Yealink device.

   3. All channels remain idle ( light green ) in the SIP local registrar-related signaling group (for our example deployment, the   LocalReg  signaling group). 

      

Success

If all test cases are successfully completed, Teams client survivability is correctly provisioned and operational. If any test cases fail, please revisit all prerequisites and provisioning.