Hi @IV-rol.,
Welcome to Google Cloud Community!
You're experiencing a common issue with SSML in Dialogflow CX voice calls. Although the documentation indicates that SSML is supported for text and output audio, there are certain limitations and potential misconfigurations that can cause call drops or unexpected outputs like the "less than, greater than" readout.
Here’s a summary of potential problems and troubleshooting steps:
1. SSML Compatibility and Implementation:
- Platform Limitations: While Dialogflow CX supports SSML, the underlying Google Cloud Text-to-Speech engine may not fully support all SSML tags in voice call fulfillments. Some tags might work well in other contexts but could cause issues in real-time interactions. For example, the <say-as> tag is usually reliable, but incorrect usage or unusual phone number formats can lead to problems.
- Parameter Issues: The way you're using $session.params.phonenumber in your SSML might be causing the issue. Ensure this parameter consistently holds a valid phone number format before integrating it into the SSML. Incorrect formatting (such as extra characters or mishandled international prefixes) can lead to speech synthesis errors.
- SSML Tag Nesting and Syntax: Verify your SSML for syntax errors. Improper nesting or missing closing tags can lead to failures. A single misplaced character can result in unexpected behavior. Use an online SSML validator to check for simple syntax issues.
2. Troubleshooting Steps:
- Simplify Your SSML: Start with a basic SSML example to isolate the problem. Remove complex elements like the <say-as> tag and see if simple <speak> tags function properly. Gradually reintroduce other elements to identify the source of the crash.
- Format the Phone Number: Before using the phone number in SSML, add a validation step in your Dialogflow agent to ensure it’s properly formatted. Consider using a regular expression for validation before sending it to SSML.
- Test with a Static Phone Number: Replace $session.params.phonenumber with a known valid phone number (e.g., "+15551234567") to rule out issues with parameter extraction or formatting. If this works, the problem likely lies in your parameter handling.
- Check Dialogflow Logs: Review your Dialogflow logs for error messages when the call drops. These logs can provide important insights into the failure's source (e.g., SSML parsing or fulfillment errors).
- Alternative Approach (Without SSML): If SSML continues to be problematic, consider omitting the <say-as> tag. You could rephrase the message to ensure clarity, such as:
<speak>Thank you, $session.params.Name. The number I heard was $session.params.phonenumber. Is that correct?</speak>
While less elegant, this approach may be more reliable if SSML fails.
Example of Improved SSML:
<speak>Thank you <say-as interpret-as="name">$session.params.Name</say-as>. The number I heard was <say-as interpret-as="telephone">
<say-as interpret-as="digits">$session.params.phonenumber</say-as>
</say-as>. Is that correct?</speak>
This example uses nested <say-as> tags to clarify the number as digits and then as a telephone number. Adjust the formatting for different regional numbers to enhance compatibility with speech synthesis.
Please refer to the SSML document for examples and tips for using SSML or in Text-to-Speech public docs.
I hope the above information is helpful.
LinkedIn
Twitter
