1040702 - Add a fallback to websockets for the call progress protocol

Status: VERIFIED INVALID

(Hello (Loop) :: Server, defect)

Description

[José Antonio Olivera Ortega [:jaoo]]

We are facing some issues with the websocket-based call progress protocol for certain WiFi networks (see bug 1039596). We should add a fallback to some URL polling.

Comment 1

[Alexis Metaireau (:alexis)]

José, do you have something specific in mind about the fallback you're talking about?

It seems that it should be a requirement to have a network which supports websockets in order to use loop.

If possible, I would try to avoid adding complexity to the server, and this specific request seems to add a bunch of future potential problems.

Adam, maybe do you have some thoughts about that? Do you think that would make sense to have such a fallback machanism on the server?

Comment 2

[Adam Roach [:abr]]

I suspect the analysis on Bug 1039596 is incomplete.

At the moment, the TokBox SDK relies on WebSockets to convey call setup information (including, for example, SDP exchange). If WebSockets doesn't work on a given network, then the TokBox SDK will fail to establish media streams altogether.

So it's *already* true that a network is required to support WebSockets in order for Loop -- or any other TokBox application -- to work at all.

Comment 3

[José Antonio Olivera Ortega [:jaoo]]

Hey guys, I think we should pause here and figure out why the websocket-based call progress protocol didn't worked for us in some cases. I hit the issue today while testing on the cellular network (3G) and after disabling the protocol bits the TokBox session worked well. As Adam commented this is weird as TokBox is using websockets as well. I'll take bug 1039596 and debug deeper. Keep you updated guys.

Comment 4

[José Antonio Olivera Ortega [:jaoo]]

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #3)
> Hey guys, I think we should pause here and figure out why the
> websocket-based call progress protocol didn't worked for us in some cases. I
> hit the issue today while testing on the cellular network (3G) and after
> disabling the protocol bits the TokBox session worked well. As Adam
> commented this is weird as TokBox is using websockets as well. I'll take bug
> 1039596 and debug deeper. Keep you updated guys.

I have been googling a bit and the Websocket connection issue might be cause by the Nginx configuration for the Loop server. That would explain Tokbox sdk works and the connection to the Loop websocket server doesn't.

Comment 5

[José Antonio Olivera Ortega [:jaoo]]

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #3)
> Hey guys, I think we should pause here and figure out why the
> websocket-based call progress protocol didn't worked for us in some cases. I
> hit the issue today while testing on the cellular network (3G) and after
> disabling the protocol bits the TokBox session worked well. As Adam
> commented this is weird as TokBox is using websockets as well. I'll take bug
> 1039596 and debug deeper. Keep you updated guys.

I have been googling a bit and the Websocket connection issue might be cause by the Nginx configuration for the Loop server. That would explain Tokbox sdk works and the connection to the Loop websocket server doesn't.

Comment 6

[Alexis Metaireau (:alexis)]

Do you have some links to share maybe?

Comment 7

[Daniel Coloma:dcoloma]

(In reply to Adam Roach [:abr] (Traveling through July 28th) from comment #2)
> I suspect the analysis on Bug 1039596 is incomplete.
> 
> At the moment, the TokBox SDK relies on WebSockets to convey call setup
> information (including, for example, SDP exchange). If WebSockets doesn't
> work on a given network, then the TokBox SDK will fail to establish media
> streams altogether.
> 
> So it's *already* true that a network is required to support WebSockets in
> order for Loop -- or any other TokBox application -- to work at all.

Do you know if TokBox using Plain Web Sockets or Secure Web Sockets? Secure Web Sockets should bypass proxies easier and that might be the difference we are facing.

Comment 8

[Adam Roach [:abr]]

(In reply to Daniel Coloma:dcoloma from comment #7)
> Do you know if TokBox using Plain Web Sockets or Secure Web Sockets? Secure
> Web Sockets should bypass proxies easier and that might be the difference we
> are facing.

When we use the TokBox toolkit, it communicates with their servers using wss.

The design for Loop is to use wss for call progress as well (cf. <https://wiki.mozilla.org/Loop/Architecture/MVP>), so this shouldn't be the cause of any differences in behavior.

Your comment ("that might be the difference") causes me significant alarm, as it implies that we might be using unencrypted connections for the call progress channel.

Alexis: surely we aren't allowing unencrypted connections here, are we?

Comment 9

[Alexis Metaireau (:alexis)]

That's correct, all the http and websocket should be encrypted. I'll double check if that's the case but we've configured like so.

Comment 10

[Daniel Coloma:dcoloma]

(In reply to Adam Roach [:abr] (Traveling through July 28th) from comment #8)
> (In reply to Daniel Coloma:dcoloma from comment #7)
> > Do you know if TokBox using Plain Web Sockets or Secure Web Sockets? Secure
> > Web Sockets should bypass proxies easier and that might be the difference we
> > are facing.
> 
> When we use the TokBox toolkit, it communicates with their servers using wss.
> 
> The design for Loop is to use wss for call progress as well (cf.
> <https://wiki.mozilla.org/Loop/Architecture/MVP>), so this shouldn't be the
> cause of any differences in behavior.
> 
> Your comment ("that might be the difference") causes me significant alarm,
> as it implies that we might be using unencrypted connections for the call
> progress channel.

I am commenting that because in the logs, when we try to connect to the websocket to start the protocol and the connection fails, we are consistenly getting:

E/GeckoConsole( 2794): [JavaScript Error: "Firefox can't establish a connection to the server at ws://loop.dev.mozaws.net/websocket." {file:"app://loop.dev.mozaws.net/js/helpers/call_progress_helper.js"

Comment 11

[Alexis Metaireau (:alexis)]

Yes, that's for the dev instance. Dev instance doesn't run behind ssl.

Comment 12

[Daniel Coloma:dcoloma]

(In reply to Alexis Metaireau (:alexis) from comment #11)
> Yes, that's for the dev instance. Dev instance doesn't run behind ssl.

Any plans to run dev instance with ssl?

Comment 13

[Rémy Hubscher (:natim)]

Yes we could setup something as we did it for MSISDN

Comment 14

[Alexis Metaireau (:alexis)]

We surely can setup something.

Comment 15

[Daniel Coloma:dcoloma]

(In reply to Alexis Metaireau (:alexis) from comment #14)
> We surely can setup something.

Great! I think it would be helpful in order to have the same configuration in production and development.

Comment 16

[James Bonacci [:jbonacci]]

OK.