Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I started learning webRTC a few days back. WebRTC follows offer/answer model. Do all the exchanges(metadata, network information, and media streams) follow this model? Do we need of STUN/TURN servers in all the exchanges. After getting the public IPs of the peers from STUN/TURN server for the first time, peer to peer communication can be started .
WebRTC follow SIP and SDP protocol using a signaling server to do so.
All of this is used with the RTCPeerConnection. RTCPeerConnection is initiate with TURN/STUN servers. STUN/TURN is only usefull to generate ICE Candidate. You can use webrtc without Stun and Turn, it only means it will not be able to establish a peer-to-peer connection between every network (firewall and NAT are problematic mostly).
You don't need at all STUN/TURN for the offer/answer part. It only need a signaling server. STUN/TURN is usefull only in the ICE protocol that is a different flow than the Offer/Answer part. But of course, you need to do both to have a working peer-to-peer connection.
After Offer/Answer are exchange, both peer gather ICE candidate and send it to the other peer. Then ICE find the best way to establish the peer-to-peer and so the communication begin.
If you have moire question, go for it if ou don't find the answer elsewhere.
Related
Can I code a website which allows p2p video calls for peers behind NATs without relaying the video data myself as a 3rd party server (since it is expensive)
my network knowledge says it's impossible but this is not emphasized in any docs I've been reading, so simple yes/no answer to this question please.
and I assume most of the computers people use are behind NATs, so they are not outliers but the norm.
Not impossible. Definitely possible, but not 100% reliable.
WebRTC does support peer to peer video conferencing using STUN instead of TURN relays.
Bare minimum for establishing a WebRTC session:
At least a STUN server for clients to self-discover their own IP:port mappings
Your own web service for clients to exchange SDP data generated by WebRTC APIs.
The TURN server is a superset to STUN that supports relay data as well. While you aren't required to have it, clients that are behind "symmetric NAT" or any NAT configuration where the port mapping can not be predicted will have difficulty connecting to other endpoints.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
The community reviewed whether to reopen this question 8 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I am using coTurn as my turn server in my application.
what is the minimum configuration to do to make my Turn server work behind NAT?
what are all ports I have to open for it to work behind NAT?
As I have read coturn comes with inbuilt STUN so can I use STUN address in my application instead of default google STUN mentioned here https://github.com/coturn/coturn/wiki/CoturnConfig
if so what should be my configuration there to be modified in the javascript object in RTCPeerConnection
I'm assuming work behind NAT refers to the TURN server, and not to the application.
In this case, you can refer to the external-ip parameter in coturn configuration:
TURN Server public/private address mapping, if the server is behind NAT. In that situation, if a -X is used in form "-X " then that ip will be reported as relay IP address of all allocations.
This works for example in NAT scenarios like AWS of GCP, where there's a 1:1 mapping between a private IP address, where coturn can listen on, and an ephemeral public IP address.
Your application can just be configured to use coturn in the ice settings as if coturn was listening directly on the public IP.
e.g.:
listening-ip=172.10.1.1
external-ip=3.3.3.3/172.10.1.1
Furthermore, coturn will respond to Allocate requests with relay transport addresses with the public IP in the XOR-RELAYED-ADDRESS of the Allocate Success response.
The port will be the same as the one allocated on the private interface. So for example if the relay is allocated on 172.10.1.1:40032, the XOR-RELAYED-ADDRESS will contain 3.3.3.3:40032.
Needless to say, whatever port range is configured in coturn's configuration needs to be reachable from the applications. For example if min-port is 40000 and max-port is 50000, there must be a Security Group for that EC2 instance which allows accessing to UDP 40000-50000.
By default coturn acts also as a STUN server (even fully RFC-5780 compatible if listening on more than one IP address).
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I am having a server which supports RC4 SSL Cipher suites. I just want to know whether it is easy for a attacker to determine the contents and IP of the users who are connecting to my server?
Concerning the IP, that is out of scope for SSL. SSL works on top of TCP and thus doesn't even know about IPs. Hiding IPs is hard, since they're required to deliver data to the correct recipient. You can use proxies like TOR to hide your IP.
SSL keeps the content transferred over the encrypted connection secret. RC4 isn't the greatest encryption since it produces a biased bitstream. That allows an attacker to learn your secret data if it's transferred several billion times at a known position close the the beginning of the stream.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have server and client running OS Window 7 ultimate. I would like to configure so that server and client communicate under TLS.
At server, I go Local Group Policy-> Remote Desktop Host -> Security to enable Secure Layer to TLS1.0.
When I connect the server from client, I did capture the packet using Wireshark, but I never see the TLS setup .
I did google alot regarding how to set up the TLS. It said that the self-signed cert is not trusted from the trusted root CA. Is it because of this so the TLS can't set up?
Wireshark often can't guess the protocol when the protocol changes on the same connection. This is typically the case for most protocols that upgrade to SSL/TLS on the same connection (using STARTTLS-like mechanisms).
If you want to see this, you have to tell Wireshark to decode the packets as SSL/TLS: right-click and choose Decode As -> Transport -> SSL.
This should work even with a self-signed certificate (typically one is generated automatically and configured by default on a Windows 7 Pro machine, for example). In this case, if you want the connection the be secure, you'd need to verify manually that it is the certificate set up on that machine.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
Much of the information regarding UDP NAT Traversal involves an intermediate server to communicate the public end points to both clients. Is it possible to shortcut this if the public end points are pre-configured for the clients?
Can two clients behind NATs begin sending UDP traffic to each other's public IP:Port to punch a hole? Is the intermediate required for anything other than communicating the public endpoints?
I can't speak with authority (or provide sources), but from what I've gathered in the past month working with STUN and TURN protocols:
Some background
There are many ways for NATs to assign ports (see below). A full cone NAT is a one-to-one mapping so that once the NAT maps a port, any external host can send packets to the private host using the same mapping. However, for example, if the NAT type is symmetric, packets to different external IPs will have different port mappings.
With certain NAT types (eg. full cone), one can use a STUN server to determine the NAT port mapping. This STUN server is a popular example of the intermediate server you mentioned. Some more restrictive NAT types (eg. symmetric) make it impossible to use a STUN server, and direct peer to peer connections are impossible. This is because a STUN server assumes NAT port mappings do not depend on the external IP, but a symmetric NAT assigns different port mappings for different external IPs.
Can we remove the intermediate server?
The specific address translation (how a router maps port numbers) algorithm depends on the specific router (my speculation). Some routers use random port assignments, which makes it impossible for clients to beforehand make connections without an intermediate public server to make this determination (STUN).
In general, no, it is not possible to remove the intermediate server. Unless you have some internal knowledge of how the NAT works (this might depend on the specific model of router), an intermediate server must be used.
STUN RFC
RFC 4787 Section 4.1
NAT RFC 1631
Incomplete list of NAT types