Ce document aborde certains des problèmes courants qui peuvent se produire dans les conversations sonores à sens unique de téléphonie IP qui impliquent des passerelles Cisco. Les passerelles Cisco couvertes par ce document sont les passerelles et routeurs Cisco IOS®, les commutateurs Catalyst et les passerelles DT-24+.
Ce document est destiné au personnel qui s'occupe des réseaux de téléphonie IP et qui possède des connaissances de base sur les réseaux vocaux.
Ce document n'est pas limité à des versions de matériel ou de logiciel spécifiques.
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, seule l'une des parties reçoit du son (communication unidirectionnelle).
Lorsqu'un appel de contournement est établi entre deux passerelles Cisco, une seule des parties reçoit du son (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 du son (communication unidirectionnelle).
Les causes de l'audio unidirectionnel dans la téléphonie IP peuvent être variées, 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 la passerelle VG200, désactivent le routage IP par défaut. Ce paramètre par défaut entraîne des problèmes de voix unidirectionnelle.
Remarque : avant d'aller plus loin, assurez-vous 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. Étant donné que les flux RTP (Real-Time Transport Protocol) sont sans connexion (transportés via UDP), le trafic peut se déplacer correctement dans une direction, mais se perdre dans la direction opposée. Ce diagramme présente 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 d’établir des appels entre A et B.
Une fois qu'un appel est établi, un flux RTP transportant le son doit circuler dans les deux directions 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 de routage IP afin d'atteindre l'étape où vous pouvez envoyer une requête ping au téléphone A à partir de la passerelle B. N’oubliez pas que la commande ping est une vérification bidirectionnelle.
Ce document ne couvre pas le dépannage du routage IP. Cependant, confirmez ces étapes comme quelques étapes initiales à suivre :
Les passerelles par défaut sont configurées sur les stations d’extrémité.
Les routes IP sur ces passerelles par défaut mènent aux réseaux de destination.
Remarque : Cette liste explique comment vérifier la configuration par défaut du routeur ou de la passerelle sur différents téléphones IP Cisco :
Téléphone IP Cisco 7910 : appuyez sur Paramètres, sélectionnez l'option 6 et appuyez sur le volume jusqu'à ce que le champ Routeur par défaut s'affiche.
Téléphone IP Cisco 7960/40 : appuyez sur Paramètres, sélectionnez l'option 3 et faites défiler la liste jusqu'à ce que le champ Routeur par défaut s'affiche.
Téléphone IP Cisco 2sp+/30vip : appuyez sur **#, puis appuyez sur # jusqu'à ce que gtwy= s'affiche.
Remarque : lorsque vous utilisez l'application Cisco IP SoftPhone et que plusieurs cartes d'interface réseau (NIC) sont installées dans le boîtier, assurez-vous que le boîtier source la carte réseau appropriée. Ce problème est généralement présent dans le logiciel IP SoftPhone version 1.1.x. 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 existe une option Default Gateway (routeur 003) dans l'étendue. Le paramètre de routeur 003 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 acheminera la passerelle.
Si le transcodage est configuré pour une agrégation d'interclusters (ICT), assurez-vous qu'un point de terminaison de support (MTP) est configuré dans le groupe de ressources multimédias et la liste des groupes de ressources multimédias associés à l'agrégation. Si vous spécifiez un MTP lorsqu'il n'est pas nécessaire ou si vous ne configurez pas un MTP si nécessaire, il est connu qu'il cause des problèmes de voix 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 faire référence à une autre adresse source. Cela peut générer différents types de problèmes. Un de ces problèmes est l'audio unidirectionnel.
Pour 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 de 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 provoquer un problème audio unidirectionnel. Pour plus d'informations, référez-vous à l'ID de bogue Cisco CSCdw69681 (clients enregistrés uniquement).
La voix unidirectionnelle peut se produire dans les passerelles MGCP (Media Gateway Control Protocol) si l'interface source pour la signalisation et les paquets de support 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. 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 de la commande mgcp bind sont les suivantes :
Lorsqu'il y a des appels MGCP actifs sur la passerelle, la commande mgcp bind est rejetée pour le contrôle et le support.
Si l'interface de liaison n'est pas activée, la commande est acceptée mais ne prend effet que lorsque l'interface est activée.
Si l'adresse IP n'est pas affectée à l'interface de liaison, la commande mgcp bind est acceptée mais prend effet uniquement 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 tombe en panne, 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 média (MGC), l'adresse IP utilisée pour le contrôle et le support MGCP source 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 le 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 traverser (ouvrir) le chemin audio dans une direction avancée. Cette défaillance entraîne une voix unidirectionnelle. Une solution de contournement consiste à émettre la commande voice rtp send-recv on.
Pour plus d'informations, consultez Cut Through Two-Way Audio Early with the voice rtp send-recv Command on the Cisco IOS Gateway and Routers.
Le chemin vocal est établi dans la direction arrière au début du flux RTP. Le chemin audio de transfert n'est pas coupé tant que la passerelle Cisco IOS n'a pas reçu un message de connexion de l'extrémité distante.
Dans certains cas, il est nécessaire d'établir un chemin audio bidirectionnel dès que le canal RTP est ouvert, c'est-à-dire avant la réception du message Connect. Pour cela, émettez la commande de configuration globale voice rtp send-recv.
Ce problème s'applique à des scénarios, tels que le contournement téléphonique, dans lesquels plusieurs routeurs ou passerelles Cisco IOS sont impliqués dans le chemin vocal et où le protocole RTP compressé (cRTP) est utilisé. cRTP, ou RTP Header Compression, est une méthode permettant de 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 fournit 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 à Consommation de bande passante de la voix sur IP par appel.
cRTP se fait 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'histoire est la suivante :
Dans les versions du logiciel Cisco IOS antérieures à la version 12.0(5)T du logiciel Cisco IOS, 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 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 les plates-formes du logiciel Cisco IOS (version 12.1 du logiciel Cisco IOS), vérifiez que l'ID de bogue Cisco CSCds08210 (clients enregistrés uniquement) n'affecte pas votre version du logiciel Cisco IOS. Le symptôme de ce bogue est l'échec de VoIP et de fax sur IP à fonctionner avec la compression d'en-tête RTP sur.
Si vous constatez qu'il existe des curseurs d'horloge sur l'interface E1 ou T1 à partir du contrôleur show {e1 | t1}, la configuration de synchronisation sur la passerelle vocale peut comporter des incohérences. Référez-vous à Configurations de synchronisation sur les plates-formes vocales IOS et vérifiez 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 les exigences minimales du niveau logiciel. Les versions antérieures de la NAT ne prennent pas en charge la traduction de protocole mince. 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 les passerelles Cisco IOS afin de prendre en charge skinny et H.323 version 2 avec NAT simultanément. Pour plus d'informations, référez-vous à NAT-Support of IP Phone to Cisco CallManager.
Remarque : si votre Cisco CallManager utilise un port TCP pour la signalisation mince qui est 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, consultez 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 contrôleur d'accès. La prise en charge du contrôleur d'accès ne fait pas partie de ce document.
La commande du logiciel Cisco IOS voice-fastpath enable est une commande de configuration globale masquée pour les AS5350 et 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 le 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 de la couche inférieure. Cela permet de réduire l'utilisation du CPU de manière marginale, dans les scénarios de volume d'appels élevé.
Lorsque des services supplémentaires tels que la mise en attente ou le transfert sont utilisés, la commande voice-fastpath entraîne le routeur à diffuser l'audio vers l'adresse IP et le port UDP mis en cache. Les nouvelles informations de canal logique 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 se rendre en permanence à la couche application afin que la redéfinition du canal logique soit prise en compte et que l'audio soit diffusé vers la nouvelle adresse IP et la paire de ports UDP. Par conséquent, veillez à désactiver voice-fastpath afin de prendre en charge les services supplémentaires.
Cisco IP SoftPhone permet à un PC de fonctionner comme un téléphone IP Cisco 7900. Les utilisateurs distants qui se connectent à nouveau 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 vocal unidirectionnel. En effet, le flux multimédia doit connaître le point de terminaison 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 en deux modes : mode client et mode d'extension réseau (NEM). En mode client, tous les hôtes derrière le client VPN Cisco 3002 sont des adresses de port traduites en adresse IP externe du client VPN 3002. La norme H.323 ne fonctionne pas avec la traduction d'adresses de port (PAT) et donne lieu à un signal audio unidirectionnel lorsqu'un téléphone IP est placé derrière un client VPN 3002. Lorsque le VPN 3002 fonctionne dans NEM, les réseaux distants peuvent se voir via leurs adresses IP réelles, et non par 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 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 de voix unidirectionnelle 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 Non, utilisez le mode Extension réseau 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 réseau
Deux commandes utiles pour 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 des appels d'une manière en collectant des informations de trafic d'appels sur le pare-feu PIX. La commande de capture PIX peut être utilisée pour vérifier le port ouvert et utilisé lorsqu'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 résoudre les problèmes.
Ce problème ne peut se produire que dans une configuration d'appel SIP initiale sortante où MTP est requis. Dans ce cas, le message SIP INVITE sortant contient une offre SDP. Le problème peut survenir dans ces scénarios :
Appels de liaison SIP sortants avec point de terminaison de support obligatoire cochés sur la liaison SIP
Appels entre des terminaux IPv6 uniquement et des terminaux IPv4 uniquement
Les ressources MTP peuvent faire l'objet de fuites intermittentes, ce qui entraîne la défaillance des appels SIP qui nécessitent 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 contient a=inactif de manière incorrecte.
Complétez ces étapes afin de résoudre le problème :
Décochez Media Termination Point Required sur la configuration de la ligne principale SIP, si possible.
Si une offre anticipée est requise, configurez l'offre anticipée, mais ne cochez pas Media Termination Point Required.
Pour le déploiement IPv6, utilisez des terminaux à double pile plutôt que des terminaux IPv6 uniquement.
Note : Ceci est documenté dans l'ID de bogue CSCtk77040 (clients enregistrés uniquement).
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
13-Oct-2008 |
Première publication |