Limite appels simultanés sur utilisateur non prise en compte

Français
1

Bonjour à tous,

Je rencontre un soucis sur l’utilisation de wazo platform. J’ai ouvert un ticket sur Jira (WAZO-3497) mais je n’ai pas de retour du coup je me demande si c’était la bonne méthode ou si il fallait plutôt passer par le forum d’où ce topic.
Je vous laisse me dire qu’elle est la meilleur marche à suivre.

J’en profite donc également pour vous re-exposer mon soucis.
Lorsque qu’un appel arrive (interne ou depuis une SDA) sur un utilisateur en direct, l’option du nombre d’appels simultanés de l’utilisateur est bien prise en compte mais lorsque l’appel arrive via un groupe, là ce n’est plus pris en compte, les utilisateurs du groupe reçoivent autant d’appels qu’il en arrive.

Je suis partie d’une nouvelle installation en 23.15 il y a quelques jours.

Pourriez-vous me dire si je fais quelque chose de mal, si il s’agit d’un bug, si vous avez une piste ou autre ?

Merci pour votre attention, j’attends vos retours avec impatience car il ne me reste que ce point à corriger avant de déployer la solution :wink:

2

Salut,

Je n’ai pas souvenir qu’on est spécialement développé le use case dont tu parles. Pour moi sur le groupe y a pas de prise en compte de ce paramètre.

Sylvain

3

Salut Sylvain,

Merci pour ton retour

En fait, c’est pas tant sur le groupe que je voudrais appliquer ce paramètre mais sur les utilisateurs du groupe.
En fait aujourd’hui j’ai un client qui peut recevoir 4 appels sur 2 postes mais ne souhaite en géré que 2 par poste. Le soucis est que si un utilisateur à déjà pris 2 lignes et qu’un 3ème appel arrive, il le voit alors que si je fais arriver les appels sur l’utilisateur directement ça se limite bien à 2 appels, le 3ème n’est pas notifié

Ce qui est étrange c’est qu’il me semble que cela fonctionnait correctement sur des anciennes versions (la 17.08) par exemple, je n’en ai plus sous la main là pour faire des tests mais j’en suis quasi sûr

4

Je n’ai pas souvenir d’un tel fonctionnement même sous Xivo, juste avant les premières versions de Wazo.

Je n’ai pas de groupe pour tester, mais tu dois avoir “diversions” qui te permet de gérer les appels sur une queue ou groupe normalement.

tu peux raccrocher (mais c’est rarement voulu), transférer sur un IVR, un parking, ou plein d’autres solutions.

Mais un groupe ou queue est justement fait pour recevoir tous les appels peu importe leur nombre.
A toi de définir l’action si tout le monde est en ligne.

Mais je n’ai pas testé …
J’ai juste souvenir que je mettais en place des file d’attente et jamais de groupe, sauf un groupe pour un service avec 5 personnes qui reçoit 1 appel tous les 4 matins.

tiens nous au courant !

5

Salut Julien,

Merci pour cette réponse et effectivement je viens de tester sur un Xivo 2020.18.00 sur lequel il me semblait que ça fonctionnait mais ça ne fonctionne effectivement pas.
Donc vous aviez tout les deux raison, je suis parti sur une mauvaise piste :sweat_smile: :sweat_smile:

Désolé de vous dérangé pour ça :wink:

Surtout que je viens de comprendre comment son configurées les queues dans le queues.conf et effectivement ça ne risque pas d’appliquer de limites.

Bref merci beaucoup pour tout ces éclaircissements :slightly_smiling_face:

Du coup, y aurait-il pas un axe d’amélioration pour que ce soit pris en compte ? Ou peut-être que comme tu dis c’est jouable avec les files d’attentes (ça je connais moins) et que ce n’est pas la vocation d’un groupe ?
Prenons le cas de mon client par exemple, il a 4 lignes entrantes de possible sur 2 postes mais il ne veut gérer que 2 lignes max par postes, comment est-ce que tu peux faire ça avec une file d’attente ?

6

yop,

ça fait longtemps que je n’ai plus fait de conf pour des scénarios.

Ma capture d’écran vient d’une queue.

Tu peux utiliser les fallbacks

image
image1919×273 13 KB

Dans l’exemple, si tout le monde est en ligne, alors l’appel est raccroché.
La cause Busy est censé déclencher le message audio associé si il existe.
le Timeout, par défaut c’est le temps de sonnerie (30sec) mais tu peux le mettre à 0 pour éviter que ça sonne.

Mais tu pourrais rediriger l’appel n’importe où.

Les fallbacks d’un groupe ne sont pas si évolués.
Tu peux gérer uniquement le non réponse, ce qui n’est pas ta demande.

Mais tu peux passer par une subroutine, et avoir un IVR qui vérifie si Busy → hangup, si available → goto
ça demande donc plus d’actions de configuration … mais ça se fait bien.

Dans une queue, tu as deux manières de gérer la connexion.
un agent : il peut se connecter / déconnecter / pause
un membre : qui est toujours connecté (si sa ligne est connectée, comme pour un groupe)

j’espère que ça te donne les infos attendues

7

Salut Julien,

Ok, merci pour toutes ces infos, c’est bon à savoir, mais ça ne résout toujours pas mon soucis :sweat_smile:
Même en passant par une queue soit les membres reçoivent un seul appel en même temps (si ringinuse à no) soit autant d’appel qui rentre (si ringinuse à yes).

En fait mon client veut pouvoir recevoir sur chaque poste du groupe ou de la queue que 2 appels max par poste.
Si il est déjà en ligne il veut voir arriver l’appel suivant pour le mettre en attente sur son poste mais ensuite il ne veut pas voir un troisième appel arriver.

Désolé de batailler avec ça mais merci pour ta patience et tes retours en tout cas :smiley:

8

yep,

Un peu de mal avec le changement d’interface, mais voici comment le faire avec une queue et sans IVR:

image
image1665×504 12.1 KB

Si déjà un appel en attente, alors l’appel suivant est raccroché avant d’entrer dans la file d’attente.

En tant que “téléphoniste”, je trouve ça bizarre, car celui qui appelle ne va pas comprendre pourquoi ça raccroche direct !
au lieu de faire un hangup, je basculerais sur un message ou un IVR qui joue un message puis raccroche.

cheers !

9

Alors c’est presque ça :sweat_smile: :sweat_smile:

Je pense que j’explique pas bien le scénario en fait :laughing: :laughing:

Admettons :

  • l’utilisateur A (UserA) veut recevoir 2 appels simultanés
  • l’utilisateur B (UserB) veut recevoir 1 appel simultané
  • Les utilisateurs sont toujours avec leurs appels quand les suivants arrivent
  • Le trunk permet d’avoir 6 communications simultanées

Premier appel :

  • Personne n’est en ligne
  • La musique d’attente est jouée à l’appelant
  • Les 2 utilisateurs sont notifiés de l’appel
  • UserA décroche

Deuxième appel :

  • UserA est toujours en ligne mais peut recevoir 2 appels simultanés
  • La musique d’attente est jouée à l’appelant
  • Les 2 utilisateurs sont donc notifiés
  • UserB décroche, tout le monde est donc en ligne

Troisième appel :

  • UserA et UserB sont toujours en ligne mais UserA peut recevoir 2 appels simultanés
  • La musique d’attente est jouée à l’appelant
  • UserA est notifié de l’appel mais pas UserB car il ne peut recevoir qu’un seul appel à la fois
  • UserA décroche et mets en attente l’appel pour reprendre le premier
  • La musique d’attente est jouée à l’appelant du troisième appel

Situation actuelle :

  • UserA est en ligne et a une ligne en attente sur son poste (l’appelant a la musique d’attente)
  • UserB est en ligne

Quatrième appel :

  • UserA et UserB ont atteint leur nombre max d’appel par postes (2 pour UserA et 1 pour UserB)
  • La musique d’attente est jouée à l’appelant
  • Aucun téléphone n’est notifié
  • L’appel reste en attente qu’un appel se termine

De là on peut imaginer effectivement que :

  • Soit un des User raccroche et prenne le quatrième appel en attente
  • Soit au bout du timeout du groupe, l’appel est rediriger vers un message, un autre groupe ou autre chose

Est-ce que tu vois mieux ce dont j’aurais besoin ?
En fait le fonctionnement serait parfait si lors de l’appel des membres du groupe ou de la queue le nombre d’appels simultanés par membre était vérifié avant de faire sonner le dit membre.
Ce serait possible dans

[ Context ‘usersharedlines’ created by ‘pbx_config’ ]

par exemple, avant de faire le Dial
Ce n’est qu’une idée, je ne suis pas assez avancé dans Wazo pour savoir si c’est faisable ou pas :wink:
Qu’en penses-tu ?

10

Hello !

Tu me confirmes que déjà que UserA et userB sont notifiés du troisième appel, contrairement à ce qui est attendu ?
Que c’est déjà la première chose à corriger ?

11

Yep Julien,

Oui, c’est exactement ça, aujourd’hui UserB est notifié de l’appel alors qu’il ne peut en recevoir qu’un seul à la fois.
En fait ce qui serait top c’est que la limite du nombre d’appels simultanée paramétré sur chaque utilisateur du groupe soit prise en compte. ça permettrait que l’utilisateur du groupe qui souhaite recevoir 2 appels simultanés en reçoivent 2, celui qui en veut qu’un n’en reçoivent qu’un etc.

J’ai commencé à creuser et apprendre le code que vous avez mis en place et j’étais parti dans le fait que dans le dialplan du contexte

[ Context ‘usersharedlines’ created by ‘pbx_config’ ]

J’allais récupérer le nombre d’appels simultanées de l’utilisateur, utiliser la fonction GROUP() pour compter le nombre de channel déjà en cours, comparer les 2 valeurs et appeler l’utilisateur ou pas.
ça ressemble au dialplan du context User quand on appel un utilisateur en direct au final.

Mais bon, tu connais mieux la chose que moi :sweat_smile:
Dis-moi si tu veux un coup de main sur quelque chose, le dev, le test ou autre

Encore merci pour ton suivi et ta réactivité en tout cas :wink:

12

yep,

Je ne suis absolument pas expert dans ces configs …

Si tu fais un groupe, il est sûr que ça ne prend pas en compte la limite d’appel.

Il faut donc passer par une file d’attente (queue) et que les personnes soient connectées en Agent et non en tant que membre.

Tu peux tester simplement comme ça, voir si ça prend en compte la limite d’appel par utilisateur.

Sinon, il faut faire un dialplan.

ça fait longtemps que je n’ai pas écrit de dialplan, alors il faudra à coup sûr le corriger

valeur à changer :
0123 = numéro de la file d’attente
0124 = userA

[mon-std]
exten = s,1,NoOp(APPEL AU STANDARD)
// on vérifie si il y a déjà 2 appels en cours, si oui, on dial que userA
same = n,GotoIf($[${QUEUE_WAITING_COUNT(0123)}=2]?TOA)
same = n(TOA),Dial(SIP/0124)
// on vérifie si il y a déjà 3 appels ou plus en cours, si oui, on joue le son std-busy
same = n,GotoIf($[${QUEUE_WAITING_COUNT(0123)}>2]?BUSY)
same = n(BUSY),Playback(std-busy)
// aucun des 2 cas, on prend l'appel sur la file d'attente
same = n,Answer()
// à la fin, on raccroche
same = n,Hangup()

Mais franchement, je ne suis pas bien placé pour répondre, ça fait 7 ans que j’avais pas écrit un dialplan.
Mais ça donne une idée d’une réponse.

A mon avis, le fait de Dial le userA fait que l’appel n’est pas compté dans le queue_waiting_count
et que donc, on ne verra jamais 3 appels dans queue_waiting_count … à tester.
Si c’est le cas, on peut SET une variable pour éventuellement contourner le soucis de compteur …

Si jamais quelqu’un peut aider, car je n’ai jamais vu ce cas.

Tu peux trouver des exemples de dialplan ici:

13

Salut Julien,

ça marche, merci pour le retour, je vais tester avec une queue et des agents du coup :wink:

14

Salut, je comprends bien ce que tu veux faire, mais honnêtement utiliser les queues et agent pour cela n’est pas une solution super conseillée, ça va complexifier ton installation et la logique. L’idéal serait de surcharger le dialplan qui appel l’utilisateur dans le cas d’un groupe pour faire ce que tu souhaites. Sinon as-tu regardé si le téléphone ne peux pas simplement dropper l’appel sur le nombre voulu?

15

Dis moi si ça fonctionne en faisant cela sur ton installation avec un groupe d’appel.

apt install wazo-plugind-cli
wazo-plugind-cli -c "install git https://github.com/sboily/wazo-user-group-max"
1 Like
16

Pour supprimer le plugin.

wazo-plugind-cli -c "uninstall quintana/wazo-user-group-max"

1 Like
17

Salut Sylvain,

Dans ton dialplan, je vois:

same  =            n,Set(COUNT=${GROUP_COUNT(${EXTEN}@user)})
same  =            n,GotoIf($[${COUNT} >= 2]?maxreached)

la particularité de sa demande, c’est que
USERA = max 2 lignes
USERB = max 1 ligne

Donc lorsqu’un 3eme appel arrive sur le groupe, seul USERA doit le recevoir.

Et si il y a un 4eme appel, il doit être mis en attente.

Il me semble que le COUNT ne répond pas à cette particularité.

Mais on doit pouvoir faire un mix de ce que j’ai écris, avec ton code, afin de pouvoir répondre à ce cas.

Si on fait ${GROUP_COUNT()} la valeur est bien le total des appels sur le groupe ?

cheers

18

Bonjour Messieurs,

Merci pour vos messages

@quintana je suis d’accord, utiliser des file / agents ça va complexifier l’installation mais si c’est la solution pourquoi pas

@julienfr effectivement, l’idée du code de Sylvain est bonne mais ça limite tout le monde à 2 appels

Est-ce qu’il ne sera pas possible dans

same  =            n,GotoIf($[${COUNT} >= 2]?maxreached)

Au lieu de comparer à 2 :

  • passer par un script AGI pour récupérer la variable du nombre d’appels simultané de l’utilisateur
  • affecter la valeur à une variable asterisk du genre WAZO_SIMULTANOUS_CALL
  • et comparer à cette variable

En plus, si je comprend bien ce code, ça ne compte que les appels arrivants via le groupe, si il y a un appel interne par exemple, ce n’est pas pris en compte dans le nombre total d’appels en cours de l’utilisateur.
C’est bien ça ?

Je commence un peu à me familiariser avec tout ça, je vais essayer de sortir quelque chose d’ici la fin de la semaine si vous voulez. Je pense que vous avez pas que mes soucis à régler :wink:

Si entre temps vous avez d’autres tips, n’hésitez-pas :slight_smile:

Encore merci pour votre implication :wink:

19

Salut,

Je vous laisse adapter le code et n’hésitez pas à soumettre une PR sur le plugin ça peut permettre à tout le monde d’en profiter. L’idée était de donner une piste pour avancer.

Sylvain

20

Julien, je compte simplement les appels par utilisateur, il suffit de rajouter un peu plus de logique, ça serait possible aussi d’aller chercher la valeur par utilisateur de simulcall et de l’utiliser. EXTEN ici est égal à l’uuid de l’utilisateur.

1 Like