Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing "registered" event after reconnection. #337

Closed
pg94au opened this issue Oct 1, 2015 · 5 comments

Comments

@pg94au
Copy link

@pg94au pg94au commented Oct 1, 2015

Copied from this thread discussing the current behaviour where JsSIP does not emit a "registered" event upon reconnection when it was already registered during the previous connection: https://groups.google.com/forum/#!topic/jssip/svj9c5TZ4y4

I don't believe that this is the best way for JsSIP to be handling disconnections.  As you previously stated in the referenced thread, when the connection is lost, that connection's registration is lost.  I don't currently understand why a registration binding should be treated as having survived a connection loss when the aim of registration was to bind a user to that no longer existing connection.

It's possible for JsSIP to support the notion of a virtual registration that spans connections as it does, but I don't see what the abstraction provides.  That is, especially when "connected" does not really mean "registered" in the case of a reconnection where we were previously registered, even if isRegistered() returns true at that time, because the "connected" event is emitted immediately on reconnection, not after successful re-registration.

I can work with what exists to the best I can, but it could become awkward to deal with, if for example upon reconnect some action is taken based on the result of isRegistered(), only to have a "registrationFailed" event fire and invalidate it because the agent at that time was not and could not be registered.

I believe that within a single connection re-registrations to refresh the binding don't need to be emitted as events, but on disconnect an "unregistered" event should be emitted, followed by another "registered" event when the connection and registration are re-established.

@ibc

This comment has been minimized.

Copy link
Member

@ibc ibc commented Feb 5, 2016

@jmillan @saghul I think we should go ahead and fire "registered" for every successful REGISTER/200, regardless we were previously registered or not. I've also found myself stuck with the current behavior. Thoughts?

@saghul

This comment has been minimized.

Copy link
Contributor

@saghul saghul commented Feb 5, 2016

👍

1 similar comment
@jmillan

This comment has been minimized.

Copy link
Member

@jmillan jmillan commented Feb 5, 2016

👍

@ibc

This comment has been minimized.

Copy link
Member

@ibc ibc commented Feb 24, 2016

This is about being implemented.

ibc added a commit that referenced this issue Feb 24, 2016
@jmillan

This comment has been minimized.

Copy link
Member

@jmillan jmillan commented Feb 24, 2016

Hi,

This is implemented in 0.7.16 tag

@jmillan jmillan closed this Feb 24, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
4 participants
You can’t perform that action at this time.