SIP.Transport disconnect and reconnect

[capi...@gmail.com]

I have noticed some odd behaviour with the SIP.Transport object with regards to the websocket connection and the propagation of the disconnect event to SIP.UA.

On a shaky connection I have noticed that SIP.Transport will sometimes output to the console that the websocket has disconnected and then a second later it will say that the websocket has reconnected. Sometimes this happens only once, but sometimes it happens in cycles of up to 15 times. Along with the messages about the websocket connection the current SIP.Session will emit a 'failed' event every time the websocket disconnects and the UA will emit a 'connected' event every time the websocket connects again. Most of the time the session isn't noticeably affected by the interruption and the call continues normally, but sometimes the websocket will be disconnected long enough for the call to drop. When the call drops in this manner there's no 'bye' emitted and it seems like the library still thinks that the session is still connected.

One question I have is why does the UA emit a 'connected' event every time while never emitting a 'disconnected' event?

The other is do you know of any way to determine if the session is actually still connected or not after a 'failed' event? Or would it be safest to just call bye() myself and force it to not reestablish a connection?

Below is the console log to show this occurring. Unfortunately I only captured the cycle happening once because I forgot to copy the console when it was happening continuously. The connect/disconnect cycle of the transport was the last eleven lines happening over and over.

I produced it using this jsfiddle, http://jsfiddle.net/kcrfefxe/26/.

"Thu Oct 02 2014 15:02:32 GMT-0400 (Eastern Standard Time) | sip.inviteclientcontext | emitting event accepted" sip.js:2762
"BigBlueButton call started" show:152
"Thu Oct 02 2014 15:02:32 GMT-0400 (Eastern Standard Time) | sip.invitecontext.mediahandler | stream added: undefined" sip.js:2762
"Thu Oct 02 2014 15:02:32 GMT-0400 (Eastern Standard Time) | sip.invitecontext.mediahandler | emitting event addStream" sip.js:2762
"Thu Oct 02 2014 15:03:04 GMT-0400 (Eastern Standard Time) | sip.transaction.ict | Timer B expired for INVITE client transaction z9hG4bK7586365" sip.js:2762
"Thu Oct 02 2014 15:03:04 GMT-0400 (Eastern Standard Time) | sip.transaction.ict | Timer M expired for INVITE client transaction z9hG4bK7586365" sip.js:2762
"Thu Oct 02 2014 15:03:04 GMT-0400 (Eastern Standard Time) | sip.transaction.ict | emitting event stateChanged" sip.js:2762
"Thu Oct 02 2014 15:03:04 GMT-0400 (Eastern Standard Time) | sip.ua | emitting event transactionDestroyed" sip.js:2762
"Thu Oct 02 2014 15:03:12 GMT-0400 (Eastern Standard Time) | sip.transport | WebSocket disconnected (code: 1000)" sip.js:2762
"Thu Oct 02 2014 15:03:12 GMT-0400 (Eastern Standard Time) | sip.ua | connection state set to 1" sip.js:2762
"Thu Oct 02 2014 15:03:12 GMT-0400 (Eastern Standard Time) | sip.inviteclientcontext | emitting event failed" sip.js:2762
"call failed with cause: Connection Error" show:146
"Thu Oct 02 2014 15:03:12 GMT-0400 (Eastern Standard Time) | sip.transport | trying to reconnect to WebSocket ws://my.server.com/ws (reconnection attempt 1)" sip.js:2762
"Thu Oct 02 2014 15:03:16 GMT-0400 (Eastern Standard Time) | sip.transport | connecting to WebSocket ws://my.server.com/ws" sip.js:2762
"Thu Oct 02 2014 15:03:16 GMT-0400 (Eastern Standard Time) | sip.ua | emitting event connecting" sip.js:2762
"Thu Oct 02 2014 15:03:16 GMT-0400 (Eastern Standard Time) | sip.transport | WebSocket ws://my.server.com/ws connected" sip.js:2762
"Thu Oct 02 2014 15:03:16 GMT-0400 (Eastern Standard Time) | sip.ua | connection state set to 0" sip.js:2762
"Thu Oct 02 2014 15:03:16 GMT-0400 (Eastern Standard Time) | sip.ua | emitting event connected" sip.js:2762
"WebSocket connected" show:83

Chad

[Will Mitchell]

Hi Chad,

I'll have to look into the UA events being fired in more detail to see what is going on there.  It may be related to Issue 63, and is definitely something to make sure behaves in a consistent, expectable manner.

As for the Session failure, I can explain what is going on there.  When the WebSocket disconnects, it doesn't necessarily affect the flow of media (which goes over a separate RTCPeerConnection).  When the WebSocket drops, we've lost connection with the signaling server, and so we can no longer send messages in-dialog (including a BYE).  For the purposes of SIP signaling, the session is dead.  Rather than kill the media entirely in this situation, we attempt to let it keep going as long as possible.  That's why in some cases, the media keeps flowing, unless the network connection is flakey enough to drop that as well.  Sending a BYE in this situation is unlikely to successfully get a BYE to the other end, although it will probably cause the local client to stop sending media.  To detect when media stops flowing, you may need to use something more advanced, like perhaps ICE events or the WebAudio API.

-Will

[Bharath]

Hi Will,

I'm pretty much facing the issue. Initially, the WSS connection is established and the call gets connected and everything works fine. Exactly after 2 mins, the web socket gets disconnected with the generic error code 1006 but the call is not affected since the flow of media is happening via RTP but if either the client or server sending BYE doesn't reach the other end. I have attached the console logs for your reference. Is there any possible way to circumvent this issue.

VM45279:895 Wed Sep 12 2018 15:23:39 GMT+1000 (Australian Eastern Standard Time) | sip.transport | WebSocket disconnected (code: 1006)

VM45279:895 Wed Sep 12 2018 15:23:39 GMT+1000 (Australian Eastern Standard Time) | sip.transport | WebSocket abrupt disconnection

[Eric Green]

We are using the browsers built in websocket and the error message you are seeing is bubbling up from an error on the underlying socket. It is most likely related to whatever websocket server you are connecting to.