CORRECTION DES LABS CTCOLLAB
GUIDED LAB 1 : GATEWAY AND ENDPOINTS REGISTRATION ISSUES
TASK1 (Phones HQ): Gather Facts: -lire le symptôme sur le phone : reste en registering
-effectuer un test de connectivité par ping (par ex depuis le HQ-PC vers les 2 phones HQ, entre CUCM par un accès SSH ou CM Platform et les HQ phones..): ping ok, donc à moins d’un filtrage du SCCP, le réseau devrait permettre l’enregistrement des phones.
-examiner les status msg et les paramètres réseaux des phones (vlan, ad IP, mask, gateway, tftp) : on peut lire « TFTP Timeout » sur le HQ-Phone1 9971, « TFTP Error » sur HQ-Phone2, ainsi que no Trust List installed sur les 2 phones, et une vérification de la Trust List montre aucun ITL installé. -examiner les services de CUCM : les services sont déjà démarrés dont le service tftp et cucm
Action plan : Aller examiner l’option tftp dans le DHCP server qui est ici le CUCM : Aller dans CM Admin > System > DHCP > DHCP Subnet et corriger le tftp server de 10.1.15.5 à 10.1.5.15
Observe Results : Les phones finissent par s’enregistrer au bout de quelques min après un éventuel upgrade de firmware. Pour observer le résultat plus vite, il est possible de resetter les paramètres réseaux sur les phones par un Erase Config sur le HQ-Phone2 7965, ou un Reset des Network settings sur le HQ- Phone1 9971.
TASK2 (Gateway MGCP):
Gather Facts : -test de connectivité par ping entre Gateway BR2 et CUCM : ping depuis CUCM vers 10.13.1.2 et 10.1.130.1 ok (rem la correction Cisco p123 montre un test de ping vers HQ et non BR2)
-vérifier le paramétrage réseau de la passerelle : sh ip int brief montre un paramétrage IP ok
-vérifier que le service CUCM servant à l’enregistrement est démarré : ok
-vérifier que le service TFTP servant au téléchargement de la config est démarré : ok
-vérifier le status d’enregistrement de BR2 par sh ccm-manager : « host down » quand la commande « mgcp » est manquante et donc MGCP totalement désactivé sur BR2, ou « Registering with CM » quand la commande « mgcp » est rétablie mais d’autres paramètres posent pb comme un hostname faux.
1
-vérifier sur BR2 si des messages apparaissent par debug mgcp events : pas de log du tout quand la commande « mgcp » est manquante, et montrant « MGCP conn stat= 3 » (3=CONNECTING) quand la commande « mgcp » est remise.
-vérifier dans RTMT par une real time trace sdl sur le sub-hq les messages MGCP (dans le champ de filtre rechercher les occurrences MGCP) : on peut voir "MGCPBhHandler 10.13.1.2 - Unregistered but TCP remains open" donc une communication MGCP s’effectue entre CUCM et BR2 mais n’aboutit pas, d’ailleurs on voit également MGCPRestartInProgress en boucle.
-l’uilisation d’un syslog (kiwisyslog, syslog watcher…) montre reason code=2 NoEntryInDatabase (cisco.com/go/uc>CUCM>encadré support, troubleshoot and alert>error and system messages pour les n°erreurs ou page 125 du lab guide) -vérifier si la configuration de BR2 en tant que gateway MGCP dans CUCM correspond à ses paramètres et type de carte Voix et Emplacement : le hostname sur CUCM ne correspond pas.
Action plan : remettre la commande mgcp si manquante, corriger le hostname dans CUCM et le mettre à BR2, Save, Apply Config (rem : il n’est pas nécessaire ici de faire no mgcp /mgcp car la gateway télécharge automatiquement sa config du fait de la présence de la commande ccm- manager config). La commande sh ccm-manager doit montrer que BR2 est enregistré sur le sub (10.1.5.16). Le lab ne demande pas de tester les appels une fois l’enregistrement réussi. Néanmoins, on peut tester les appels entrants en ajoutant dans la config de BR2 dans CUCM un CSS BR2_phones_css, sous Incoming Called number settings pour un type National +44, puis d’appeler depuis le PSTN Phone, de sa 5ème line (London) le 011448822884001. La commande debug isdn q931 doit montrer l’appel arriver et aboutir. Lorsque l’appel fonctionne il peut être intéressant de tester sh call active voice compact et sh voice call status.
GUIDED LAB 2 : TROUBLESHOOTING LDAP INTEGRATION ISSUES
TASK1 (Sycnhro LDAP HQ):
Gather Facts 1: -vérifier si des users sont synchronisés dans CUCM : dans User Management > End User, on ne voit apparaître que John Doe en tant que user local.
-vérifier la configuration de l’intégration dans CUCM par System > LDAP > System et System > LDAP > LDAP Directory : le manager ne semble pas correct car c'est john doe mais en théorie c'est possible donc en attendant d’aller vérifier dans le LDAP, on le conserve tel qu'il est écrit: "CN=John Doe, CN=Users, DC=collab10x, DC=cisco,DC=com".
-le vérifier dans le LDAP AD Users and Computers : le user john doe est bien défini correctement
-de retour dans LDAP Directory du CUCM, ressaisir le password et Faire Save
2 Un message d’erreur apparaît : « Can’t schedule next resync in the past ».
-Résoudre cela avant de refaire Save 2 résolutions possibles : a) ne pas oublier avant d’activer la synchro de cocher « Perform sync just once » sinon il synchronise à la next sync qui peut être dans le passé comme le laisse comprendre le message d’erreur b) indiquer une date future de synchronisation. Si le message d’erreur persiste, vérifier que le CUCM est bien synchronisé par un accès SSH par putty, login/pass=admin/adpa$$1 puis lancer sh ntp status Si on voit unsynchronized, lancer un utils ntp restart. CUCM va alors se synchroniser en mois de 10min et le Save devient possible.
En faisant un save, on s'aperçoit que le compte est accepté mais que le service DirSync est désactivé : “Update successful. Perform a synchronization operation (manual or scheduled) to synchronize changes with the directory.” “In order to sync users from the LDAP Directory directly into Communications Manager, you must activate the Cisco DirSync service…”
De Plus le bouton “Perform Full Sync Now” est grisé
-Observer si une trace est apparue : non
-Aller vérifier si les traces sont bien activées pour DirSync en mode debug: on peut constater là aussi que le service DirSync est signalé « inactive ».
Action Plan 1: Activer le Service DirSync dans Serviceability > Tools > Service Activation
Puis cocher « Perform sync just once » et faire “Perform Full sync now”: dans la trace realTime, on voit : « Successfully completed full sync », et 2 nouveaux users devraient apparaitre dans User Management>End Users au bout de plusieurs minutes (Le Perform Full Sync Now peut engendrer le message d’erreur : “The attempted action was a violation of security protocols and will not be allowed. This may be caused by having multiple concurrent windows open or using browser buttons (back, refresh, etc). Please retry the operation. » Dans ce cas sortir et revenir sur la page LDAP directory pour relancer la synchro. Gather Facts 2 : -Une fois que la synchro a pu être lancée, et que les Users Jdoe et Jwhite sont apparus, vérifier la façon dont ils apparaissent dans User Management > End User. Est-ce que cela correspond à ce qui est imposé page 20 du lab guide ? Non, les users apparaissent en [email protected] et [email protected]
Action Plan 2 : -Aller dans LDAP directory et retenir les infos qui ont permis de créer cette intégration (faire un copier/coller dans un notepad pour le recréer plus facilement). Puis, supprimer ce directory LDAP -Dans LDAP > LDAP System, décocher "enable synchronizing from LDAP server"(sinon les users ne
3 peuvent être effacés, l’option Convert to local users n’apparaissant pas) -Dans User Management>End User, supprimer les 3 comptes user. -Dans LDAP > LDAP System, changer le LDAP Attribute for User ID=userPrincipalName par sAMAccountName et recocher "Enable Synchronizing From LDAP server".
-Recréer un nouveau LDAP directory avec les paramètres suivants : LDAP Manager Distinguished Name: [email protected] LDAP Manager password : adpa$$1 LDAP User Search Base: CN=Users,DC=collab10x,DC=cisco,DC=com Perform Sync Just Once coché Access Control Groups associés: Standard CCM End Users et Standard CTI Enabled adresse IP du LDAP Server: 10.1.5.14
-Faire Save, Perform full Sync now
Observe Results La synchro LDAP est quasi instantané et il apparaît alors les 2 comptes : jane.white et john.doe
TASK2 (Auth LDAP BR1): Gather Facts 1 : -vérifier si les users sont synchronisés dans User Management>End User : ils le sont bien et ont un status « Active LDAP Synchronized User »
-se connecter au Self-Care Portal du CUCM BR1 (https://10.1.7.15/ucmuser) depuis un autre navigateur que l’accès admin pour éviter les conflits d’authentifcation, et vérifier que l’authentification de john.doe ou jane.white est possible : non cela ne fonctionne pas, on obtient le message d’erreur : « An LDAP error has occured. Contact you system administrator »
-Forcer une resynchro LDAP et observer le résultat : le message d’erreur : « Failed to connect to ldap://10.1.5.14:389, check the server IP address or the network connection” apparaît.
-Aller dans LDAP > LDAP Authentication et faire un Save, observer le résultat : Failed to connect to ldap://10.1.5.14:3268, check the server IP address or the network connection
-constater une information différente dans les 2 messages d’erreurs : le n°port est différent entre les deux, et en effet en examinant le paramétrage du LDAP port, il y a 3269 pour l’authentification LDAP et 389 pour la synchro LDAP
-vérifier la connectivité réseau entre le BR1 CUCM et le LDAP : se connecter en putty à 10.1.7.15 login/pass=admin/adpa$$1 et tester utils network ping 10.1.5.14 : le ping est ok
-lancer RTMT sur 10.1.7.15 et vérifier si une trace apparait sur BR1 quand on force une Synchro dans LDAP>LDAP Directory ou quand on Save dans LDAP>LDAP Authentication: aucune communication semble se faire entre le CUCM BR1 et le LDAP
4 -Corriger de façon à ce que le trafic fonctionne, que le Save de l’authentification réussisse, et relancer une synchro pour vérifier que la trace affiche une communication : d’après show ip route, la serial 0/1/0.101 du routeur BR1 est celle permettant d’envoyer du trafic vers 10.1.5.0/24. L’examen de la config de BR1 fait apparaître une ACL sur cette interface serial qui bloque les ports 389 et 3268
Action Plan 1 : enlever l’ACL de la serial 0/1/0.101 connectée vers le site HQ par no ip access-group 101 out. En relançant une synchro, la trace fait apparaître une communication entre BR1 et LDAP (Save du LDAP Auth n’engendre aucune trace)
-se reconnecter au Self-Care Portal du CUCM BR1 et constater si l’accès est possible. Si non, vérifier de nouveau le paramétrage du LDAP Authentication : Le User Search Base pointe peut-être sur un user au lieu d’un OU. Enlever de la chaîne de caractères CN=John Doe puis Save pour obtenir le message Successful Update
Observe Results :
Depuis le PC2, ouvrir une page web : https://10.1.7.15/ucmuser avec john.doe ou jane.white avec adpa$$1
(Remarque : Finalement le fait que l’authentification LDAP utilise le port 3268 n’est pas un problème)
GUIDED LAB 3 : TROUBLESHOOTING ENDPOINTS REGISTRATION ISSUES
TASK1 (Jabber Video): Gather Facts 1:
-essayer de se logger depuis BB-PC sur le Jabber video for Telepresence avec le username sgreen et password Cisco1234, cela fonctionne-t-il ? Non, le message d’erreur suivant apparaît : « Connection rejected by server. Try logging in later. »
-vérifier les sign-in settings de Jabber Video, sont-ils correct ? Non, l’internal server est incorrect, il ne devrait pas être tms-hq.collab10x.cisco.com mais vcsc-bb.collab10x.cisco.com
Action Plan 1: Changer tms-hq.collab10x.cisco.com en vcsc-bb.collab10x.cisco.com Le SIP domain est conservé à collab10x.cisco.com
Gather Facts 2: -Après cette 1ère correction, retenter une authentification, quel est le résultat, est-ce le même message d’erreur ? Non, désormais on obtient « unable to connect to server »
5 -vérifier si BB-PC peut atteindre le serveur, le corriger sinon : dans une fenêtre MS-DOS, lancer un ping vcsc-bb.collab10x.cisco.com. On obtient le résultat : « Ping request could not find host ». Mais ping 10.1.6.19 réussit
Se connecter au DNS Manager sur DC-HQ (10.1.5.14). Aller dans DC-HQ > Forward Lookup Zones > collab10x.cisco.com. Il y a une entrée vsc-bb qui existe et non vcsc-bb.
Action Plan 2: Créer une nouvel entrée A "vcsc-bb" dans le serveur DNS : clic droit>new host A or AAAA, entrer le Name vcsc-bb et l’adresse IP 10.1.6.19, cliquer sur Add Host.
Observe Result : Vérifier si ping vcsc-bb.collab10x.cisco.com fonctionne. Si cela ne marche toujours pas faire un ipconfig /flushdns (ipconfig /displaydns pour voir le cache).
Gather Facts 3: -Après cette deuxième correction, essayer de se reconnecter. Y-a-t-il un nouveau message d’erreur ? Oui le message d’erreur est "Wrong username, domain and/or password"
Vérifier si c’est le cas en se connectant depuis le BB-PC au VCS https://10.1.6.19/login avec admin/Cisco1234 puis aller dans Status > Logs > Network logs puis filtrer sur 10.1.50.201. Y-a-t-il des logs de tentative d’enregistrements ? Oui, on peut voir des échanges sur le port TCP 5060 de messages de méthode SUBSCRIBE pour un Request-URI [email protected].
-Quel enseignement tirer du message d’erreur ? On peut voir un « response 404 ». Une recherche sur « List of SIP response codes » donne la définition suivante : 404 Not Found
The server has definitive information that the user does not exist at the domain specified in the Request-URI. This status is also returned if the domain in the Request-URI does not match any of the domains handled by the recipient of the request
Depuis l’accès au VCS, en examinant le domaine, Configuration > Domains , on peut voir un domaine incorrecte cisco.com au lieu de collab10x.cisco.com
Action Plan 3 : Remplacer le nom de domaine dans le VCS par collab10x.cisco.com
Gather Facts 4 : -essayer de se reconnecter, le message d’erreur a-t-il changé ? Examiner l’Event Log dans Status > Logs > Event Log et en déduire la correction à effectuer
Si c’est toujours : "Wrong username, domain and/or password", et que l’on voit dans Status > Logs > Event Log : "authentication failed" et "incorrect authentication credential for user", réinitialiser le mot de passe de sgreen dans TMS (10.1.5.34/TMS , administrator / Cisco1234) , en allant dans Systems > Provisionning > Users, sélectionner le user Scott Green > Edit User, ressaisir le password, faire Save
Si c’est désormais "Login Failed due to registration failure" et dans le Event Log on voit: Event="Registration Rejected" Reason="Not permitted by policy" Src-ip= « 10.1.50.201 »
6 Aller dans VCS dans Configuration > Registration > Configuration : une deny list est activé. En cliquant dans configure the Registration Deny List, on peut voir qu’elle filtre pour le Pattern type=Suffix, pour le Pattern string= « @collab10x.cisco.com »
Action Plan 4 : Depuis VCS > Configuration > Registration > Configuration , passer la restriction Policy à None
-Se reconnecter et vérifier l’event log : cette fois ci l’authentification réussit et on voit dans les event log : Event="Registration Accepted" Service="SIP" Src-ip="10.1.50.201"
GUIDED LAB 4 : TROUBLESHOOTING LDAP INTEGRATION ISSUES
TASK1 (LDAP Auth VCS): Gather Facts 1:
Le log d’un user synchronisé par LDAP réussit-il ? essayer de se logger en john.doe avec le password adpa$$1 : on voit apparaître le message d’erreur "Wrong username, domain and/or password"
-Examiner les Event Log de VCS. Y-a-t-il un message d’erreur pertinent ? Les messages "authentication failed" et "incorrect authentication credential for user" apparaissent
-En déduire la vérification à effectuer puis la correction à apporter: Aller sur le VCS dans Configuration > Authentication > Devices > AD service . Sous la section « Status », le State, le ADS LDAP Connectivity sont « Inactive ». En effet le paramètre "Connect to Active Directory service" est en « Off ».
Action Plan 1 : Activer "Connect to Active Directory service" à on puis faire Save en acceptant le reste.
Observe Result 1 : Le ADS LDAP Connectivity passe en active mais le reste du status est incorrect
Gather Facts2 :
-Après cette 1ère correction, quels messages d’erreur apparaissent en haut de la page ? Failed to join domain: failed to kinit password: NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND Not joined to AD domain: To complete the connection to the Active Directory Service you must provide correct credentials.
- dans la section Status : quel état est obtenu ? Le ADS LDAP Connectivity est passé à « Active », mais le State reste à « Failed » et le Domain status est « Not joined »
-Quel autre paramétrage dans la page peut créer ce problème ? S’aider de l’outil DNS Lookup du VCS et effectuer une deuxième correction
7 Le AD domain Short domain name semblent incorrects. En vérifiant dans Maintenance > Tools > Network utilities > DNS lookup , le nom de domaine COLLAB01X.CISCO.COM ne donne aucun résultat, alors que COLLAB10X.CISCO.COM retourne des entrées
Si ce dernier n’en retourne pas, en allant dans System > DNS, on découvre que le DNS est mal défini.
Action Plan 2 : Dans System > DNS, corriger l’adresse 101.5.34 en 10.1.5.14 Dans Configuration > Authentication > Devices > AD service, corriger les paramètres suivants et faire Save : AD domain de COLLAB01X.CISCO.COM à COLLAB10X.CISCO.COM Short domain name de COLLAB01X à COLLAB10X
Observe Result 2 :
-Les messages d’erreurs en haut de la page ou les Status ont-ils changés ? Oui. L'adresse IP 10.1.5.14 apparait maintenant dans le status , et en haut de page il y a un message d'erreur : « Failed to join domain: failed to kinit password: NT_STATUS_INVALID_ACCOUNT_NAME » et toujours : Not joined to AD domain: To complete the connection to the Active Directory Service you must provide correct credentials.
Gather Facts 3 : -Déduire du précédent message d’erreur la vérification à faire et la correction à apporter Le compte username = admin n'est pas correct.
Action Plan 3 : Corriger le compte à Administrator / adpa$$1
Observe Result 3: On obtient dans Configuration > Authentication > Devices > AD service les Status suivants qui s’affichent en vert : State : Active Domain status: Joined to COLLAB10X.CISCO.COM / COLLAB10X ADS Domain Controller: 10.1.5.14 ADS LDAP Connectivity: Active ADS Domain Controller Connectivity: Active
Les messages en haut de page : Success: Joined domain.
- Essayer de se connecter avec jane.white et john.doe / adpa$$1, quel est le résultat obtenu ? Cela fonctionne
Note : en essayant de se reconnecter avec sgreen / Cisco1234, on voit à nouveau apparaître "wong username" Dans les event log : "Authentication Failed" mais avec "Credential verification failed" et pas "incorrect authentication credential for user" comme dans le TT3. Il n’est pas possible d’avoir en même temps l'identification par AD et avec un compte local TMS. Si on repassait le
8 paramètre "connect to Active Directory service" en off, sgreen pourrait se logguer à nouveau.
TASK 2 (LDAP Auth admin)
Gather Fact 1 :
-essayer de se connecter avec les 2 users du domaine à l’admin de VCS john.doe et jane.white. Cela fonctionne-t-il ? Non, et l’on obtient le message d’erreur suivant : "Login failed: Unable to log in"
-vérifier la config LDAP de 2 façons : 1) en se reconnectant par admin/Cisco1234 puis Users > LDAP, vérifier le Status : Failed 2) par accès CLI en se connectant au VCS en SSH : utiliser putty vers 10.1.6.19, login/pass=admin/Cisco1234, et entrer la commande xConfiguration Login Remote et observer le résultat : Dans Users > LDAP configuration : Administrator authentication source est à « Local only » En CLI, xConfiguration Login Remote montre de nombreuses informations incorrectes ou manquantes : xConfiguration Login Remote *c xConfiguration Login Remote LDAP BaseDN Accounts: *c xConfiguration Login Remote LDAP BaseDN Groups: *c xConfiguration Login Remote LDAP CRLCheck: "None" *c xConfiguration Login Remote LDAP DirectoryType: "ActiveDirectory" *c xConfiguration Login Remote LDAP Encryption: "TLS" *c xConfiguration Login Remote LDAP SASL: "DIGEST-MD5" *c xConfiguration Login Remote LDAP Server Address: *c xConfiguration Login Remote LDAP Server FQDNResolution: "AddressRecord" *c xConfiguration Login Remote LDAP Server Port: "389" *c xConfiguration Login Remote LDAP VCS BindDN: *c xConfiguration Login Remote LDAP VCS BindPassword: "{cipher}RTCLZY2YOnFiQYsKm02uxA==" *c xConfiguration Login Remote LDAP VCS BindUsername: *c xConfiguration Login Remote Protocol: "LDAP"
Action Plan1 : -Dans User > LDAP Configuration, permettre les 2 sources d’authentification, puis faire Save : Paramétrer le champ Administrator authentication source à « Both »
Que dit la popup apparue ? Invalid bind DN
Gather Facts 2 : - d’après la popup précédente dans User > LDAP Configuration, compléter le paramétrage :
Action Plan 2 : Entrer les paramètres suivants: host name : 10.1.5.14 encryption : off bind DN: cn=John Doe, cn=Users,dc=collab10x, dc=cisco, dc=com
9 Bind Password : adpa$$1 SASL : DiGEST-MD5 Bind username : john.doe Base DN for accounts : cn=John Doe, cn =Users,dc=collab10x, dc=cisco, dc=com Base DN for groups : cn =Users,dc=collab10x, dc=cisco, dc=com
Observe Results 2: On doit obtenir un Status Available qui s’affiche en vert : en effet
-Est-il possible de se logger avec john.doe désormais? Non. Il y a la même erreur "Login failed: Unable to log in". Dans les event log, il apparaît : "User="john.doe" Event="Admin Session Login Failure"
Gather Facts 3 : -Vérifier que sur le serveur DC-HQ, dans AD Users and Computers, il y ait à la racine du domaine collab10x.cisco.com un groupe dédié aux administrateurs de VCS, différent de l’OU Users contenant tous les users du domaine, appelé VCS_Admin : en effet. En double-cliquant dessus, dans l’onglet members, on voit john.doe et jane.white. Ce groupe dédié évite que tous les users du domaine puissent avoir des droits d’accès admin à VCS.
-Un même groupe existe-t-il dans VCS ? dans Users > Administrator groups, il n’y a aucun groupe.
Create Action Plan 3: Créer un group administrator dans Users > Administrator groups > new. Le nommer "VCS_Admin " comme dans l'AD. Mettre un accès read-write. Il y a un message d'erreur précisant "Group VCS_Admin cannot be found by the remote authorization server" et aussi qu'il faut vérifier le Base DN for group.
Gather Facts 4 : -D’après le message d’erreur suivant qu’en déduire ? de vérifier le Base DN for group dans Users > LDAP Configuration
Create Action Plan 4 : Dans VCS en allant sur Users > LDAP Configuration, faire la modification suivante: Base DN for groups : dc=collab10x, dc=cisco, dc=com
Si on revient dans le groupe VCS_Admin, il n'y a plus d'erreur lors de la sauvegarde
Observe Result 4 : Le log dans https://10.1.6.19/login avec john.doe réussit. Il dispose bien de droit RW car lorsque l’on veut par exemple créer un nouveau domaine par Configuration > Domain, l'option New existe bien. Remarque : le log avec jane.white échoue. Solution : configurer dans Users > LDAP Configuration le Base DN for accounts : dc=collab10x, dc=cisco, dc=com
Et en se connectant en SSH par admin/Cisco1234 (cela reste le compte CLI), le résultat de la commande xConfiguration Login Remote donne : *c xConfiguration Login Remote LDAP BaseDN Accounts: "dc=collab10x, dc=cisco, dc=com" *c xConfiguration Login Remote LDAP BaseDN Groups: "dc=collab10x, dc=cisco, dc=com"
10 *c xConfiguration Login Remote LDAP CRLCheck: "None" *c xConfiguration Login Remote LDAP DirectoryType: "ActiveDirectory" *c xConfiguration Login Remote LDAP Encryption: "Off" *c xConfiguration Login Remote LDAP SASL: "DIGEST-MD5" *c xConfiguration Login Remote LDAP Server Address: "10.1.5.14" *c xConfiguration Login Remote LDAP Server FQDNResolution: "AddressRecord" *c xConfiguration Login Remote LDAP Server Port: "389" *c xConfiguration Login Remote LDAP VCS BindDN: "cn=John Doe, cn=Users,dc=collab10x, dc=cisco, dc=com" *c xConfiguration Login Remote LDAP VCS BindPassword: "{cipher}Qmm+p37Fj+s5Vagm+79Gmw==" *c xConfiguration Login Remote LDAP VCS BindUsername: "john.doe" *c xConfiguration Login Remote Protocol: "LDAP"
GUIDED LAB 5 : TROUBLESHOOTING ON-NET SINGLE-SITE CALLING ISSUES
TASK1 (appels entre HQ Phones): Gather Facts 1:
Pour commencer, lorsque l’appel échoue, est-ce un bip bip ! ou le msg Annunciator ? Que peut-on en déduire ? Le msg Annunciator est perceptible si le service Voice Media Streaming App est activé, dans ce cas il signifie que le CUCM « sait » que l’appel ne peut être acheminé. Dans le cas du bip bip, ça peut être un échec lié à un blocage de l’appel sur un équipement hors du cluster. Ici il s’agit d’un appel intra cluster.
Pour commencer, vérifier la configuration des phones impliqués et noter ce qui peut être lié à la numérotation : Device et Line CSS, partition et DN, Enterprise et E164 Alternate Number et partition. On peut en déduire les partitions accessibles pour chaque HQ Phone : Les 2 phones ont un Line CSS HQ-phones-css contenant les partitions : BR2-DN, HQ-DN, HQ Seul HQ-phone1 a un Device CSS System_css contenant la partition : System
Vérifier simplement le DialPlan depuis l’interface d’admin de CUCM pour identifier les matchs potentiels qui pourraient interférer avec le routage Call Routing > Route Plan Report montre un translation pattern 2.XXX dans la partition HQ qui vise à transformer le numéro appelé en +12012012XXX, mais aussi les DN 2001 et 2002 en partition None.
Tester le Dialed number Analyzer et identifier si on obtient un résultat pertinent pour l’investigation Aller dans https://10.1.5.15/dna > Analysis > Phone, et sélectionner le Phone1 et simuler un appel vers 2002. Le DNA considère l’appel réussi car il trouve un match, mais sur le DN 2002 avec « no Device associated to the DN », et ne montre pas de match avec le translation Pattern, y compris en « alternate matches ».
Vérifier avec une trace real time SDL sur le sub CUCM avec un Search sur « dd= » ce que l’on obtient lors d’un appel : L’appel digit par digit échoue dès le 2 composé. La trace d’un appel vers 2002 donne :
11 00243277.008 |17:17:50.693 |AppInfo |Digit analysis: match(pi="2",fqcn="+12012012001", cn="+12012012001", plv="5", pss="BR2-DN:HQ-DN:HQ:System", TodFilteredPss="BR2-DN:HQ- DN:System", dd="2002",dac="0") 00243277.009 |17:17:50.693 |AppInfo |Digit analysis: potentialMatches=NoPotentialMatchesExist
On peut constater que le pss contient la partition HQ, pas le ToFilteredpss. Cela signifie donc que le Time of Day Routing filtre de la liste des partitions accessibles au HQ-Phone1 la partition HQ. En déduire la vérification et première correction à apporter En allant dans Call routing > Class of Control > Partition > partition HQ, on découvre un time Schedule « Saturday »
Action Plan 1a: Dans Call routing > Class of Control > Partition >partition HQ, enlever le Time Schedule Saturday Et effacer également dans Call Routing > Directory Number les DN 2001 et 2002 qui perturbent l’affichage du DNA
Gather Facts 1b: Après cette première correction, retenter l’appel, réussit-il ? Non. En composant digit par digit, CUCM nous laisse composer jusqu’au bout mais le msg Annunciator se joue quand même.
Relancer une trace et une analyse DNA et vérifier l’évolution des messages 00252617.013 |18:11:21.624 |AppInfo |Digit analysis: match(pi="2", fqcn="+12012012001", cn="+12012012001",plv="5", pss="BR2-DN:HQ-DN:HQ:System", TodFilteredPss="BR2-DN:HQ- DN:HQ:System", dd="2002",dac="0") 00252617.014 |18:11:21.624 |AppInfo |Digit analysis: analysis results 00252617.015 |18:11:21.624 |AppInfo ||PretransformCallingPartyNumber=+12012012001 |CallingPartyNumber=+12012012001 |DialingPartition=System |DialingPattern=+! |FullyQualifiedCalledPartyNumber=+1201201002
Désormais TodFilteredpss contient la partition HQ, mais l’appel match sur le Route Pattern \+ ! Les détails du match sur le Translation Pattern qui se font avant le RoutePattern ne sont pas disponibles, mais on voit qu’il a transformé le numéro appelé devenu : FullyQualifiedCalledPartyNumber=+1201201002 CUCM, ne trouvant pas de match avec le DN du HQ-phone2, cherche à utiliser la RoutePattern \+
De même, le DNA montre un match avec le translation pattern 2.XXX avec un Called Number dans Called Party Transformations qui est +1201201002
Cela amène à découvrir que la transformation du numéro appelé dans le Translation Pattern est incorrecte
Action Plan 1b : Dans Call Routing > Translation Pattern > 2.XXX, enlever le « . » de 2.XXX (ce qui grise le discard Predot).
Observe Result 1b :
12 Désormais le numéro est bien +12012012002 dans la trace et DNA. Les phones affichent correctement +12012012001 et +12012012002 sur leur écran pour les 2 sens d’appel
Gather Facts 2a : Si on considère déjà le cas de l’appel de HQ-Phone2 vers 812001, que montre la trace de son appel ? 00292967.006 |22:29:38.758 |AppInfo |Digit analysis: match(pi="2",fqcn="+12012012002", cn="+12012012002", plv="5", pss="BR2-DN:HQ-DN:HQ", TodFilteredPss="BR2-DN:HQ-DN:HQ", dd="812001",dac="0") 00292967.007 |22:29:38.758 |AppInfo |Digit analysis: potentialMatches=NoPotentialMatchesExist
Les pss ne contiennent pas la partition system associée aux Enterprise Number 812001, conséquence l’appel vers ce numéro échoue.
Action Plan 2a : Ajouter le CSS css_system en tant que device CSS à HQ-Phone2 pour qu’il soit comme HQ-Phone1
Observe Result 2a : Le HQ-Phone2 peut appeler 812001
Gather Facts 2b : Après une première correction, l’affichage des numéros reste incorrect. Quels paramétrages sont impliqués dans la présentation du numéro (Connected Number) ? Sur le Phone, dans la section Number Presentation Transformation, rubrique Remote Number, un Calling Party Transformation CSS doit être configuré et contenir la partition d’un Calling Party Transformation Pattern, de plus dans les Services Parameters de Cisco Call Manager, en Advanced, l’option Apply Transformations on Remote Number doit être à True En déduire les vérifications à effectuer dans les phones puis le Device Pool, enfin les transformations, et les corrections à apporter Le paramétrage du Calling Party Transformation CSS pour le Remote Number sur les HQ-phones est défini à Use Device Pool Calling Party Transformation CSS. Un peu plus haut, on peut vérifier que le Device Pool des phones est Default.
En allant dans le Device Pool Default, dans la section Device Mobility Related Information on peut constater qu’aucun Calling Party Transformation CSS n’est défini. Il faudrait en mettre un mais lequel ?
En allant dans Call Routing > Transformation > Transformation Pattern > Calling Party Transformation Pattern, on découvre que les Pattern 81.2XXX et \+1201201.2XXX transforment en 2XXX et sont associés à la partition HQ-ph_in. Dans Call Routing > Class of Control > Partition > partition HQ-ph_in dans les Related Links, par l’option Dependency Records (activable dans System > Enterprise Parameters si ce n’est pas activé), on peut découvrir que le CSS associé est HQ-ph_in_css On peut alors l’associer au Device Pool Default
De plus, en allant dans System > Service Parameters > Service Cisco CallManager > Advanced, l’option Apply Transformations on Remote Number est à false.
Action Plan 2b
13 Dans System > Device Pool > device pool Default, dans la section Device Mobility Related Information, mettre le Calling Party Transformation CSS à HQ-ph_in_css Cette première correction fait que le n° appelant d’un appel reçu s’affiche sur le phone appelé raccourci en 4 digits (comme la localisation sur le phone) ex : HQ-Phone1 appelle 2002 transformé par TP en +12012012002, ou 812002, ou +12012012002 : du fait du calling transform css sur HQ-Phone2, le numéro d’appelant affiché sur HQ-Phone2 est raccourci en 2001.
Enfin Dans System > Service Parameters > Service Cisco CallManager > Advanced, mettre l’option Apply Transformations on Remote Number à True (pas de redémarrage à faire)
Observe Result 2b : Les appels dans les 2 sens entre HQ-Phone1 et 2 par tout format de numéro, affichent des n° à 4 digits sur les 2 phones.
TASK2 (appels entre HQ Phones et Jabber video):
Gather Facts 1 : Sur le BB-PC, se logger avec john.doe / adpa$$1 sur le Jabber Video et essayer d’appeler [email protected] ou [email protected] Quel est le résultat ? On obtient le message d’erreur : "Call Failed - The user could not be found…"
Voit-on partir cet appel dans les logs de VCS ? Oui : dans Status>Logs>Event Log, en faisant un filtre sur [email protected] , il y a : tvcs : Event= "Call rejected" Service="SIP"Src-ip="10.1.50.201"…Src- alias="sip :[email protected]"…Detail="Not Found" Protocol="TCP" Response- code="404"
Depuis le HQ-Phone1, appeler [email protected] Quel est le résultat ? On obtient le message d’erreur de l’Annunciator : "Your call cannot be completed as dialed…”
Voit-on cet appel de HQ-Phone1 vers le Jabber video dans les traces CUCM et log VCS ? Oui pour CUCM : SIP/2.0 404 Not Found Via: SIP/2.0/TCP 10.1.110.108:49509;branch=z9hG4bK49293e74 From: "+12012012001"
14 Reason: Q.850;cause=1 Server: Cisco-CUCM10.5
On voit un échec de l’appel (Note : Sur wikipedia : 404 Not Found : The server has definitive information that the user does not exist at the domain specified in the Request-URI)
Mais on ne le voit pas arriver dans VCS
Vérifier le paramétrage dans VCS et CUCM de ce qui permet la communication entre les deux, en déduire une première correction Dans VCS, aller dans Configuration > Zones > Zones pour vérifier le status de la neighbor zone HQ_CUCM. Malgré un paramétrage correct on voit les états suivants s’afficher en rouge : Failed to connect to 10.1.5.15:5060 : Service unavailable Failed to connect to 10.1.5.16:5060 : Service unavailable Le State en bas de la page est Failed
A présent dans CUCM > Device > Trunk > VCS-tr, on constate que le trunk pointe vers l’ad IP 10.1.5.19 et non 10.1.6.19
Action Plan 1 : Dans CUCM > Device > Trunk > VCS-tr, modifier l’adresse IP de 10.1.5.19 en 10.1.6.19, Save, Reset
Observe Result 1 : Après une minute, sur la page de la Neighbor Zone, on voit les états suivants s’afficher en vert : SIP: Reachable: 10.1.5.15:5060 SIP: Reachable: 10.1.5.16:5060 Le State en bas de page est passé Active
Gather Facts 2: Retester l’appel de Jabber Video vers [email protected] ou [email protected], cela marche-t-il ? Que voit-on dans les logs de VCS ? Ni l’un ni l’autre ne marchent. Les logs de VCS montrent le même message d’erreur que précédemment.
Aller vérifier dans VCS le deuxième élément de configuration important pour le routage vers CUCM et en déduire une autre correction (s’aider de Status > Search history) Dans VCS > Dial plan > Search rules > Calls_to_HQ_cucm Cliquer sur le lien: Perform a test search for an alias (ce qui renvoit vers Maintenance > Tools > Locate) et entrer en Alias [email protected] et en Protocol SIP et en source Alias [email protected]
On peut aussi faire un test d’appel dans Jabber Video vers [email protected] ou [email protected] puis aller dans VCS > Status > Search history vérifier le résultat.
Dans les 2 cas, on voit une erreur « Not Found », seule une local zone apparaît dans le résultat, ce qui peut être le signe d’un pattern mismatch dans la Search Rule
Action Plan 2 :
15 Dans VCS > Dial plan > Search rules > Calls_to_HQ_cucm, corriger le pattern string hq1.cisco.com en hq.cisco.com
Observe Result 2: L’appel depuis Jabber Video continue d’échouer mais désormais Status > Search history ou Maintenance > Tools > Locate montrent le serach rule Calls_to_HQ_cucm et la zone HQ_CUCM
Gather Facts 3: Sur CUCM pub, par une trace SDL real time et un search sur l’occurrence hq.cisco.com vérifier ce que l’on obtient en testant un appel de Jabber video vers HQ-Phone1 par [email protected] et en déduire une correction à faire pour que l’appel fonctionne INVITE sip :[email protected] SIP/2.0 Via SIP/2.0/TCP 10.1.6.19 :5060 ;egress-zone=HQCUCM… Via SIP/2.0/TCP 10.1.50.201… … Contact :
… TRYING … |Digit Analysis: Host Address=hq.cisco.com DOES NOT MATCH any active CUCM node in this cluster |Digit Analysis: Host Address=hq.cisco.com DOES NOT MATCH top level org domain (Le CUCM cherche à matcher avec la partie host un member du cluster puis l’OTLD donc il considère que la partie user de l’URI est numeric.)
Action Plan 3 : Aller dans CUCM > System > enterprise Parameters mettre l’Organization Top Level Domain à hq.cisco.com Observe Result 3 : Un nouvel appel du Jabber video vers [email protected] marche et apparaît comme provenant de john.doe.movi Gather Facts 4 : Tester un appel de Jabber video vers HQ-Phone1 par [email protected] en le traçant dans le CUCM pub, en déduire la vérification à faire et la correction à apporter |Digit Analysis: star_DaReq : Matching SIP URL, Alphanumeric User, [email protected] |Digit Analysis: star_DaReq : IMDB lookup failed |star_DaReq : Attempt Match on route String Host : hq.cisco.com … Outgoing SIP TCP message to 10.1.6.19… SIP/2.0 404 Not Found
On peut aller vérifier si cette URI [email protected] existe bien et si elle est joignable pour un appel entrant, autrement dit est-ce que sur CUCM le incoming call CSS du SIP trunk VCS-tr contient la partition de [email protected] En checkant le user John Doe dans User Management > End User, puis la line du HQ-Phone1, il s’avère que cet URI n’existe pas. Il faut l’ajouter mais dans quelle partition ? Dans la partition HQ-DN étant donné que la trace SDL
16 montre que le CSS du trunk contient les partitions HQ-DN et BR2-DN : 00548165.010 |22 :35 :37.232 |AppInfo |Digit analysis : match(pi="2",fqcn="", cn="john.doe.movi", plv="5", pss="HQ-DN :BR2-DN", TodFileteredpss="HQ-DN :BR2-DN", dd="hq1", dac="0")
00548165.011 |22 :35 :37.232 |AppInfo |Digit analysis : potentialMatches=NoPotentialMatchesExist Create Action Plan 4 : Dans CUCM dans Device > Phone > HQ-Phone1 > line +12012012001 ajouter l’URI [email protected] dans la partition HQ-DN en cochant Primary URI pour cette URI. Faire de même avec HQ_Phone2 avec [email protected]
Observe Result 4 : Un nouvel appel de Jabber Video vers [email protected] fonctionne
Gather Facts 5 : Retester un appel du HQ-Phone1 vers [email protected] En déduire une vérification puis correction L’appel échoue comme au début de la task. Puisque l’appel dans le sens VCS vers CUCM fonctionne, on peut supposer que le SIP Trunk vers le VCS est bien en state Full Service, et on le constate dans Device > Trunk. La trace faite sur le sub avec une recherche sur collab10x.cisco.com montre : 00525246.002 |23 :20 :04 :380 |AppInfo |DigitAnalysis : star_DaReq : Matching SIP URL, Alphanumeric User, [email protected] 00525246.003 |23 :20 :04 :380 |AppInfo |DigitAnalysis : star_DaReq : IMDB lookup failed 00525246.004 |23 :20 :04 :380 |AppInfo |star_DaReq : Attempt Match on Route String Host : collab10x.cisco.com 00525246.010 |23 :20 :04 :380 |AppInfo |DigitAnalysis : match(pi="2",fqcn="+12012012001", cn="+12012012001", plv="5", pss="BR2-DN: HQ-DN:HQ:System ", TodFileteredpss=" BR2-DN: HQ- DN:HQ:System", dd="john.doe.movi", dac="0") 00525246.011 |23 :20 :04 :380 |AppInfo |DigitAnalysis : potentialMatches=NoPotentialMatchesExist D’après le pss, le CSS de HQ-Phone1 contient la partition System, qui est la partition du SIP Route Pattern, mais il n’y a pas de match avec collab10x.cisco.com En vérifiant le SIP Route Pattern on découvre qu’il est incorrect.
Action Plan 5 : Dans CUCM > Call Routing > SIP Route Pattern, modifier le IPv4 pattern de hq.cisco.com à collab10x.cisco.com
Observe result 5 : Un nouvel appel de HQ-Phone1 vers [email protected] fonctionne.
Gather Facts 6 : Jabber Video reçoit bien l’appel de HQ-Phone1 et peut établir l’appel, mais en recevant un appel de [email protected]. De ce fait le rappel depuis Jabber Video en cliquant dans History échoue.
17 Investiguer puis résoudre ce problème L’ID d’appelant émis par le trunk devrait être [email protected] et non [email protected] Vérifier sur le trunk SIP dans CUCM quelles informations d’appelant sont transmises
Action plan 6 : Dans CUCM > Device > Trunk > VCS_tr passer le paramètre Calling and connected Party Info Format de "Deliver DN only in connected party, if available" à "Deliver URI only in connected party, if available " ou "Deliver URI and DN in connected party, if available "
Observe Result 6 : Désormais quand l’appel arrive de Jabber Video, c’est [email protected] qui est présenté, et qui peut être rappelé depuis l’history de Jabber Video
TASK3 (Troubleshooting du Mobile and Remote Access):
Gather Facts 1: Quel message d’erreur apparaît en essayant de se logger? Il est impossible de se logger en mode automatique avec [email protected] : après l’acceptation des popup de certificats, le message d’erreur suivant apparaît : "Cannot find your services automatically. Click advanced settings to set up manually"
Avec quel DNS le Jabber sur BB-PC doit-il se mettre en relation ? Est-ce que le cas ? Le corriger sinon Le Cisco Jabber doit se mettre en relation avec le DNS externe joué par HQ router (10.1.5.1) ipconfig/all sur le PC montre un DNS 10.1.5.14, qu’il faut donc modifier en 10.1.5.1 dans les paramètres de la carte réseau de BB-PC
Action Plan1 : Modifier l’adresse de DNS server de 10.1.5.14 à 10.1.5.1 sur BB-PC.
Gather Facts 2: A présent que Jabber attaque le DNS externe, est-ce que celui-ci résoud correctement le FQDN du Expressway-E ? Comment le vérifier ? En lançant dans une fenêtre MS-DOS la commande nslookup sur BB-PC, le résultat donne : Default Server : hq.cisco.com Address : 10.1.5.1 > on entre : >set type=SRV >_collab-edge._tls.hq.cisco.com
On obtient le résultat : Server : hq.cisco.com Address : 10.1.5.1
DNS request timed out.
18 timeout was 2 seconds. Non-authoritative answer : _collab-edge._tls.hq.cisco.com SRV service location : priority = 1 weight = 1 port = 8443 svr hostname = vcsxe-hq.collab10x.cisco.com
Qu’en déduire du résultat ? La commande nslookup a retourné le FQDN mais aucune adresse IP
Examiner la configuration du DNS externe pour vérifier si l’entrée DNS est correcte, sinon la corriger. Sur le routeur HQ, une entrée vcsxe existe, mais elle est erronée (Rem : la commande debug ip udp port 53 sur le routeur HQ permet de voir en cas de commande nslookup ou de log sur Jabber si la fonction DNS du routeur est sollicitée)
Action Plan 2 : Sur le routeur HQ, entrer les commandes suivantes : no ip host vcsxe-hq.hq.collab10x.cisco.com 10.1.5.20 ip host vcsxe-hq.collab10x.cisco.com 10.1.5.20
Observe Results 2 : la résolution par le DNS externe se fait bien désormais et le nslookup fournit le résultat : internet adress = 10.1.5.20
Gather Facts 3 : Essayer de se logger de nouveau. Quel est le message d’erreur ? Redémarrer le Cisco Jabber « Cannot communicate with the server » ou « No internet connection. Please check your network settings »
Essayer de se connecter en telnet sur le Expressway-E avec le port 8443. Quel est le résultat de la connexion ? Depuis le putty sur le bureau du BB-PC, en sélectionnant telnet vers 10.1.5.20 port 8443, le résultat est « Network error : Connection refused »
Ce résultat peut indiquer un problème de connexion réseau ou de traversée de firewall. En se connectant sur l’Expressway-E (http://10.1.5.20/login, admin/Cisco1234), vérifier dans les Event logs les messages d’erreur, que voit-on ? Des erreurs toutes les 20s apparaissent du type "Inbound TLS Negociation Error"..."Peer's TLS certificate identity was unacceptable"entre la Src-ip 10.1.5.19 et la Dst-ip 10.1.5.20.
Vérifier la relation de l’Expressway-E avec l’Expressway-C, quel est l’état ? manque-t-il un paramètre ? Dans Configuration > Zones > Zones sélectionner la zone toExpressway-C, on voit en bas de page le State Failed (on peut également y accéder Status > Zones, ou encore par Configuration > Traversal > Ports puis en sélectionnant la zone toExpressway-C en bas de page dans la rubrique « Zones with Traversal configuration »)
On découvre que dans la partie SIP, le champ TLS verify subject name est vide
19 Se connecter sur Expressway-C (10.1.5.19 admin/Cisco1234) et comparer le paramétrage et l’état, quel est le format dans le champ peer address 1 dans la zone vers Expressway-E ? vcsxe- hq.collab10x.cisco.com
En déduire la correction à apporter dans Expressway-E et vérifier que le state devient Active sur Expressway-C, la zone "toExpressway-E"est failed. Le location peer 1 address vcsxe- hq.collab10x.cisco.com est bien résolu mais il y a sur le côté le message d’erreur SIP:failed to connect to 10.1.5.20:7001. Le lien juste en dessous "Check the certificates for the traversal connection" envoie vers la page Maintenance > Security certificates > Secure traversal test, de là il est possible de cliquer sur le bouton Check traversal certificates. Le résultat donne "TLS verify name not supplied"
Action Plan 3 : Sur Expreswway-E, dans la zone toExpressway-C, mettre dans le champ TLS verify subject name : vcsxc-hq.collab10x.cisco.com
Observe Result 3 : Après save, la zone "toExpressway-E" sur VCS-C et la zone "toExpressway-C" sur VCS-E deviennent actives et les serveurs sont "reachable" (en vert). Depuis le putty sur le bureau du BB-PC, en sélectionnant telnet vers 10.1.5.20 port 8443, il n’y a plus de rejet de conexion tant que l’on ne passe pas de caractère, et lorsqu’on le fait le résultat est désormais « Network error : Sofware caused connection abort » (c’est le soft qui nous rejette de façon normale) on peut voir dans les Event log que le tunnel entre Expressway-C et E est bien monté Toutes les minutes, il semble qu’il y ait un échange de certificat et donc la clé publique de vcsxc
Gather Facts 4 : Essayer de se reconnecter avec Jabber. Quelle erreur apparait dans les event logs de Expressway-C? Après plus de 20 sec (dûes aux requêtes DNS avec un timeout de 1sec, 1sec, 2sec, 4sec pour chaque requête pour _cisco-uds._tcp.hq.cisco.com puis _cuplogin._tcp.hq.cisco.com et enfin _collab- edge._tls.hq.cisco.com, on a le message d’erreur "your username or password is not correct".
Dans les event logs de Expressway-C, on obtient : edgeconfigprovisioning : Level="INFO" Detail="Failed to find home cluster for user" Username="jane.white". UTCTime="2016-02-04 9:58:41,893" Cette erreur peut correspondre à un problème de configuration dans CUCM
Essayer de se connecter avec Jabber, username jane.white depuis le HQ-PC pour vérifier déjà si le log direct depuis le réseau interne en sollicitant directement le DNS interne fonctionnerait (cela évitera de rechanger l’ad IP DNS sur BB-PC). Cela fonctionne-t-il ? En déduire les vérifications et corrections à faire dans CUCM Non le log échoue (on obtient le message d’erreur suivant : "Cannot find your services automatically. Click advanced settings to set up manually."
Dans CUCM > Device > Phone, sélectionner le CSFJANEWHITE : on peut constater que le owner user
20 ID est manquant. Dans User Management > End User, le user jwhite a des paramètres manquants également
Create Action Plan 4 : Dans CUCM > Device > Phone, sélectionner le CSFJANEWHITE , associer le Owner User Id jane.white Dans CUCM > User Management > End User : - cocher la case Home Cluster sous Service Settings (et seulement cela, car il n’y a pas de serveur de presence donc ne pas cocher Enable User for Unified CM IM and Presence) - Dans Device Information associer le CSFJANEWHITE - Dans Directory Number Associations , mettre la Primary Extension à +12012012002
Retester le log sur Jabber. Si ça ne fonctionne pas, vérifier l’authentification LDAP et le tester en se connectant à https://10.1.5.15/ucmuser avec jane.white / adpa$$1 (resetter le password dans l’AD si nécessaire et purger le cache de Jabber)
Pour purger le cache de Jabber et repartir en discovery comme au 1er démarrage, il faut supprimer le contenu des deux dossiers CSF se trouvant dans (si on est loggé en Administrator sur le PC): C:\Users\Administrator\AppData\Local\Cisco\Unified Communications\Jabber\CSF C:\Users\Administrator\AppData\Roaming\Cisco\Unified Communications\Jabber\CSF
GUIDED LAB 6 : TROUBLESHOOTING ON-NET MULTISITE CALLING ISSUES
TASK1 (appels intercluster):
Etape préliminaire : S’assurer que le BB-Phone est bien enregistré au CUCM BB (10.1.6.15). Si ce n’est pas le cas, corriger l’adresse IP de la sous interface HQ de 10.1.150.2 en 10.1.150.1
Pour voir le graph des messages SIP : S’assurer que dans CUCM > System > Enterprise Parameters > l’option Enable Call trace Log est à Enabled puis aller dans RTMT dans Voice/Video > Call Process > Session Trace Log View > Real Time Data. (Sinon par une copie de RealTime trace dans un fichier ouvert par Translator X)
Gather Facts 1a : Comprendre le Plan de numérotation.
Le plan de numérotation est :
81200X : HQ phones (+1201201200X sur CUCM HQ : 10.1.5.16)
82300X : BR1 phones (300X sur CUCM BR1 : 10.1.7.15)
83400X : BR2 Phone (+442288224001 sur CUCM HQ : 10.1.5.16)
21 84500X : BB Phone (5001 sur CUCM BB : 10.1.6.15)
Faire une trace realtime SDL sur le sub HQ et faire un Search sur Remote-Party-ID. Qu’observe-t-on ? Il est envoyé en +1201201200x quand HQ-Phonex appelle et vaut 5001 dans les messages SIP reçus de BB CUCM.
Quels sont les endroits possibles dans CUCM pour une manipulation de digits du n°appelant ? Les passer en revue et en déduire la correction à apporter Sur le Phone ou son DevicePool, Translation Pattern, Route Pattern, RouteList pour un RouteGroup donné, Trunk ou Gateway, Transformation Patterns associés aux devices.
-Sur le Phone, le paramètre « Caller ID From Calls From This Phone » est grisé car le « Use Device Pool Calling Party Transformation CSS (Caller ID From This Phone) » est coché.
-Sur le Device Pool Default, il n’y a pas « de Calling Party Transformation CSS (Caller ID From This Phone) » de défini. (Attention, sur le Device Pool il y a plusieurs Calling Party Transform CSS)
-Il n’y a pas de Translation Pattern qui match le numéro appelé 845001
-Dans le Route Pattern 845XXX, pas de manipulation de digits
-Dans la RouteList BB_rl et le Route Group BB_rg associé, pas de manipulation de digits
-Dans le Trunk BB_tr, il y a un calling party transformation CSS : BB-cg_out_css qui contient la partition : "BB-cg_out". On trouve le calling transformation pattern \+1201201.2XXX associé à la partition "BB-cg_out" avec un predot et un prefix +1201201
Action Plan 1a : Dans le CUCM HQ > Call Routing > Transformation > Transformation Pattern > Calling Party Transformation Pattern> sélectionner le Calling Party transformation Pattern \+1201201.2XXX associé à la partition "BB-cg_out", remplacer le prefix +1201201 par 81
Observe Result 1a : pas de changement
Gather Facts 1b : Le problème est-il résolu ? Non Refaire la même trace sur CUCM HQ et vérifier que le Remote-Party-ID est correct Oui. On voit sur le INVITE Incoming SIP TCP message venant du HQ-Phone1 un Remote-Party-ID +12012012001 qui devient 812001 dans l’INVITE Outgoing SIP TCP message envoyé vers 10.1.6.15 (BB CUCM)
En déduire une vérification sur le BB CUCM. Y’a-t-il transformation du calling number sur le trunk ? Non Dans ses Incoming Calling Party Settings, le SIP Trunk HQ_tr ne contient pas de calling party transformation et a l’option « Use Device Pool CSS » coché. Son Device Pool Default ne contient
22 pas de transformation. Le Significant Digits transforme le numéro appelé reçu par BB CUCM 845001 en 5001. Le CSS juste en dessous BB_css contient la partition BB du 5001. Autrement dit l’appel passe du SIP Trunk au BB-Phone sans passer par un Translation Pattern entre les deux.
En déduire la vérification et correction à effectuer et vérifier que le num appelant 812001 s’affiche sur le BB Phone Dans le Phone BB section Number Presentation Transformation > Remote Number , il y a un Calling Party Transform CSS BB-ph_in_css qui contient la partition BB-ph_in. Elle contient un pattern \ 81.2XXX qui ne sert à rien sauf à créer l'erreur.
Action Plan 1b : Dans le CUCM BB Call Routing > Transformation > Transformation Pattern > Calling Party Transformation Pattern> supprimer le Calling Party transformation Pattern \81.2XXX
Observe Result 1b : L’appel de +12012012001 vers 845001 présente bien un num appelant 812001 sur le phone BB, mais HQ-Phone affiche toujours 5001
Gather Facts 1c : Le problème est-il résolu pour le HQ-Phone (845001 s’affiche et non plus 5001)? Non En déduire la correction à apporter ?
Action Plan 1c : Sur le CUCM HQ, ajouter le Calling Party Transformation Pattern : 5XXX dans la partition HQ-ph_in avec le prefix : 84 (en étant certain d'avoir dans les services parameters du service CallManager (Advanced): Apply Transformations On Remote Number = True)
Observe Result 1c : L'appel de HQ1 vers 845001 apparait en 6 digits sur les 2 téléphones
Gather Facts 2 : Faire une trace SDL sur BR1 CUCM et vérifier si l’appel peut partir correctement vers le CUCM BB Y’a-t-il l’erreur Send Error to 10.1.15.6:5060 for transport TCP ? Si oui alors aller vérifier le Trunk BB_tr dans le CUCM BR1, qui pointe vers la mauvaise adresse IP, et remplacer la par 10.1.6.15.
Avec Dialed Number Analyzer > Analysis > Phones, simuler un appel du phone 3001 vers 845001 et vérifier les transformations de digits. En déduire la correction à apporter On découvre qu’il y a un called party transform mask 845002 dans le BB_rg associé au BB_rl du Route Pattern 845XXX
Action Plan 2 : Dans le CUCM BR1 dans Call Routing > Route/Hunt >Route List > Route List BB_rl, sélectionner en bas de page BB_rg et supprimer le mask 845002, puis Save, encore Save une fois revenu dans le Route List, Reset
23 Observe Result 2 : Les appels entre BR1 phones et BB phones (300X et 845001) fonctionnent avec la bonne présentation de numéro dans les 2 sens
Gather Facts 3a : Utiliser le DNA pour découvrir d’éventuels transformations, passer en revue le paramétrage de CUCM BR1 et HQ. En déduire la correction à apporter, puis retester l’appel
On découvre que sur CUCM-BR1 , dans le trunk HQ_tr, il y a dans la section "incoming called party settings" un prefix "+" sur incoming number.
Action Plan 3a Sur CUCM-BR1, dans Device > trunk, sélectionner le trunk HQ_tr, Aller dans "incoming called party settings", remplacer prefix "+" par "default" puis save et reset.
Observe Result 3a : En rappelant de +12012012001 vers 823001, l'appel se fait correctement mais présente le numéro 2001 et pas 812001 sur le BR1-phone, de même sur HQ-Phone1 : 3001 s’affiche.
Gather Facts 3b : Du fait du format de numéro présenté, en déduire les ajouts à effectuer
Action Plan 3b : Sur CUCM HQ, ajouter le Calling Party Transformation Pattern 3XXX dans la partition HQ-ph_in avec le prefix 82. Sur CUCM BR1, ajouter le Calling Party Transformation Pattern 2XXX dans la partition BR1-ph_in avec le prefix 81.
Observe Result 3b : En rappelant de +12012012001 vers 823001 et vice versa, les numéros s’affichent correctement sur 6 digits
Gather Facts 4 : Dans le cas des appels redirigés, examiner le dialplan de BB CUCM et découvrir par le DNA le problème Le DNA sur CUCM BB montre un Called Party Mask 823XXX sur le HQ_rg du HQ_rl
Dans le cas des problèmes d’affichage, ajouter les transformations nécessaires sur le CUCM BB
Action Plan 4 : Pour le problème des appels redirigés, sur le CUCM BB supprimer le Called Party Mask 823XXX sur le HQ_rg du HQ_rl Pour les problèmes de présentation, sur CUCM BB, ajouter le Calling Party Transformation Pattern \+1201201.2XXX et \+44228822.4XXX dans la partition BB-ph_in avec discard predot et les prefix 81 et 83. S’assurer que dans les services parameters du service CallManager (Advanced): Apply Transformations On Remote Number = True
TASK2 (appels avec CUBE):
24 Gather Facts Pour un appel vers +1301301300x, quel Route Pattern est utilisé ? Le Route Pattern utilisé doit être \+! qui par le Local Route Group est relié à HQ_rg qui contient la passerelle H323 10.1.5.1. En faisant debug voice translation sur HQ, on peut voir que le numéro d'appelant et le numéro appelé sont passés au format E164 (+12012012001 vers +13013013001)
Pour un appel vers +1301301300x, quel Route Pattern est utilisé ? En déduire les recherches à faire sur le CUBE (interpréter le debug voip ipipgw, debug voip dialpeer, debug voice translation)
Le debug voip ipipgw montre une réception de l’appel:
Feb 5 11:57:24.451: //8/8042089C0200/H323/setup_ind: Receive bearer cap infoXRate 24, rateMult 6 Feb 5 11:57:24.451: //8/8042089C0200/H323/cch323_set_h245_state_mc_mode_incoming: h245 state m/c mode=0x10F, h323_ctl=0x2F Feb 5 11:57:24.455: //-1/xxxxxxxxxxxx/H323/cch245_event_handler: callID=8 Feb 5 11:57:24.455: //-1/xxxxxxxxxxxx/H323/cch245_event_handler: Event CC_EV_H245_SET_MODE: data ptr=0x397D4D78 Feb 5 11:57:24.455: //8/8042089C0200/H323/cch323_set_mode: callID=8, flow Mode=1 spi_mode=0x3 Feb 5 11:57:24.455: //8/8042089C0200/H323/cch323_do_call_proceeding: set_mode NOT called yet...saved deferred CALL_PROC Feb 5 11:57:24.455: //8/8042089C0200/H323/cch323_process_set_mode: Setting inbound leg mode flags to 0x4F0, flow-mode to FLOW_THROUGH Feb 5 11:57:24.455: //8/8042089C0200/H323/cch323_process_set_mode: Sending deferred CALL_PROC Feb 5 11:57:24.455: //8/8042089C0200/H323/cch323_do_call_proceeding: set_mode called so we can proceed with CALLPROC
Le debug voip dialpeer montre un match sur le dial-peer 2 en incoming et sur le dial-peer 12 en outgoing, calling number 2012012001 et called number 913013013001.
Feb 5 12:00:35.159: //-1/008CE00D0300/DPM/dpAssociateIncomingPeerCore: Calling Number=2012012001, Called Number=913013013001, Voice-Interface=0x0, Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE, Peer Info Type=DIALPEER_INFO_SPEECH Feb 5 12:00:35.159: //-1/008CE00D0300/DPM/dpAssociateIncomingPeerCore: Result=Success(0) after DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=2 List of Matched Outgoing Dial-peer(s): 1: Dial-peer Tag=12
Le debug voice translation montre une transformation du num appelant en format E164: Feb 5 12:09:40.291: //-1/80F2B8520400/RXRULE/regxrule_profile_translate_internal:
25 number=2012012001 type=unknown plan=unknown numbertype=calling
Feb 5 12:09:40.291: //-1/80F2B8520400/RXRULE/regxrule_profile_match_internal: Matched with rule 1 in ruleset 13
Feb 5 12:09:40.291: //-1/80F2B8520400/RXRULE/sed_subst: Successful substitution; pattern=2012012001 matchPattern=^([2-9]..[2-9]...... $) replacePattern=+1\1 replaced pattern=+12012012001
Et une transformation du num appelé en format E164:
Feb 5 12:09:40.291: //-1/80F2B8520400/RXRULE/regxrule_profile_translate_internal: number=913013013001 type=unknown plan=unknown numbertype=called
Feb 5 12:09:40.291: //-1/80F2B8520400/RXRULE/regxrule_profile_match_internal: Matched with rule 1 in ruleset 12
Feb 5 12:09:40.291: //-1/80F2B8520400/RXRULE/sed_subst: Successful substitution; pattern=913013013001 matchPattern=^91301301 replacePattern=+1301301 replaced pattern=+13013013001
Sur le HQ router, la commande sh voice translation-rule et sh voice translation-profile permet de retrouver la voice translation-profile toBR1 utilisant la rule 12 et 13 qui globalisent les numéros.
La dernière commande met en évidence la réception par CUCM BR1 d’un format E164 du numéro appelant et appelé. Est-ce le problème ?
Le calling et called number reçus par BR1 sont donc des numéros E164, transformés en 812001 pour le calling number par le Calling Party transformation Pattern \+1201201.2XXX (partition BR1- Ph_in), associé au BR1-Phone par le CSS BR1-Ph_in_css ; pour le called number, sur la line 3001 de BRA-Phone,le numéro +1301301300X est associé en alternate E164 number. Donc non le format E164 n’est pas le problème.
Est-ce que les appels d’un dial-peer voip H323 vers un dial-peer voip SIP et vice versa sont utilisés sur HQ ? Oui, du fait de la présence des commandes allow-connections h323 to sip et allow-connections sip to h323
Examiner la relation entre CUCM BR1 et le CUBE HQ. En déduire une correction
Sur CUCM-BR1, le trunk HQ_cube a comme référence : 10.1.5.1. Sur le routeur HQ, on les commandes :
dial-peer voice 12 voip
translation-profile outgoing toBR1
destination-pattern 913013013...$
session protocol sipv2
26 session target ipv4:10.1.7.15
incoming called-number .
voice-class sip bind control source-interface GigabitEthernet0/0.xxx
voice-class sip bind media source-interface GigabitEthernet0/0.xxx
Donc l'adresse présenté sur CUCM-BR1 est bien la bonne : 10.1.5.1. Debug ccsip message sur HQ aurait aussi pu montrer : INVITE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/UDP 10.1.5.1:5060;branch=z9hG4bK6F3E Remote-Party-ID:
Par contre sur CUCM BR1 sur le Trunk HQ_cube par lequel CUCM BR1 reçoit l’appel de HQ, le incoming CSS est à None !
Action Plan 1 : Aller sur CUCM BR1 dans Device > Trunk > trunk HQ_cube, mettre dans la section inbound calls le CSS trunk_CSS
Observe Result 1 : Le HQ-Phone peut appeler le BR1-Phone mais après 15s il y a déconnexion
L’appel fonctionne-t-il ? Réessayer les commandes de debug sur HQ La commande debug voip ipipgw montre des problèmes de codec 00/H323/cch323_peer_caps_ind_common: No matching codec after filtering - use dial-peer codecs in TCS Feb 5 12:50:01.987: //14/801D94F10500/H323/cch323_peer_caps_ind_common: need xcoder resource for codec mismatch Feb 5 12:50:01.987: //14/801D94F10500/H323/cch323_peer_caps_ind_common: try to find transcoder
En déduire la correction à faire Sur le routeur HQ, il faut indiquer le même codec sur les dial-peer entrant et sortant. Lequel ? En examinant la Region Default du Device Pool Default associé aux trunk HQ_cube de CUCM BR1, et de la gateway 10.1.5.1 sur le CUCM HQ, on peut voir que le codec commun serait G711µlaw
Create Action Plan 1: Sur le routeur HQ, aller dans dial-peer voice 2 et 3 (pour 10.1.5.15 et 10.1.5.16) et configurer la commande codec g711µlaw
Observe Result 1 : L’appel fonctionne (avec une bonne présentation de numéro en 6 digits)
Gather Facts 2a : Retester l’appel et vérifier par debug voip dialpeer si l’appel arrive bien jusqu’à HQ, et interprêter les
27 numéros appelant et appelé Depuis le BR1-Phone l’appel ou le rappel vers +12012012001 donne une absence de communication pendant 15s et ensuite un fast busy tone Sur HQ Le debug voip dialpeer montre qu'il y a utilisation du dial-peer voice 3, avec un numéro appelé de la forme "912012012001"et une transformation du numéro en E164 (+12012012001) par le translation-profile outgoing toHQ ; par contre le calling number reste 3001, ce qui ne devrait pas arriver.
Le format de numéro est-il correctement envoyé par HQ à CUCM HQ ? En déduire la correction à faire sur le routeur HQ
Normalement si CUCM-HQ reçoit le numéro en +12012012001, du fait de la présence de : voice translation-rule 2 rule 1 //^91201201/ //+1201201/ cela devrait faire sonner HQ phone 1. Mais comme l'appel est reçu depuis une passerelle H323, le "+" n'est pas envoyé, donc CUCM-HQ reçoit depuis HQ le called "12012012001" qui ne matche aucun numéro.
De plus dans CUCM-HQ > Device > Gateway > 10.1.5.1, on remarque que dans les "incoming called party prefix" on ajoute +1 aux appels en national. Donc il faut obtenir du routeur HQ le numéro en 2012012001 TON:national
Action Plan 2a : Sur le routeur HQ corriger la voice translation rule 2 comme suit: voice translation-rule 2 rule 1 /^91201201/ /201201/ type unknown national
Faire un test voice translation-rule 2 912012012001 type unknown pour vérifier qu’elle transforme bien en 2012012001 national
Observe result 2a Quand on refait l'appel vers +12012012001 depuis BR1 phone, l'appel apparait avec 823001 sur HQ1 phone et 812001 sur BR1-Phone.
Si ce n’est pas le cas, et qu’il apparaît avec 12012012001 sur le BR1 phone (sans + car l'appel passe par une passerelle H323 incapable de gérer les "+") alors :
Action Plan 2b : Sur le CUCM BR1, créer le calling party transfo pattern : 1201201.2XXX (partition BR1-ph_in), avec discard predot et le prefix 81
Observe Result 2b : Quand on refait l'appel vers +12012012001 (ou 912012012001) depuis BR1 phone, l'appel apparait avec 823001 sur HQ1 phone et avec 812001 sur BR1 phone.
Gather Facts 3 : BR1 phone appelle +12012012001. HQ phone sonne et présente 823001. Ne pas répondre. Si on
28 rappelle, c'est le numéro 3001 (contrairement au lab guide qui donne le numéro E164) qui apparait dans le journal d'appel car c'est celui qui est envoyé par CUCM-BR1. Si on rappelle ce numéro 3001 depuis le téléphone HQ, on tombe sur "the call cannot be completed as dialed..."
Gather Facts 3 : BR1 phone appelle +12012012001. HQ phone sonne et présente 823001. Ne pas répondre. Si on rappelle (on décroche et sélectionne le 1er numéro proposé), c'est le numéro 3001 (contrairement au lab guide qui donne le numéro E164) qui apparait dans le journal d'appel car c'est celui qui est envoyé par CUCM-BR1. Si on rappelle ce numéro 3001 depuis le téléphone HQ, on tombe sur "the call cannot be completed as dialed..."
Comment est-ce possible ? En déduire les corrections à apporter le numéro de BR1 n'est pas correctement envoyé, car il y a sur le routeur HQ :
voice translation-rule 3 rule 1 /^\([2-9]..[2-9]...... $\)/ /+1\1/ ! voice translation-profile toHQ translate calling 3 translate called 2
Cette règle ne s'applique pas puisque le numéro est 3001 et pas 3013013001. Autrement dit, il faut envoyer le numéro de BR1 phone comme 3013013001 . Puis il faut que le routeur HQ transforme ce numéro 3013013001 en TON national de façon à ce que la gw 10.1.5.1 de CUCM-HQ dans les "incoming calling party prefix" puisse ajouter +1 à l'appel qui arrivera en national.
Action Plan 3 : -Sur CUCM-BR1, créer un calling transform pattern : 3XXX (partition BR1-cg_out) avec prefix : 301301
-Sur le routeur HQ, modifier la voice voice translation-rule 3 en :
voice translation-rule 3 rule 1 /^\([2-9]..[2-9]...... $\)/ /\1/ type unknown national
Observe Result 3: L'appel vers +12012012001 depuis BR1 phone vers HQ se fait avec to 812001 / from 3013013001 (à cause d'un calling transform pattern : +1.XXXXXXXXXX). Mais dans le journal d'appel c'est bien le numéro E164 : +13013013001 qui apparaît. On peut donc faire le rappel vers BR1 phone. Il nous reste donc à modifier le numéro 3013013001 apparaissant sur HQ phone pour qu'ils apparaissent au format 6 digits
Action Plan 3b : Sur CUCM-HQ, créer un calling transform pattern : +1301301.3XXX / HQ-ph_in / prefix : 82
Observe Result 3b :
29 Quand on refait l'appel vers +12012012001 (ou 912012012001) depuis BR1 phone, l'appel apparait avec 823001 sur HQ1 phone et avec 812001 sur BR1 phone.
GUIDED LAB 7 : TROUBLESHOOTING OFF-NET CALLING ISSUES
TASK1 (Troubleshoot Off-Net Calling Issues Including MGCP, H323, SIP, and ISDN protocols):
Note préalable : Appliquer le contenu du fichier 4.4 HQ GW sur tous les PODs ou le faire appliquer par les stagiaires
1)---INBOUND PSTN CALL TO HQ SITE------
DF:PSTN > HQ (line2 : 4087071222 > 12012012001). L'appel ne marche pas immediatement (fast busy tone)
GF :
-debug isdn q931
Calling Party Number i = 0x2180, '4087071222'
Plan:ISDN, Type:National
Called Party Number i = 0xA1, '2012012001'
Plan:ISDN, Type:National
Cause i = 0x80A6 - Network out of order
-debug cch323 h225 :
//158/0A81F164800A/H323/generic_send_setup: src address = 10.1.10.1; dest address = 10.1.5.16
-On déduit que h323-gateway voip bind srcaddress appliqué sur la mauvaise interface (10.1.10.1). Il faut supprimer ces entrées et les appliquer à la bonne interface, celle qui est en 10.1.5.1
CAP :
interface GigabitEthernet0/0.1x2
no h323-gateway voip interface
no h323-gateway voip bind srcaddr 10.1.10.1
interface GigabitEthernet0/0.1x1
30 h323-gateway voip interface
h323-gateway voip bind srcaddr 10.1.5.1
OR:
-L'appel entrant PSTN > HQ (line2 : 4087071222 > 12012012001) fonctionne mais apparait avec la présentation "4087071222" ainsi que dans le journal d'appel
GF:
-Debug voip ccapi inout montre un TON qui est passé unknown
Call Params(Calling Number=4087071222,(Calling Name=)(TON=Unknown, NPI=ISDN, Screening=Not Screened, Presentation=Allowed),
-Sur la passerelle h323 10.1.5.1, vérifier les "incoming party calling prefix" :ils doivent être corrects. Le problème vient du TON qui est unknown à cause d'un voice translation-rule 1 qui transforme tout en TON unknown:
voice translation-rule 1
rule 1 // // type any unknown
voice translation-profile outHQ
translate calling 1
CAP:
-Enlever "translation-profile outgoing outHQ" des dial-peer voice 20 et 30:
dial-peer voice 20 voip
no translation-profile outgoing outHQ
dial-peer voice 30 voip
no translation-profile outgoing outHQ
OR:
-L'appel apparaît en 4087071222 sur le téléphone HQ1 lors de l’appel entrant, mais en +14087071222 dans le journal d'appel donc en E164, ce qui permettrait le rappel du numéro. Ceci dit, si on rappelle ce numéro E164 ça ne marche pas. Ce problème sera résolu ci-dessous
2)-----HQ CALLS TO PSTN------
DeFine pb: HQ phones vers 9911 ne marche pas et après 15s on a "the call cannot be completed as...". L’ecran de HQ Phone1 affiche alors à la place de 911, +911
GF:debug voip dialpeer ne montre aucun dial-peer out. Show dialplan number 9911 ne donne rien.
31 CAP:
-modifier le dial-peer voice 1 ( destination-pattern 0T à l'origine)
dial-peer voice 1
destination-pattern 9T
-Dans CUCM-HQ, modifier le TP 9.911 et activer "urgent priority" pour accélerer l'appel.
OR: L'appel se présente immédiatement sur la première ligne du PSTN : 2012012001 et il apparait sur HQ1 phone : 911. On peut aussi essayer de rappeler le PSTN avec +14087071222. Maintenant que le dial-peer voice 1 est correct, ça marche! L'appel se présente sur la 2ème ligne avec le numéro 2012001.
------
DeFine PB: HQ phones vers 914087071222. En décrochant le téléphone, on ne peut pas dépasser la numérotation "9140870712" ensuite on a : a "the call cannot be completed as...".
GF: le DNA dans CUCM-HQ pour 914087071222 donne "blockthispattern" alors que pour 9140870712, il donne le TP incorrect : 91.[2-9]XX[2-9]XXXX
CAP : Dans CUCM-HQ, modifier le TP:91.[2-9]XX[2-9]XXXX en ajoutant XX
OR : L'appel depuis HQ1 vers 914087071222 se présente sur la ligne 2 du PSTN avec 2012001 et l'appel vers 912012517295 se présente de la même manière sur la 3ème ligne du PSTN
------
DF: HQ phones vers 9011442030215601#. L'appel tombe sur "the call cannot be completed as...".
CAP : Dans CUCM-HQ, modifier le TP: 9011.1# en 9011.!#
OR : L'appel depuis HQ1 vers 9011442030215601# se présente sur la ligne 5 du PSTN avec 2012012001 et 011442030215601 s’affiche sur le HQ Phone1
3)------INBOUND PSTN CALL TO BR1 SITE------
DeFine Pb : PSTN line 2 > BR1 (13013013001) ne marche pas : "the call cannot be...."
GF: debug voip dialpeer : calling= 4087071222, called=3013013001 (initialement), incoming dial-peer 2, outgoing dial-peer 1. On a aussi avec debug voip ccapi inout :
Call Params(Calling Number=4087071222,(Calling Name=)(TON=National, NPI=ISDN, Screening=Not Screened, Presentation=Allowed),
Called Number=+13013013001(TON=Unknown,
-Sur dial-peer voice 2, il y a un translation-profile ougoing outBR1 qui explique pourquoi le debug voip donne un called avec +13013013001 (car l'appel entre en isdn avec 3013013001 type national)
-A priori CUCM-BR1 récupère un appel avec calling=4087071222 et called=+13013013001 (voir aussi
32 debug voip ccapi inout ci-dessus)
GF:debug ccsip message ne donne rien.
CAP :
-Ajouter : dial-peer voice 1
session protocol sipv2
OR: Toujours en fast busy tone mais on voit les messages SIP être envoyé correctement
GF:Faire un trace SDL sur CUCM-BR1, on reçoit dd="+1+13013013001". Sur BR1 CUCM, dans le trunk BR1_tr, dans inbound calls, il y a un prefix : +1
CAP: Sur CUCM-BR1, dans le trunk BR1_tr, enlever le prefix DN +1. Save puis reset
OR: l'appel PSTN line 2 > BR1 (13013013001) se fait bien sur BR1 Phone et il apparait le calling="4087071222", de même dans le journal d'appel, ce qui fait qu'on ne peut pas rappeler. SIP ne supporte pas l'envoi des TON, donc on ne peut pas appliquer un incoming prefix en fonction de ce dernier. La solution consiste à modifier directement depuis HQ l'envoi de 4087071222 en E164
CAP : ajouter dans BR1 router
voice translation-profile outBR1
translate calling 1
(contrairement à la correction, conserver translate called 1, sinon l'appel ne passe plus)
OR : Tester sur le routeur BR1 :
BR1#test voice translation-rule 1 4087071222 type national
Matched with rule 2
Original number: 4087071222 Translated number: +14087071222
OR: Faire l'appel de PSTN line 2 > BR1 (13013013001).
-debug voip ccapi inout:
Call Params(Calling Number=+14087071222,(Calling Name=)(TON=Unknown,
33 Called Number=+13013013001(TON=Unknown,
Le téléphone BR1 montre le numéro appelant en 4087071222 car il y a un calling transformation pattern \+1.XXXXXXXXXX (partition BR1-ph_in) qui s'applique sur les téléphones de BR1.
-Si on rappelle le numéro E164 : +14087071222 depuis BR1 phone ça ne marche pas : on reste en "+14087071222 connecting" silencieusement durant plusieurs minutes. Voir le pourquoi ci-dessous
------
Define Pb : BR1 Phone > 9911 ne marche pas. On reste en "9911 connecting" silencieusement durant 2-3 minutes.
GF : debug ccsip message ne donne rien et en SDL on peut voir dans l'invite que le port demandé est à 1720.
CAP: Sur CUCM-BR1, changer le port dans Br1_tr de 1720 à 5060.
OR: après 15s, l'appel part avec 3001 qui apparait sur la 1ere ligne du PSTN, ce qui n'est pas une présentation correcte.
GF: Dans CUCM-BR1, dans le TP 9.911 il y a bien un urgent priority et en faisant un block this pattern, on peut voir qu'il n'y a pas 15s d'attente. En fait c'est le dial-peer voice 2 qui contient destination- pattern 9T qui crée ce pb.
-GF:dans les phones BR1, dans caller ID for call from this phone, le calling party transformation CSS = BR1-ph_in_css.
CAP:Dans CUCM-BR1, dans phone 1. mettre BR1-ph_out_css . (c'est déjà fait dans le 2eme téléphone BR1 phone 3002). La partition de ce css, BRA-ph_out, est associé au calling transfo.pattern 3XXX / prefix : +1301301
34 -OR: BR1 ph appelle 9911. le numéro montré au PSTN après 15s devient +13013013001. On en restera là mais ce devrait être 3013012001. Les appels à l'international apparaissent aussi avec ce numéro. Tous les appels PSTN mettront 15s du fait du dial-peer 1 pots / destination-pattern 9T. A moins de definir un dial-peer par type d'appel sub, nat, int et de faire des translation-profile par type d'appel, on aura pour tous les type d'appel, l'appelant au format E164.
OR : Maintenant si on appelle depuis BR1 phone le numéro E164 : +14087071222 ça marche, toujours après 15s d'attente.
NOTE:les appels depuis PSTN line 2 vers 3013001 ne marche pas car il n'y a pas de destination- pattern 3013....Copier le dial-peer voice 1 voip en tant que voice 2 voip et mettre ce destination- pattern à la place:
dial-peer voice 3 voip
translation-profile outgoing outBR1
destination-pattern 3013...
session protocol sipv2
session target ipv4:10.1.7.15
incoming called-number .
voice-class codec 1
4)------INBOUND PSTN CALL TO BR2 SITE------
DF: Appel depuis PSTN line 5 vers 2288224001 (tel BR2) : fast busy tone
GF: sh ccm-manager indique que la passerelle est registered. Cela a été résolu dans le TT1. Sh ccm- manager backhaul montre également la connexion TCP sur le port 2428 et l’adresse du CUCM 10.1.5.16. debug isdn q931 :
Calling Party Number i = 0x2180, '2030215601'
Plan:ISDN, Type:National
Called Party Number i = 0xA1, '2288224001'
Plan:ISDN, Type:National
Cause i = 0x8081 - Unallocated/unassigned number
GF: Dans CUCM-HQ, la passerelle BR-2 MGCP n'a pas de CSS. On peut vérifier aussi dans les traces que le TodFilteredPss=
CAP : Dans CUCM-HQ, dans la gateway BR2, mettre le CSS = Gw_css. Save et apply config. On voit bien que la passerelle BR2 réinitialise ses ports voix
OR : L'appel reste toujours en fast busy tone alors que show isdn status et show ccm-manager sont parfaitement correct. Il semble que normalement il devait y avoir omission de la commande : isdn
35 bind-l3 ccm-manager mais elle est bien présente. On peut vérifier avec show ccm-manager backhaul
OR: En faisant une trace SDL on s'aperçoit que :
Digit analysis: match(pi="2",fqcn="", cn="+442030215601", plv="5", pss="HQ-DN:BR2-DN", TodFilteredPss="HQ-DN:BR2-DN", dd="2288224001",dac="1")
On s'attendait plutôt à avoir : dd="+442288224001",
CAP : Dans CUCM-HQ, dans la gateway BR2, dans Incoming Called Party settings, le national Number est en "Default". Le changer par "+44"
OR: Trace SDL donne :
Digit analysis: match(pi="2", fqcn="", cn="+442030215601",plv="5", pss="HQ-DN:BR2-DN", TodFilteredPss="HQ-DN:BR2-DN", dd="+442288224001",dac="1")
L'appel est présenté sur BR2 phone avec 2030215601 mais dans le journal d'appel on voit +442030215601. Il y a en effet sur le phone BR2 dans remote number calling transformation css : BR2-ph_in_css : il enlève +44 avec le calling transfo pattern : \+44.XXXXXXXXXX / predot
GF:Si on rappelle ce numéro +442030215601 depuis le journal d'appel du téléphone BR2, ça ne marche pas. Apparemment, sur ce téléphone SIP, c'est du digit par digit quand on rappelle. On le voit car lors du rappel les digits sortent 1 par 1 et finalement c'est +4 qui est conservé pour l'appel.
36 Sur le RP \+! on est en urgent priority, ce qui fait que l'appel est immédiatement envoyé si on compose en digit par digit ou par le journal d'appel (c'est propre au 7965 en SIP : on voit bien chaque digit qui est composé dans le rappel, c'est pas le cas sur un 9971). La solution peut être d'enlever urgent priority dans \+! mais fera attendre 15s pour TOUS les appels, sinon de composer manuellement 902030215601 qui doit être transformé en E164 par TP 90.[1-9]XXXXXXXXX(ajoute prefix +44) . Autre solution : ne pas globalizer l'appelant en E164
CAP: Dans CUCM-HQ, modifier le TP 9.XXXXXXXX qui devrait avoir un préfix +4420 et pas +4422 pour pouvoir numéroter 930215601. Puis modifier dans la passerelle MGCP BR2 :
OR:Si on appelle depuis le PSTN ligne 5, l'appel apparait dans les missed called avec "902030215601". On peut donc rappeler 902030215601 qui se présentera sur le PSTN line 5 avec 2288224001. 9112 fonctionne et fait sonner la ligne 4 PSTN (UK Emergency). 902030215601 fait sonner la ligne 5. 90014087071222 fait sonner la ligne 2 après 15s ou immédiatement en ajoutant un #
Note : Si on appelle depuis la ligne 2 du PSTN le numéro 011442288224001, l'appel n'arrive pas en international mais en TON national donc l'appelant sur BR2 apparaît avec 904087071222 (au lieu de avec 9004087071222) , ce qui ne permet pas le rappel vers ce même numéro (Mais l’appel direct du BR2-Phone vers 9004087071222 marche). C'est donc un problème avec notre PSTN qui ne met pas le TON correctement
37 GUIDED LAB 8 : TROUBLESHOOTING OFF-NET CALLING ISSUES
TASK1 (Troubleshoot ILS and GDPR)
Préalable : supprimer les RP: 845XXX sur CUCM-HQ et RP 812XXX sur CUCM-BB car les appels fonctionnent sinon
Define pb : Si on tente d'appeler ces numéros 812001 depuis BB ph ou 845001 depuis HQ phs, on a : "the call cannot be completed...". De même si on essaie de contacter les URIs : [email protected], [email protected] . Par contre depuis le BB-Phone, [email protected] est joignable.
GF: Dans CUCM-HQ et CUCM-BB : advanced features > ILS configuration. Dans les 2 CUCM, BB cluster ou HQ cluster sont "USN Data Synchronization Status : unknown". Dans le passé ils se sont joint puisqu'ils apparaissent dans" Last USN Data Received". D'après le message qui apparait dans les traces SDL : "decryptedData failed", cela signifie que ça peut être un pb de mot de passe
-Call routing > Global dial plan replication > Learned Numbers : 812001 sur CUCM BB et on a rien sur CUCM HQ
-Pour learned patterns : rien pour l'un et l'autre
-Pour learned Directory URI : pour CUCM-BB : [email protected]. Pour CUCM-HQ : [email protected] et [email protected]
CAP:
-Avertir en ILS les DN et les URI en allant dans les 3 DNs (+12012012001,+12012012002 sur CUCM HQ, et 5001 sur CUCM BB) et cocher les cases :
38 -Dans les 2 CUCM-HQ et CUCM-BB, advanced features > ILS configuration . Mettre le mot de passe : ilspass. Le temps de synchronisation est de 1 minute. Cliquer sur le bouton refresh après une minute et on devrait voir sur chaque CUCM le USN Data Synchronization Status="up to date" immédiatement pour le cluster local et distant.
OR: Dans Call Routing > g d p r > learned numbers, CUCM HQ montre 845001 dans la partition Global Learned Enterprise Patterns et CUCM BB montre 812001 et 812002 dans la partition Global Learned Enterprise Numbers. Dans Call Routing > g d p r > learned directory URI , CUCM HQ apprend [email protected] et [email protected] et CUCM BB apprend [email protected] , [email protected] , [email protected] , [email protected]
Les appels ne passent pas en numérotation. Certains passent en URIs : HQ1 appelle [email protected] mais BB ne peut pas appeler [email protected]
GF: Route plan report montre que la partition pour atteindre 845001 est "Global Learned Enterprise Pattern"
CAP:
-Dans CUCM-HQ, mettre cette partition "Global Learned Enterprise Pattern" dans HQ_phones_css (sinon mettre la partition "HQ-DN" dans call routing > g d p r > partitions for learned Numbers and patterns et attendre 1 minute pour la mise à jour).
-Dans CUCM-BB, mettre la partition "Global Learned Enterprise Numbers" dans BB_css
OR:on peut appeler depuis 2001 vers 845001 ou vers [email protected] mais pas de 5001 vers 812001 ou [email protected] : "the call cannot be"...
Note : pour faire l'appel, il faut que le CSS de l'appelant matche la partition du numéro appris (Global Learned Enterprise Numbers) ET la partition du sip route pattern. A l'autre bout, sur l'autre CUCM, il faut que le CSS du trunk coincide avec la partition du numero alternate.
GF: sur CUCM-BB, le BB_css contient bien la partition "Global learned Enterprise Numbers". C'est le CSS du trunk HQ_tr donc l'appel peut sortir vers 845001. Par contre l'appel dans l'autre sens ne marche pas (de 5001 vers 812001). Dans CUCM-HQ, advanced features > ILS configuration > advertised route string : hq.cisco.con au lieu de hq.cisco.com.
CAP : Dans CUCM-HQ, advanced features > ILS configuration > advertised route string : hq.cisco.con. Changer cette valeur pour hq.cisco.com et attendre environ 1 minute, le temps de mettre à jour.
39 OR:Les appels de BB ph vers 812001 et [email protected] fonctionnent
Note : les appels sont dans tous les cas présentés en 6 digits
GUIDED LAB 9 : TROUBLESHOOTING DEVICE MOBILITY
TASK1 (Troubleshoot Device Mobility
Préalable : Dire aux stagiaires d'associer le dp BR2 au DMI 10.1.110.0/24. Aller dans CUCM-HQ : System > Device Mobility> Device Mobility Info. Choisir HQ_dmi et selectionner le device pool BR2. Puis faire un reset : on doit voir le message "Device in home location" sur HQ1 mais ce message n'apparait pas sur HQ2
Define Problem : après avoir resetté le téléphone HQ1, il y a le message "device in Home Location" (attention, le téléphone se met vite en veille après le redemarrage, appuyer sur la touche exit par ex.). Ce n'est pas le cas de HQ2 : il n'y a aucun message. Ce n'est pas ce que je remarque, la mobilité ne semble pas configurée sur les phones HQ. Par contre sur le téléphone BR2, si on redemarre, le téléphone indique "Device in home location"
GF: Service parameters > Call Manager > device mobility mode = on, donc tous les téléphones étant configuré en "default" sont donc activé pour la mobility par défaut. Ce n'est pas le cas de HQ2 (device mob = off), mais de HQ1 et BR2 phones
CAP: sur HQ2, activer device mobity mode = default et redémarrer le poste.
OR: Au redemarrage, le telephone passe en veille, appuyer sur la touche verte pour voir le message "Device in home location" apparaître.
GF:vérifier que le DP BR2 est bien associé à HQ_dmi=10.1.110.0/24 et vérifier dans "view current Device mobility settings" dans la config du téléphone qu'il n'y a pas de roaming pool ("Not selected"). Les 2 DP, default et BR2, ont comme Physical Location BR2_pl. Donc il n'y a pas de changement de DP dans ce cas.
40 CAP:Dans DP default, mettre Physical Location HQ_pl au lieu de BR2_pl et faire un reset du DP.
OR:Dans les télephone HQ ou BR, "view current Device mobility settings", vérifier que le DP = BR2. il y a eu aussi un message qui a montré "Device in roaming location" pour les 2 téléphones HQ et pour BR2, le message est resté "montré "Device in Home location" .
Composer le numéro 914087071222 et voir que l'appel sort par la gw BR2 par debug isdn q931. L'appel sort correctement :
Calling Party Number i = 0x0081, '+12012012001'
Plan:Unknown, Type:Unknown
Called Party Number i = 0x80, '0014087071222'
Plan:Unknown, Type:Unknown
Note : Si l'appel échoue c'est sans doute parce que le TP 9.1[2-9]XX[2-9]XXXX n'aurait pas été corrigé dans un lab précédent, il lui manque XX pour que ça marche
OR:l'appel marche et fait sonner la ligne 2 du PSTN avec lenuméro E164 +12012012001. on peut corriger ça en ajoutant dans les Cg trans pattern : \+.12012012XXX / BR2-cg_out / predot. En ISDN on aura, cd=0014087071222, cg=12012012001
TT10
41 ______
Préalable : dans CUCM-HQ : System > Device Mobility> Device Mobility Info. Choisir HQ_dmi et associer le DP default à la place de BR2
Define problem : Sur HQ2, en appuyant sur le bouton service, on voit EM "host not found".
GF:Dans CUCM-HQ : Device > Device Settings > Phones Services > EM. Le service URL montre l'IP 10.1.5.1
CAP: corriger en 10.1.5.15.
OR : Après update subscription il y a une erreur HTTP Error [404].
GF:En fait même l'URL est incorrect! C'est : http://10.1.5.15:8080/emapp/EMAppServlet? device=#DEVICENAME#
CAP: -Corriger le service URL avec http://10.1.5.15:8080/emapp/EMAppServlet? device=#DEVICENAME#
-Faire un update subscription et changer l'URL. Le téléphone doit restarter et remontrer : "Device in Home location"
OR: Lancer le service EM. On a la mire de UserID / PIN. Entrer john.doe / 12345 j'ai l'erreur "Please try to login again (201)".
CAP : Modifier le PIN du user john.doe en 12345. On a maintenant l'erreur "Login is unavailable (205)".
GF: Le user john.doe, le profil n'est pas dans "Controlled Profiles".
CAP: Dans User Management > End User : Ajouter l'UDP john_dp au user john.doe dans "Controlled Profiles".
OR:Le login est successful et on a le numéro +12012012222. On compose 9911 pour voir si l'appel se fait "the call annot be completed..."
GF: Dans Device > Device Settings > Device Profile, l'UDP john_dp, le CSS est "HQ-ph_in_css"
CAP : Dans Device > Device Settings > Device Profile : john_dp. Aller dans le DN +12012012222 et mettre le CSS HQ-phones_css. Faire "apply config"
OR: Le téléphone va redemarrer avec le profil par défault. Se relogger. L'appel 9911 marche correctement
Note : Si l'appel échoue c'est peut être parce que le téléphone HQ2 est en "Roaming Location" et donc que l'appel sort par BR2 avec 00911. Pour que le numéro 9911 soit envoyé correctement, créer dans les Called transfo pattern : \+.911 / BR2-cd_out / predot / Called party transform mask=112 (l'appelant apparait avec 12012012002)
42 TT11
______
Préalable : Si besoin delogguer le poste HQ2 de l'EM en allant dans le device HQ2 > Extension information > logout. On doit revenir avec le numéro +12012012002
NOTE IMPORTANTE : Il est possible que ce lab ne soit pas du tout en place : pas de RD et pas de RDP. Dans ce cas le faire configurer par les stagaire. Le lab concerne le téléphone HQ2 mais ici on a choisi de le faire avec HQ1
______
Configuration
1) Dans User Management > End User > john.doe, Cocher:
* Enable Mobility
* Enable Mobile Voice Access
Save
2) Dans Device > Device Settings > Remote Destination Profile, mettre:
* Name : Jdoe_RDP
* User ID : john.doe
* Device Pool : Default
* Calling Search Space : System_css
Save
3) Click on Line [1] - Add a new DN
* Directory Number : \+12012012001 avec Urgent priority
* Route Partition : HQ-DN
On doit être en Associateed device avec le phone HQ1
43 4) Cliquer sur Go pour revenir sur la config du RDP puis faire Add a New Remote Destination et entrer les paramètres suivants:
44 Note : Si Save montre REMOTEDESTINATION_MOBILITY_NOT_ENABLED, il faut d'abord activer la mobility sous le user john.doe comme dans le point 1)
5) Associer le Owner User ID sous le téléphone HQ1
TASK 1 : Troubleshoot Mobile Connect
Define Problem : Quand on place un appel depuis la line 2 PSTN (RD de hq2) vers 12012012001, l'appel présenté sur hq2 est 4087071222 et pas 2001
GF: la Line association est décoché pour le RD jdoe_home.
CAP : Dans le RDP puis dans le RD : cocher la case Line association
45 OR : 2002 est maintenant présenté sur hq2
DF : Si on appelle 2002 depuis HQ1 on devrait avoir PSTN line 2 qui sonne aussi. Ce n'est pas le cas
GF : dans le RD John home, Ring schedule : seulement le sunday.
CAP : on coche "Enable Single Number Reach" et on met le ring schedule à "All the time"
OR: rien ne change
GF : Dans jdoe_RDP, il y a rerouting CSS =
CAP : Dans jdoe_RDP, il y a rerouting CSS : system_css
OR : Appel de HQ1 vers HQ2, la line 2 PSTN sonne mais présente 2001.
CAP:Ajouter un calling transformation pattern = 2XXX / pt=HQ-cg_out / prefix = 201201.
OR: l'appel de HQ2 vers HQ1 apparaît avec 2012001 sur la 2eme ligne du PSTN alors qu'on attendait 2012012001. La gateway HQ ne modifie pas l'appelant car il n'y a pas de règle translation dans ce sen d'appel. Néanmoins ce n'est pas 10D qui est présenté mais 7D. Ddebug isdn q931 :
Calling Party Number i = 0x2181, '2012012002'
Plan:ISDN, Type:National
Called Party Number i = 0x80, '14087071222'
OR : C'est un problème avec notre PSTN car l'appelant envoyé est correct.
______
DF : durant un appel actif entre 2002 et un autre téléphone on ne peut pas switcher vers la remote destination.
GF : si on appuie sur la touche mobility (3 fois la touche more) durant un appel entre 2001 et 2002, il apparait : "Mobility Connect Off / Contact admin to enable mobility)
GF:Si on décroche le PSTN puis qu'on raccroche. Le téléphone 2002 affiche la touche "resume" pour récupérer l'appel sur son IP phone. Néanmoins impossible de re-basculer sur le PSTN par la touche mobility ("il y a le message MobileConnect Off / contact admin to enable mobility")
CAP : ce message vient de la non association du poste 2002 au "owner user id : john.doe". Aller dans ce téléphone, associer ce user et faire reset.
OR: La touche mobility permet d'activer la mobility ou de la désactiver. Elle est fonctionnelle. Si on fait un appel entre 2001 et 2002, durant l'appel en cours on appuie sur mobility. "Send to mobile phone" donne "No Mobile Remote Destination found".
GF: RDP > RDP "john home" : "enable Move to mobile" est décoché
46 CAP : cocher puis save
OR: Appel de 2001 vers 2002 puis on appuie sur mobility > send to mobile phone. Le téléphone PSTN sonne avec 2012001.
TASK2
-----
Define problem : si on appelle le numéro MVA on tombe sur fast busy tone
GF : Debug voip dialpeer et debug voip application : "application mwa in dial-peer 4 not found"
IAP: l'application doit être MVA dans le
dial-peer voice 4
service mva
OR:refaire un appel : on attend "welcome to cisco unifed communication, enter your remote destination number followed by the pound key". On entre 912012517295 : "this is not a recognized number...". The number you dialed cannot be reached..."
GF : service parameter call manager : "inbound css for rd" : trunk or gw inbound css. Dans media ressources > MVA : 2012012999 relié à la pt: Global Learned Enterprise Patterns
IAP : mettre la partition : HQ-DN
OR : Depuis ligne 2 (RD), on appelle 12012012999 : "enter your pin" : to make a call press 1...Le problème n'est pas résolu : même message
GF: CSS de la line = HQ_phones_CSS mais pas de CSS dans le RDP. Depuis le téléphone HQ2, on peut appeler ce numéro :
GUIDED LAB 12: TROUBLESHOOTING CISCO TMS ISSUES
TASK1 (Troubleshoot Cisco TMS)
Define Problem: -La page web de TMS n’est pas accessible -Le provisioning de nouveaux users ou devices, ou les modifications de users ou devices existants n’est pas possible par la page web du TMS -En changeant la configuration du FindMe dans cisco TMS, les changements ne sont pas reflétés dans VCS
Gather Facts 1 :
47 La connexion Web au TMS se fait par https://10.1.5.34/tms avec le login/pass Administrator/Cisco1234. Mais en se connectant, la page web est inaccessible (Unable to Connect).
Pour quelles raisons ? Cela peut être dû à un problème sur le World Wide Web Publishing Service, qui est arrêté ou ne répond plus, ou la database inaccessible du fait d’un arrêt du service SQL ou plus rarement la database SQL est corrompu.
Comment vérifier les services ? En déduire la correction à apporter Aller directement sur la machine tms-hq, pour accéder au serveur Windows qui porte l’application TMS (changer la langue du claver en FR si nécessaire) et lancer la console des services par Start > Run > services.msc . On peut constater que tous les SQL Service sont démarrés (sauf le « SQL Server Agent (MSSQL Server) » mais ne nous concerne pas) mais ce n’est pas le cas du WWW Publishing Service.
Action Plan 1 : Depuis la console des services sur TMS, pour le service World Wide Web Publishing Service, faire un click droit sur le service et cliquer sur Start ou sélectionner ce service et cliquer sur Start en haut à gauche de la fenêtre.
Observe Result 1 : Après quelques secondes, l’accès web au TMS redevient possible
Gather Facts 2 Il n’est pas possible de provisionner de nouveaux users ou devices, ou changer des devices ou users existant par le TMS.
Aller aux options du menu de provisioning dans TMS. Qu’en déduire ? Corriger un deuxième paramètre Dans le menu Systems, le menu de Provisioning est manquant. Cela arrive lorsque que le Provisioning n’a pas été activé
Action Plan 2 : Pour corriger cela, aller dans Administrative Tools > Configuration > General Settings, et mettre le Provisioning Mode à Provisioning Extension
Observe Results 2 : Immédiatement après le Save, l’option Provisioning apparait dans le menu Systems et propose les options Users, FindMe, Devices
Gather Facts 3 Les changements de configuration FindMe ne sont pas appliqués dans le VCS. Comment le vérifier ? On peut vérifier le status de synchronisation de la fonction FindMe sur TMS et VCS : -sur VCS par: Status > Applications > TMS Provisioning Extension Services > TMS Provisioning Extension Service Status (https://10.1.6.19/login avec admin/Cisco1234) : il apparait Failed. En cliquant à droite sur View, on obtient les détails suivants : Service FindMe Status Failed
48 Response HTTP response error Reason (408) Unable to service request Le server address est bien défini à 10.1.5.34 (TMS)
-sur TMS par : Systems > Navigator > sélectionner le VCSC-BB dans le folder BB , on peut voir dans l’onglet summary : Warning #4122 - TMS Provisioning Extension services communication failure - The VCS is unable to communicate with the TMS Provisioning Extension services.
En cliquant dans l’onglet Provisioning, on peut vérifier le status du service FindMe : il apparait Failed : HttpResponseError. En cliquant sur ce message d’erreur pour obtenir des détails, on voit ” (408) Service Unavailable[Message: The API is currently disabled. To enable this feature go to the Provisioning Extension Settings page]”
Cela semble indiquer que l’option FindMe n’est pas active sur TMS. Aller vérifier si le provisioning FindMe est activé en allant dans Administrative Tools > Configuration > Provisioning Extension Settings.
Comment le réactiver ?
Action Plan 3 : dans TMS dans Administrative Tools > Configuration > Provisioning Extension Settings, mettre Enable FindMe à Yes, puis restarter le service TMS Provisioning Extension pour que le changement soit pris en compte (peut prendre 10min).
49