TUTO : Analyser les données d’un rapport CLIR
CLIR (Command Line Interface Report) est utilisé pour afficher les informations de débogage d’Asterisk.
Pour obtenir le CLIR pour un appel :
- Connectez-vous à l’administration système.
- Accédez à Rapports > CDR
- Sélectionnez un appel en cliquant sur la case à cocher correspondante
- Cliquez sur le bouton CLIR .
Les informations de sortie sont utilisées pour identifier le problème ; par exemple, si l’appel n’atteint pas sa destination. Veuillez lire les instructions ci-dessous pour savoir comment interpréter les informations de débogage :
La première partie d’un rapport CLIR consiste en des variables qui nous sont envoyées par Asterisk. Il donne essentiellement des informations sur qui appelle qui, l’identifiant de l’appelant, le code de compte, le type de canal, etc.
Analyse des variables Asterisk
Nous avons le type de canal. Il peut s’agir d’un canal SIP, IAX2 ou Zap selon le transport entrant.
Variables VAR
La première partie du rapport CLIR vous montre la déclaration des variables Asterisk, il s’agit de la partie colorée en bleue sur le rapport.
19:05:51 VAR: agi\_channel: SIP/1001-08185a40
Il est important de rappeler que sur certaines actions, comme la sortie de file d’attente et certains types de transferts, ce numéro est conservé. Cela signifie que 3 ou 4 appels distincts peuvent avoir 1 seul identifiant unique. C’est ainsi que nous les relions sur la page CDR dans les dernières versions.
19:05:51 VAR: agi\_uniqueid: 1173377151.6
La ligne ci-dessous nous indique l’ID de l’appelant.
19:05:51 VAR: agi\_callerid:1001
Si le contexte est le nom de la ligne réseau, cela signifie qu’il s’agit d’un appel entrant. Dans de tels contextes, seuls les DID sont autorisés. C’est pourquoi vous pouvez avoir des CLIR indiquant “Destination introuvable” car nous n’autorisons rien d’autre que les DID.
Il existe plusieurs autres contextes qui indiquent essentiellement à PBXware quelles limitations doivent être effectuées.
Lorsque nous sommes dans un contexte de « transfert », il n’y a pas de limitations pour les destinations.
19:05:51 VAR: agi\_callingpres: 0
19:05:51 VAR: agi\_callingani2: 0
19:05:51 VAR: agi\_callington: 0
19:05:51 VAR: agi\_callingtns: 0
19:05:51 VAR: agi\_dnid: \*149
19:05:51 VAR: agi\_rdnis: unknown
19:05:51 VAR: agi\_context: default
19:05:51 VAR: agi\_extension: \*149
Commandes
Nous allons maintenant identifier la deuxième partie du CLIR caractérisé par un fond coloré en jaune sur le rapport. Elle se compose de trois parties :
La commande TIME à exécuter résulte de Asterisk
La commande à effectuer peut être de deux types :
- Si elle commence par APP : cela signifie que nous disons à Asterisk de faire une action.
- Si ce n’est pas le cas, cela signifie que nous renvoyons simplement des informations de débogage afin que nous puissions facilement suivre ce qui se passe en cas de problème.
result-from-asterisk consiste généralement en result=[valeur], et il n’est vraiment utile que pour les entrées APP, car c’est à ce moment-là que nous aimerions lire un résultat d’Asterisk.
Ici, nous demandons Asterisk pour la variable TRANSFER_PARENT. Comme vous pouvez le voir, Asterisk a déclaré result = 0, ce qui signifie qu’il n’y a pas de telle variable. Si le résultat était, par exemple result = 1131023912.1, cela signifie que la variable est définie.
Cette variable nous indique que nous faisons partie d’un appel transféré ou que nous sommes fondamentalement un nouvel appel. Cela ne fonctionne que pour les transferts aveugles et les transferts normaux. Les transferts supervisés sont affichés comme de nouveaux appels et donc TRANSFER_PARENT est égal à 0 ici.
19:05:51 APP: get variable TRANSFER\_PARENT 200 result=0
Ici, nous définissons la variable TRANSFER_PARENT avec notre identifiant unique actuel. Notez la variable __ devant : cela signifie qu’Asterisk doit copier cette variable dans tous les appels qui suivent celle-ci.
19:05:51 APP: set variable \_\_TRANSFER\_PARENT 1173377151.6 200 result=1
La ligne suivante signifie que nous avons détecté le code de compte 1001 à partir de agi_accountcode.
19:05:51 Detected accountcode '1001' ... 200 result=1
Vérification du transfert aveugle (Blind transfer). Si quelqu’un a transféré une tierce partie, cela signifie que nous devons forcer un contexte de “transfert” qui permettra à cette partie d’être transférée vers n’importe quelle extension. Cela peut constituer un risque pour la sécurité, mais c’est le seul moyen de transférer avec succès un tiers.
19:05:51 APP: get variable BLINDTRANSFER 200 result=0
Maintenant nous vérifions si *149 est dans la base de données des SDA, cela pour deux raisons :
- Parfois, nous devons utiliser le contexte “par défaut” pour les appels SIP car il existe de nombreux Trunks SIP qui envoient des appels à partir d’adresses IP différentes. De cette façon, nous détectons la SDA et la bloquons immédiatement.
- Si les extensions locales appellent un SDA local, cela signifie que nous ne composerons pas vraiment, mais en fait nous composerons simplement l’extension locale. Exemple : supposons que nous ayons un SDA 09 74 10 10 10, si les extensions locales appellent ce numéro, nous ne composerons pas via notre Trunk, mais nous traduirions en fait ce numéro vers l’extension 100.
19:05:51 '\*149' is not in DID database, continuing ... 200 result=1
Ici on fixe une limite au niveau global du PBXware. Pour le moment, cela nous indique que nous avons fixé une limite à 246 appels mondiaux.
19:05:51 Set limit - 246 200 result=1
Cette ligne nous montre que Asterisk compare la limite globale au nombre actuel d’appels. Si la limite était atteinte, l’appel n’aurait pas pu être progressé et aurait été échoué à partir de ce moment.
19:05:51 Limit not exceeded (1 < 246) for localextensions 200 result=1
Les limites entrantes/sortantes existent aussi au niveau des extensions. Pour cette extension, la limite est fixée à 3 appels :
19:05:51 Set limit - 3 200 result=1
Comme pour la limite du PBXware, on compare les valeurs avec le nombre actuel d’appels sortants pour l’extension 1001. C’est le premier appel donc tout va bien, la limite n’est pas dépassée :
19:05:51 Limit not exceeded (1 < 3) for 1001\_out 200 result=1
Nous vérifions si le service Dernier appelant (*149) est activé pour cette extension particulière. Le service est activé, donc on progresse.
19:05:51 Lastcaller enabled 200 result=1
19:05:51 APP: answer 200 result=0
Maintenant, le rapport nous informe que nous diffuserons un fichier à l’autre partie.
19:05:51 Playing macro 'last-num-to-call' ... 200 result=1
Nous diffusons le fichier.
19:05:53 APP: stream file last-num-to-call 200 result=0 endpos=19040
19:05:53 APP: exec SayDigits unknown 200 result=0
Le rapport nous montre ici que l’on a fixé des délais d’attente. Après avoir appuyé sur la touche, nous attendons 3 secondes supplémentaires pour le chiffre suivant. On dit également que le délai de réponse global est de 6 secondes, ce qui signifie que si rien n’est entré en 6 secondes, nous considérons cela comme la fin de l’entrée :
19:05:53 APP: exec Set TIMEOUT(digit)=3 200 result=0
19:05:53 APP: exec Set TIMEOUT(response)=6 200 result=0
19:05:53 APP: answer 200 result=0
Maintenant, le système diffuse un autre fichier :
19:05:53 Playing macro 'to-call-this-number' ... 200 result=1
19:05:55 APP: stream file to-call-this-number 200 result=0 endpos=11040
Le système réinitialise à nouveau cette limite :
19:05:55 APP: exec Set TIMEOUT(response)=5 200 result=0
19:05:55 APP: exec Set TIMEOUT(digit)=3 200 result=0
Maintenant, le rapport nous indique l’exécution de l’application READ et nous disons à Asterisk de lire le fichier ‘press_one’ :
19:05:59 APP: exec read dtmfdata|press\_one 200 result=0
Maintenant, le système va vérifier si la touche DTMF 1 est enfoncée. Si elle est effectivement pressée, l’appel continue. Comme vous pouvez le voir, 1 est entre parenthèses (1), cela signifie donc que la touche est bien enfoncée :
19:05:59 APP: get variable dtmfdata 200 result=1 (1)
Désormais, le système vérifie s’il existe un autre préfixe réseau attribué avec l’extension “inconnu” :
19:05:59 Checking for 'Other Network' prefix ... 200 result=1
Puisque nous ne sommes pas un autre réseau, le système emprunte maintenant l’itinéraire (la route) :
19:05:59 Detecting destination for '0033501020304' ... 200 result=1
En routage simple, on constate que la route empruntée est la route internationale :
Looking for range in Simple Routing table ... 200 result=1
Found Destination 'International' (RouteID: 6) ... 200 result=1
Maintenant, le système définit un délai d’expiration, ici le délai est d’une heure (3600s).
19:05:59 APP: exec Set TIMEOUT(absolute)=3600 200 result=0
19:05:59 Setting AbsoluteTimeout to 3600 seconds ... 200 result=1
Ici, le système va chercher un Trunk et trouve un Trunk principal 032445231 pour cette destination particulière :
19:05:59 Found primary trunk '032445231' ... 200 result=1
Puisqu’il n’y avait pas d’autres Trunks, PBXware saute les trunks secondaires & tertiaires :
19:06:00 Secondary trunk set as '-- None --', skipping it ... 200 result=1
19:06:00 Tertiary trunk set as '-- None --', skipping it ... 200 result=1
Maintenant, le système va essayer de récupérer les données LCR à partir de la table LCR globale ou à partir de la table LCR dans les extensions.
19:06:00 Detecting LCR data ... 200 result=1
Encore une fois, le système vérifie les limites des extensions locales.
Set limit - 246 200 result=1
Limit not exceeded (1 < 246) for localextensions 200 result=1
Le système sauvegarde notre CallerID précédent.
19:06:00 APP: get variable CALLERID 200 result=1 ("gloCOM" )
19:06:00 Setting backup CallerID to 'gloCOM' ... 200 result=1
La ligne ci-dessous souligne une information importante. Celle-ci nous indique que le Trunk n’est pas défini pour faire de l’appel en E164, il y aura donc une translation de numéro.
19:06:00 Trunk does not support E164 ... 200 result=1
MONITOR_EXEC est une variable d’enregistrement globale et n’est pas liée à ‘Instant Recording’ mais plutôt à l’option ‘Record Calls’ dans Extension. Faites attention à cela pour des options supplémentaires. Pour le moment, comme vous pouvez le voir, il est vide, cela signifie donc que l’enregistrement est réglé sur “off”.
19:06:00 Dialing over PJSIP protocol ... 200 result=1
19:06:00 APP: set variable DYNAMIC_FEATURES automon 200 result=1
19:06:00 APP: set variable TOUCH_MONITOR_SILENT FALSE 200 result=1
19:06:00 APP: exec Set MONITOR_EXEC=|g 200 result=0
19:06:00 APP: set variable TOUCH_MONITOR_ARGS wav49|1173377151.6|m 200 result=1
19:06:00 APP: set variable TOUCH_MONITOR_START_SOUND recorded 200 result=1
19:06:00 APP: set variable TOUCH_MONITOR_STOP_SOUND beep 200 result=1
Maintenant, passons un appel.
exec Dial PJSIP/101/sip:101@70.210.41.14:6654,32,trixj
Le système vérifie l’état de l’appel (est-il RÉPONDU, OCCUPÉ…) et s’il est RÉPONDU, il vérifie combien de temps a duré l’appel.
19:06:06 APP: get variable DIALSTATUS 200 result=1 (ANSWER)
19:06:06 APP: get variable ANSWEREDTIME 200 result=1 (4)
Enfin, le système nous montre le temps total de conversation.
19:06:06 Total time: 4 200 result=1
Problèmes fréquents
Certains problèmes d’appels liés à votre configuration PBXware peuvent être résolus facilement en regardant le rapport CLIR d’Asterisk, notamment les lignes colorées en blanc voici quelques exemples.
- Exemple 1 : Horaires de fermeture actifs
Si un appel arrive alors que des horaires sont configurés, cela apparaîtra clairement dans le rapport CLIR.
Ici, on constate que le système est entrain de récupérer les données contenue dans les paramètres des temps de fonctionnement.
Fetching Operation Times data ...
On constate que les horaires sont activés sur la destination appelée :
Operation Times enabled, checking ...
Ici, le système nous informe que l’appel a été passé dans les heures de fermeture :
Closed day/time period in effect ..
Désormais, l’appel sera transmis à la destination par défaut configurée dans les temps de fonctionnement, ici la messagerie vocale de l’extension 108 :
Returning operator '108' as new destination ..
Forcing destination type to 'voicemail' (via Operation Times) ...
No limit for voicemail
exec Set CDR(userfield)=108
get variable CBUNIQUEID
Dialing Voicemail 108 ...
- Exemple 2 : Route non autorisée
Dans l’exemple ci-dessous, l’extension ne peut pas passer d’appels sortant et il est indiqué que l’utilisateur n’est pas autorisé à appeler cette destination.
Dans le rapport CLIR, l’erreur apparaît également :
Detecting destination for '0601020304' ...
Looking for range in Simple Routing table ...
Found Destination 'Mobile' (RouteID: 3) ...
Loading Default Operation Times ...
Skipped Operation Times ...
Cependant, le rapport nous montre que l’extension n’est pas autorisée à passer par la route Mobile, alors l’appel n’ira pas plus loin, comme le montre la ligne “answer 200 result=0”, la ligne suivante nous informe que le fichier son “not_authorized” est joué à l’appelant.
Destination 'Mobile' not allowed ...
answer 200 result=0
Playing macro 'not_authorized' ..
Afin de résoudre le problème, il suffit alors d’autoriser la destination Mobile dans l’extension concernée.
- Exemple 3 : DND activé
Si un appel est passé vers une extension et que celle-ci est en mode DND (ne pas déranger), cela apparaîtra dans le rapport CLIR :
'Do Not Disturb' is enabled ...
Enabling permament Do Not Disturb ...
exec Answer 200 result=0
Dialing Voicemail 108 ...
L’appel n’ira pas plus loin comme le montre la ligne “exec answer 200 result=0” et l’appel sera transmis à la boîte vocale de l’extension comme le montre la dernière ligne.
- Exemple 4 : Limite de canaux dépassée
Lorsqu’un appel entrant arrive et que tous les canaux sont déjà occupés, le rapport CLIR montre que cette limite est dépassée.
Tout d’abord, Asterisk fixe bien la limite de canaux à 8 (il s’agit de la configuration que vous avez indiquée dans vos réglages PBXware), et un neuvième appel entre alors, ainsi on peut voir que la limite est dépassée avec la dernière ligne :
Set limit - 8
Decrementing limit for '990.lmt_localextensions' ...
Limit exceeded (9 > 8) for localextensions
