In this section:
Ribbon Communications recommends embedded URLs be accessed in a separate browser window/tab. To open embedded URLs in a separate window/tab, Ctrl+Left-click or Right-click with your mouse and select Open Link in New Tab/Open Link in New Window.
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.
The benefits of voice service survivability between enterprise sites hosting Yealink Teams voice-related clients and Phone System hosted in the Azure cloud include the following:
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.
The following Yealink Teams clients collaborate with the Ribbon Communications SBC Edge to support survivability:
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.
The firmware version required to support survivability in a Teams context is:
For product documentation that details the configuration and operation of the Teams clients, visit support.yealink.com
The following SBC Edge offerings support Yealink Teams Client Local Survivability:
The SBC Edge firmware versions required to support Teams client survivability are Release 8.0.1 for the SBC SWe Lite and Release 8.0.1 for the SBC 1000/SBC 2000. Using earlier firmware versions is not supported and may result in conflicts and unexpected behavior.
Contact an authorized Ribbon Communications sales representative or partner to obtain the appropriate firmware release.
The survivability capabilities available to Teams clients vary based on the accessibility of Phone System and the deployment type (on-premises or Azure).
When the Phone System is accessible, the Yealink Teams and SBC Edge operate as designed for the integrated solution.
When the SBC Edge is deployed on-premises, operation with the Yealink Teams clients is as follows with the Phone System accessible:
When the the SBC SWe Lite is deployed in Azure, operation with the Yealink Teams clients is as follows with Phone System accessible:
Operation of the Yealink Teams clients and the SBC Edge (deployed on-premises) when the Phone System is not available (e.g. WAN outage, etc.) is characterized by:
Operation of the Yealink Teams clients and the SBC Edge (deployed in Azure) when the Phone System is not available is characterized by:
Please note that a WAN outage has the potential to sever the connection not only between the on-premises Yealink Teams clients and Phone System, but also the connection between the on-premises Yealink Teams clients and the SBC SWe Lite found in Azure. Please consider the location of the SBC (on-premises vs. Azure-based) carefully to ensure business availability requirements are properly addressed.
To place outgoing calls using the SBC Edge instead of using the Phone System ( for example, if 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.
The Yealink client device does not present the user with an indication that Phone System is unavailable to process a call establishment request from the Teams Client UI. If the user observes a condition that suggests Phone System is unavailable (e.g. a timeout on a call attempt, etc.):
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 in the latter). The user simply needs to answer the incoming call to engage in the call.
When call routing is configured appropriately post-deployment, the SBC Edge automatically offers survivability services with no additional intervention.
Yealink Teams client-supporting devices (phones, etc.) must fulfill the following prerequisites prior to undertaking further actions:
As an option, Yealink devices may be configured to communicate with the SBC Edge using TLS (Transport Layer Security, used for SIP signaling encryption) and SRTP (Secure Real-time Transport Protocol, used for media encryption).
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.
Assuming the conditions are fulfilled, the Yealink devices are ready for Teams-related survivability configuration, and should be updated only after the SBC Edge prerequisites and configuration are complete.
Refer to the following sources of information for basic Microsoft Phone System features and deployment:
In all cases, the SBC Edge 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.
For SBC Edge devices deployed on-premises, confirm the following:
Initial setup is complete.
SBC SWe Lite on-premise deployment initial steps
The SBC SWe Lite initial setup instructions include content related to feature licensing, trials, and easy configuration. Note the following:
You can choose to undertake feature licensing under the initial setup instructions, please ensure the minimum licensing requirements listed in step 2 are addressed;
You can choose to configure the SBC SWe Lite 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;
Please do not undertake any Easy Configuration Wizard actions at this time; the easy configuration actions in a Teams-related deployment has additional considerations, as defined in step 3
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 1000 and SBC 2000 SIP session licenses;
SBC SWe Lite licenses for on-premises deployments.
For instructions on how to obtain and apply licenses, refer to Working with Licenses.
Any intervening routers undertaking LAN ↔ WAN addressing conversions, such as those related to NAT;
Any intervening firewalls undertaking network traffic filtering actions.
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. 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 device is ready for further configuration for Yealink Teams Client Local Survivability.
For an SBC SWe Lite deployed in Azure, confirm the following:
Initial setup is complete per the instructions applicable for an Azure deployment.
The SBC SWe Lite initial setup instructions include content related to feature licensing, trials, and easy configuration. Note the following:
You can choose to undertake feature licensing under the initial setup instructions, please ensure the minimum licensing requirements listed in step 2 are addressed.
You can choose to configure the SBC SWe Lite 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.
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 Lite to an IP-based client (e.g. a SIP trunk, a SIP-based IP PBX, etc.)
For instructions on how to obtain and apply licenses, refer to Working with Licenses.
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 Lite, especially the network security group (NSG) security rules.
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 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.
Refer to the following sources of information for basic Azure virtual networking concepts, features and deployment:
After you complete the steps above, the SBC SWe Lite in Azure is ready for further configuration for Yealink Teams Client Local Survivability.
The following instructions detail how to configure the Ribbon SBC to accept Yealink Teams client devices registrations and to route calls properly between the devices and the PSTN. Please note the following context prior to the configuration being undertaken:
Create new call routing for use whenever a Yealink device needs to place calls via the SBC.
Create a new Call Routing Table instance.
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;
Specify two new call routing entries to identify the final instructions for intra-office and PSTN routing for a Yealink device-originated call.
● 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 undertaken in the prerequisites of the SBC setup.
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 Phone System is unavailable:
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.
Specify a new call routing entry to identify the final instructions for routing to an SBC-subtended Yealink device.
● 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 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 ).
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.
In the left navigation page, access SIP > Local Registrars Table.
Click
to add a row.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.
For details on SIP local registrar configuration, refer to Creating and Modifying SIP Local Registrars.
Click OK.
In the left navigation page, access SIP > Local/Pass-thru Auth Tables
Click () to add a local pass-through authorization table.
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.
Click OK.
For details on Local Pass-through Authorization Tables configuration, refer to Managing Local Pass-through Authorization Tables.
In the left navigation page, access SIP > Local/Pass-thru Auth Tables, and select (click) the new Local Pass-through Authorization Table just created. In example deployment, the entered name is Local registration table. The table displays under the tabs, with the note: -- Table is empty --
Click the Create Local Pass-through Authorization Entry ( ) icon
Specify the following values for fields:
For details on Local Pass-through Authorization Table Entry configuration, refer to Creating and Modifying Entries to Local Pass-through Authorization Tables.
Click OK.
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 the fraudulent use of your enterprise's SIP trunking services by unauthorized users.
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.
In the left navigation pane, go to Security > TLS Profiles.
Configure the parameters shown below. Leave all other parameters as default.
Click OK, and confirm the presence of the new TLS Profile entry.
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.
For more information about creating new TLS Profile entries, refer to Managing TLS Profiles.
Access the WebUI, click the Settings tab.
In the left navigation pane, go to Call Routing > Call Routing Table.
Click ().
Enter a descriptive name in the Description text field; for this deployment example, the value is From Local SIP EP
Click OK.
For more information about creating call routing tables, refer to Managing Call Routing Tables.
In the left navigation pane, go to Call Routing -> Transformation .
Click the Create (
) icon.In the Description dialog box, enter the desired Transformation Table name identifier for calling to the PSTN. For our example deployment, the entered name is from SIP to IMS.
Click OK .
For details on Transformation Table configuration, refer to Managing Transformation Tables.
Click the Create ( ) icon
Type or select the following values to specify the passthrough of dialed digits from the subtended registered Yealink Survivability (SIP) client to the PSTN:
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.
Click OK .
In the left navigation pane, go to Call Routing > Transformation.
Click the Create ( ) icon.
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.
Click OK.
For details on Transformation Table configuration, refer to Managing Transformation Tables.
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 --
Click the Create ( ) icon
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.
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.
Click OK .
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.
Click the Create Routing Entry ( ) icon to create the route for calling into the PSTN.
Enter the following values into the pop-up window:
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.
Click OK .
Click the Create Routing Entry (
) icon once again to create the route entry for intra-office calling.Type or choose the following values:
Click OK.
Review and confirm the two new Call Routing Table entries in the newly created Call Routing Table.
Access the WebUI, click the Settings tab.
In the left navigation pane, go to Signaling Groups.
From the top menu bar, click Create Signaling Group and select SIP Signaling Group (note: for the SBC SWe Lite, select Add SIP SG )
Create the SIP Signaling Group using the following configuration:
For details on Signaling Group configuration attributes described above including modification of fields with default values, refer to Creating and Modifying SIP Signaling Groups.
Click OK . The new SIP Signaling Group (in the example deployment, named LocalReg ) may be expanded to present the following sample attributes.
In the WebUI, click the Settings tab.
In the left navigation pane, Call Routing -> Transformation .
Click the Create ( ) icon.
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.
Click OK .
For details on Transformation Table configuration, refer to Managing Transformation Tables.
In the left navigation page, go to Transformation, and select (click) the new Transformation Table just created. In example deployment, the entered name is from IMS to SIP. The table will appear under the tabs, with a note stating – Table is empty --
Click the Create ( ) icon
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:
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.
Click OK.
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.
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 .
Click the Create Routing Entry (
) icon.Enter the following values into the pop-up window:
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.
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.
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.
This section assumes the following actions are complete:
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
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.
The configuration commands (whether via a configuration file or the CLI) must be repeated with each Yealink client device that is to register with the SBC Edge.
Product manuals that describe the configuration and operation of the Teams clients may be found at support.yealink.com
Five key tests are required to confirm the Yealink Teams client devices can successfully offer users survivability services in the event that Phone System is unavailable, while defaulting to Teams-related services when Phone System is available.
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.
Access the WebUI, click the Settings tab.
In the left navigation page, access SIP > Local Registrars Table.
Confirm the SIP Local Registrar instance created to support survivability appears in the main body of the WebUI. For our example deployment, the the SIP Local Registrar instance is identified as LocalReg.
From the SIP Local Registrar instance presented in step 2, click Registered Users.
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.
For details surrounding the information available on the registered users, refer to Managing SIP Local Registrars.
Access a Yealink device's Survivability (SIP) UI. In the example deployment, one such device is the 30001 client.
Place a call from the UI to the PSTN, and confirm two-way audio. Note the following indicators in the UI:
The green handset icon indicating a live call;
The Talking text indicating a live audio path.
Access the WebUI, and click the Monitor tab.
Expand the three signaling groups (that pertain to the survivability scenario) so all channels become visible. For our example deployment, the three signaling groups identifiers are LocalReg (the signaling group to which the Yealink devices are registered), IMS (the PSTN-related signaling group), and Microsoft Teams.
Review the channel states for each signaling group, and confirm correct operation:
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 outgoing, call originator has the same phone number as the Yealink device, called party number is the dialed PSTN number, etc.).
One channel is seized (blue) in the SIP local registrar-related signaling group (for our example deployment, the LocalReg signaling group). Double-click the seized channel to ensure consistency between the channel details and the call placed from the Yealink device.
All channels remain idle (light green) in Phone System-related signaling group (for our example deployment, the Microsoft Teams signaling group).
For details surrounding the information available in the monitor related to signaling groups, refer to Monitoring Real Time Status . Note pop-ups must be enabled in your Internet browser to allow channel details to be presented.
Access one SBC subtended Yealink device's Survivability (SIP) UI. In the example deployment, one such device is the 30001 client.
Place a call from the Survivability (SIP) UI to a second Yealink device, using the SIP phone number to the second Yealink device. For the example deployment, the SIP phone number assigned to the second Yealink device is 30003.
Please dial from first Yealink device the SIP phone number associated with the second Yealink device, as opposed to the phone number associated with the Teams (SIP) client. By using the SIP phone number, the test confirms that the transformation and routing table entries associated with the SIP local registrar-related signaling group (for our example deployment, the LocalReg signaling group) have been correctly provisioned for intra-office dialing when Phone System is unavailable.
Answer the call from the Survivability (SIP) UI on the second Yealink device, and confirm two-way audio. Note the following indicators in the UI:
The green handset icon indicating a live call;
The Talking text indicating a live audio path.
Access the WebUI, and click the Monitor tab.
Expand the three signaling groups (that pertain to the survivability scenario) so all channels become visible. For our example deployment, the three signaling groups identifiers are LocalReg (the signaling group to which the Yealink devices are registered), IMS (the PSTN-related signaling group), and Microsoft Teams .
Review the channel states for each signaling group, and confirm correct operation:
Two channels are seized and in connected state (channels will be blue) in the SIP local registrar-related signaling group (for our example deployment, the LocalReg signaling group). Double-click either seized channels to ensure consistency between the channel details and the call placed from one Yealink device to the other.
All channels remain idle ( represented by the light green) in the Phone System-related signaling group (for our example deployment, the Microsoft Teams signaling group) as well as the PSTN-related signaling group (for our example deployment, the IMS signaling group).
For details surrounding the information available in the monitor related to signaling groups, refer to Monitoring Real Time Status.
Access the Yealink device's Teams UI.
Place a call from the Teams UI to the PSTN, and confirm two-way audio. Note the active call indicators in the display.
Access the WebUI, and click the Monitor tab.
Expand the three signaling groups (that pertain to the survivability scenario) so all channels become visible. For our example deployment, the three signaling groups identifiers are LocalReg (the signaling group to which the Yealink devices are registered), IMS (the PSTN-related signaling group), and Microsoft Teams .
Review the channel states for each signaling group, and confirm correct operation:
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 outgoing, call originator has the same phone number as the Yealink device, called party number is the dialed PSTN number, etc.).
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.
All channels remain idle (light green) in the SIP local registrar-related signaling group (for our example deployment, the LocalReg signaling group).
Access the WebUI, click the Settings tab.
In the left navigation pane, go to Signaling Groups
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.
Confirm that the Phone System-related signaling group is out of service, through the Down indication in the Service Status field.
For details on SIP Signaling Group operation including enablement and disablement, refer to Creating and Modifying SIP Signaling Groups.
Access the Yealink device's Survivability (SIP) UI.
Place a call from the PSTN to the Yealink device, using the Teams phone number assigned to the Yealink device. For the example deployment, the Teams phone number assigned to the Yealink device with the 30003 SIP-related number is +86XXXX604393.
Please dial from the PSTN the phone number required to reach the Teams client on the Yealink device, as opposed to the phone number associated with the Survivability (SIP) client. By using the Teams client phone number, the test confirms that the transformation table entries associated with the PSTN signaling group (for our example deployment, the IMS signaling group) have been correctly provisioned for survivability routing.
Confirm an incoming call is presented in the Survivability (SIP) UI. Note the alerting indication.
Access the SBC's WebUI, and click the Monitor tab.
Expand the three signaling groups (that pertain to the survivability scenario) so all channels become visible. For our example deployment, the three signaling groups identifiers are LocalReg (the signaling group to which the Yealink devices are registered), IMS (the PSTN-related signaling group), and Microsoft Teams .
Review the channel states for each signaling group, and confirm correct operation:
The PSTN-related signaling group (for our example deployment, the IMS signaling group) presents an alerting indication (magenta) in a single channel. Double-click the seized channel to ensure consistency between the channel details and the call placed from the PSTN (e.g. call direction is incoming, called digits are the Teams client number of the 30003 endpoint, calling party number is the PSTN endpoint, etc.).
The SIP local registrar-related signaling group (for our example deployment, the LocalReg signaling group) presents an alerting indication (magenta) in a single channel. Double-click the seized channel to ensure consistency between the channel details and the call placed from the PSTN (e.g. call direction is incoming, called digits are the Teams client number of the 30003 endpoint, calling party number is the PSTN endpoint, etc.).
All channels remain out of service (gray) in the Phone System-related signaling group (for our example deployment, the Microsoft Teams signaling group).
From the Yealink device's survivability (SIP) UI, answer the call and confirm two-way audio. Note the following indicators in the UI:
The green handset icon indicating a live call;
The Talking text indicating a live audio path.
Access the SBC's WebUI, and click the Monitor tab.
Expand the three signaling groups (that pertain to the survivability scenario) so all channels become visible. For our example deployment, the three signaling groups identifiers are LocalReg (the signaling group to which the Yealink devices are registered), IMS (the PSTN-related signaling group), and Microsoft Teams .
Review the channel states for each signaling group, and confirm correct operation:
The PSTN-related signaling group (for our example deployment, the IMS signaling group) presents a connected indication (blue) in the channel that previously presented the alerting indication. Double-click the seized channel to ensure consistency between the channel details and the call placed from the PSTN (e.g. call direction is incoming, called digits are the Teams client number of the 30003 endpoint, calling party number is the PSTN endpoint, etc.).
The SIP local registrar-related signaling group (for our example deployment, the LocalReg signaling group) presents a connected indication (blue) in the channel that previously presented the alerting indication. Double-click the seized channel to ensure consistency between the channel details and the call placed from the PSTN (e.g. call direction is incoming, called digits are the Teams client number of the 30003 endpoint, calling party number is the PSTN endpoint, etc.).
All channels remain out of service (gray) in the Phone System-related signaling group (for our example deployment, the Microsoft Teams signaling group).
Access the WebUI, click the Settings tab.
In the left navigation pane, go to Signaling Groups
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.
Confirm the Phone System-related signaling group is active, through the Up indication in the Service Status field.
Access the Yealink device's Teams UI.
Place a call from the PSTN to the Yealink device, using the Teams phone number assigned to the Yealink device. For the example deployment, the Teams phone number assigned to the Yealink device with the 30003 SIP-related number is +86XXXX604393.
Please dial from the PSTN the phone number required to reach the Teams client on the Yealink device, as opposed to the phone number associated with the Survivability (SIP) client. By using the Teams client phone number, the test confirms that the routing table entries associated with the PSTN signaling group (for our example deployment, the IMS signaling group) have been correctly provisioned to prioritize call routing to Phone System when the latter is available for processing calls.
Confirm an incoming call is presented in the Teams UI. Note the alerting indication.
Answer the call, and confirm two-way audio.
Access the WebUI, and click the Monitor tab.
Expand the three signaling groups (that pertain to the survivability scenario) so all channels become visible. For our example deployment, the three signaling groups identifiers are LocalReg (the signaling group to which the Yealink devices are registered), IMS (the PSTN-related signaling group), and Microsoft Teams.
Review the channel states for each signaling group, and confirm correct operation:
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, called party number has the same phone number as the Yealink device, calling party number is the PSTN number from which you made the call, etc.).
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.
All channels remain idle (light green) in the SIP local registrar-related signaling group (for our example deployment, the LocalReg signaling group).
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.