This initial message, called a binding request, originates from the local IP and Port that the browser already has allocated. This process begins by sending a message to a server on the public internet, using the STUN protocol. Rather than signal one address and port to the other endpoint, the browser goes into a process called ICE candidate gathering to generate a list of potential IP and port endpoints with which to establish a connection on. The browser knows it’s local interface IP address and port that it has ready for the session, but doesn’t know what IP and port might exist in a NAT binding created during the connection to Alice's device. The two browsers send session data to the IP address/port each one indicated, and a session is established.Īs Bob’s browser prepares it’s peerConnection to Alice's browser (step 2-3), it has no way of knowing what kind of topology it might face during this process. To work around this, a STUN server that is located outside of the NAT network is used to relay the public IP address back to the device that requested it.īob indicates (through the web UI) he is ready to start a session with Aliceīob’s web application interacts with the browser API to prepare a peerConnectionīob’s browser returns a set of data representing the details of Bob’s session offer, including the layer 3 information regarding where it is prepared to receive session dataīob’s web application signals (through any number of means) the offer to Alice’s web applicationĪlice’s web application notifies Alice of the incoming session request, and Alice indicates (through the web UI) that she wants to accept the sessionĪlice’s web application prepares it’s peerConnection, and provides Bob’s offerĪlice’s browser returns a set of data representing the details of Alice’s session answer, including the layer 3 information regarding where it is prepared to receive session dataĪlice’s web application signals the answer to Bob’s web applicationīob’s web application feeds the answer to the browser's peerConnection The RFC states that this port and IP are arbitrary.Īt SingleComm, we use port 19302, and use Google's STUN servers.īecause the devices we typically connect to are behind a NAT device, a request for the IP address of the computer will most likely return a local IP instead of the public IP and port that must be used to direct voice data to a client over the Internet. The STUN server is contacted on UDP port 3478, however the server will also ask clients to perform tests on a secondary IP and port number also associated with the server. The STUN protocol is defined in RFC 3489. This information is used to set up a UDP communication session between the client and the VoIP provider to establish a call. The STUN server enables clients to find out their public IP address, NAT type, and the Internet-facing port associated by the NAT device with a particular local port. IP Phones behind a firewall) to setup phone calls to a VoIP provider hosted outside of the local network. A STUN (Session Traversal Utilities for NAT) server allows NAT clients (i.e.
0 Comments
Leave a Reply. |