Dépannez les étapes pour suivre quand le CUBE n'est pas découvert comme Border Element dans le PCA

Introduction

Ce document décrit les étapes à suivre pour dépanner quand le Logiciel Cisco Unified Border Element (CUBE) n'est pas découvert comme Border Element dans l'assurance principale de Collaboration (PCA).

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• PCA
• Cisco Unified Communications Manager (CUCM)
• CUBE

Composants utilisés

Les informations dans ce document sont basées sur l'assurance principale de Collaboration.

  

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.

Étapes à suivre si le CUBE n'est pas découvert comme Border Element dans le PCA

Pour qu'un CUBE soit identifié comme Border Element dans le PCA :

1. a. Déploiement de Non-CUCM : Ces conditions devraient être satisfaites :

Condition 1 : Le modèle de périphérique devrait être dans la liste de Plateformes prises en charge (http://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-border-element/data-sheet-c78-729692.html?cachemode=refresh,) - tableau 2.

Condition 2 : Le SIP-UA-MIB devrait renvoyer la valeur autre que le noSuchObject/noSuchInstance pour SipCfgPeerTable.

1. b. Déploiement CUCM : Ces conditions devraient être satisfaites :

Condition 1 : Le modèle de périphérique devrait être dans la liste de Plateformes prises en charge (http://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-border-element/data-sheet-c78-729692.html?cachemode=refresh,) - tableau 2.

Condition 2 : Le SIP-UA-MIB devrait renvoyer la valeur autre que le noSuchObject/noSuchInstance pour SipCfgPeerTable.

Condition 3 : L'IP address de périphérique doit être associé avec le joncteur réseau de SIP d'un du CUCM.

Pour qu'un périphérique soit identifié comme fournisseur de services de CUBE, il devrait être d'abord identifié pendant que le CUBE et lui devraient répondre à CISCO_SESS_BORDER_CTRLR_CALL_STATS_MIB.csbSIPMthdCurrentStatsAdjName (1.3.6.1.4.1.9.9.757.1.3.1.1)

Si ces conditions sont remplies et le PCA n'identifie toujours pas le périphérique comme Border Element, alors vérifiez si la configuration sur CUCM et périphérique.

Le Cube-Side de l'intégration de CUCM-à-CUBE

Quand vous premier installez un CUBE, vous devez permettre au routeur afin de conduire des appels comme un CUBE. Cette image affiche une configuration de base du service vocal VoIP sur un CUBE :

Voici quelques points importants au sujet de cette configuration :

• La première ligne de la configuration est le cadre-élément de mode, que les enables CUBENT sur un routeur. Quelques périphériques n'ont pas cette configuration quand ils fonctionnent comme CUBE.
• L'allow-connections sirote pour siroter permet au CUBE de recevoir des appels de Protocole SIP (Session Initiation Protocol) et de les conduire pendant que le SIP appelle. Il y a des options pour le h323 aussi bien.
• Le protocole t38 de télécopie est une configuration par défaut pour des Routeurs d'ISR G2. Il n'est pas nécessaire pour la configuration de CUBE.
• L'early-offer forcé permet au CUBE pour conduire des appels dans une offre retardée au scénario tôt d'offre. Presque tous les fournisseurs exigent des appels tôt de SIP d'offre. Il est recommandé réellement pour envoyer l'offre tôt de CUCM afin d'éviter les questions tôt de cut-through de medias.
• Le passthru de midcall-signaling est seulement pour des appels de Sip-à-SIP. On l'exige pour que quelques services supplémentaires fonctionnent.
• Le g729 annexb-all est optimal dans les cas où le CUBE est en pourparlers avec les fournisseurs qui ne suivent pas le format RFC pour les codecs G729r8 et G729br8.

Configuration de Cadran-pair sur le CUBE

les Cadran-pairs sur le CUBE sont comme d'autres cadran-pairs sur des passerelles de Cisco IOS. La différence est que l'artère d'appels d'un homologue de numérotation VoIP à un autre homologue de numérotation VoIP.

Notez qu'il y a deux cadran-pairs ici : entrant et sortant. Le CUBE apparie toujours deux cadran-pairs. Les homologues de numérotation en entrée sont du point de vue de CUBE, du CUCM ou du fournisseur de SIP. Des cadran-pairs sortants sont envoyés vers le CUCM ou au fournisseur de SIP.

ICisco recommande que vous exécutiez la majeure partie de la Manipulation de chiffres sur CUCM par les chiffres significatifs, le masque externe de numéro de téléphone, et les traductions.

Référez-vous compréhension derrière les homologues de numérotation entrante et sortante étant assortis sur l'article de plates-formes IOS pour plus d'informations sur des cadran-pairs.

La Manipulation de chiffres peut être exécutée sur le CUBE de la même manière qu'elle est exécutée sur des Passerelles voix de Cisco IOS. Référez-vous à la conversion de numéros utilisant le pour en savoir plus d'article de profils de traduction de Voix.

Adressage IP de base

L'adressage IP sur le CUBE est accompli la même manière que sur d'autres périphériques de Cisco IOS, mais il emploie la table de routage afin de déterminer à partir de quelle interface les sources de CUBE SIROTENT le trafic. La commande du show ip route A.B.C.D fournit des informations au sujet de l'interface que le CUBE utilise le trafic de SIP de source. C'est important quand des appels sont envoyés à CUCM et quand des appels sont envoyés à un fournisseur de SIP. Les artères statiques pourraient être nécessaires afin de faire ce travail.

Dans certains cas, vous pourriez devoir lier le SIP à une interface spécifique, telle qu'une interface de bouclage sur le CUBE. L'attache de SIP peut entraîner des effets secondaires, comme quand le CUBE n'écoute pas le trafic de SIP sur une interface spécifique. Cisco recommande que vous pas utilisiez des attaches et permettiez la table de routage de décider, mais ce n'est pas toujours possible. Vous pouvez appliquer des attaches de SIP sous le service vocal VoIP > SIP, ou sur différents cadran-pairs. Des attaches de SIP sont expliquées plus dans l'article de caractéristiques configurant de grippage de SIP.

Codecs de Voix-classe sur le CUBE

des codecs de Voix-classe sont utilisés pour le CUBE afin d'offrir de plusieurs codecs quand les appels utilisent un homologue de numérotation VoIP particulier. C'est identique comme il était sur une passerelle de Voix de Cisco IOS, mais quand c'est un CUBE, des codecs sont filtrés d'un tronçon d'appel VoIP à l'autre. Il utilise les codecs qui sont disponibles sur l'homologue de numérotation en entrée et le cadran-pair sortant. Les codecs qui apparient chacun des deux sont envoyés à des offres. Quand le CUBE reçoit un message SIP avec la Session Description Protocol (SDP), il apparie également ceci contre les codecs de Voix-classe. Ceci permet au CUBE pour filtrer des codecs basés sur ce qui est reçu du message SIP avec le SDP, de l'homologue de numérotation en entrée, et de l'homologue de numérotation en sortie. L'autre l'agent d'utilisateur de SIP (uA) répond alors aux codecs offerts.

La voice class codec dans l'image précédente contient trois codecs, g729r8, g711ulaw, ou g711alaw. L'image les affiche dans la commande dans laquelle la passerelle de Cisco IOS donne la priorité à comment les codecs sont offerts à l'extrémité.  des codecs de Voix-classe sont appliqués aux cadran-pairs.

Le CUCM-Side de l'intégration de CUCM-à-CUBE

1. Afin d'ajouter le joncteur réseau à la configuration CUCM, naviguez vers cet emplacement :
   
   

2. Choisi ajoutez nouveau et poursuivez pour installer le joncteur réseau de Protocole SIP (Session Initiation Protocol) comme affiché ici :
   
   

3. Dans la page de configuration de joncteur réseau, souvenez-vous pour sélectionner le Pool d'appareils approprié qui permet des appels d'arrivée au serveur particulier CUCM qui reçoit des appels.
   
   

Une fois que le joncteur réseau est créé, assurez-vous que l'accès de modèles d'artère il correctement par un modèle d'artère de SIP ou une installation de liste de routage/groupe d'artère.

L'en-tête de réorientation de transfert peut être faite tic tac pour d'arrivée ou des appels sortants.

Quand des nombres externes sont expédiés dans le réseau VoIP, le SIP invitent des messages été livré avec les informations transmises par relais de transfert dans CUCM. Il affiche l'appelant de commencement. Par exemple, si un écoulement d'appel est intégré avec l'UC et entre dans la messagerie vocale, l'UC utilise la source initiale de transfert (nombre expédié externe) comme boîte aux lettres destinaire. Ainsi il est possible qu'ils pourraient obtenir le message d'accueil par défaut d'ouverture au lieu de la boîte aux lettres d'abonnés comme prévue. Il dépend de l'écoulement d'appel et des conditions requises de votre topologie si ceci va être exigé pour la configuration.

4. Le profil de SIP pour l'offre tôt est souvent nécessaire quand vous connectez le CUBE à un fournisseur. Si le joncteur réseau connecte à un autre Cisco le périphérique, alors vous ne pourriez pas vouloir sélectionner l'insertion du protocole de transport de medias (MTP), basée sur les périphériques finaux. Cette image affiche l'emplacement de profil de SIP et où sélectionner la case pour l'offre tôt. 

L'offre tôt aide souvent à résoudre les problèmes tôt de medias qui surgissent quand vous intégrez le serveur et le CUBE CUCM à d'autres produits tiers. Il est également recommandé dans la conception de réseaux de référence de solution (SRND).

Si le profil va être modifié, il est toujours le meilleur de créer un nouveau profil pour l'utiliser au lieu du profil par défaut. 

Remarque: Cette case à cocher est utilisée quand les utilisateurs finaux ne veulent pas avoir un MTP utilisé à chaque appel.

5. Il pourrait être nécessaire de changer de TCP/UDP pour le protocole dans le profil de Sécurité de SIP basé sur l'écoulement d'appel. Afin d'apporter cette modification, naviguez POUR SIROTER des profils de Sécurité de joncteur réseau > sécurisent non le profil de joncteur réseau de SIP :

Les appels échoueront, et des suivis CUBE/CUCM sont exigés afin de comprendre ce qui se produit au moment de la panne, mais cette caractéristique peut être modifiée afin de confirmer que ce n'est pas la cause du problème. Cependant, une fois que ceci est modifié, vous devez remettre à l'état initial/reprise le joncteur réseau afin d'apporter la modification se produire.

6. Dans certaines circonstances, le masque externe de téléphone sur la configuration de téléphone pourrait devoir être ajouté pour que l'appel poursuive, parce que quelques compagnies de téléphone ne permettent pas à l'appel pour poursuivre sans masque prévu. Afin d'apporter cette modification, allez à la page de configuration de nombre de répertoire (DN) du téléphone d'appelant, apportent la modification nécessaire pour la case, et la remise/reprise le téléphone après les modifications sont enregistrées.
   
   

Une fois que cette configuration est faite sur CUCM, initiez la détection de batterie sur le PCA.

Le périphérique sera maintenant découvert comme Border Element sur le PCA.