Vous êtes sur la page 1sur 48

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
jane.white@collab10x.cisco.com et john.doe@collab10x.cisco.com

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: john.doe@collab10x.cisco.com
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 sgreen@collab10x.cisco.com.

-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
+12012012001@hq.cisco.com ou hq1@hq.cisco.com 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 hq1@hq.cisco.com , il y a :
tvcs  : Event=  "Call rejected" Service="SIP"Src-ip="10.1.50.201"…Src-
alias="sip  :john.doe.movi@collab10x.cisco.com"…Detail="Not Found" Protocol="TCP" Response-
code="404"

Depuis le HQ-Phone1, appeler john.doe.movi@collab10x.cisco.com 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" <sip:
+12012012001@10.1.5.16>;tag=88908d73d5e4047e02910ae3667a4ab0
To: <sip:john.doe.movi@collab10x.cisco.com>;tag=12928~94dcae32-10ec-4047-93b2-
1ada63d44c4f-45916520
Date: Tue, 02 Feb 2016 22:30:04 GMT
Call-ID: 88908d73-d5e40049-0c372dad-4a600c20@10.1.110.108
CSeq: 101 INVITE
Allow-Events: presence

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 +12012012001@hq.cisco.com ou hq1@hq.cisco.com, 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 hq1@hq.cisco.com et en Protocol SIP et en source Alias
john.doe.movi@collab10x.cisco.com

On peut aussi faire un test d’appel dans Jabber Video vers hq1@hq.cisco.com ou
+12012012001@hq.cisco.com 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 +12012012001@hq.cisco.com
et en déduire une correction à faire pour que l’appel fonctionne
INVITE sip  :+12012012001@hq.cisco.com 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  : <sip  :john.doe.movi@collab10x.cisco.com…>
From: “John doe” < sip  :john.doe.movi@collab10x.cisco.com…>
To: sip:+12012012001@hq.cisco.com


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 +12012012001@hq.cisco.com marche et apparaît comme
provenant de john.doe.movi
Gather Facts 4 :
Tester un appel de Jabber video vers HQ-Phone1 par hq1@hq.cisco.com 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, uri=hq1@hq.cisco.com
|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 hq1@hq.cisco.com 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 hq1@hq.cisco.com
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
hq1@hq.cisco.com dans la partition HQ-DN en cochant Primary URI pour cette URI.
Faire de même avec HQ_Phone2 avec hq2@hq.cisco.com

Observe Result 4 :


Un nouvel appel de Jabber Video vers hq1@hq.cisco.com fonctionne

Gather Facts 5 :


Retester un appel du HQ-Phone1 vers john.doe.movi@collab10x.cisco.com
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, uri=john.doe.movi@collab10x.cisco.com
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 john.doe.movi@collab10x.cisco.com 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
2001@hq.cisco.com. 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 hq1@hq.cisco.com et non 2001@hq.cisco.com
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 hq1@hq.cisco.com 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 jane.white@hq.cisco.com: 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:+13013013001@10.1.7.15:5060 SIP/2.0
Via: SIP/2.0/UDP 10.1.5.1:5060;branch=z9hG4bK6F3E
Remote-Party-ID: <sip:+12012012001@10.1.5.1>;party=calling;screen=yes;privacy=off
From: <sip:+12012012001@10.1.5.1>;tag=10DB8240-60E
To: <sip:+13013013001@10.1.7.15>

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,

Called Number=+13013013001(TON=Unknown,

33
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

-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

34
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=<none>.

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
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 :

35
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.
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

36
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

GUIDED LAB 8 : TROUBLESHOOTING OFF-NET CALLING ISSUES

37
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 : hq1@cisco.lab,
hq2@cisco.lab . Par contre depuis le BB-Phone, bb@cisco.lab 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 : hq2@cisco.lab. Pour CUCM-HQ : bb@bb.cisco.com et
bb@cisco.lab

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 :

-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.

38
Dans Call Routing > g d p r > learned directory URI , CUCM HQ apprend bb@bb.cisco.com et
bb@cisco.lab et CUCM BB apprend hq1@cisco.lab , hq1@hq.cisco.com , hq2@cisco.lab ,
hq2@hq.cisco.com

Les appels ne passent pas en numérotation. Certains passent en URIs : HQ1 appelle bb@cisco.lab
mais BB ne peut pas appeler hq1@cisco.lab

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 bb@cisco.lab mais pas de 5001 vers 812001 ou
hq1@cisco.lab : "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.

OR:Les appels de BB ph vers 812001 et hq1@cisco.lab fonctionnent

Note : les appels sont dans tous les cas présentés en 6 digits

GUIDED LAB 9 : TROUBLESHOOTING DEVICE MOBILITY

39
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.

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

40
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
__________________________________________

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?

41
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)

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:

42
 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

4) Cliquer sur Go pour revenir sur la config du RDP puis faire Add a New Remote Destination et entrer
les paramètres suivants:

43
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

OR : 2002 est maintenant présenté sur hq2

44
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 = <none>

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é

CAP : cocher puis save

45
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 :


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).

46
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
Response HTTP response error
Reason (408) Unable to service request
Le server address est bien défini à 10.1.5.34 (TMS)

47
-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).

48