Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit les problèmes courants qui peuvent survenir dans les conversations audio unidirectionnelles de téléphonie IP impliquant des passerelles Cisco.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Ce document n'est pas limité à des versions de matériel ou de logiciel spécifiques.
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. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
Ce document fournit des scénarios et des solutions à ces problèmes :
Lorsqu'un appel téléphonique est établi à partir d'une station IP via une passerelle vocale ou un routeur Cisco IOS, une seule des parties reçoit des données audio (communication unidirectionnelle).
Lorsqu'un appel de contournement de réseau interurbain est établi entre deux passerelles Cisco, une seule des parties reçoit des données audio (communication unidirectionnelle).
Lorsqu'un appel téléphonique est établi à partir d'une station IP placée derrière un client matériel VPN 3002, une seule des parties reçoit l'audio (communication unidirectionnelle).
Les causes de l'audio unidirectionnel dans la téléphonie IP peuvent varier, mais la racine du problème implique généralement des problèmes de routage IP. Cette section présente quelques-uns des scénarios et des solutions qui ont été trouvés sur le terrain.
Certaines passerelles Cisco IOS, telles que le VG200, désactivent le routage IP par défaut. Ce paramètre par défaut entraîne des problèmes vocaux unidirectionnels.
Remarque : avant de continuer, vérifiez que le routage IP est activé sur votre routeur. En d'autres termes, assurez-vous que votre routeur ne dispose pas de la commande de configuration globale no ip routing.
Afin d'activer le routage IP, émettez cette commande de configuration globale sur votre passerelle Cisco IOS :
voice-ios-gwy(config)#ip routing
Vérifiez toujours d'abord l'accessibilité IP de base. Comme les flux RTP (Real-Time Transport Protocol) sont non orientés connexion (transportés via UDP), le trafic peut circuler correctement dans une direction, mais se perdre dans la direction opposée. Ce diagramme montre un scénario dans lequel ceci peut se produire :
Les sous-réseaux A et B peuvent atteindre le sous-réseau X. Le sous-réseau X peut atteindre les sous-réseaux A et B. Cela permet d'établir des connexions TCP entre les stations d'extrémité (A et B) et Cisco CallManager. Par conséquent, la signalisation peut atteindre les deux stations d'extrémité sans aucun problème, ce qui permet l'établissement d'appels entre A et B.
Une fois qu'un appel est établi, un flux RTP qui transporte l'audio doit circuler dans les deux sens entre les stations d'extrémité. Dans certains cas, le sous-réseau B peut atteindre le sous-réseau A, mais le sous-réseau A ne peut pas atteindre le sous-réseau B. Par conséquent, le flux audio de A à B est toujours perdu.
Il s’agit d’un problème de routage de base. Utilisez les méthodes de dépannage du routage IP afin d'atteindre l'étape à laquelle vous pouvez envoyer une requête ping au téléphone A à partir de la passerelle B. N'oubliez pas que la requête ping est une vérification bidirectionnelle.
Ce document ne couvre pas le dépannage du routage IP. Cependant, assurez-vous que les étapes suivantes sont bien les suivantes :
Les passerelles par défaut sont configurées au niveau des stations d'extrémité.
Les routes IP sur ces passerelles par défaut mènent aux réseaux de destination.
Cette liste explique comment vérifier la configuration par défaut du routeur ou de la passerelle sur divers téléphones IP Cisco :
Téléphone IP Cisco 7910 : appuyez sur Settings, sélectionnez l'option 6, puis appuyez sur la touche Volume jusqu'à ce que le champ Default Router (Routeur par défaut) s'affiche.
Téléphone IP Cisco 7960/40 : appuyez sur Settings, sélectionnez l'option 3, puis faites défiler la liste jusqu'à ce que le champ Default Router (Routeur par défaut) s'affiche.
Téléphone IP Cisco 2sp+/30vip : appuyez sur **#, puis sur # jusqu'à ce que gtwy= s'affiche.
Remarque : lorsque vous utilisez l'application Cisco IP SoftPhone et que plusieurs cartes réseau sont installées dans le boîtier, assurez-vous que celui-ci fournit la carte réseau appropriée. Ce problème est souvent présent dans la version 1.1.x du logiciel IP SoftPhone. La version 1.2 doit résoudre ce problème.
Remarque : lorsque vous utilisez des passerelles Cisco DT-24+, vérifiez l'étendue DHCP et assurez-vous qu'il y a une option Default Gateway (003 router) dans l'étendue. Le paramètre 003 router renseigne le champ Default Gateway (Passerelle par défaut) dans les périphériques et les PC. L'option d'étendue 3 doit avoir l'adresse IP de l'interface du routeur qui peut effectuer le routage pour la passerelle.
Si le transcodage est configuré pour une agrégation intercluster (ICT), assurez-vous qu'un point de terminaison média (MTP) est configuré dans le groupe de ressources média et la liste de groupes de ressources média associés à l'agrégation. Si vous spécifiez un MTP lorsqu'il n'est pas nécessaire, ou si vous ne parvenez pas à configurer un MTP s'il est nécessaire, il est connu qu'il provoque des problèmes vocaux unidirectionnels pour les configurations ICT.
Lorsque la passerelle Cisco IOS a plusieurs interfaces IP actives, une partie de la signalisation H.323 peut provenir d'une adresse IP et d'autres parties de celle-ci peuvent référencer une adresse source différente. Cela peut générer différents types de problèmes. L'audio unidirectionnel est l'un de ces problèmes.
Afin de contourner ce problème, vous pouvez lier la signalisation H.323 à une adresse source spécifique. L’adresse source peut appartenir à une interface physique ou virtuelle (bouclage). Utilisez la commande h323-gateway voip bind srcaddr ip-address en mode de configuration d'interface. Configurez cette commande sous l'interface avec l'adresse IP vers laquelle pointe Cisco CallManager.
Cette commande a été introduite dans le logiciel Cisco IOS Version 12.1(2)T. Référez-vous à Prise en charge H.323 pour les interfaces virtuelles.
Attention : il existe un bogue dans le logiciel Cisco IOS Version 12.2(6) dans lequel cette solution peut réellement causer un problème audio unidirectionnel. Pour plus d'informations, référez-vous au bogue Cisco ID CSCdw69681. Seuls les utilisateurs Cisco enregistrés peuvent accéder aux informations et aux outils Cisco internes.
La voix unidirectionnelle peut se produire dans les passerelles MGCP (Media Gateway Control Protocol) si l'interface source pour la signalisation et les paquets multimédias n'est pas spécifiée. Vous pouvez lier le support MGCP à l'interface source si vous émettez la commande mgcp bind media source-interface interface-id puis la commande mgcp bind control source-interface interface-id erasecat4000_flash:. Réinitialisez la passerelle MGCP dans Cisco CallManager après avoir exécuté les commandes.
Si la commande mgcp bind n'est pas activée, la couche IP fournit toujours la meilleure adresse locale.
Les instructions pour la commande mgcp bind sont les suivantes :
Quand il y a des appels MGCP actifs sur la passerelle, la commande mgcp bind est rejetée pour le contrôle et le média.
Si l'interface de liaison n'est pas active, la commande est acceptée mais ne prend effet qu'une fois l'interface active.
Si l'adresse IP n'est pas attribuée sur l'interface bind, la commande mgcp bind est acceptée mais ne prend effet qu'après l'attribution d'une adresse IP valide. Pendant ce temps, si les appels MGCP sont actifs, la commande mgcp bind est rejetée.
Lorsque l’interface liée est désactivée, soit en raison d’un arrêt manuel sur l’interface, soit en raison d’une défaillance opérationnelle, l’activité de liaison est désactivée sur cette interface.
Lorsque la liaison n'est pas configurée sur le contrôleur de passerelle de support (MGC), l'adresse IP utilisée pour le contrôle MGCP source et le support est la meilleure adresse IP disponible.
Si vous disposez d'une passerelle Cisco IOS qui se connecte à un opérateur téléphonique ou à un commutateur, vérifiez que la supervision des réponses est envoyée correctement lorsque le périphérique appelé derrière l'opérateur téléphonique ou le commutateur répond à l'appel. Si vous ne recevez pas la supervision des réponses, la passerelle Cisco IOS ne peut pas couper (ouvrir) le chemin audio vers l'avant. Cette défaillance entraîne une voix unidirectionnelle. Une solution de contournement est d'émettre la commande voice rtp send-recv on.
Pour plus d'informations, consultez Couper tôt le son bidirectionnel avec la commande voice rtp send-recv sur la passerelle et les routeurs Cisco IOS.
Le chemin vocal est établi dans le sens inverse au début du flux RTP. Le chemin audio de transfert n'est pas coupé jusqu'à ce que la passerelle Cisco IOS reçoive un message de connexion de l'extrémité distante.
Dans certains cas, il est nécessaire d'établir un chemin audio bidirectionnel dès l'ouverture du canal RTP, c'est-à-dire avant la réception du message Connect. Pour ce faire, émettez la commande de configuration globale voice rtp send-recv.
Ce problème s'applique à des scénarios, tels que le contournement de péage, dans lesquels plusieurs routeurs ou passerelles Cisco IOS sont impliqués dans le chemin vocal et le protocole RTP compressé (cRTP) est utilisé. cRTP, ou compression d'en-tête RTP, est une méthode pour réduire les en-têtes de paquets VoIP afin de récupérer la bande passante. cRTP prend l'en-tête IP, UDP (User Datagram Protocol) ou RTP de 40 octets sur un paquet VoIP et le compresse à 2 à 4 octets par paquet. Cette compression génère environ 12 kbits/s de bande passante pour un appel codé G.729 avec cRTP. Pour plus d'informations sur cRTP, référez-vous à Voice Over IP - Per Call Bandwidth Consumption.
cRTP est effectué saut par saut, avec décompression et recompression à chaque saut. Chaque en-tête de paquet doit être examiné pour le routage. Par conséquent, cRTP doit être activé des deux côtés d'une liaison IP.
Il est également important de vérifier que cRTP fonctionne comme prévu aux deux extrémités de la liaison. Les niveaux de version du logiciel Cisco IOS varient en termes de chemins de commutation et de prise en charge simultanée de cRTP.
En résumé, l'historique est le suivant :
Dans les versions du logiciel Cisco IOS antérieures à la version 12.0(5)T, cRTP est commuté par processus.
Dans le logiciel Cisco IOS version 12.0(7)T et dans le logiciel Cisco IOS version 12.1(1)T, la prise en charge de la commutation Fast Forwarding (CEF) et Cisco Express Forwarding (CEF) pour cRTP est introduite.
Dans le logiciel Cisco IOS Version 12.1(2)T, des améliorations des performances algorithmiques sont introduites.
Si vous exécutez cRTP sur des plates-formes logicielles Cisco IOS (Logiciel Cisco IOS Version 12.1), vérifiez que l'ID de bogue Cisco CSCds08210 n'affecte pas votre version du logiciel Cisco IOS. Le symptôme de ce bogue est l'échec de la VoIP et de la télécopie sur IP à fonctionner avec la compression d'en-tête RTP sur.
Seuls les utilisateurs Cisco enregistrés peuvent accéder aux informations de bogue et aux outils internes de Cisco.
Si vous trouvez qu'il y a des glissements d'horloge sur l'interface E1 ou T1 à partir de la commande show controller {e1 | t1}, il peut y avoir une incohérence dans la configuration de synchronisation sur la passerelle vocale. Référez-vous à Configurations de synchronisation sur les plates-formes basées sur Cisco IOS compatibles voix et assurez-vous que les configurations de synchronisation sur la passerelle vocale sont correctes.
Si vous utilisez la traduction d'adresses de réseau (NAT), vous devez respecter la configuration logicielle minimale requise. Les versions antérieures de NAT ne prennent pas en charge la traduction de protocole skinny. Ces versions antérieures entraînent des problèmes de voix unidirectionnelle.
Vous devez exécuter le logiciel Cisco IOS version 12.1(5)T ou ultérieure pour que les passerelles Cisco IOS prennent en charge simultanément skinny et H.323 version 2 avec NAT. Pour plus d'informations, référez-vous à Prise en charge NAT du téléphone IP vers Cisco CallManager.
Remarque : si votre Cisco CallManager utilise un port TCP pour la signalisation skinny différent du port par défaut (2000), vous devez ajuster le routeur NAT. Exécutez la commande de configuration globale ip nat service skinny tcp port number.
Le niveau logiciel minimum requis pour utiliser NAT et skinny simultanément sur un pare-feu PIX est 6.0. Pour plus d'informations, référez-vous à Cisco PIX Firewall Version 6.0.
Remarque : ces niveaux de logiciel ne prennent pas nécessairement en charge tous les messages RAS (Registration, Admission, and Status) nécessaires à la prise en charge complète du portier. La prise en charge des portiers sort du cadre de ce document.
La commande voice-fastpath enable du logiciel Cisco IOS est une commande de configuration globale masquée pour l'AS5350 et l'AS5400. La commande est activée par défaut. Afin de le désactiver, émettez la commande de configuration globale no voice-fastpath enable.
Lorsque la commande est activée, elle met en cache l'adresse IP et les informations de numéro de port UDP pour le canal logique ouvert pour un appel spécifique. La commande empêche le flux RTP d’atteindre la couche application. Au lieu de cela, les paquets sont transférés au niveau d'une couche inférieure. Cela permet de réduire légèrement l'utilisation du processeur, dans des scénarios de volume d'appels élevé.
Lorsque des services supplémentaires tels que l'attente ou le transfert sont utilisés, la commande voice-fastpath amène le routeur à diffuser l'audio à l'adresse IP et au port UDP mis en cache. Les nouvelles informations de canal logique qui sont générées après la reprise d'un appel en attente ou après la fin d'un transfert sont ignorées. Afin de contourner ce problème, le trafic doit aller à la couche application constamment afin que la redéfinition du canal logique soit prise en compte et que l'audio soit diffusé en continu vers la nouvelle paire d'adresses IP et de ports UDP. Par conséquent, assurez-vous de désactiver voice-fastpath afin de prendre en charge des services supplémentaires.
Cisco IP SoftPhone permet à un PC de fonctionner comme un téléphone IP Cisco 7900. Les utilisateurs distants qui se reconnectent au réseau de leur entreprise via un réseau privé virtuel (VPN) doivent configurer des paramètres supplémentaires afin d'éviter un problème de voix unidirectionnelle. En effet, le flux multimédia doit connaître le point d’extrémité de la connexion.
La solution consiste à configurer l'adresse IP VPN, au lieu de l'adresse IP de la carte réseau, sous Network Audio Settings. Pour plus d'informations, référez-vous à Comment utiliser Cisco IP SoftPhone sur VPN.
Un client matériel Cisco VPN 3002 peut fonctionner dans deux modes : le mode client et le mode d'extension de réseau (NEM). En mode client, tous les hôtes derrière le client Cisco VPN 3002 sont des adresses de port traduites en adresses IP externes du client VPN 3002. H.323 ne fonctionne pas avec la traduction d'adresses de port (PAT) et produit un son unidirectionnel lorsqu'un téléphone IP est placé derrière un client VPN 3002. Lorsque le VPN 3002 fonctionne en mode NEM, les réseaux distants peuvent se voir via leurs adresses IP réelles, et non via une adresse IP basée sur NAT ou PAT. Si le VPN 3002 est configuré pour fonctionner dans NEM, H.323 peut fonctionner. En d'autres termes, les téléphones IP qui sont derrière un client VPN 3002 ne peuvent fonctionner que lorsque VPN 3002 fonctionne dans NEM. Par conséquent, afin d'éviter les problèmes vocaux unidirectionnels avec un client VPN 3002, configurez le client VPN 3002 pour utiliser NEM.
Afin de configurer le client matériel Cisco VPN 3002 pour utiliser NEM, choisissez Configuration > Quick > PAT et cliquez sur No, use Network Extension mode dans la fenêtre PAT.
Pour plus d'informations, référez-vous à Configuration du client matériel Cisco VPN 3002 sur le routeur Cisco IOS avec EzVPN en mode d'extension de réseau
Deux commandes utiles à utiliser afin de vérifier le flux de paquets sont la commande debug cch323 rtp et la commande debug voip rtp. La commande debug cch323 rtp affiche les paquets qui sont transmis (X) et reçus (R) par le routeur. Un caractère majuscule indique une transmission ou une réception réussie. Un caractère minuscule indique un paquet abandonné.
voice-ios-gwy#debug cch323 rtp RTP packet tracing is enabled voice-ios-gwy# voice-ios-gwy# voice-ios-gwy# voice-ios-gwy# voice-ios-gwy# !--- This is an unanswered outgoing call. !--- Notice that the voice path only cuts through in the forward direction and
!--- that packets are dropped. Indeed, received packets are traffic from the !--- IP phone to the PSTN phone. These are dropped until the call is answered. Mar 3 23:46:23.690: ****** cut through in FORWARD direction ***** XXXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr XrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr XrXrXXrrrrrrrrrrrrrrrr voice-ios-gwy# voice-ios-gwy# !--- This is an example of an answered call: voice-ios-gwy# voice-ios-gwy# *Mar 3 23:53:26.570: ****** cut through in FORWARD direction ***** XXXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr XrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr XXrrrrrXrXrXrXrXrXrXrXrXrXrXrXrrXXrrXrXrXrXrXrXXXXXXXXXXXXXXXXrXXXXXXXXrXrXrXXrrXr XrXrXrXrXrXrXrXrXXrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr !--- At this point, the remote end picks up the phone. *Mar 3 23:53:30.378: ****** cut through in BOTH direction ***** XRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXR XXRRXRXRXXRRXRXRXRXRXXRXRXRXRXRXRRXRXXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR RRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRXXRXRXRXRXRXRRXRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR XXRRRRRRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXXRRRXR !--- This is the end of the conversation.
Remarque : dans le logiciel Cisco IOS version 12.2(11)T et ultérieure, la commande debug cch323 rtp command-line interface (CLI) a été remplacée par la commande debug voip rtp.
voice-ios-gwy#debug voip rtp --------cut through in BOTH direction------------------- *Mar 27 19:52:08.259: RTP(32886): fs rx d=10.48.79.181(20002), pt=0, ts=4FFBF0, ssrc=8E5FC294 *Mar 27 19:52:08.275: RTP(247): fs tx d=10.48.79.181(20002), pt=0, ts=5D00C8D9, ssrc=1F1E5093 *Mar 27 19:52:08.279: RTP(32887): fs rx d=10.48.79.181(20002), pt=0, ts=4FFC90, ssrc=8E5FC294 *Mar 27 19:52:08.295: RTP(248): fs tx d=10.48.79.181(20002), pt=0, ts=5D00C979, ssrc=1F1E5093 *Mar 27 19:52:08.299: RTP(32888): fs rx d=10.48.79.181(20002), pt=0, ts=4FFD30, ssrc=8E5FC294 *Mar 27 19:52:08.315: RTP(249): fs tx d=10.48.79.181(20002), pt=0, ts=5D00CA19, ssrc=1F1E5093 *Mar 27 19:52:08.319: RTP(32889): fs rx d=10.48.79.181(20002), pt=0, ts=4FFDD0, ssrc=8E5FC294 *Mar 27 19:52:08.335: RTP(250): fs tx d=10.48.79.181(20002), pt=0, ts=5D00CAB9, ssrc=1F1E5093 *Mar 27 19:52:08.339: RTP(32890): fs rx d=10.48.79.181(20002), pt=0, ts=4FFE70, ssrc=8E5FC294 *Mar 27 19:52:08.355: RTP(251): fs tx d=10.48.79.181(20002), pt=0, ts=5D00CB59, ssrc=1F1E5093 *Mar 27 19:52:08.359: RTP(32891): fs rx d=10.48.79.181(20002), pt=0, ts=4FFF10, ssrc=8E5FC294 *Mar 27 19:52:08.375: RTP(252): fs tx d=10.48.79.181(20002), pt=0, ts=5D00CBF9, ssrc=1F1E5093 *Mar 27 19:52:08.379: RTP(32892): fs rx d=10.48.79.181(20002), pt=0, ts=4FFFB0, ssrc=8E5FC294 *Mar 27 19:52:08.395: RTP(253): fs tx d=10.48.79.181(20002), pt=0, ts=5D00CC99, ssrc=1F1E5093 *Mar 27 19:52:08.399: RTP(32893): fs rx d=10.48.79.181(20002), pt=0, ts=500050, ssrc=8E5FC294 *Mar 27 19:52:08.976: RTP(282): fs tx d=10.48.79.181(20002), pt=0, ts=5D00DEB9, ssrc=1F1E5093 *Mar 27 19:52:08.980: RTP(32922): fs rx d=10.48.79.181(20002), pt=0, ts=501270, ssrc=8E5FC294 *Mar 27 19:52:08.996: RTP(283): fs tx d=10.48.79.181(20002), pt=0, ts=5D00DF59, ssrc=1F1E5093 *Mar 27 19:52:09.000: RTP(32923): fs rx d=10.48.79.181(20002), pt=0, ts=501310, ssrc=8E5FC294 *Mar 27 19:52:09.016: RTP(284): fs tx d=10.48.79.181(20002), pt=0, ts=5D00DFF9, ssrc=1F1E5093
Vous pouvez dépanner les appels unidirectionnels en collectant des informations sur le trafic d'appels à travers le pare-feu PIX. La commande PIX capture peut être utilisée pour vérifier le port ouvert et utilisé quand un appel se produit. Référez-vous à Gérer le trafic VoIP avec le pare-feu PIX pour plus d'informations sur le trafic VoIP à travers le pare-feu PIX.
Remarque : veillez à désactiver la commande capture après avoir généré les fichiers de capture dont vous avez besoin pour le dépannage.
Ce problème ne peut se produire que dans une configuration d'appel SIP initial sortant où MTP est requis. Dans ce cas, le message SIP INVITE sortant peut contenir une offre SDP. Le problème peut se produire dans les scénarios suivants :
Appels sortants de la liaison SIP avec Media Termination Point Required coché sur la liaison SIP
Appels entre des terminaux IPv6 uniquement et des terminaux IPv4 uniquement
Des fuites de ressources MTP peuvent se produire par intermittence, ce qui entraîne l’échec d’appels SIP nécessitant des ressources MTP. À partir de RTMT, les ressources MTP disponibles atteignent 0 et le nombre d'échecs d'allocation MTP augmente pour chaque appel nécessitant un MTP. La partie SDP de l'invitation initiale peut contenir a=inactive de manière incorrecte.
Complétez ces étapes afin de résoudre le problème :
Si possible, désactivez la case Media Termination Point Required sur la configuration de la ligne principale SIP.
Si l'option Early Offer est requise, configurez Early Offer, mais laissez la case Media Termination Point Required décochée.
Pour le déploiement IPv6, utilisez une double pile plutôt que des terminaux IPv6 uniquement.
Remarque : ceci est documenté dans l'ID de bogue Cisco CSCtk77040. Seuls les utilisateurs Cisco enregistrés peuvent accéder aux informations et aux outils de bogue Cisco internes.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
11-Oct-2001 |
Première publication |