Missing "registered" event after reconnection.

[pg94au]

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]

@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]

👍

[jmillan]

👍

[ibc]

This is about being implemented.

[jmillan]

Hi,

This is implemented in 0.7.16 tag