Distinguishing between human and answering machine

SUMMARY: Provide better information about AMD tuning in the GVP User Guide.

Document: The next publication of the GVP 8.5 User's Guide will include this revision:
Appendix: Appendix C: Tuning Call Progress Detection
SECTION: Continuous Tone Detection

Add a new section Distinguishing between human and answering machine after the section Continuous Tone Detection with the following information:

MCP uses the following process to distinguish between human and answering machine:

1. Wait for voice energy to be received.
2. Wait for silence and measure the duration of silence for voicepausedur or start of the voice energy again.
3. If voice energy is received during the silence before voicepausedur has expired, go back to step 2.
4. Return "silence" if postconnecttimeout expires before voice energy followed by voicepausedur of silence has been received.
5. When voicepausedur of silence has been received, compare the duration of the last segment or any of the previous segment of voice energy received against maxvoicesigdur for the profile selected. If any of the voice energy segment is less than maxvoicesigdur, then return “human”.
6. In the last voice energy segment, look for human voice signatures, and if satisfied, return “human”.
7. If voice energy segment is greater or equal to the machinegreetingdur for the profile selected, then return “machine”.
8. If the latest silence period is greater or equal to 1.5 times voicepausedur, then return “human”.

The process reflects the heuristic that a short greeting, for example, "Hello", is likely human, while a long greeting, for example, "After the beep, please leave a message", is a machine.

The MCP configuration options (and the profile selected via OCS call_answer_type_recognition) can be used to tune the process, as covered in Tone Definition. However, tuning the system (decreasing maxvoicesigdur and machinegreetingdur) to increase the percentage of voicemail systems (and so on) correctly as answering machines typically leads to a corresponding increase in the percentage of humans incorrectly detected as answering machines.

There are also some greetings, for example, "Genesys Customer Care, XYZ speaking, how may I assist you today?" or voicemail greetings containing long pauses, which will often be detected incorrectly. For the latter, increasing voicepausedur may help but will increase the time required for detection and may not completely eliminate the issue.

For reference, the following is the mapping from OCS call_answer_type_recognition to MCP option profile:

• no_am_detection → priority_normal (no machine)
• positive_am_detection → priority_normal
• full_positive_am_detection → priority_voice
• accurate_am_detection → priority_machine
• telephony_preset → priority_normal (no machine)

For reference, the following table lists Call Progress Analysis & Tuning (CPA)-related symptoms and actions:

Symptom	Action
Longer human greetings are being identified as AM	Increase mpc.cpa.priority_<profile>_maxvoicesigdur and mpc.cpa.priority_<profile>_machinegreetingdur
Takes too long to connect after human greeting	Reduce mpc.cpa.priority_<profile>_voicepausedur
Detection times out, or an incorrect result is returned after long (5 to 10 seconds or more) delay	Decrease mpc.cpa.voice_range_db and mpc.cpa.voice_level_db
Beginning parts of the VXML application is not recorded in voice message Voice message has silence before the initial prompt of the VXML application	Adjust msml.cpd.beeptimeout
Sometimes AM is classified as silence	Decrease cpa.priority_<profile>_machinegreetingdur
Silence is marked as OK by OCS	Enable the SIP Server option timeguard-reduction

While it is possible to configure the environment (OCS, SIP Server, and MCP) to ensure the call is answered within a very short timeframe (e.g 2 seconds or less) in order to meet regulatory requirements, this is typically insufficient for accurate AMD (which requires time for the greeting to be provided followed by a period of silence).

For example, if the requirement is for calls to be transferred within 2 seconds then Genesys would recommend setting call_timeguard_timeout to 2000ms (or less, to allow for transfer time) and the SIP Server configuration option timeguard-reduction to 500ms. This will ensure MCP provides a response within 2 seconds, although MCP will provide a silence result if AMD has not been completed.

If the objective is for MCP to perform postconnect processing as quickly as possible (with "no_am_detection"), then Genesys would recommend the following MCP configuration options:

• [mpc] cpa.normal_voicepausedur=200
• [mpc] cpa.normal_maxvoicesigdur=10000 and [mpc] cpa.normal_machinegreetingdur=15000

Important

These options will also effect positive_am_detection and are not suitable for general answering machine detection.

Important

MCP will return a silence result if it has not received (with the above options) voice energy followed by 200ms of silence.

The following is additional CPA-related information:

• Preconnect tones (busy, fast busy, ringback, SIT, and custom defined SIT tones) can be detected in both preconnect and postconnect states. You can enable this mode by setting mpc.cpa.preconn_tones_det_mode=1.
• Starting from 8.5.185.34, MCP introduces two new configuration options, mpc.cpa.postconnsilresult and mpc.cpa.postconnsilduration to return a configurable CPA result if a configurable length of silence is detected right after the post-connect event arrives.
  • Otherwise, MCP returns cpd.silence only when postconnecttimeout (or call_timeguard_timeout in T-Lib) times out.
• Set mpc.cpa.enable_log_param to true to log CPA parameters
• Set mpc.cpa.enable_log_result to true to log CPA result:

  cpa_result Answering machine detected