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

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

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.

Y a pas de raison :)

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.

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.

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

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.

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 ?

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)

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 ?

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 ?

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