Ce document décrit comment certains événements d'erreur VoiceXML peuvent être traités avec élégance avec des éléments HotEvent au lieu d'un raccrochage sur l'appelant.
Les informations contenues dans ce document sont basées sur Cisco Unified Call Studio, Universal Edition.
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
Symptômes : Le concepteur de flux d'appels souhaite prendre en compte les événements d'erreur VoiceXML les plus courants et les gérer dans le flux d'appels plutôt que d'autoriser la gestion des erreurs par défaut.
Résolution : L'élément HotEvent écoute un événement particulier comme spécifié dans sa configuration d'élément. Lorsque cet événement se produit, son seul état de sortie est suivi et le flux d'appels peut continuer. Bien que l'interception de certains événements, tels qu'un raccrochage, soit déconseillée car elle peut affecter le fonctionnement normal de Cisco Unified Call Studio, Universal Edition, vous pouvez gérer plusieurs événements dans votre flux d'appels afin d'améliorer l'expérience de l'appelant dans les situations d'erreur. Reportez-vous à la documentation de votre navigateur vocal pour obtenir la liste des événements que le navigateur peut lancer au cours d'un appel.
Voici un exemple de la façon dont vous pouvez gérer un serveur de redémarrage automatique du serveur (ASR) en cas de panne :
Configurez un HotEvent pour écouter l'événement déclenché par votre navigateur vocal dans cette situation ; il peut s'agir d'un fichier similaire à resource.available.asr.
Quittez le HotEvent pour accéder à un élément Cisco Unified Call Studio, Universal Edition, qui explique à l'appelant qu'une erreur mineure s'est produite, mais qu'il peut continuer son appel.
Connectez l'état de sortie de l'élément Cisco Unified Call Studio, Universal Edition, à un élément Application Transfer.
Utilisez l'élément Application Transfer pour envoyer l'appelant vers une version dtmf uniquement de l'application.
Avec cette approche, si le serveur ASR tombe en panne, l'appelant peut poursuivre l'appel. En fonction de la manière dont l'entrée de l'appelant est stockée, l'appelant peut avoir besoin de saisir à nouveau certaines données ou de revenir dans le flux d'appels, mais au moins l'appelant peut continuer l'expérience de réponse vocale interactive (IVR) sans avoir besoin de rappeler ultérieurement.
Un autre exemple de cette utilisation est error.badfetch, qui peut se produire si un serveur multimédia tombe en panne. Dans ce cas, vous pouvez utiliser un HotEvent pour router vers un élément Action personnalisé qui modifie le chemin par défaut pour faire référence à un serveur de support de sauvegarde à la place.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
16-May-2007 |
Première publication |