commit f929a365d445f320d1d985cc3efd5673e9d62ba4
author simon <tran.simon2@gmail.com> Fri Nov 18 16:53:45 2022 -0500
committer simon <tran.simon2@gmail.com> Tue Nov 22 15:27:54 2022 -0500
tree 315cda7e249c716ffa719cf5b1e75e50100a73be
parent b05ad993a09cd8d35baa136ef27e30908354bb1b

Implement proper WebRTC call management

This is a big CR that implements the whole proper call logic.

-- Other Contributors --

This CR was created in pair programming with:

-  Charlie Duquette <charlie_duquette@hotmail.fr>

-- New files --

- `ConversationProvider`: Provides the conversation object to its children. Also contains the function to begin a call (first step in the flow) which sends the `BeginCall` event.
- `CallProvider`: Contains the call logic that was previously in WebRTCProvider. From now on, WebRTCProvider contains only the WebRTC logic, while CallProvider
  contains everything related to the call (get the media devices, start/accept calls...)
- `NotificationManager`: Wrapper component to bind the WebSocket CallBegin event listener. That listener will fire when a `BeginCall` event is received and will then redirect the user to the call receiving page.

-- New routes --

When a `conversationId` is included in the URL, all pages are inside a `<ConversationProvider />`.

When starting a call, the caller is redirected to:

> http://localhost:3000/conversation/:conversationId/call?role=caller

When receiving a call, the receiver is redirected to:

> http://localhost:3000/conversation/:conversationId/call?role=receiver&hostId={HOST_ID}

When the user is in a `.../call` route, the `WebRTCContext` and
`CallContext` are provided

The `hostId` is the account URI of the caller. It's used when the receiver wants to send their answer back to the caller.

```
/
|-- login: <Welcome />
|-- settings: <AccountSettings />
|-- ...
`-- conversation: <Messenger />
    |-- add-contact/:contactId
    `-- :conversationId: <ConversationProvider />
        |-- /: <ConversationView />
        `-- /call: <WebRTCProvider>
                     <CallProvider>
                       <CallInterface />
                     </CallProvider>
                    </WebRTCProvider>
```

-- Call flow --

1. Caller:

- Clicks "Call" button
- Sends `BeginCall` event
- Redirects to call page `/call?role=caller`
- Sets `callStatus` to "Ringing"

2. Receiver:

- Receieves `BeginCall` event
- The callback in `NotificationManager` is called
- Redirects to the call receiving page `/conversation/{CONVERSATION_ID}/call?role=receiver`

3. Receiver:

- Clicks the "Answer call" button
- Sends a `CallAccept` event
- Sets `callStatus` to "Connecting"

4. Caller:

- Receives `CallAccept` event
- The callback in `CallProvider` is called
- Sets `callStatus` to "Connecting"
- Creates WebRTC Offer
- Sends `WebRTCOffer` event containing the offer SDP

5. Receiver:

- Receives `WebRTCOffer` event
- The callback in `WebRTCProvider` is called
- Sets WebRTC remote description.
- WebRTC `icecandidate` event fired. Sends `IceCandidate` WebSocket event
- Creates WebRTC answer
- Sends `WebRTCAnswer` event
- Sets WebRTC local description
- Sets connected status to true. Call page now shows the call interface

6. Caller:

- Receives `WebRTCAnswer` event
- Sets WebRTC local description
- Sets WebRTC remote description
- WebRTC `icecandidate` event fired. Sends `IceCandidate` WebSocket event
- Sets connected status to true. Call page now shows the call interface

-- Misc Changes --

- Improve CallPending and CallInterface UI
- Move `useUrlParams` hook from the (now deleted) `client/src/utils/hooks.ts` file to `client/src/hooks/useUrlParams.ts`
- Disable StrictMode. This was causing issues, because some event would be sent twice. There is a TODO comment to fix the problem and reenable it.
- Improvements in server `webrtc-handler.ts`. This is still a WIP
- Rename dash-case client files to camelCase

GitLab: #70
Change-Id: I6c75f6b867e8acb9ccaaa118b0123bba30431f78