Sip.js: UserAgent.stop() function takes too much time

Confirmed it in the code...

@john-e-riordan this looks to be an order of operations issue.

At the top of user-agent.stop() we transition to the Stopped state.

We then cycle through registerers, sessions, then subscriptions.

The subscription.dispose() function rightfully sends a SUBSCRIBE with an Expires=0 header. That causes a NOTIFY to get sent to SIP.js indicating that subscription has closed. However there is a check in user-agent.onTransportMessage() that is checking if the user-agent is stopped. And then dropping the NOTIFY because of the user-agent state. Causing the subscriber to wait for the timeout.

We will work on getting this patched. Thanks.

cating that subscription has closed. However there is a check in user-agent.onTransportMessage() that is checking if the user-agent is stopped. And then dropping the`NOTIFY because of

Thank you very much for quickly responding and finding the root cause of the problem! Hope it will be fixed soon :)
By the way, I tested the stop() function when I'm not doing my initial SIP SUBSCRIBE that I'm also doing when making the REGISTER, and everything is working fast. But of course I'll need this SUBSCRIBE.
Thank again!

To work around this you could dispose of your subscriptions manually before calling stop() on the user-agent.

To work around this you could dispose of your subscriptions manually before calling stop() on the user-agent.

Thanks! Already done, but not in an efficient way I think. If you can suggest me a better way it be very helpful.
I have a few subscriptions I'm making while the user is registered (like presence, conference and some other events).
Is there a way to itterate on all active subscriptions and call the dispose or unsubscribe method?
I saw that I can get the subscriptions list by doing: userAgentObject._subscriptions and it is getting some array of Subscribers and for some reason I cannot take it and do anything with it, like iterating or something else.

The way how I did it currently, but again, I don't like it, for each subscribe event type, I stored the subscriber into a different global variable in the class and for each subscriber variable I'm calling the unsubscribe method.

By the way, what's the difference between dispose and unsubscribe? I assume that dispose will not unsubscribe the subscription in the PBX. Right? If so, I think it's less recommended, because in my case, if I will not fully unsubscribe, the PBX will keep sending irrelevant NOTIFY messages to my Kamailio (which may lead to a total block because Kamailio will block my PBX if it'll overload him).

To work around this you could dispose of your subscriptions manually before calling stop() on the user-agent.

Any progress😊? How to do this before the bug is fixed?

I don't have any subscription, but the UA.stop() is very slow too. Almost 1min...

Thank you.

To work around this you could dispose of your subscriptions manually before calling stop() on the user-agent.

Any progress😊? How to do this before the bug is fixed?

I don't have any subscription, but the UA.stop() is very slow too. Almost 1min...

Thank you.

Nope, this issues is not resolved yet.
But, you can do what I did... you can just destroy your objects manually one by one with the following logical order:

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

Preferably, do every action with promises. I mean, use then so you can wait each action promise to get back and act accordingly to do the next step.

I have the same issue. I don't have any subscriptions. For me, closing the WebSocket takes too long, (20-50 secs)

I tried:

• destroying object manually as @slavikbialik suggests.
• closing the WebSocket manually with userAgent.transport.ws.close() to make sure if my issue is related to WebSocket.
• in Chrome and Firefox.

I don't have any specific configurations, just followed SIP.js guide to reproduce. I don't know if this helps or is related my issue but I tried to open a WebSocket with sip protocol without any library and closed it. They both lasted under 1 second.