==== Signaling ====
//working out an example with 2 clients trying to connect//
  * There has to be some sort of server outside of the ICE server that handles the signaling
  * The clients need some way to identify themselves on the signaling server so there is typically a login process. //This is not required though.//
    * typically after login we would then connect to a STUN server for the candidate negotiation. We don't need a unique ID to do this tho so login is not required.
  * The signaling server is typically accessed through websockets
  * Part of the point is to agree on an ICE server?
  * Signaling follows a protocol called SDP (Session Description Protocol). Looks something like:

<code>
Caller                      Signaling Server                      Target Peer
"type": "offer",
"offer": {
  "sdp": "v=0\r\n...",
  "type": "offer"
},
"name": "userB"
--------------------->
  
                            "type": "offer",
                            "offer": {
                              "sdp": "v=0\r\n...",
                              "type": "offer"
                            },
                            "name": "userA"
                            --------------------->
                                                                "type": "answer",
                                                                "answer": {
                                                                  "sdp": "v=0\r\n...",
                                                                  "type": "answer"
                                                                },
                                                                "name": "userA"
                                                                <---------------------
                            "type": "answer",
                            "answer": {
                              "sdp": "v=0\r\n...",
                              "type": "answer"
                            }
                            <---------------------

  "type": "candidate",
  "candidate": {
    "candidate": "candidate:842163049 1 udp 1677729535 192.168.1.2 56143 typ host",
    "sdpMid": "0",
    "sdpMLineIndex": 0
  },
  "name": "userB"
  --------------------->
                             "type": "candidate",
                              "candidate": {
                                "candidate": "candidate:842163049 1 udp 1677729535 192.168.1.2 56143 typ host",
                                "sdpMid": "0",
                                "sdpMLineIndex": 0
                              },
                              "name": "userA"
                              --------------------->
  </code>

  * candidate exchange goes back and forth between the caller and the target until they agree
  * the ''"sdp": "v=0\r\n...",'' stuff is about agreeing on what protocols, types of messages, etc. And SDP is currently at version 0
  * the tutorialspoint example does not use the "name" label when negotiating candidates. Is that because the offer and answer have already happened so both clients know the other client is the one offering the candidates?

==== Notes ====
  * when we connect to the STUN server we need to give it info on the type of data we are sending
    * straight-up data: use ''openDataChannel'' and ''onDataChannel''
    * audio or video: use ''addTrack'' and ''onTrack''