XiVO Community

Si j'ai bien compris ta demande,

Pourquoi ne pas créer des extensions (ex: *8000) qui alimentent une valeur liée à la ligne dans la BDD asterisk :

exten => *8000,1,Set(DB(ligne/${CALLERIDNUM})=ouvert)
same => n,Hangup()

exten => *8001,1,Set(DB(ligne/${CALLERIDNUM})=ferme)
same => n,Hangup()

Tu bind sur 2 touches des téléphones concernés *8000 et *8001

Et derrière faire une routine de prétraitement sur les SDAs qui renvoie vers un dialplan à base de Gotoif =ouvert/ferme ${EXTEN] et voicemail

Bonjour Antoine,

Merci beaucoup pour ta réponse.

ça peut effectivement être une solution mais est-ce que cela va afficher sur l'écran du téléphone en question si le répondeur est actif ou pas ?

Sinon, n'y a-t-il pas une solution plus "standard" que ça ? Quelque chose en mettre en place avec Xivo sans forcément passer par des fichiers de conf ?

Avec ton idée, il n'est pas possible de combiner une activation / désactivation d'un renvoi inconditionnel ce qu'il ferait qu'il n'y aurait plus qu'une touche sur laquelle l'état serait en plus affiché ?

J'ai continué à chercher de mon côté entre temps et je me demande si ce n'est pas côté conf xivo que j'ai un soucis parce que quand j'utilise la cli astérisk, je vois bien la subscription et le hint de créer par rapport à mon renvoi et il semble aussi y avoir le watcher, j'ai l'impression que c'est juste l'état qui ne remonte pas sur le téléphone au final mais que le reste est bon.

En plus standard, tu as le client Xivo qui est prévu pour ça, tu as un mode DND au clic.

je partais du principe que tu n'avais que des téléphones, mais c'est le but du Desktop assistant de tout piloter simplement.

Tu as également beaucoup d'extensions qui existent déjà et qui font une bonne partie du taf :

Tu n'aura pas de diode de statut mais c'est clairement annoncé vocalement. (type *90 pour l'activation / désactivation de la messagerie)

Sinon, si il est question d'une gestion de standard, il est possible de configurer une file d'attente spéciale (Switchboard) qui ne va fonctionner qu'avec des téléphones un peu premium (ex: Yealink T54w)

https://documentation.xivo.solutions/en/latest/ipbx_configuration/switchboard/switchboard.html

Ca va permettre aux utilisateurs de s'abonner à la file d'attente quand bon leur semble, soit via BLF, soit via Desktop Client.

Tu vas associer le SDA principal de la structure à la file d'attente, les téléphones de tous les utilisateurs abonnés à la file sonneront.

Depuis la Webi de Xivo tu peux aussi pousser des configs de touches / utilisateur, certains types acceptent la supervison.

La couleur des BLF n'est pas toujours bonne si les services Xivo ont été redémarrés.

J'imagine que ça dépend aussi des téléphones utilisés (fonctionne avec Yealink)

Bonjour,

Merci beaucoup pour toutes ces infos. Tu vas dire que je suis pénible mais je trouve tout ça un peu lourd juste pour contourner une supervision qui ne fonctionne pas :)

J'ai continué les recherches sur mon problème d'origine, la supervision et j'ai quelques pistes, voyons si ça te dis quelque chose ;)

J'ai chercher la différence entre un Xivo sur lequel la supervision fonctionne et un autre o^ù ça ne fonctionne pas.

Déjà le premier truc que j'ai remarqué c'est que selon le Xivo, ça n'appelle pas la même extension :
sur xivo qui fonctionne -> 735222139710
sur xivo qui ne fonctionne pas -> *7358221397101
Quelle est la différence entre le 2 et le 8* ?

Ensuite, je te mets en PJ les traces complètes et tu vas vois que vers la fin de de la trace qui fonctionne, il y a la ligne :
== Extension Changed 7352221*39710[default new state InUse for Notify User jpqthjoe
qu'il n'y a pas dans la trace où la supervision ne fonctionne pas.
Tu as une idée de ce qui pourrait être changé ou à changer ?

J'ai regardé le dialplan mais je ne vois pas à quel moment ce changement d'état ce fait, faut dire que mes connaissances à partir de là sont assez limité, j'apprends au fûr et à mesure que je regarde

Je te laisse jeter un oeil à tout ça voir si t'as une idée ;)

Merci beaucoup en tout cas de m'aider et de t'intéresser à mon soucis, ça fait plaisir :)

Il y a des étoile qui ont sauté dans mon message précédent sur les extensions, tu peux les retrouver dans les traces comme il faut ;)

Ca m'apprendra à ne pas lire correctement avant d'en mettre une platrée, tu fais déjà du provisionnement de touche du coup.

Je peux te confirmer que le renvoi inconditionnel fonctionne sous Kuma avec la supervision, et ce qui est transmis chez moi à l'AGI est bien 2***221*Numéroàjoindre

/usr/share/xivo-config/dialplan/asterisk/extensions_lib_features.conf

[phoneprogfunckey]
exten = s,1,Gosub(xivo-chk_feature_access,s,1)
same  =   n,GotoIf($[$["${ARG1}" = ""] | $["${ARG2}" = ""]]?error,1)
same  =   n,Set(XIVO_SRCNUM=${CALLERID(num)})
same  =   n,AGI(agi://${XIVO_AGID_IP}/phone_progfunckey,${ARG2})
same  =   n,Set(XIVO_PHONE_PROGFUNCKEY_DEVICE_STATE=${ARG1}${ARG2})
same  =   n,GotoIf($["${XIVO_PHONE_PROGFUNCKEY_FEATURE}" != ""]?${XIVO_BASE_CONTEXT},${XIVO_PHONE_PROGFUNCKEY},1)
same  =   n,Hangup()

Je ne connais pas les scripts derrière, ni la matrice derrière ces arguments, mais il y a eu du changement à ce moment là :
https://documentation.xivo.solutions/en/latest/releasenotes/upgrade_from_helios_to_izar.html#python3-migration-scripts-and-agi

Peut être une piste.

Oui, pour le provisionnement de touche c'est déjà fait ;) mais t'inquiètes, toute info est bonne à prendre quand même :)

Ah !!! ok, c'est déjà pas mal si ça fonctionne chez toi parce que moi sur une fresh install Kuma ça n'a pas fonctionné. Je vais retester demain au cas où du coup voir si j'ai pas fait une mauvaise manip.

Mais du coup c'est peut-être juste une histoire de paramétrage sur mon Xivo, t'aurais une idée où ça pourrait être ou pas du tout ? ça correspond à quoi en fait toute cette combinaison de touche ? Parce que :

• le 735 ça ok, c'est une extension dans Xivo (je la retrouve dans extensions -> avancé)
• le 2***2 je vois pas à quoi ça correspond
• le 21 c'est le renvoi inconditionnel (pareil je le retrouve dans extensions)
• après les 3 étoiles 9, je vois pas
• et le 9710 ça c'est la destination, ok

Je fais le test avec une fresh install de Kuma et te tiens au courant

Encore merci pour ton aide

Bon en fait, j'ai pas pu attendre ;) j'ai fait le test avec une version Kuma que j'avais sous la main mais ça ne fonctionne pas pour moi.
Je pense que c'est une fresh install mais je suis pas sûr sûr (j'en suis venu à faire pas mal de test, je sais plus trop quelle VM j'ai triturée ou pas :) ), je vais refaire une install demain pour être sûr.

Cela dit, encore plus bizarre de mon côté ça envoie 4***221 et pas 2***221ce qui est encore différent de ce que j'avais en 8***221.

Là j'avoue que je comprends plus rien :D

Ta version de Kuma, c'est une fresh install ou t'as fais des montés de version ?

J'ai essayé avec une Freya par exemple et ça marche, je vais essayer d'autres version peut-être histoire de voir depuis quelle version ça fonctionne plus, ça nous donnera peut-être une piste....

La touche de ton côté, tu l'as faite comment ?
Par ton utilisateur, onglet Touches et la t'as pris "Active / Désactive le renvoie inconditionnel" dans le type ?

Salut Antoine,

Bon, c'est bizarre parce que de mon côté sur une fresh install Kuma ça fonctionne pas.
T'as version de Kuma, c'est un uprade du coup ou pas ?

J'ai continué à gratter et je pense qu'il y a un soucis au niveau des scripts AGI qui sont dans /usr/lib/python3/dist-packages/xivo_agid/modules. J'ai comparé avec une version Freya qui utilisait Python 2 et sur laquel ça fonctionne pour moi (c'est avant le changement avec Izar dont tu m'as parlé plus tôt) et il y a pas mal de différences mais j'arrive pas à tout comprendre, c'est un peu poussé.

Je continu a gratter pour voir....

Tu peux juste me dire si t'as fait le test sur une fresh install ou si c'est un upgrade stp ?

Merci

A tout hasard, tu utilises bien PJSIP et pas SIP ?

Salut Antoine,

Je sais pas si tu suis encore ce post mais après avoir remonté tout le dialplan, les scripts agi etc il s'avère que le soucis vient de l'API qui est appelé pour mettre à jour les infos du renvois dans l'utilisateur.
Sur la version Freya c'est : https://localhost:9486/1.1/users/2/forwards/unconditional avec {'destination': '*9710', 'enabled': True} comme données transmise. Là ça fonctionne.
Sur la version Kuma c'est : http://localhost:9100/configmgt/api/2.0/users/8/services avec {'unconditional': {'enabled': False, 'destination': ''}} comme données transmise. Là ça ne fonctionne pas.

Avec Freya le hint de l'extension passe bien à InUse mais pas avec Kuma (il reste à Idle.

Mais encore plus étrange c'est que si l'activation / désactivation du transfert se fait par la page Web, là ça fonctionne comme il faut.

Bref, je pense qu'il y a un soucis dans les scripts de l'API mais je ne trouve pas où ils sont ni sur Freya ni sur Kuma pour aller voir.
Je suis donc bloqué, nous reste plus qu'à attendre un coup de pouce de l'équipe Xivo / Wisper sinon c'est point mort je pense.

Bonjour Bastien,

De retour de déplacement,

Je peux te confirmer déjà que mon serveur a été installé en Helios et a depuis suivi toutes les upgrade, version par version, jusqu'à Kuma.

Le passage en PJSIP a été fait en deux temps, passage à Izar avec fallback SIP pour stabiliser, et passage PJSIP ensuite.

Je vais essayer d'analyser tes remarques dans la journée et de regarder les scripts appelés.

Avant de partir, je me demandais si les scripts utilisés pour le provisionnement de touches étaient différents en fonction du type de téléphone, vu que c'est une config poussée c'est forcement le cas.
Je travaille avec du Yealink, et je sais que depuis Izar : In repository only Yealink (v85) and Snom (v10) plugins were kept (i.e. the officialy supported phone brands)

Vu que tu as du Polycom, peut être qu'il y a une coquille. (Surtout que tu as l'air de dire que ça fonctionne via le Web Client)

Je n'ai que le plugin Yealink d'installé, mais il y a des choses intéressantes ici qui définissent la façon dont le téléphone doit être configuré via l'autoprov, notamment au niveau des touches de fonction.

/var/lib/xivo-provd/plugins/xivo-yealink-v85/common.py

Bonjour Antoine,

Super, merci pour ton retour. Pour la partie plugin effectivement j'avais envisagé la piste mais j'ai le même comportement avec un Yealink T53 et un Polycom VV500 du coup j'ai abandonné cette piste.

J'ai continué à pas mal creuser et je suis quasi sûr que le problème vient bien de l'API. Vu que toi ça fonctionne, je suppose que le passage à la nouvelle version de l'API n'a pas été fait de ton côté pendant les upgrades, peut-être qu'ils ont oublié de l'implémenté pour le faire automatiquement ou c'est peut-être volontaire aussi. Mais quand on part d'une installation fraîche, là ils l'ont activé.
C'est ma supposition en tout cas.

Cela dit, je pense avoir trouvé les scripts qui sont appelé dans l'API qui fonctionne, ils sont dans /usr/lib/python2.7/dist-packages/xivo_confd/plugins
Du coup j'étudie le code pour comprendre ce qui est fait et où l'état de la supervision est changé.
Quand j'aurais compris, je regarderais l'API qui ne fonctionne pas.

Et oui, quand j'active ou que je désactive le renvoi depuis l'interface d'admin sur l'utilisateur, le changement d'état est bien fait et la supervision fonctionne bien.

Bonjour,

Je viens juste de lire ce thread étant bien occupé à la livraison de Luna, notre nouvelle version.
En tout cas, bravo pour la ténacité !

Je vais checker avec l'équipe, c'est possible qu'on ait loupé un truc, mais en effet, il y'a eu un gros saut de versions (debian 11, pjsip et migration python3 de tous les paquets / plugins postes, rien que ça en une version pour izar....).
Je me renseigne et regarde car ce n'est pas évident ce qui a pu engendrer ce soucis.

Bonjour,

Super, merci beaucoup pour ce retour et merci de vous occuper de ce thread ;) (et merci du compliment ;) )

Je suis presque arrivé à remonter tout le code mais j'avoue que je me perds un peu avec tout ces appels de fonctions et ces objets :) c'est assez dense comme code quand on regarde de l'extérieur.
Oui, j'ai vu qu'il y a eut énormément de changements avec Izar, normal qu'il y est encore des choses à ajuster, on ne peut pas penser à tout surtout avec tant de changements.

Je me suis penché sur un autre soucis entre temps que j'ai mais ça semble plus simple cette fois, je pense trouver le code pour modifier ça, je ferais un post quand j'aurais trouvé pour proposer l'amélioration ou demandé de l'aide si je trouve pas.
C'est sur la génération du fichier de pjsip.conf lors de l'ajout de 2 trunks chez le même register (les 2 connexions sont enregistrées sur le même reg_ ce qui cré des soucis).
je reviendrais sur ce problème dans un autre thread, ne mélangeons pas tout ;)

Je vous laisse checker avec l'équipe alors et voir ce qu'il en est de la supervision.
Si jamais vous avez besoin de plus d'infos, de tests ou autres de ma part n'hésitez-pas (je peux même essayer de faire quelques bouts de code si besoin pour participer à l'évolution si vous avez de la doc ou des pistes)

Encore merci pour votre aide

Cordialement

Bonjour Laurent,

Avez-vous pu avoir un retour de l'équipe concernant ce soucis de supervision ?

Pour mon soucis de fichier pjsip.conf, il y avait bien quelque chose dans sa génération et j'ai réussi à le corriger (pour moi en tout cas, à voir si ça peut correspondre à tout le monde).
Je vais ouvrir un nouveau post dédié à ça avec tout les détails et la correction, peut-être que ça servira à quelqu'un d'autre et que vous pourrez améliorer la chose.

Je reste dans l'attente de votre retour

Bonne continuation

Cordialement

Bonjour,

Oui, on vient de refaire le test, on a aucun soucis de notre coté de supervision de touche en Jabbah/Kuma, elles fonctionnent bien sur un Yealink et un Snom.

Pour le changement d'API, voici le détail de ce qu'il s'est passé :

En Freya, :

Depuis Gaia :

Quand vous appuyez sur la touche, vérifiez les logs du config-mgt (/var/log/xivo-configmgt/xivo-configmgt.log), puis du xucserveur (/var/log/xivocc/xuc/xuc.log) , et enfin les log asterisk (asterisk -r) pour vérifier qu'il y'a pas une erreur quelconque qui pourrait expliquer le hic ?

Bonjour,

Ok, merci d'avoir regarder et merci pour les infos, je vais faire le test et regarder les logs mais c'est étrange du coup.

Vous avez fait les tests depuis une fresh install ? Parce qu'à priori quand on passe par des update de version ça fonctionne, c'est uniquement en fresh install que ça ne fonctionne pas

Je fais un tour dans les logs est vous tiens informé.