Ce document aborde des questions connexes d'intrabande de progression d'appel lors d'interconnexion du RNIS et la signalisation du H.323 entre les réseaux VoIP et le réseau téléphonique commuté public (PSTN). Les défis surgissent quand le routeur ou les passerelles Cisco VoIP permutent les capacités de signalisation avec le commutateur Telco.
La connaissance de la configuration H.323 et de Cisco CallManager est nécessaire pour comprendre ce document.
Ce document utilise Cisco CallManager et les passerelles vocales Cisco IOS® pour la solution du problème abordé dans ce document.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
Ce document traite des problèmes liés à la progression d'appel intrabande lors de l'interfonctionnement de la signalisation RNIS et H.323 entre les réseaux VoIP et RTPC. Les défis surgissent quand le routeur ou les passerelles Cisco VoIP permutent les capacités de signalisation avec le commutateur Telco. Cette liste décrit les scénarios/symptômes de problèmes courants :
Aucune tonalité de retour d'appel sur les appels de contournement de péage VoIP
Symptôme : Un utilisateur d'un service téléphonique traditionnel (POTS) (RTPC/PBX) passe un appel via un routeur/une passerelle Cisco et n'entend pas de tonalité de retour d'appel avant que l'appel ne soit pris.
Symptôme : Un utilisateur POTS (RTPC/PBX) passe un appel vers un téléphone IP via un routeur/une passerelle Cisco et n'entend pas de tonalité de retour avant que l'appel ne soit pris.
Symptôme : Un utilisateur passe un appel d'un téléphone IP ou d'un périphérique tiers vers un numéro externe via un routeur/modem routeur Cisco et n'entend pas de tonalité de retour d'appel.
Aucune tonalité de retour d'appel vers RTPC (Cisco CallManager)
Symptôme : Lorsque des appels proviennent du RTPC via Cisco CallManager, l'appelant n'entend pas de tonalité de retour d'appel. Si l'appel est pris, les deux interlocuteurs peuvent s'entendre ou l'appelant peut entendre les invites de la messagerie vocale.
Symptôme : Un appel entrant d'une passerelle/d'un routeur Cisco vers Cisco CallManager ou la messagerie vocale Cisco Unity qui est transféré après que l'appel a obtenu une réponse n'entend pas de retour d'appel.
Symptôme : Lorsqu'un utilisateur compose un numéro à partir d'un téléphone IP enregistré auprès de Cisco CallManager et destiné à un téléphone IP enregistré auprès de Cisco CallManager Express, la sonnerie n'est pas entendue. Cela se produit même si le téléphone récepteur sonne et que l'appel est terminé.
Référez-vous à Dépannage des appels sans tonalité d'occupation et sans messages d'annonce sur RNIS-VoIP (H.323) pour plus d'informations sur les problèmes liés à la progression de l'appel RNIS - VoIP (H.323) dans la bande.
Remarque : Cisco vous recommande de lire la section Informations générales avant de lire la section Solutions.
L’interopérabilité est définie comme le mappage des messages de signalisation d’appel entre deux suites de protocoles différentes. Ce document se concentre sur les questions d'interfonctionnement RNIS et H.323 (VoIP). Ce schéma affiche les messages de signalisation d'appel dans la branche d'appel RNIS (Q.931) et VoIP (H.225).
Remarque : H.225 est un protocole spécifié par H.323 pour la signalisation et l'établissement des appels. H.225 spécifie l'utilisation et la prise en charge de Q.931. Référez-vous au Tutoriel H.323 pour plus d'informations sur H.323.
Les tonalités de progression intrabande, telles que les tonalités de retour d'appel et d'occupation, et les annonces, telles que « Le numéro que vous avez composé n'est plus en service », sont nécessaires pour signaler correctement les appels vocaux. Les tonalités de progression sont 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 (IE) Indicateur de progression dans les réseaux RNIS et H.323. L'indicateur de progression signale les situations d'interfonctionnement dans lesquelles des tonalités intrabande et des annonces doivent être utilisées. Dans le contexte de ce document, voici les valeurs d'intérêt de l'indicateur de progrès ITU Q.931 :
Indicateur de progression = 1 : l'appel n'est pas un appel RNIS d'extrémité. D'autres informations sur la progression de l'appel peuvent éventuellement être disponibles en bande.
Indicateur de progression = 2 : l'adresse de destination est non RNIS.
Indicateur de progression = 3 : l'adresse d'origine est non RNIS.
Indicateur de progression = 8 : des informations intrabande ou un modèle approprié sont désormais disponibles.
L'indication que des tonalités et des annonces sont disponibles est signalée par un message d'alerte, de poursuite de l'appel, de progression, de connexion, d'accusé de réception de configuration ou de déconnexion qui contient un indicateur de progression égal à 1 ou 8.
Lorsqu'un message d'installation arrive à la passerelle d'origine avec un PI égal à 3, cela signifie que le commutateur informe la passerelle que des messages intrabande sont attendus.
Remarque : L'absence d'un PI dans un message suppose que le périphérique d'origine fournit le signal sonore approprié à l'appelant. Sur la passerelle, si vous avez configuré pour couper la voix et envoyer une tonalité de retour d'appel, et que vous n'entendez toujours pas la tonalité de retour d'appel, il est possible que la configuration PBX du fournisseur de services pose problème.
Remarque : les circuits RTPC de signalisation associée aux canaux analogiques et numériques (CAS) transportent généralement les informations en tant qu'informations intrabande.
Le «cut-through» de la voie vocale est l'achèvement de la voie de transmission porteuse d'un appel vocal. Dans un appel vocal, la coupure se produit en deux étapes :
Cut-through in the Backward Direction : cela signifie que seul le chemin vocal de l'appelé à l'appelant est complet.
Cut-through in Both Directions : cela 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 de destination. Si des tonalités et des annonces sont générées par le commutateur de destination, le chemin de transmission vocale vers l'arrière, du commutateur de destination à l'appelant, doit être coupé avant que les tonalités et les annonces ne soient générées. Une coupure anticipée du chemin de support arrière (avant le message de connexion) est nécessaire pour transporter les tonalités intrabande et les annonces de l'appelé vers l'appelant et pour éviter la coupure de la parole.
Le routeur/modem routeur Cisco de terminaison d’appel coupe le chemin audio vers l’arrière afin de transmettre des informations intrabande lorsque le commutateur RNIS de terminaison lui envoie les messages suivants :
Message d'alerte avec PI égal à 1 ou PI égal à 8.
Message de progression avec PI égal à 1 ou PI égal à 8.
Message Call Proceeding avec PI égal à 1 ou PI égal à 8.
Message de confirmation de configuration avec PI égal à 1 ou PI égal à 8.
Message de déconnexion avec PI égal à 1 ou PI égal à 8.
Remarque : à la terminaison des interfaces CAS, le routeur/la passerelle Cisco coupe l'audio en sens inverse une fois que tous les chiffres du numéro appelé ont été envoyés.
Le routeur/modem routeur Cisco de terminaison coupe le chemin audio dans les deux directions dans les cas suivants :
Le message de connexion est reçu sur une interface RNIS.
La supervision de la réponse (décroché) est reçue sur une interface CAS.
La découpe dans les deux directions peut être définie sur les passerelles à l'aide de la commande de configuration globale voice rtp send-recv Cisco IOS.
Dans les versions du logiciel Cisco IOS 12.1(3)XI1 et 12.1(5)T, l'indication de progression est modifiée pour fournir une meilleure interopérabilité entre les interfaces POTS et VoIP. Pour ce faire, il faut principalement activer et propager des valeurs d'indication de progression de bout en bout qui définissent la génération de tonalité d'indication de progression.
L'utilisation de ces commandes suppose que vous exécutez le logiciel Cisco IOS version 12.1(3a)XI5 ou 12.2(1) et ultérieure. Référez-vous à Améliorations de la signalisation d'interfonctionnement pour H.323 et SIP VoIP et Référence des commandes voix, vidéo et télécopie de Cisco IOS, version 12.2 pour plus d'informations.
Un utilisateur de POTS (RTPC/PBX) passe un appel via un routeur/une passerelle Cisco et n'entend pas de tonalité de retour d'appel avant que l'appel ne soit pris.
Dans ce scénario, le commutateur de terminaison d'appel envoie la tonalité de rappel. Il signale un PI=8 au routeur/modem routeur Cisco de terminaison. Les informations IP sont ensuite transmises à la passerelle d'origine via un message de progression H.225. La passerelle d'origine ne parvient pas à décoder le message de progression. Il ne coupe pas le chemin audio vers l'arrière pour permettre la transmission des tonalités de retour d'appel. Voici quelques scénarios courants :
Une passerelle/routeur de terminaison exécute le logiciel Cisco IOS version 12.1(3)XI /12.1(5)T ou ultérieure avec une passerelle d'origine qui exécute le logiciel Cisco IOS version 12.1T. La passerelle source ne comprend pas le message de progression H.225. Il ne coupe pas le chemin audio tant que le message Connect n'est pas reçu.
Une passerelle/routeur Cisco de terminaison est connectée à une interface CAS ou analogique. Il envoie les informations IP dans un message de progression H.225 à la passerelle d'origine. La passerelle/le routeur d'origine ne parvient pas à décoder le message de progression H.225.
Les passerelles et contrôleurs d'accès tiers n'analysent pas correctement les messages de progression H.225.
Le commutateur RNIS renvoie une tonalité de rappel intrabande, mais le message d’alerte ne contient pas d’indicateur de performance.
Essayez l'une des solutions suivantes :
Configurez la commande de configuration globale voice call send-alert Cisco IOS dans la passerelle/routeur de terminaison.
Cette commande permet à la passerelle d'arrivée d'envoyer un message d'alerte au lieu d'un message de progression après réception d'un appel en cours.
Référez-vous à Référence des commandes voix, vidéo et télécopie de Cisco IOS, version 12.2 pour plus d'informations sur cette commande.
Mettez à niveau le logiciel Cisco IOS sur la passerelle/le routeur d'origine vers la version 12.1(3a)XI/12.1(5)T ou ultérieure du logiciel Cisco IOS.
Si la solution précédente ne fonctionne pas, configurez la passerelle de terminaison pour envoyer un PI = 8 dans le message d'alerte en configurant la commande progress_ind alert enable 8 sous la configuration voice dial-peer # pots.
Cette commande remplace la valeur IP reçue dans le message d'alerte RNIS. Le routeur coupe le chemin audio vers l'appelant avant de se connecter.
Référez-vous à Référence des commandes voix, vidéo et télécopie de Cisco IOS, version 12.2 pour plus d'informations sur cette commande.
Remarque : les commandes progress_ind alert et progress_ind setup sont masquées dans certaines versions du logiciel Cisco IOS et peuvent ne pas être visibles dans l'analyseur d'aide. Cependant, si la commande progress_ind progress est disponible dans l'analyseur d'aide, ces commandes sont également disponibles et peuvent être entrées dans le terminal de numérotation dial-peer dans leur intégralité. Ces commandes apparaissent ensuite dans la configuration en cours.
L'utilisateur POTS (RTPC/PBX) passe un appel vers un téléphone IP via un routeur/une passerelle Cisco et n'entend pas de tonalité de retour avant que l'appel ne soit pris.
Ceci est généralement dû au fait que l’appel entrant n’arrive pas à la passerelle/au routeur Cisco avec un PI=3. Les commutateurs RNIS envoient le PI=3 dans le message de configuration pour informer la passerelle que l’appel d’origine n’est pas RNIS et que des messages intrabande sont attendus. Ce scénario est également décrit dans Appelants RTPC n'entendant aucun rappel lorsqu'ils appellent des téléphones IP.
Complétez l'une de ces solutions :
Configurez la commande progress_ind setup enable 3 Cisco IOS sous la configuration voice dial-peer # VoIP dans la passerelle/routeur Cisco.
Cette commande force la passerelle/le routeur à traiter le message d'installation RNIS entrant comme s'il arrivait avec un PI égal à 3 et à générer une tonalité de retour d'appel intrabande vers l'appelant si le message d'alerte H.225 ne contient pas un PI de 1, 2 ou 8.
Référez-vous à Référence des commandes voix, vidéo et télécopie de Cisco IOS, version 12.2 pour plus d'informations sur cette commande.
Remarque : les commandes progress_ind alert et progress_ind setup sont masquées dans certaines versions du logiciel Cisco IOS et ne sont pas visibles dans l'analyseur d'aide. Cependant, si la commande progress_ind progress est disponible dans l'analyseur d'aide, ces commandes sont également disponibles et sont entrées dans le terminal de numérotation dial-peer dans leur intégralité. Ces commandes apparaissent ensuite dans la configuration en cours.
Une alternative à la commande progress_ind setup est la sous-commande dial-peer voice # voip tone ringback alert-no-pi .
La passerelle génère alors un retour d'appel vers l'appelant si une alerte est reçue sur la branche d'appel IP sans PI. Il diffère de la commande progress_ind setup en ce que le message de configuration H.225 sortant ne contient pas une PI de 3 avec la commande tone ringback. Il est possible que certains périphériques n'acceptent pas les messages de configuration lorsqu'un PI est inclus.
Un utilisateur passe un appel sortant d'un téléphone IP vers le RTPC via une passerelle/un routeur Cisco IOS et n'entend pas de tonalité de retour d'appel.
Dans cette situation, le périphérique d'origine attend des tonalités de retour d'appel intrabande. Au lieu de cela, l'un ou l'autre peut se produire :
Le RTPC/commutateur ne fournit pas la tonalité de retour d'appel.
Le routeur/la passerelle Cisco IOS ne coupe pas l'audio vers le périphérique d'origine.
Si le RTPC fournit un retour d'appel intrabande et que le message d'alerte Q.931 ne fournit pas de PI indiquant qu'il existe des informations intrabande, la passerelle ne coupe pas le son tant que l'appel n'est pas connecté.
Complétez l'une de ces solutions :
Dans ce cas, les tonalités de retour doivent provenir du RTPC pour les circuits agrégés. Deux sous-commandes dial-peer peuvent vous aider. Sur le routeur/la passerelle Cisco IOS sous les ports # outgoing voice dial-peer, configurez ces commandes : .
progress_ind alert enable 8 progress_ind progress enable 8 progress_ind connect enable 8
La commande progress_ind alert enable 8 présente le message d'alerte Q.931 au logiciel sur le routeur/la passerelle comme si le message d'alerte avait un PI de 8 et coupait le chemin audio. Référez-vous à Configuration de l'indicateur de progression dans les terminaux de numérotation dial-peer H.323 POTS pour plus d'informations.
Remarque : les commandes progress_ind alert et progress_ind setup sont masquées dans certaines versions du logiciel Cisco IOS et peuvent ne pas être visibles dans l'analyseur d'aide. Cependant, si la commande progress_ind progress est disponible dans l'analyseur d'aide, ces commandes sont également disponibles et peuvent être entrées dans le terminal de numérotation dial-peer dans leur intégralité. Ces commandes apparaissent ensuite dans la configuration en cours.
Si la commande précédente ne résout pas le problème, dans les versions du logiciel Cisco IOS de 12.2(1) à 12.2(2)T et ultérieures, configurez la commande progress_ind setup enable 3 sous la configuration voice dial-peer # port.
Cette commande force la passerelle à envoyer un PI avec une valeur de 3 dans le message de configuration RNIS. Cela indique au RTPC/PBX que le périphérique d'origine est un périphérique non RNIS et que des informations intrabande doivent être présentées. Il est recommandé d'utiliser cette commande avec la commande progress_ind alert enable 8.
Si le périphérique RTPC ne peut pas générer de retour d'appel intrabande (par exemple, un téléphone RNIS directement connecté à un port BRI sur la passerelle), la passerelle peut être configurée pour générer un retour d'appel sur la branche d'appel IP en configurant la commande tone ringback alert-no-pi sur les ports de numérotation dial-peer voice #.
Lorsque l'alerte RNIS est reçue sans PI, la passerelle génère le retour d'appel entrant et inclut un PI=0x8 dans le message d'alerte H.225.
Lorsque des appels proviennent du RTPC via Cisco CallManager, l'appelant n'entend pas de tonalité de retour d'appel. Si l'appel est pris, les deux interlocuteurs peuvent s'entendre ou l'appelant peut entendre les invites de la messagerie vocale.
Afin de résoudre ce problème, définissez le paramètre de service Disable Alerting Progress Indicator sur False dans Cisco CallManager. Vous pouvez effectuer cette opération lorsque vous vous connectez à la page d'administration de Cisco CallManager et que vous effectuez les étapes suivantes :
Accédez au menu Service et sélectionnez Service Parameters dans la page Cisco CallManager Administration.
Sélectionnez le serveur Publisher CallManager et le service Cisco CallManager.
Faites défiler vers le bas jusqu'à Disable Alerting Progress Indicator dans la section Clusterwide Parameters (Device - PRI and MGCP Gateway). Définissez ce paramètre sur False et cliquez sur Update.
Lorsqu'un appel vers un téléphone IP reçoit une réponse, puis est transféré, l'appelant n'entend pas de retour d'appel. Lorsque l'appel transféré reçoit une réponse, les deux interlocuteurs peuvent s'entendre.
Du point de vue de la passerelle/du routeur Cisco IOS, l'appel est terminé une fois qu'un téléphone IP (via Cisco CallManager) ou le système de messagerie vocale Cisco Unity y répond. Toute tonalité de progression supplémentaire (en cas de transfert d'appel) doit être générée par le périphérique de terminaison. Toutefois, Cisco CallManager et Cisco Unity ne peuvent pas générer les tonalités de progression intrabande.
Pour résoudre ce problème, suivez les étapes décrites ici ou configurez la passerelle/le routeur Cisco IOS en tant que passerelle MGCP au lieu d'une passerelle H.323.
ToSend H.225 User Info Message : Ce paramètre spécifie si Cisco CallManager envoie un message d'information H.225 utilisateur ou un message d'information H.225.
Vous devez d'abord disposer de Cisco CallManager 3.0 (8) ou version ultérieure.
Sur la page Cisco CallManager Administration (http://<Nom ou adresse IP de votre Cisco CallManager>/ccmadmin/), accédez au menu Service. Sélectionnez Paramètres du service.
Procédez comme suit pour chaque serveur Cisco CallManager actif :
Dans la zone Services configurés, sélectionnez Cisco CallManager.
Dans la zone de liste déroulante Parameter, sélectionnez ToSendH225UserInfoMsg.
Définissez la zone de liste déroulante Valeur sur T pour true.
Mettez à niveau le routeur/la passerelle vers le logiciel Cisco IOS version 12.2 (2.4) ou ultérieure.
Ce problème est documenté dans l'ID de bogue Cisco CSCds1354 (clients enregistrés seulement) .
Remarque : ces correctifs sont valides pour les tonalités de retour d'appel, mais pas pour les autres tonalités de progression, telles que signal occupé.
Remarque : certaines modifications apportées aux options disponibles pour ToSendH225UserInfoMsg dans les versions ultérieures de Cisco CallManager 3.3 et 4.0 sont répertoriées dans la section suivante.
Cisco CallManager 3.3 propose les options suivantes :
No Ring Back : le message d'informations utilisateur H.225 ou le message d'informations H.225 n'est pas envoyé à la passerelle Cisco IOS pour lire la tonalité de retour d'appel.
User Info for Ring Back Tone : envoie un message d'informations utilisateur H.225 à la passerelle Cisco IOS pour lire la tonalité de retour d'appel.
H.225 Info for Ring Back : le message d'information H.225 est envoyé à la passerelle Cisco IOS pour lire la tonalité de retour d'appel.
Remarque : Cisco CallManager version 3.1 ne prend pas en charge le message H.225 Information. Choisissez l'option User Info for Ring Back Tone si vous utilisez des agrégations inter-clusters et que l'un des clusters exécute Cisco CallManager version 3.1 ou antérieure. Cependant, si tous les clusters exécutent Cisco CallManager 3.2(2a) ou une version ultérieure, choisissez l'option H225 Info for Ring Back. Par défaut : Informations utilisateur pour la tonalité de rappel.
Cisco CallManager 4.0 propose les options suivantes :
Dans Cisco CallManager 4.0, ce paramètre spécifie le message que Cisco CallManager envoie pour la tonalité de retour d'appel ou la tonalité d'attente.
Use ANN for Ring Back : utilise l'annonciateur Cisco Signaling Connection Control Part (SCCP) pour émettre une tonalité de retour d'appel (disponible dans Cisco CallManager version 4.0 et ultérieure).
User Info for Call Progress Tone : envoie un message d'informations utilisateur H.225 à la passerelle Cisco IOS pour une tonalité de retour d'appel ou une tonalité d'attente (valeur par défaut).
H.225 Info for Call Progress Tone : envoie un message d'information H.225 à la passerelle Cisco IOS pour une tonalité de retour d'appel ou une tonalité d'attente.
Lorsqu'un utilisateur compose un numéro à partir d'un téléphone IP enregistré auprès de Cisco CallManager et destiné à un téléphone IP enregistré auprès de Cisco CallManager Express, la sonnerie n'est pas entendue. Cela se produit même si le téléphone récepteur sonne et que l'appel est terminé.
Afin de résoudre ce problème, ajoutez ces commandes dans le terminal de numérotation dial-peer VoIP qui pointe vers Cisco CallManager à partir de Cisco CallManager Express :
Ajoutez la commande incoming called-number sous le terminal de numérotation dial-peer VoIP qui pointe vers Cisco CallManager.
Ajoutez la commande delay transport-address, qui force le téléphone IP à créer une tonalité de retour d'appel sous le même terminal de numérotation dial-peer.
Remarque : cette commande peut être masquée dans certaines versions de Cisco IOS.
Référez-vous à Activation de l'interfonctionnement avec Cisco CallManager pour plus d'informations.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
19-Apr-2002 |
Première publication |