Voix et communications unifiées : Cisco Unified Personal Communicator

CUPC 8.x : Incapable de faire un appel vidéo par CUCM 8.5

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


Contenu


Introduction

Le Cisco Unified Personal Communicator (CUPC) 8.5.1 sur le bit des Windows Vista 32 ne met pas en marche le vidéo sur les deux extrémités. Avec le mode de téléphone IP sur CUPC, vous pouvez voir que la caméra et l'endroit une option d'appel vidéo est disponible, mais vous ne pouvez pas voir le vidéo sur les deux extrémités. Ce document décrit comment résoudre ce problème.

Conditions préalables

Conditions requises

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

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

  • CUPC 8.x

  • Serveur 8.x de Cisco Unified Presence

  • Cisco Unified Communications Manager (CUCM) 8.x

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

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

Problème

CUPC 8.5.1 ne voit pas le vidéo sur l'un ou l'autre d'extrémité, quoique l'endroit une option d'appel vidéo soit disponible. La question est que CUPC 8.5 ne peut pas faire un appel vidéo (linéaire) en mode de téléphone IP. Spécifiquement, les deux côtés détectent la caméra vidéo, le « endroit option de l'appel vidéo » est disponible, et l'appel intervient, mais le vidéo n'apparaît pas pour quelque raison.

Solution

Quand le support tôt doit être fourni POUR SIROTER des points finaux avant la connexion, CUCM envoie toujours un message d'avancement de 183 sessions avec le SDP. Bien que CUCM ne génère pas un message d'alerte 180 avec le SDP, il prend en charge le message d'alerte 180 avec le SDP quand il reçoit un. La question ici est celle même après que le client envoie sa capacité, CUCM peut envoyer un message d'avancement de session avec le SDP inactif pour le vidéo.

Après que des capacités initiales soient envoyées à CUCM, il appartient à CUCM pour décider quels paramètres seront utilisés, et envoie en fonction au SIP aux deux extrémités avec des paramètres négociés. Afin de vérifier ceci, se terminer ces étapes et prendre les logs :

  1. Assurez-vous que le log de Cisco Unified Communications Manager est placé au détaillé/met au point de niveau avec toutes les cases à cocher a vérifié tous les serveurs. (Vous pouvez vouloir exécuter le débogage pendant un temps à faible trafic.)

  2. Quittez hors de CUPC des deux côtés.

  3. Le SSH dans l'éditeur CUCM, état d'exposition de type, et notent le temps.

  4. En outre, notez l'heure locale des deux postes de travail où CUPC est installé.

  5. Installez Wireshark sur les deux postes de travail (www.wireshark.orgleavingcisco.com ).

  6. Commencez Wireshark sur l'interface appropriée sur des les deux poste de travail.

  7. Début CUPC sur les deux postes de travail.

  8. Commencez un appel vidéo.

  9. Arrêtez l'appel vidéo et collectez ces informations :

    • Le log CUCM pour tout divise (Publisher et abonné) pour les 5 dernières minutes ou ainsi couvrant le test (c'est très l'importation pour avoir les logs à un niveau d'analyse détaillé)

    • Capture Wireshark des deux postes de travail

    • Rapport sur les problèmes CUPC des deux côtés

    • L'ID utilisateur de les deux côtés, aussi bien qu'appeler et le DN appelé

    • La période de l'appel que vous avez noté vers le bas dans l'étape 3 et 4

    • IP des postes de travail et des serveurs CUCM

  10. Voici le résumé des logs de la question trouvée :

    15379 : m=video 0 RTP/AVP 31 34 96 97
    
    15380 : c=IN IP4 0.0.0.0
    
    15381 : a=rtpmap:31 H261/90000
    
    15382 : a=fmtp:31 MAXBR=224
    
    15383 : a=rtpmap:34 H263/90000
    
    15384 : a=fmtp:34 MAXBR=225
    
    15385 : a=rtpmap:96 H263-1998/90000
    
    15386 : a=rtpmap:97 H264/90000
    
    15387 : a=inactive

Du log, vous pouvez voir que CUCM envoie que le vidéo ne devrait pas être utilisé. Afin de résoudre ce problème, diminuez le débit binaire à 2k dans la région CUCM où le Pool d'appareils du téléphone CSF se trouve.

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.


Informations connexes


Document ID: 113263