Project

General

Profile

Test Upgrade Helios LTS vers Izar LTS

Added by Antoine TIXIER over 2 years ago

Juste pour signaler une erreur rencontrée pendant l'upgrade.

dkms: running auto installation service for kernel 5.10.0-13-amd64:.
Setting up xivo-confd (2022.04.00+20220310.161802.34a458dc) ...
Job for xivo-confd.service failed because the control process exited with error code.
See "systemctl status xivo-confd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript xivo-confd, action "start" failed.
● xivo-confd.service - xivo-confd server
     Loaded: loaded (/lib/systemd/system/xivo-confd.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Sat 2022-04-30 15:40:52 CEST; 6ms ago
    Process: 12412 ExecStartPre=/usr/bin/install -d -o www-data -g www-data /var/run/xivo-confd (code=exited, status=0/SUCCESS)
    Process: 12413 ExecStart=/usr/bin/xivo-confd (code=exited, status=1/FAILURE)

Apr 30 15:40:51 urgan systemd[1]: Starting xivo-confd server...
Apr 30 15:40:52 urgan xivo-confd[12413]: /usr/lib/python3/dist-packages/xivo/xivo_helpers.py:27: FutureWarning: Possible nested set at position 1
Apr 30 15:40:52 urgan xivo-confd[12413]:   find_asterisk_pattern_char = re.compile('[[NXZ!.]').search
Apr 30 15:40:52 urgan systemd[1]: xivo-confd.service: Control process exited, code=exited, status=1/FAILURE
Apr 30 15:40:52 urgan systemd[1]: xivo-confd.service: Failed with result 'exit-code'.
Apr 30 15:40:52 urgan systemd[1]: Failed to start xivo-confd server.
dpkg: error processing package xivo-confd (--configure):
 installed xivo-confd package post-installation script subprocess returned error exit status 1

Surement en lien avec ce défaut de config :

[Apr 30 16:08:26]     -- Reloading module 'res_pjsip.so' (Basic SIP resource)
[Apr 30 16:08:26] ERROR[6896]: res_pjsip_config_wizard.c:1080 object_type_loaded_observer: Unable to load config file 'pjsip_wizard.conf'
[Apr 30 16:08:26] ERROR[6896]: res_pjsip_config_wizard.c:1080 object_type_loaded_observer: Unable to load config file 'pjsip_wizard.conf'
[Apr 30 16:08:26] WARNING[6896]: res_pjsip/config_transport.c:739 transport_apply: Transport 'transport-udp' is not fully reloadable, not reloading: protocol, bind, TLS, TCP, ToS, or CoS options.
[Apr 30 16:08:26] ERROR[6896]: res_pjsip_config_wizard.c:1080 object_type_loaded_observer: Unable to load config file 'pjsip_wizard.conf'
[Apr 30 16:08:27] ERROR[6896]: res_pjsip_config_wizard.c:1080 object_type_loaded_observer: Unable to load config file 'pjsip_wizard.conf'
[Apr 30 16:08:27] NOTICE[6896]: sorcery.c:1348 sorcery_object_load: Type 'system' is not reloadable, maintaining previous values
[Apr 30 16:08:27] ERROR[6896]: res_pjsip_config_wizard.c:1080 object_type_loaded_observer: Unable to load config file 'pjsip_wizard.conf'

Et pour finir :

Le lien à un serveur ldap du serveur cti n'a pas été mentionné dans la doc d'upgrade, mais il semble avoir été impacté par l'upgrade Debian puisqu'il ne fonctionne plus.
A déterminer si ça vient du xuc.conf ou du keytab, ou de la config.


Replies (38)

RE: Test Upgrade Helios LTS vers Izar LTS - Added by Antoine TIXIER almost 2 years ago

Bonjour Damien,

Dans le fichier "/etc/docker/compose/docker-xivocc.yml" au niveau de la section xuc :

environment:

  • CONFIG_FILE=/etc/docker/xuc/xuc.conf volumes:
  • /etc/docker/xuc:/etc/docker/xuc

Fichier "/etc/docker/xuc/xuc.conf" :

include "application.conf"

authentication {
ldap {
managerDN = "CN=XXX,OU=XXX,DC=XXX,DC=XXX" # utilisateur avec droit de lecture sur le LDAP
managerPassword = "XXX" # password
url = "ldap://XXX:389" # ldap URI
searchBase = "OU=XXX,DC=XXX,DC=XXX" # UO dans laquelle rechercher
userSearchFilter = "sAMAccountName=%s" # filtre de recherche pour login utilisateur
}
}

Reconstruction du container :

xivocc-dcomp up -d xuc

RE: Test Upgrade Helios LTS vers Izar LTS - Added by Antoine TIXIER almost 2 years ago

Bonjour Damien,

Dans le fichier "/etc/docker/compose/docker-xivocc.yml" au niveau de la section xuc :

environment:
- CONFIG_FILE=/etc/docker/xuc/xuc.conf
volumes:
- /etc/docker/xuc:/etc/docker/xuc

Fichier "/etc/docker/xuc/xuc.conf" :

include "application.conf"

authentication {
  ldap {
    managerDN = "CN=XXX,OU=XXX,DC=XXX,DC=XXX"      # utilisateur avec droit de lecture sur le LDAP
    managerPassword = "XXX"                                                 # password
    url = "ldap://XXX:389"                                                           # ldap URI
    searchBase = "OU=XXX,DC=XXX,DC=XXX"                      # UO dans laquelle rechercher
    userSearchFilter = "sAMAccountName=%s"                    # filtre de recherche pour login utilisateur
  }
}

Reconstruction du container :

xivocc-dcomp up -d xuc

RE: Test Upgrade Helios LTS vers Izar LTS - Added by Damien VARICLIER almost 2 years ago

Antoine bonjour,

Je te remercie pour ta réponse :)

Pour la partie fichiers de configuration, je n'ai rien touché à ce que j'avais déjà car ça correspondait exactement à ce que tu avais indiqué.

La différence par contre est dans la reconstruction du container XUC, à chaque modification, je faisais :

xivocc-dcomp stop xuc
xivocc-dcomp rm xuc
xivocc-dcomp up -d xuc

Par précaution je redémarrais le serveur mais ça ne marchait pas.

Cette fois-ci j'ai uniquement fait uniquement :

 xivocc-dcomp up -d xuc

et ça a marché !!!

Je ne comprends vraiment pas pourquoi depuis des semaines ça n'a jamais voulu en authentification LDAP et que là ça veut...
... sauf une solution : tu as propagé des bonnes ondes ^

Je vais expérimenter tout ça à plus grande échelle maintenant et tenter de repasser en LDAPs, sur un malentendu ça va fonctionner :)

Encore merci à toi !!!

Damien.

RE: Test Upgrade Helios LTS vers Izar LTS - Added by Antoine TIXIER almost 2 years ago

Migration Helios vers Izard, tout fonctionne en fallback sur SIP.

Par contre, en PJSIP, comportement sur une plateforme de test avec des appels internes :

  • Appels WebRTC vers WebRTC (Desktop client) : tout fonctionne, du son dans les deux sens.

  • Appels WebRTC vers téléphone, et inversement : je m'entend sur le téléphone, mais je n'entend pas de retour au casque sur Client Xivo.
    Si je raccroche depuis le Desktop client, l'appel prend fin immédiatement.
    Si je raccroche le téléphone, la fin d'appel n'est signalée au serveur, et l'appel continue sur le Desktop client.

  • Appels téléphone vers téléphone : Aucun son, signalisation catastrophique.

J'ai analysé la piste du Firmware téléphone sans succès (Yealink T53 et T54W)
Les options RTP ne donnent rien de mieux.

J'ai beau tourner le problème dans tous les sens, je n'ai pas trouvé de solution.
Il va falloir inspecter plus bas, sauf si quelqu'un a une idée à proposer.

RE: Test Upgrade Helios LTS vers Izar LTS - Added by Antoine TIXIER almost 2 years ago

Test des codecs G722, son HD vu sur le téléphone, mais même symptôme.

Iptables vidées tout a ACCEPT, idem.

C'est très semblable à un problème de NAT, au niveau des symptômes.

RE: Test Upgrade Helios LTS vers Izar LTS - Added by Antoine TIXIER almost 2 years ago

Aucune option de "mise en attente", "transfert", "conférence" etc ne fonctionne si elles sont demandées par le téléphone.

RE: Test Upgrade Helios LTS vers Izar LTS - Added by Antoine TIXIER almost 2 years ago

Après analyse de trame, le téléphone envoi tous ses paquets SIP à destination de l'IP définie dans le paramètre "externip" du serveur et non au serveur, ce qui n'est pas le cas du desktop client.

Une fois l'IP retirée de "externip", tout fonctionne. Ma faible connaissance de PJSIP ne me permet pas d'expliquer ce comportement.

RE: Test Upgrade Helios LTS vers Izar LTS - Added by Antoine TIXIER almost 2 years ago

Comme indiqué au cours de ce post, après la mise à jour Helios vers Izar, l'entrée suivante a été ajouté dans les source.list d'apt :

izar

deb https://mirror.xivo.solutions/archive/ izar main

deb-src http://mirror.xivo.solutions/archive/ izar main

Or il n'existe pas dans les depots https://mirror.xivo.solutions/archive/dists/

Faut il corriger et faire pointer vers : xivo-2022.05-latest/ ?

Vous mettez à jour le source.list après chaque update ou manque-t-il le xivo-izar dans le dépôt ?

RE: Test Upgrade Helios LTS vers Izar LTS - Added by Antoine TIXIER almost 2 years ago

Le fait qu'en PJSIP, lors d'appels internes, les téléphones envoient les paquets à l'IP définie dans "externip" reste inexplicable.

A quelle option le champ externip a - t - il été relié en pjsip ? (Vu qu'a priori il n'a plus de raison d'exister)

RE: Test Upgrade Helios LTS vers Izar LTS - Added by Laurent MEILLER almost 2 years ago

Bonjour, je viens de regarder dans le script de Digium (Asterisk) qu'on utilise pour mapper chan_sip -> pjsip et en effet le champs externip est splitté pour sortir le host et le port afin de remplir 3 variables pjsip:

  • external_media_address
  • external_signaling_address
  • external_signaling_port

La définition de ces valeurs sont ici : https://wiki.asterisk.org/wiki/display/AST/Configuring+res_pjsip+to+work+through+NAT
Ce n'est pas la première fois que l'on doit faire des patchs sur ce script qui n'est pas forcément adapté pour XiVO, on découvre encore des coquilles sur des conf bien particulière.

Pour vous, quel serait le comportement attendu ?

RE: Test Upgrade Helios LTS vers Izar LTS - Added by Antoine TIXIER almost 2 years ago

Bonjour et merci de votre retour, (meilleurs vœux 2023 également)

Téléphones et serveur avec le trunk opérateur sont internes.

J'étais effectivement tombé sur les 3 paramètres que vous nommez au passage à pjsip.

Le fait que les téléphones en interne, en s'appelant entre eux, essaient de contacter "externip" plutôt que le serveur sous entend une mauvais définition de "localnet" pourtant OK

Le résultat via Desktop client est 100% bon (entrant / sortant, interne et externe), la gestion du NAT y est elle différente ?

RE: Test Upgrade Helios LTS vers Izar LTS - Added by Laurent MEILLER almost 2 years ago

Bonjour Antoine, meilleurs voeux, en espérant que votre XiVO ne vous créé pas plus de sueurs froides ;)

Pour ce parametre externip qui fonctionne avec ou sans pour le webrtc ne m'étonnes pas plus que ça car, le protocole webrtc utilise sa propre mécanique pour identifier la connexion à utiliser avec un pair (https://developer.mozilla.org/fr/docs/Web/API/WebRTC_API/Connectivity#qu%E2%80%99est-ce_que_ice). Ca me semblerai logique que cette négociatation ICE bypass cette configuration NAT, mais c'est une hypothèse ...

(26-38/38)