Dépannage d'absence de tonalité de ligne occupée et d'absence de message d'annonce sur les appels RNIS-VoIP (H.323)

Introduction

Ce document traite des problèmes liés à la progression des appels dans la bande lors de l'interconnexion de signaux RNIS et H.323 entre VoIP et le réseau téléphonique public commuté (RTPC). Des défis se posent lorsque les routeurs/passerelles VoIP Cisco échangent des fonctionnalités de signalisation avec le commutateur de l'opérateur téléphonique. Cette liste décrit les scénarios/symptômes de problèmes courants :

• Aucun chiffre DTMF ou son transmis sur les appels VoIP vers PSTN/PBX : un utilisateur de téléphone IP passe un appel, peut entendre des messages d'annonce, tels que « entrez votre numéro de compte... », mais ne peut pas transmettre de chiffres DTMF (Dual-Tone Multifrequency). Ce symptôme s'applique à la fois aux appels de contournement VoIP et aux appels RTPC/PBX de téléphone IP Cisco.

• Aucune tonalité d'occupation ou aucun message d'annonce reçu lors de l'émission d'appels sortants VoIP : un téléphone IP Cisco (scénario CallManager) ou un téléphone POTS (scénario VoIP Toll-Bypass) n'entend pas de tonalité d'occupation ou de message d'annonce du réseau RTPC. Ce symptôme s'applique à la fois aux appels de contournement de appels VoIP et aux appels téléphoniques IP vers RTPC/PBX.

Référez-vous à Dépannage des appels sans tonalité de retour sur RNIS-VoIP (H.323) pour plus d'informations sur les problèmes liés à la progression des appels intrabande RNIS - VoIP (H.323).

Cisco vous recommande de lire la section Informations générales avant de lire la section Solutions.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Components Used

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Informations générales

Interfonctionnement RNIS-VoIP

L’interconnexion est définie comme le mappage des messages de signalisation d’appels entre deux suites de protocoles différentes. Dans le cadre de ce document, nous nous concentrons sur les problèmes d'interconnexion RNIS et H.323 (VoIP). Ce schéma affiche les messages de signalisation d'appel dans le segment d'appel RNIS (Q.931) et VoIP (H.225).

Remarque : H.225 est un protocole spécifié par H.323 pour la signalisation et la configuration des appels. La norme H.225 spécifie l'utilisation et la prise en charge de la norme Q.931. Reportez-vous au Tutoriel H.323pour plus d'informations sur le protocole H.323.

Tonalités d'avancement et indicateurs d'avancement

Les tonalités de progression intrabande (par exemple, les tonalités de retour d'appel et de ligne occupée) et les annonces (par exemple, « Le numéro que vous avez composé n'est plus en service ») sont nécessaires pour transmettre correctement les appels vocaux. Les tonalités de progression peuvent être générées par les périphériques d'origine, de terminaison ou intermédiaires.

L’indication des tonalités et des annonces intrabande est contrôlée par l’élément d’information de l’indicateur de progression (PI) dans les réseaux RNIS et H.323. L’IP signale les situations d’interconnexion où les tonalités et les annonces intrabande doivent être utilisées. Dans le contexte de ce document, il s'agit des valeurs PI Q.931 de l'UIT qui présentent un intérêt :

• PI = 1 : l'appel n'est pas un RNIS de bout en bout. Des informations supplémentaires sur la progression des appels peuvent être disponibles en bande.

• PI = 2 : l'adresse de destination n'est pas RNIS.

• PI = 3 : l'adresse d'origine n'est pas RNIS.

• PI = 8 : des informations intrabande ou un modèle approprié sont désormais disponibles.

L'indication que les tonalités et les annonces sont disponibles est signalée par un message d'alerte, de traitement de l'appel, de progression, de connexion, de confirmation de configuration ou de déconnexion qui contient un PI = 1 ou 8.

Lorsqu'un message Setup arrive à la passerelle d'origine avec un PI = 3, cela signifie que le commutateur informe la passerelle que des messages intrabande sont attendus.

Remarque : l'absence de PI dans un message suppose que le périphérique d'origine fournit le signal de tonalité approprié à l'appelant.

Remarque : Les circuits RTPC analogiques et numériques CAS (Channel Associated Signaling) transportent généralement les informations sous forme d'informations intrabande.

Coupure du chemin vocal

Le découpage du chemin vocal est la fin du chemin de transmission au porteur d'un appel vocal. Dans un appel vocal, la coupure se produit en deux étapes :

• Coupure dans la direction arrière signifie que seul le chemin vocal entre l'appelé et l'appelant est terminé.

• La coupure dans les deux directions signifie que le chemin vocal entre l'appelé et l'appelant est terminé.

Les tonalités et les annonces peuvent être générées au niveau du commutateur d’origine ou du commutateur de destination. Si des tonalités et des annonces sont générées par le commutateur de destination, le chemin de transmission du chemin vocal (vers l'arrière) du commutateur de destination à l'appelant doit être coupé avant la génération des tonalités et des annonces. Une coupure précoce du chemin du support de retour (avant le message de connexion) est nécessaire pour transporter les tonalités et les annonces intrabande de l'appelé vers l'appelant et éviter la coupure de la parole.

L’appel qui termine le routeur/la passerelle Cisco traverse le chemin audio en sens inverse pour transmettre des informations intrabande lorsque le commutateur RNIS qui termine envoie ces messages :

• Message d'alerte avec PI = 1 ou PI = 8

• Message de progression avec PI = 1 ou PI = 8

• Message de traitement de l'appel avec PI = 1 ou PI = 8

• Message Accusé de réception de configuration avec PI = 1 ou PI = 8

• Déconnecter le message avec PI = 1 ou PI = 8

Lors de la terminaison des interfaces CAS, le routeur/passerelle Cisco traverse l'audio en sens inverse une fois que tous les numéros appelés sont envoyés.

Le routeur/passerelle Cisco de terminaison traverse le chemin audio dans les deux directions dans les cas suivants :

• Le message de connexion est reçu sur une interface RNIS.

• La supervision des réponses (décroché) est reçue sur une interface CAS.

La coupe dans les deux directions peut être définie sur les passerelles à l'aide de la commande de configuration globale Cisco IOS, voice rtp send-recv.

Solutions

Dans les versions 12.1(3)XI1 et 12.1(5)T du logiciel Cisco IOS®, l'indication d'avancement est modifiée afin de fournir une meilleure interopérabilité entre les interfaces POTS et VoIP. Ceci est principalement réalisé par l'activation et la propagation de la fin de la valeur PI qui définit la génération de tonalité d'indication de progression.

L'utilisation de ces commandes suppose que vous exécutez au moins le logiciel Cisco IOS Version 12.1(3a)XI5 ou 12.2(1)ou ultérieure.

Référez-vous à Améliorations de la signalisation d'interconnexion pour H.323 et SIP VoIP et Référence des commandes voix, vidéo et télécopie Cisco IOS, version 12.2 pour plus d'informations.

Aucun chiffre DTMF ou son transmis sur les appels VoIP vers PSTN/PBX

Symptôme

L'utilisateur passe un appel, entend des messages d'annonce, tels que « entrez votre numéro de compte... », mais ne peut pas transmettre de chiffres DTMF. Ce symptôme s'applique à la fois aux appels de contournement des appels VoIP et aux appels téléphoniques IP vers des appels RTPC/PBX.

Description du problème

Un appel d'un téléphone IP Cisco (scénario CallManager) ou d'un téléphone POTS (scénario VoIP Toll-Bypass) passe par une passerelle Cisco IOS, où le numéro appelé est généralement un système de réponse vocale interactive (IVR) qui renvoie un message de progression RNIS, mais ne se connecte pas tant que certaines informations de compte ne sont pas entrées. Par défaut, le chemin audio est coupé dans la direction arrière (vers le téléphone IP ou la passerelle d'origine), mais pas dans la direction avant, jusqu'à ce que la passerelle de terminaison reçoive un message de connexion. Par conséquent, il n'y a aucun chemin vocal pour transmettre des tonalités DTMF ou de la parole vers le commutateur de terminaison.

Solution

Configurez la commande de configuration globale Cisco IOS, voice rtp send-recv, afin d'établir (cut-through) le chemin audio dans les deux directions avant de recevoir un message de connexion RNIS du RTPC. Référez-vous à Référence des commandes vocales, vidéo et télécopie Cisco IOS, version 12.2 pour plus d'informations sur cette commande.

Aucune tonalité d'occupation ou message d'annonce reçu lors du placement d'appels sortants VoIP

Symptôme

Un téléphone IP Cisco (scénario CallManager) ou un téléphone POTS (scénario VoIP Toll-Bypass) n'entend pas de tonalité de ligne occupée ou de message d'annonce provenant du réseau RTPC.

Solution

Configurez la commande de configuration globale du logiciel Cisco IOS, voice call convert-discpi-to-prog. Il est utilisé avec le logiciel Cisco IOS version 12.2(1) et ultérieure. Cette commande convertit un message de déconnexion RNIS entrant avec un PI en message de progression H.225 avec la même valeur PI. Cette commande peut vous aider lorsqu'une annonce est diffusée du côté PSTN de terminaison, mais l'appelant n'entend pas la réponse.

Dans le scénario VoIP Toll-Bypass, la plupart de ces problèmes sont résolus par une mise à niveau du routeur/des passerelles vers une version du logiciel Cisco IOS 12.1(3a)XI5 ou 12.2(1) et ultérieure. Cependant, si le périphérique d'origine ou le commutateur RNIS d'origine ne maintient pas l'appel actif lorsqu'un message de déconnexion H.225/RNIS est reçu, émettez la commande voice call convert-discpi-to-prog.

Ceci peut apparaître lorsque l'annonce en bande est également une tonalité occupée. Au-delà de cela, le signal occupé doit être fourni par le périphérique de terminaison, le périphérique d'origine ou le réseau. Certains aspects peuvent être contrôlés.

Pas de tonalité d'occupation sur les appels entrants de la téléphonie (RNIS) au téléphone IP Cisco CallManager, à la passerelle IOS ou au périphérique H323 tiers

Symptôme

Un appel du RTPC via une passerelle vers un téléphone IP Cisco CallManager, une passerelle Cisco IOS ou un périphérique H.323 tiers peut ne pas entendre de tonalité de ligne occupée lorsqu'il exécute une numérotation à deux étapes ou une application sur la passerelle d'origine.

Solution

Il s'agit d'un cas moins courant qui peut se produire lorsque la passerelle d'origine exécute une application vocale telle que carte de débit ou exécute une numérotation en deux étapes. Ce dernier fait référence à l'appelant qui compose d'abord le numéro vers la passerelle, reçoit la tonalité, puis compose le numéro de l'appelé. Dans les deux cas, l'appel s'est connecté en termes de réseau RTPC une fois qu'il s'est arrêté sur la passerelle d'origine. Si le segment d'appel IP revient avec une libération avec la cause utilisateur occupé, cela ne peut pas être indiqué de nouveau vers la session de téléphonie qui est en état de connexion.

Cela a été résolu en demandant à la passerelle d'origine de générer une tonalité d'occupation lorsque la libération de la branche d'appel IP est reçue avec un code de cause d'occupation utilisateur. La branche de téléphonie est libérée par l'appelant ou par la passerelle après plusieurs minutes avec le code de cause de l'effacement normal des appels.

Cette fonctionnalité est disponible à partir du logiciel Cisco IOS Version 12.2(8)/12.2(8)T et ultérieure.

Remarque : pour initier un transfert de consultation complète à partir d'un téléphone IP enregistré auprès de Cisco CallManager Express, le téléphone IP doit disposer de plusieurs lignes. Vous devez configurer et émettre la commande ephone-dn [number] dual-line. Cela permet au téléphone IP d'avoir deux lignes ou canaux associés au numéro de répertoire unique. Le comportement normal avec la double ligne configurée est que si un appel est déjà actif sur le premier canal et qu'un autre appel est passé sur ce poste, l'appelant entend la tonalité d'alerte (sonnerie) sur le deuxième canal au lieu d'une tonalité occupée. Si vous souhaitez qu'une tonalité de ligne occupée soit reçue par l'appelant lorsqu'un poste est occupé sur le premier canal, vous devez configurer et émettre la commande huntstop channel sous ephone-dn, comme indiqué dans cet exemple :

CMECUE(config)#ephone-dn 1
CMECUE(config-ephone-dn)#huntstop channel

!--- Stops hunting on the second channel of a dual-line dn.

Informations connexes

• Améliorations de la signalisation d'interconnexion pour H.323 et SIP VoIP
• Les usagers de RTPC n'entendent pas de rappels lorsqu'ils passent des appels à destination de téléphones IP
• Référence des commandes de voix, vidéo et télécopie Cisco IOS, version 12.2
• Présentation des codes de motif de déconnexion debug isdn q931
• Assistance technique concernant la technologie vocale
• Assistance concernant les produits vocaux et de communications unifiées
• Dépannage des problèmes de téléphonie IP Cisco
• Support et documentation techniques - Cisco Systems