The WebSocket transport connection timeout does not trigger a reconnection attempt

Describe the bug The WebSocket transport connection timeout does not trigger a reconnection attempt. The reconnection attempt is only triggered when the WebSocket itself times out (which can take a very long time, upwards of 1 minute).

Logs https://gist.github.com/yren-ITH/1f39bc32e0d115e30791366cff6ec17e

To Reproduce (if possible) Steps to reproduce the behavior:

1. Create a UserAgent with a list of dummy wsServers and logging enabled

const userAgent = new UA({
  transportOptions: {
    wsServers: {
      `wss:example.com:11111`,
      `wss:example.net:11111`,
      `wss:example.org:11111`
    },
    connectionTimeout: 3,
    maxReconnectionAttempts: 1,
    reconnectionTimeout: 1,
  },
  uri: '[e-mail]',
  password: 'foobar',
  log: {
    level: 3,
  },
})

Expected behavior

• Each connection attempt times out after three seconds.
• One second after the connection times out, a new connection attempt is made with the next WS server in the list.

Observed behavior

• Each connection attempt times out after three seconds.
• One minute later, a new connection attempt is made with the next WS server in the list.

Environment Information SIP.js Version 0.14.6 Chrome Version 74.0.3729.169 (Official Build) (64-bit)

Additional context N/A

[john-e-riordan]

The following comment does not speak to what is going on in the current API or provide anything helpful on that front.

But FYI with regard to the new API - a couple of architectural things changed as of 0.15.8…

1. Reconnection logic has been moved to UserAgent
2. A single Transport instance now only deals with a single WebSocket server
3. The UserAgent delegate now provides onConnect and onDisconnect (which should be used in lieu of the legacy Transport events)
4. One may now call disconnect() on a Transport instance before an outstanding call to connect() completes in which case connect() will reject.
5. Support for configuring multiple servers was removed.

With all that said, I don’t see any technical roadblocks to adding multiple server back in as a feature of the UserAgent (instead of the Transport). Having UserAgent construct and maintain individual Transport instances, and manage the associated fail overs, and swapping them in/out as the Transport being used by the UserAgentCore seems like it would relatively straightforward.

I’m not planning on getting to it in the immediate term, but I’ll put it on the 0.16.x roadmap.

[james-criscuolo]

This issue has been fixed since 0.15.8, and while there is more pending work for 0.16, the issue itself has been resolved, so I’ll close.