In Nimbus, DTMF (Dual-Tone Multi-Frequency) is primarily used in Workflow Activities (e.g. "Input Customer" to route calls according to the choice made by the incoming caller). Based on the direction, we can distinguish between:
- Inbound DTMF: With Inbound DTMF, Workflow Activities capture the DTMF inputs provided by the callers.
- Outbound DTMF: In rare scenarios there might be a need for sending outbound DTMF tones from the Nimbus user accepting the call, towards the caller (e.g. to open a door).
This article explains in which scenarios DTMF tones are available in Nimbus calls and in which scenarios they are not.
Inbound DTMF
Inbound DTMF (from the caller to Nimbus) is always available during a call1, except in very specific scenarios in which Microsoft disables the DMTF tones for the remaining life of the call. The following diagram visualizes when DTMF tones are available and in which scenarios they get disabled:
1Although DTMF tones can be sent at any time during a call by the caller, DTMF inputs are only interpreted by Nimbus in case the call reaches an activity in the workflow which is expecting those.
Based on the above diagram, if a Nimbus call gets transferred from the main service to another Nimbus service and gets to a user in one of the subsequent services, DTMF tones will not be available anymore for the entire duration of the call. In such case, workflow activities requiring DTMF tones will behave as follows in case a user transfers the call via Attendant Console to another Nimbus service:
- Input Customer and Input Customer (Advanced): The prompt text of the IVR is skipped and the NR exit of the IVR is taken.
- Collect Information: The prompt text is skipped and the No Input exit is taken.
- Standby Duty: Standby Duty functionality is not negatively affected by the limitation as in that case a new outbound call is started towards the standby duty user in which DTMF tones work as expected.
🤔 Why is Microsoft disabling the DTMF tones?
Due to privacy reasons, Microsoft disables the DTMF tones in case more than 2 participants are in the call. In the above mentioned scenario, for a short time, following three participants are in the call:
- The customer calling the Nimbus service
- The user accepting the Nimbus call
- A guest user that needs to be in the call for a short time (until a user accepts the call) to make sure the user accepting the call can see the names of the subsequent Nimbus services (instead of the name of the main Nimbus service the customer called) in the Teams toast.
🔎 See Conversation Handling Activities for more information on the above mentioned workflow activities.
Possible Workarounds
Workaround 1: Do an external workflow transfer to the same service in case DTMF is disabled.
Workaround 1: external workflow transfer to same service in case DTMF is disabled
In such case, the call after the external workflow transfer will be a new Nimbus call in which DTMF tones are available again. This workaround is completely seamless to the end users as they do not need to do anything differently.
PRECONDITIONS
- Enterprise or Contact Center licenses need to be assigned to the Nimbus services as the workaround requires the Nimbus Power Automate Connector.
- A phone number needs to be assigned to the Nimbus Services the calls are transferred to by the agents via Attendant Console.
Step 1: Create a Parameter
In Nimbus configuration, create the following Parameter:
Name |
ID |
Default Value |
|---|---|---|
| DTMFEnabled | DTMFEnabled | true |
This parameter will be used to keep track of DTMF status. The default value of the parameter will be true. Once an agent is accepting a call after a transfer, we will set the parameter's value to false via Power Automate.
Step 2: Create a Power Automate Flow
The Power Automate flow is needed to set the DTMFEnabled parameter's value to false in case a call gets accepted by an agent after a transfer.
- Start with the When a task changes state trigger of the Nimbus Connector.
| Field | Fill in / 🌟 = Nimbus dynamic content | |
|---|---|---|
| Service Item |
Select the UPN of the Service
|
 |
| Task Events | Select Connected To User | |
- Add a Control "Condition" action to your flow. Configure the action as follows:
| Field | Fill in / 🌟 = Nimbus dynamic content | |
|---|---|---|
| Condition expression |
Note: If a call gets accepted in the main service, the Task ID and Service Session ID parameters have the same value. If however a call gets transferred to a child service, the Task ID and Service Session ID parameters will be different. |
 |
-
In the True branch:
- Add a Luware Nimbus "Update Task" action to your flow.
- Configure the action as follows:
| Field | Fill in / 🌟 = Nimbus dynamic content | |
|---|---|---|
| Task ID |
🌟Task ID
|
 |
| Service Session ID | leave it empty | |
| User Session ID | leave it empty | |
| Custom Context Parameters |
Click Add new item and add a parameter with the following details:
|
|
- Save the Power Automate flow
Step 3: Adjusting the workflows
You need to make the following adjustments to workflows bound to services that agents transfer calls to:
- Immediately after the Accept workflow activity, use Check Parameter to check the value of the DTMFEnabled parameter.
- If the DTMFEnabled parameter has the value of false, then by using the Transfer activity, do an External transfer to the PSTN number of the service the workflow is currently assigned to. This will make sure to have a new Nimbus call in which DTMF is available again.
- If the DTMFEnabled parameter has the value of true, then you can continue with processing the workflow as DTMF is still enabled for the call.
Let's assume your service has the +41123456789 phone number assigned and the workflow looks as follows:
In such case you would need to add the following change to the workflow:
pros:
- No user education is needed
- Users can keep using the Attendant Console for the transfers
- Nimbus reporting shows the user transfer
- No additional phone number needed (unless the service the call gets transferred to does not have a phone number assigned yet)
cons:
- Additional configuration is needed (Nimbus, Power Automate)
- Only works with Enterprise and Contact Center licenses
- Call after transfer appears as a separate call in Nimbus reporting
Workaround 2: Transfer the call via AC via a dummy phone number
☝Only applies when using Direct Routing!
Workaround 2: Transfer the call via AC via a dummy phone number
Instead of transferring the call via AC to the target Nimbus service, the call needs to be transferred to a dummy phone number, which isn't assigned in Teams. When performing the transfer to the dummy number, Teams will automatically forward the call to the SBC as the phone number isn't assigned to any object in Teams. Next on the SBC you need to make sure to redirect that call to the phone number of the Nimbus service. Once the call is sent back to Teams by the SBC, it will be a new Nimbus call with DTMF enabled again. To make sure your end users do not need to remember those dummy numbers, you can create a Nimbus Address Book and add those dummy numbers to the Nimbus Address Book as described in the following use case: Luware Nimbus - Use Case - Adding External Address Books via Power Automate
pros:
- Users can keep using the Attendant Console for the transfers
- Works with Advanced, Enterprise and Contact Center licenses
- Nimbus reporting shows the user transfer
cons:
- User education is needed
- Additional configuration is needed (Nimbus, SBC)
- Additional phone number needed
- Call after transfer appears as a separate call in Nimbus reporting
Workaround 3: Transfer the call via Teams client to the service having an IVR
Workaround 3: Transfer the call via Teams client to the service having an IVR
In such case, the call after the transfer will be a new Nimbus call in which DTMF tones are available again.
pros:
- Additional configuration is not needed
- Works with Advanced, Enterprise and Contact Center licenses
- No additional phone number needed
cons:
- User education is needed
- Users need to use the Teams client for the transfers
- Nimbus reporting does not show the user transfer
- Call after transfer appears as a separate call in Nimbus reporting
Outbound DTMF
Outbound DTMF is limited to a few Queue Distribution Types only, as shown in the following table:
| Distribution Type | DTMF from Nimbus user to caller |
|---|---|
| Broadcast | ❌ |
| Direct | ✅ |
| Direct Conference | ❌ |
| Pickup Conference | ❌ |
| Pickup with adjustable RONA | ✅ |
If for example a Nimbus call is distributed to a Nimbus user via a Queue having Direct Conference configured as the distribution type, the Nimbus user won't be able to send DTMF tones towards the caller.