Fonctionnalités Wazo

Français
1

Bonjour,

Je m’intéresse à Wazo Plateform dans le cadre d’un déploiement d’une solution internalisée et gérée en interne.

J’ai déjà travaillé sur Asterisk par le passé.
Néanmoins je m’intéresse plus particulièrement aux nouvelles fonctionnalités orientée collaboration : la messagerie instantanée, la présence voire, cerise sur le gâteau, la vidéo typiquement en point à point.
Es ce que ces fonctionnalités peuvent être accessibles, sur Linux, voire Android, à travers par exemple des logiciels comme Linphone voire en Webrtc?

merci pour votre avis

bonne journée

2

Bonjour,

Toutes les fonctionnalités sont accessibles depuis le Web, un client android ou ios, windows, linux, mac.
Tout est fourni pour faire ton application.

Apparemment, ceux qui ont codé un logiciel pour wazo platform ne le partage pas.
C’est bien dommage.

Il existe encore le client web historique (qui n’a pas évolué en 6 ans),
qui ne propose ni le chat, ni la vidéo et qui est disponible ici:
https://phone.wazo.community/#

il y a une démo de ce qui est possible de faire avec le SDK:

là, appel audio et vidéo sont disponible.

3

Bonjour,

En effet Wazo Platform offre toutes ses capacités que tu décris. Notre projet open source existe pour offrir cette plateforme pour développer par dessus. On a des exemples sur notre github et on fourni un SDK JS pour te permettre de développer ta solution.

@julienfr l’objectif de wazo platform n’est pas d’offrir un logiciel complet pour de la téléphonie/collab. C’est une plateforme pour permettre à des développeurs de créer leur propre solution. Après, nous avons développé un produit par dessus wazo platform que nous vendons à des MSP. Tu peux regarder le site web ici https://wazo.io.

Les différences entre le produit Wazo et le projet open source Wazo Platform sont les suivantes.

  • Portail de management cloud
  • Application web, desktop et mobile
  • Application web pour les invitations video
  • Formation
  • Support technique, commercial et marketing
  • Vente aux MSP (Manage Service Provider)
  • Release séparée
  • Marque blanche

J’espère que c’est clair, n’hésites pas si tu as d’autres questions.

Sylvain

PS: Je ne développe plus le phone.wazo.community depuis des années, il reste pour ceux qui utilisent depuis le début. Mon conseil est de partir sur la demo et de proposer des PR pour la faire évoluer. On acceptera avec grand plaisir des évolutions sur ce projet. A terme on pourrait aussi très bien remplacer phone.wazo.community par cette demo. Je te conseille de lire ce post : Webrtc Client Demo

4

Bonjour

merci à vous pour vos éléments.

Si je comprends bien:
Wazo platform est un socle
De base il embarque toutes les fonctionnalités de téléphonie “traditionnelle” d’Asterisk avec son interface wazo-ui. Pour le reste il faut les développer via les nombreuses API disponibles?

Si j’ai bien compris j’aurais une question : y a t il un langage plus approprié que les autres?
Idéalement un client lourd qui “intègre” un navigateur compatible webrtc…pour moi l’avantage serait d’avoir une interface identique quelque soit le mode communication : navigateur ou client lourd. Qu’en pensez vous? Peut-être trop difficile à faire?

Par contre, j’ai installé Wazo, apparemment tout à l’air de fonctionner avec l’interface. Par contre elle reste en anglais…
Comment puis je la passer en français?
J’ai déjà vu cette question sur le forum, néanmoins j’ai pas vraiment vu comment “traduire” l’interface

merci d’avance

5

l’interface admin “Wazo-ui” est disponible uniquement en anglais.
tout est en place pour traduire l’interface, mais je ne pense pas que ce soit si utile dans un premier temps.
et l’interface ne couvre pas tout les endpoints. mais c’est largement suffisant pour démarrer sans avoir réellement besoin de modifier le projet ou en refaire un.
tu peux aussi proposer des améliorations via des pull request, bien sûr.

Pour le client, je pars sur du vite + react, ça permet de faire l’appli web et avec electron, il est possible d’en faire un client “lourd” (installable quoi).
De plus, il sera alors possible de récupérer facilement des logiques ou composants, et les mettre dans un projet en react native (expo) pour faire une appli android / ios

bref, en full js, tout en s’appuyant sur le js-sdk de wazo, qui permet de tout faire assez facilement.

Wazo n’est pas un socle, mais une surcouche à asterisk, et ajoute beaucoup de fonctionnalité et de souplesse.

6

merci beaucoup pour ton retour

Oui je suis tout à fait d’accord concernant l’interface : elle est complète, mais même un peu trop pour certaines fonctionnalités, du moins à ne pas mettre dans toutes les mains. Néanmoins je pense que ce serait un plus si elle était en français, surtout étant donné que la langue est bien prévue dans l’authentification.
Dans l’idée, dans mon cas il s’agirait de déployer des postes SIP, le tout associé à un SBC qui sécuriserait un trunk SIP.
En terme de fonction, principe de base : émettre/recevoir appel, transfert, interception, mise en attente, annuaire sur les postes
c’est ce qui me suffit dans un premier jet, quitte a ajouter ensuite d’autres choses.
Par contre peut on gérer le SSO avec l’interface? j’ai vu qu’on peut gérer le Oauth2.0 donc je pense que oui?

Je pensais bien à electron pour imbriquer sur du desktop et éventuellement cordova pour le mobile
Nativement j’ai été développeur PHP (en procédural). Es ce que vite + react est “facile” à comprendre?
Quand tu parles de js-sdk, ce sont les différentes API, ou c’est autre chose?

merci pour la précision concernant la notion de surcouche c’est vrai c’est beaucoup plus clair ainsi.

7

Je suis un peu une bille en auth et SSO.
pour l’auth, tu peux utiliser:

  • wazo
  • ldap
  • google
  • office 0365

donc le SSO est certainement possible.

Pour vite + react, c’est assez simple à prendre en main, surtout si on a une base en javascript.
tu pourras importer le sdk:

il te sera alors facile d’utiliser les fonctions et taper dans les API mais aussi le websocket (pour la communication en temps réel)

C’est une librairie javascript pour te simplifier (énormément) ton projet.

Mais tu dis “déployer des postes SIP”,
dans ce cas, tu n’as pas besoin de développer quoi que ce soit.
Les personnes peuvent gérer leurs touches sur le téléphone fixe, configurer les renvois avec les #xx habituels, accéder à leur messagerie si besoin, s’abonner/se connecter à un groupe d’appel, etc.

Avec l’interface wazo-ui, tu pourras en tant qu’administrateur régler les configurations (appels entrant, appels sortant, comptes, lignes, plugins, auto-provisionning des postes, etc).

L’utilisateur qui a un téléphone physique n’a pas besoin d’une application en plus.

L’application prend du sens pour les features video / chat ou pour intégrer un client téléphonique dans une application type CRM.

Pour le SBC, il propose Kamalio:

Dans ton cas, je commencerai par installer wazo et d’y connecter quelques téléphones SIP.
Il te faudra déjà configurer le DHCP, l’auto-provisionning, les greffons pour ton modèle de téléphone, la création de lignes et de comptes, le routage des appels (trunk sip).
Une fois cela en place, tu pourras faire toutes les actions de téléphonies:
…émettre/recevoir appel, transfert, interception, mise en attente, annuaire sur les postes et bien d’autres !

8

encore merci pour ta réponse très complete.

Le SDK est vraiment très complet effectivement. Par contre les communications y transitant sont elles cryptées?

Après oui pour l’heure pas besoin de développer quoi que ce soit pour des postes SIP. Néanmoins quitte à aller dans Wazo, autant regarder le coup d’après et voir jusqu’à ou on peut aller et dans quelles conditions.
L’objectif final restera à terme d’avoir des postes SIP, des softphones et des fonctionnalités collaboratives. Donc autant creuser si déjà théoriquement wazo peut le faire avant de trop passer du temps sur du déploiement de postes SIP sans lendemain.

Pour Kamailio, je ne suis pas sur que ce proxy permet la rupture protocolaire…

9

Non kamailio est un proxy pas un b2bua.

Sinon oui le sdk te fournit de quoi dev une appli webrtc complète, on utilise dans nos applications le même SDK et c’est chiffré grâce au srtp.

10

merci quintana.

Sauf erreur, c’est plutôt sippy ou plus connu je suppose opensips, qui peuvent servir dans le cadre d’un SBC. D’ailleurs si vous les connaissiez, avez vous un avis?

Pour en revenir au sujet : donc via la SDK, on peut donc intégrer du SRTP dans les communications voix. C’est documenté? sachant que la signalisation passe le HTTPS du webrtc. La solution peut donc être intégralement sécurisée.

Dernière question (enfin pour l’instant :slight_smile: ) concerrnant internet et en particulier les mobiles. Si on considère une appli Webrtc sur mobile, elle aura besoin d’accéder à internet pour pouvoir se connecter. Si on veut éviter que le serveur possèdent ces ports ouverts directement sur internet, idéalement, il faut un équipement intermédiaire qui sécurise les flux mais pour le webrtc.
A mon sens un SBC ne protège que le SIP, et même si certaines contsructeurs parlent de webrtc, en réalité il s’agit plutôt d’un webrtc qui a été déployé sur via propre SDK uniquement. Connaissez vous des applications qui sécurisent le webrtc?

merci à vous

11

Bonjour,

  1. opensips et kamailio c’est la même chose, c’est un proxy SIP. On peut s’en servir pour faire du SBC mais il faut utiliser d’autre composants aussi pour parvenir à avoir un SBC complet. Tout dépend de ta définition de SBC après :).
  2. SRTP est inclus dans le webrtc, contrairement à la signalisation. Nous avons fait le choix d’utiliser SIP à travers une websocket https pour sécuriser l’ensemble. Tu n’as rien à faire avec le SDK, tout est inclus et c’est sécurisé de ce côté là.
  3. Les flux sont sécurisés, il faut mettre en place un service STUN/TURN, d’expérience oublie le STUN sur du mobile, il te faut un TURN si tu veux gérer correctement les multiples NAT qui existe correctement.
  4. Un SBC ne fait pas juste que protéger la signalisation. Je ne comprends pas vraiment ta dernière question, webrtc est une technologie, elle ne possède pas de signalisation, elle permet de passer des flux voix/video/data avec un navigateur web, donne accès au micro et caméra, offre des stats et permet d’avoir du SRTP, un agent ICE. Y a pas mal plein d’autres choses aussi, mais je te donne ça en gros. Y a beaucoup de doc sur le net, je te conseille d’en lire. Un excellent pointeur ici : https://webrtcforthecurious.com/

Sylvain

12

j’étais pris sur d’autres sujets mais me revoici pour continuer à avancer
merci sylvain pour ton retour

C’est parfaitement clair je te remercie.
Pour le dernier point en fait je me suis mal exprimé. Mais j’ai vu une solution qui tu signalais sur un autre topic:

Es ce que le projet est toujours en cours? car il ne semble plus évoluer depuis 1an…

Autre question plus orientée dimensionnement et scalabilité, en terme de capacité de serveur si on imagine dans un 1er temps que des postes SIP, quelle est la capacité maximale d’une instance de wazo et avec quelles caractéristiques de serveur ?
SI on intègre du webrtc es ce que les caractéristiques du serveur évoluent ou es ce la même base?

Peut on faire fonctionner plusieurs Wazo en réseau je suppose IAX comme si c’était un seul serveur (en gardant donc les fonctionnalités comme la supervision entre poste, renvoi, transfert, etc, mais aussi les fonctionnalités du webrtc : envoi de messagerie instantanée en utilisateur de serveurs wazo différents par exemple)?

Au sujet du multi tenant géré nativement par wazo : on est d’accord que l’on créé des “entités” entièrement indépendantes entre elle mais qui peuvent se connecter au même trunk? Sur chaque “entité” déclarée on peut y adjoindre un ou plusieurs administrateurs?
Par contre es ce que les postes déclarés dans l’entité1 peuvent appeler les postes de l’entité2 comme un appel interne (si on considère un plan de numérotation cohérent bien sur). Idem pour toutes les fonctionnalités téléphoniques habituelles et celles apportées en webrtc?

merci d’avance

13

Hello,

Je vais tenter de te répondre, mais sylvain, ou autres membres de Wazo aura une réponse plus juste.
A savoir, j’étais sur du wazo il y a 7 ans (au moment de la transition Xivo vers Wazo), mais en changeant de mission, j’avais quitté le projet des yeux. Et là, je m’y remet doucement.

Sur un serveur, le nombre de postes SIP est théoriquement illimité. Il sera question de ta bande passante plutôt, et donc d’appel simultanés (vers l’extérieur).
Si on ajoute du WebRtc, la limite dépend aussi de l’optimisation de ton application.

Historiquement (il y a 7 ans) la limite était de 2000 devices, uniquement car au delà, on subissait de fort ralentissement de l’interface d’administration.
Avec la refonte des Api, cette limite est surement repoussée au delà des 3000 devices.

On peut mettre autant de serveur Wazo en parallèle (trunk IAX).
J’avais travaillé rapidement sur le fait de pouvoir partager les phonebooks entre les différents Wazo.
Une question se pose pour la supervision entre poste.
Pour le reste, je ne sais pas au premier regard, mais le fait d’avoir des notions de tenants dans les messageries instantanées me dit que c’est réalisable.
Pour le reste, c’est de la téléphonie, donc transparent pour les appels.

Normalement, un trunk n’est pas fait pour plusieurs tenants.

ou encore:

Il est tout a fait possible de faire communiquer les 2 tenants entre eux.
Apparemment, le plus simple est un trunk sip entre les 2 tenants:

Mais un trunk = un tenant, à moins de faire des configurations en plus en amont du wazo.
encore un peu de lecture

A savoir, il est très intéressant pour un admin de pouvoir avoir plusieurs “clients” et donc plusieurs tenants, tout en ayant un seul trunk, même si je pense que dans le temps, ceci peut être une difficulté d’administration avec l’augmentation des effectifs par exemple.

merci à sylvain de corriger si je dis des bêtises.

14

Bonjour

Merci pour tes éléments de réponse.

Dans mon cas le principe de relier un serveur wazo qui représenterait une ou plusieurs entités selon la capacité en postes que peut accueillir un seul serveur.

Sur certaines configurations je pense qu on sera sans mal au delà de 2000 postes.

Après dans le ou les serveurs on y raccordera un trunk sip avec un nombre de canaux cohérent et toutes les SDA. Les SDA seront ensuite redirigées sur les instances wazo (dans le cas de multi serveur) via l analyse de la tranche SDA par le SBC.

Côté serveur wazo, chaque entité aura au moins un administrateur propre, d ou l importance des tenant. Néanmoins il n est pas question qu y ait autant de trunk qui de tenant, ce sera ingérable en terme de coût. De plus si on met un 2eme trunk(pas impossible), ce sera plus pour objectif d un backup.

Par contre même si ce seront des entités distinctes idéalement si cela pourrait être vu comme un unique ipbx ce sera vraiment parfait.

Ce que je décris bien sûr c est la vision que j ai en cible. Reste à savoir ce qui est faisable avec wazo.

Si je comprends bien, ce qui semblerait poser problème en 1er lieu, c est le même trunk pour chaque entité…

Merci

15

Tu envisages 2 fonctionnement de Wazo:
1/ multi tenants sur un serveur, avec un trunk.
2/ multi serveur avec mise en relation étroite des serveurs (comme si un seul serveur).

1/
Si en amont du wazo tu as un SBC et du routing, alors il est possible d’avoir un trunk et plusieurs tenants sur un même serveur.

2/
Le fonctionnement de wazo en cluster (3 serveurs et plus) est peu documenté (ou alors je ne sais pas où chercher), mais les services sont configurables et on peut normalement partager les services de présence, phonebook et autres entre plusieurs serveurs.
Ce type d’architecture demande souvent à avoir un serveur “master” qui contient l’ensemble des informations et fait le lien avec les autres serveurs.

ces fonctionnalités et architectures sont intéressantes …
il va falloir donc creuser un peu le sujet pour une mise en place.

je suis intéressé de suivre tout ça !

16

Merci pour ton retour
Oui car moi j aurais probablement les 2 fonctionnements. Une fois de plus c est la version idéale.

J ai effectivement vu que kamailio pouvait être la solution dans le cas d un trunk pour plusieurs tenant.
Néanmoins je ne visualise pas vraiment par l interface UI + le SBC (qui ne sera pas kamailio mais un “vrai” SBC type oracle ou audiocode ou équivalent) pour faire cela…

17

Si quelqu un a des infos sur le dimensionnement (limite vers 2000 utilisateurs ?) Et la machine en vm a prévoir je suis preneur!

Également sur le suivi du projet SBC kamailio pour le webrtc, si il y a des infos sur le projet en particulier si il est toujours maintenu je suis également preneur

Merci

18

Bonjour,

Si ça peut t’aider :

1 Like
19

Bonjour et merci pour ton retour.

C’est le “2000+” qui me perturbe. Il y a forcément une limite…?

20

c’est 375 session simultanées …

Pour le 2000+, voir dans les tickets:
https://wazo-dev.atlassian.net/jira/software/c/projects/WAZO/issues/WAZO-3432?filter=allissues

j’ai vu 2 tickets sur la lenteur de l’Api si on a beaucoup d’utilisateurs.
C’est ça qui limite ou non ce chiffre, et il ne pose pas de soucis pour l’utilisateur final.
C’est pour l’administrateur qui veut aller sur l’interface admin et voir/ajouter/editer un utilisateur.
Et ils vont optimiser la requete et la bdd pour ça.

375 appels simultanés c’est bien, et si on regarde pour 2000 utilisateurs, ça fait 25% des utilisateurs en communication en même temps.
je pense que c’est assez rare.

d’ailleurs pour un call center, il part sur du 100%.
donc 300 utilisateurs = 300 appels simultanés

là où je bosse actuellement, on a environ 4000 utilisateurs, et on peut estimer à 100 appels simultanés en pointe.
en revanche, les réunions sont fait sur un autre système.
on a 30 réunions par jour, si on considère qu’elles sont simultanées, on arrive à 130 appels simultanés pour 4000 utilisateurs.

on a de la marge par rapport à ce que Wazo peut offrir.

et si on part sur mon ratio de 130 appels simultanés pour 4000 utilisateurs, wazo limitant à 375, ça me ferait 10 000 utilisateurs environ.

j’espère que ça t’a aidé !