lwc:networking:webrtc

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
lwc:networking:webrtc [2025/01/21 16:28] – created John Harrisonlwc:networking:webrtc [2025/01/23 15:42] (current) John Harrison
Line 3: Line 3:
   * There has to be some sort of server outside of the ICE server that handles the signaling   * 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.//   * 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   * The signaling server is typically accessed through websockets
   * Part of the point is to agree on an ICE server?   * Part of the point is to agree on an ICE server?
Line 15: Line 16:
 }, },
 "name": "userB" "name": "userB"
----------->+--------------------->
      
                             "type": "offer",                             "type": "offer",
Line 23: Line 24:
                             },                             },
                             "name": "userA"                             "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":
 +  }, 
 +  "name": "userB" 
 +  ---------------------> 
 +                             "type": "candidate", 
 +                              "candidate":
 +                                "candidate": "candidate:842163049 1 udp 1677729535 192.168.1.2 56143 typ host", 
 +                                "sdpMid": "0", 
 +                                "sdpMLineIndex":
 +                              }, 
 +                              "name": "userA" 
 +                              --------------------->
   </code>   </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''
  • lwc/networking/webrtc.1737498539.txt.gz
  • Last modified: 2025/01/21 16:28
  • by John Harrison