1066522 - Handle message send and response timeouts on the call connection websockets

Status: RESOLVED WONTFIX

(Hello (Loop) :: Client, defect, P3)

Description

[Mark Banner (:standard8)]

According to the Websocket spec, we should have timers for:

- Response Timer

Every client message triggers a response from the server: "hello" results in "hello" or "error"; and "action" will always cause a corresponding "progress" message to be sent. When the client sends a message, it sets a timer for 5 seconds. If the server does not respond in that time period, it disconnects from the server and considers the call failed.

- Media Setup Timer

After sending a "media-up" action, the client sets a timer for 5 seconds. If the server does not indicate that the call setup has entered the "connected" state before the timer expires, the client disconnects from the server and considers the call failed. 

https://wiki.mozilla.org/Loop/Architecture/MVP#Client_Timers

Comment 1

[:shell escalante]

hey mark, has this been handled elsewhere - if not how critical is this to get done?

Comment 2

[Mark Banner (:standard8)]

(In reply to sescalante from comment #1)
> hey mark, has this been handled elsewhere - if not how critical is this to
> get done?

No this hasn't been done already. This is hardening of the websocket protocol for link-clicker/direct calls and how desktop handles it. I think 36 would be the right sort of timescale for this.

Comment 4

[:shell escalante]

maire following up with Mark on status

Comment 5

[Maire Reavy [:mreavy]]

I talked with Mark, this is pretty unlikely to hit (it's an edge-case);  so we can move it to Fx37.

Comment 6

[:shell escalante]

check what strings we need if any with Matej/Mark

Comment 7

[:shell escalante]

shell - follow up with Matej

Comment 8

[:shell escalante]

Hi Matej - can you provide messages for the 2 timeouts that Mark explained in the user story.  Right now it's just call failed - but the messages will give a more specific reason why the call failed to the user.  This is helpful for the user and also for them to report issues that lead us more quickly to why that call failed.

Comment 9

[Mark Banner (:standard8)]

Hi Shell, this is a back-end bug for handling of the protocol, and I think we've already got strings for if this fails, or if not, we'll need something different to what comment 0 implies.

I don't think its appropriate to request strings at the moment - we should do a general review of our failure notifications first (note also this bug relates to direct calls only).

Comment 10

[:shell escalante]

awesome - thanks for the totally logical context Mark.  

Based on it being direct calling only - I'm moving lower in the P3 list.  Based on usage stats that may change (if direct calling is used more or if we add a few features that bump up visibility). 

The bugs that are being hit by the largest number of users are moved up or down in priority.

Comment 11

[Mark Banner (:standard8)]

We are currently reworking the Loop "user journey" (bug 1209713) and as part of this direct calls and contacts are being removed. Therefore closing direct call related bugs as wontfix.

Tracking id: directcallclosing