Collaboration : Cisco MediaSense

Dépannage des erreurs d'enregistrement d'appels CUCM MediaSense

16 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

Ce document décrit comment dépanner MediaSense quand une erreur apparaît dans l'enregistrement d'appels pour une passerelle intégrée.

Contribué par Pavan Dave et William Ryan Bennett, ingénieurs TAC Cisco.

Écoulement de base d'appel de MediaSense avec la passerelle intégrée

Cette image illustre l'écoulement de base d'appel de MediaSense quand une passerelle intégrée est utilisée : 

Remarque: Le téléphone IP A a l'enregistrement activé.

Ces étapes décrivent l'écoulement d'appel :

  1. Le téléphone IP du côté droit appelle le téléphone IP du côté gauche et initie l'appel par l'intermédiaire de Cisco Unified Communications Manager (CUCM).

  2. Le CUCM envoie un signal au téléphone de destination et se termine l'établissement d'appel.

  3. La connexion entre le téléphone IP A et le téléphone IP B est maintenant installée.

  4. Le profil d'enregistrement sur le téléphone IP A indique que dès qu'il recevra un appel, le CUCM doit installer une session avec MediaSense. Ceci est terminé des millisecondes après qu'étape 3 commence.

  5. L'appel est maintenant installé entre les deux téléphones, l'appel bifurque par l'intermédiaire de la passerelle intégrée, et la passerelle intégrée envoie deux flots de Protocole RTP (Real-Time Transport Protocol) au serveur de MediaSense.

Aucun enregistrement sur MediaSense

Si vous recevez une erreur qui indique qu'il n'y a aucun enregistrement sur MediaSense, alors vous devez visualiser les logs et rechercher cet ID de session :

0000049583: 10.201.227.136: May 28 2014 11:27:09.022 -0400: %CCBU_COMMON-6-VSMS
 HTTP Info: {Thrd=Pool-capture-thread-2800} %[HTTP Response Body=<Session>
   <diskusage>
      <recording name="78e146437088a93-TRACK0" size="0" repository="/
recordedMedia" />
      <recording name="78e146437088a93-TRACK1" size="0"repository="/
recordedMedia" />
   </diskusage>
</Session>][HTTP Response Content Type=application/xml][HTTP Response Status
Code=200][logId=close-25668]: VSMS Received HTTP Response

Le size="0" dans cette sortie indique qu'il n'y a aucun audio enregistré sur le serveur pour cet appel. Ceci signifie typiquement que le flot de RTP n'est pas arrivé au serveur de MediaSense du téléphone. Quand ceci se produit, l'étape suivante est de vérifier que le téléphone envoie le trafic de RTP.

Vérifiez le téléphone IP envoie le trafic

Un moyen rapide de vérifier que le téléphone IP envoie le trafic de RTP est de visualiser la page Web de téléphone IP. Ceci est activé sur CUCM manuellement dans la page de configuration de téléphone ou par l'intermédiaire de l'admin en vrac.

Le flot 1 est l'appel principal avec l'adresse distante de l'autre téléphone IP ou passerelle. Ceci se compose de deux flots : le premier est l'audio qui est reçu sur le téléphone IP et le deuxième est l'audio qui est envoyé à l'autre extrémité.

Afin de vérifier que MediaSense enregistre chacun des deux tronçons d'appel, cliquez sur en fonction le flot 2 et le flot 3 afin de vérifier que les paquets d'expéditeur incrémentent quand la page est régénérée de plusieurs périodes. L'adresse distante devrait afficher le serveur de MediaSense pour le flot 2 et le flot 3. La raison pour laquelle il y a deux flots au serveur de MediaSense est parce que l'un d'entre eux est l'audio reçu sur le flot 1 (paquets de récepteur) et l'autre est l'audio envoyé (des paquets d'expéditeur) à l'autre extrémité sur le flot 1.

Remarque: En référence à l'organigramme d'appel qui est précédemment décrit, étape 3 est le flot 1, et chaque tronçon de l'étape 5 se rapporte au flot 2 et au flot 3.

Cette capture affiche le flot 1 :

Cette capture affiche le flot 2 :

Remarque: Il est important de noter l'adresse IP et le port dans la section d'adresse distante de la page. C'est très important quand vous prenez des captures de paquet pour des appels téléphoniques de téléphone de test.

Cette capture affiche le flot 3 :

Quand vous vérifiez les données pour le flot 2 et le flot 3, les choses principales à rechercher sont :

  • L'adresse distante est l'adresse IP du serveur de MediaSense.

  • Le numéro de port sur chaque flot est seul.

  • Quand vous régénérez la page, le nombre de paquets d'expéditeur augmente.

Ceci indique que les paquets de RTP sont envoyés par le téléphone IP.

Effectuez les captures de paquet

Si vous êtes encore incertain si le téléphone IP envoie les paquets de RTP, la prochaine ligne de conduite est d'effectuer une capture de paquet et de rejouer les flots.

Avant que vous effectuiez les captures de paquet, assurez-vous que ces configurations sur la configuration de téléphone IP pour CUCM sont activées :

  • Envergure au port PC
  • Accès de la Voix VLAN PC
  • Port PC

Puis, appliquez la configuration et remettez à l'état initial le téléphone IP. Après que ce soit complet, Wireshark ouvert et prennent une capture de paquet avec une durée 30-second. Assurez-vous que vous enregistrez l'adresse distante aussi bien que le port pour le flot 2 et le flot 3 du téléphone IP en question. Exemple :

  • Flot 2 - 10.201.227.147/40676
  • Flot 3 - 10.201.227.147/33358

Une fois que les captures de paquet sont complètes, ouvrez la capture de paquet et terminez-vous ces étapes pour chaque flot :

  1. Filtrez par le == 40676 du && udp.port de 10.201.227.147 de == ip.addr.

  2. Naviguez pour analyser > décodent As.

  3. Dans la fenêtre contextuelle, RTP choisi un cliquer sur OK.

  4. Naviguez vers la téléphonie > le RTP > l'analyse de flot.

  5. Dans l'analyse de flot de RTP, naviguez vers le lecteur > décodent > jeu, et vérifient que les deux tronçons de l'appel sont entendus.

  6. Répétez les étapes 1 à 4 pour l'autre flot et mettez en communication.

Dépannez

Après que vous effectuiez la capture de paquet et vous vérifiiez que MediaSense est configuré correctement et que le téléphone IP envoie un flot valide de RTP au serveur de MediaSense, et continuiez à rencontrer des questions, puis le chemin entre le serveur et le téléphone IP devrait être vérifié.

Assurez-vous que le chemin n'a aucun Listes de contrôle d'accès (ACL) et qu'il ne bloque pas ou filtre le trafic de RTP.

Remarques importantes

Si l'appel qui est installé avec CUCM est en question, alors l'aspect dans le CUCM détaillé se connecte, et ouvre la commande de logins de MediaSense pour trouver l'ID d'appel. Ceci peut être trouvé de l'ID de session, et semble semblable à ceci dans les logs de Contrôle d'appel :

CallId: 74acba00-38c1ea2d-3a2937-f183000a@10.0.131.241
CallId: 74acba00-38c1ea2d-3a2938-f183000a@10.0.131.241

Puisque le téléphone IP installent deux flots avec MediaSense, on pour chaque tronçon de l'appel téléphonique d'origine, recherchent les logs CUCM avec un des id d'appel afin de vérifier si la session de MediaSense est installée correctement.


Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Document ID: 117788