Are the cancel and bye (and failed) events mutually exclusive?

[Rob--W]

JsSIP has "ended" for termination of an established call, and "failed" for termination of a non-established call.

SIP.js has "failed", "cancel" and "bye" (and "rejected", but I've ignored it since it is documented that the "failed" event is always triggered thereafter).

Are these events mutually exclusive? I have written a wrapper around the JsSIP class, and the "ended" and "failed" events provides me the required functionality to reliably implement a destructor that is called exactly once for a RTCSession.

Does SIP.js provide such guarantees? Are the failed/bye/cancel events mutually exclusive, and is exactly one of them going to be triggered regardless of whether the call is established? If so, please document this.

[Rob--W]

There is also an undocumented "terminated" event... (well the event itself is not documented, but there is a reference to it in the documentation: http://sipjs.com/api/0.6.0/session/#endtime)

Date - Date object indicating the time when the session ended. Takes its value at the moment when the terminated event was fired.

(emphasis mine)

[james-criscuolo]

These SIP.js events are not mutually exclusive. Here is a brief rundown of when each one is fired:

• terminated: this is the catch-all ending event. It is inconsistent and may be emitted more than once, so we haven't documented it and generally don't recommend it to be used.
• failed: this can still be used to catch any non-established call endings.
• rejected: this is fired by the UAC when it has received a response that the call has been rejected, or the UAS when it receives a cancel request.
• cancel: this covers the UAC canceling the call. Both sides will fire this, and it will be followed by a rejected and a failed (instantly on the UAS side, or after a 4xx response is received by the UAC side). The fact that this fires on both sides may change in the future, to mirror rejected.
• bye: this will be fired when the other UA ends the call. It looks like there may be a case in the code where we can remove this, but it will definitely fire when the other caller ends the call.

These ending cases are probably more confusing than they should be, but we wanted to provide more flexibility from the previous set of events. Between 'failed,' 'bye,' and covering any application-initiated endings, the old events should be covered.

[Rob--W]

So to replicate the functionality of JsSIP's "ended"+"failed" events, I have to listen the failed, cancel and bye, and keep track of whether any of these events have been triggered before, e.g. with a boolean variable?

[james-criscuolo]

'failed' will cover anything before the call is established, and 'bye' will cover anything from there. If your app initiates the bye/ending of the call, make sure to call the destructor (or whatever you need to do post-call) yourself, since there may not be an event to cover it.

[james-criscuolo]

These events could use a little makeover, so that discussion will be continuing on the google group. There is also a brief summary of all of the events there.

[wakamoleguy]

I think that I covered all of the discussed behavior in the branch I merged in. Testing was done soley via unit tests, and I'm going to follow up with some live testing soon. Likely the demo-phone and then the developer.onsip.com front page.

[wakamoleguy]

FWIW, we also plan to document these events better on sipjs.com for the rollout of 0.7.0

[wakamoleguy]

These seem to be behaving as expected, with the exception of an unintended issue with Transport failure (#167). There is another ticket for that, so I'm going to close this one.