Sip.js: La fonction UserAgent.stop() prend trop de temps

Je l'ai confirmé dans le code...

@john-e-riordan cela semble être un problème d'ordre des opérations.

Au sommet de user-agent.stop() nous passons à l'état Stopped .

Nous parcourons ensuite registerers , sessions , puis subscriptions .

La fonction subscription.dispose() envoie à juste titre un SUBSCRIBE avec un en-tête Expires=0 . Cela provoque l'envoi d'un NOTIFY à SIP.js indiquant que l'abonnement est fermé. Cependant, il y a un contrôle dans user-agent.onTransportMessage() qui vérifie si le user-agent est arrêté. Et puis en laissant tomber le NOTIFY cause de l'état de l'agent utilisateur. Faire en sorte que l'abonné attende le délai d'attente.

Nous allons travailler pour obtenir ce patché. Merci.

cation que l'abonnement a fermé. Cependant, il y a un contrôle dans user-agent.onTransportMessage() qui vérifie si le user-agent est arrêté. Et puis laisser tomber le `NOTIFY à cause de

Merci beaucoup d'avoir répondu rapidement et d'avoir trouvé l'origine du problème ! J'espère que ce sera bientôt corrigé :)
D'ailleurs, j'ai testé la fonction stop() lorsque je ne fais pas mon SIP SUBSCRIBE initial que je fais également lors de la création du REGISTER, et tout fonctionne rapidement. Mais bien sûr, j'aurai besoin de ce ABONNEZ-VOUS.
Merci encore!

Pour contourner ce problème, vous pouvez supprimer vos abonnements manuellement avant d'appeler stop() sur l'agent utilisateur.

Pour contourner ce problème, vous pouvez supprimer vos abonnements manuellement avant d'appeler stop() sur l'agent utilisateur.

Merci! Déjà fait, mais pas de manière efficace je pense. Si vous pouvez me suggérer une meilleure façon, ce sera très utile.
J'ai quelques abonnements que je fais pendant que l'utilisateur est enregistré (comme la présence, la conférence et certains autres événements).
Existe-t-il un moyen d'itérer sur tous les abonnements actifs et d'appeler la méthode dispose ou unsubscribe ?
J'ai vu que je peux obtenir la liste des abonnements en faisant : userAgentObject._subscriptions et cela obtient un certain nombre d'abonnés et pour une raison quelconque, je ne peux pas le prendre et faire quoi que ce soit avec, comme itérer ou autre chose.

La façon dont je l'ai fait actuellement, mais encore une fois, je ne l'aime pas, pour chaque type d'événement d'abonnement, j'ai stocké l'abonné dans une variable globale différente de la classe et pour chaque variable d'abonné, j'appelle le unsubscribe méthode.

Au fait, quelle est la différence entre dispose et unsubscribe ? Je suppose que dispose ne désabonnera pas l'abonnement dans le PBX. Droite? Si c'est le cas, je pense que c'est moins recommandé, car dans mon cas, si je ne me désinscris pas complètement, le PBX continuera à envoyer des messages NOTIFY non pertinents à mon Kamailio (ce qui peut conduire à un blocage total car Kamailio bloquera mon PBX s'il le surcharger).

Pour contourner ce problème, vous pouvez stop() sur l'agent utilisateur.

Des progrès😊? Comment faire avant que le bug ne soit corrigé ?

Je n'ai pas d'abonnement, mais le UA.stop() est aussi très lent. Presque 1min...

Merci.

Pour contourner ce problème, vous pouvez stop() sur l'agent utilisateur.

Des progrès😊? Comment faire avant que le bug ne soit corrigé ?

Je n'ai pas d'abonnement, mais le UA.stop() est aussi très lent. Presque 1min...

Merci.

Non, ce problème n'est pas encore résolu.
Mais, vous pouvez faire ce que j'ai fait... vous pouvez simplement détruire vos objets manuellement un par un dans l'ordre logique suivant :

1. SubscriberObj.unsubscribe();
2. registerer.unregister();
3. userAgent.transport.disconnect();
4. userAgent.stop();

De préférence, faites chaque action avec des promesses. Je veux dire, utilisez then pour pouvoir attendre que chaque promesse d'action revienne et agir en conséquence pour passer à l'étape suivante.

J'ai le même problème. Je n'ai aucun abonnement. Pour moi, la fermeture du WebSocket prend trop de temps, (20-50 secondes)

J'ai essayé:

• détruire l'objet manuellement comme le suggère @slavikbialik .
• fermer le WebSocket manuellement avec userAgent.transport.ws.close() pour m'assurer que mon problème est lié à WebSocket.
• dans Chrome et Firefox.

Je n'ai pas de configurations spécifiques, j'ai juste suivi le guide SIP.js pour reproduire. Je ne sais pas si cela aide ou est lié à mon problème, mais j'ai essayé d'ouvrir un WebSocket avec le protocole sip sans aucune bibliothèque et je l'ai fermé. Ils ont tous les deux duré moins d'une seconde.