I am new to WebRTC.
I was learned about the turn server.
The below thing is used to configure the turn server works on TCP for a webrtc application.
Example turn server configuration in webrtc application :-
{
url: ‘turn:192.158.29.39:3478?transport=tcp’,
credential: ‘JZEOEt2V3Qb0y27GRntt2u2PAYA=’,
username: ‘28224511:1379330808′
}
The meaning for the ?transport=tcp is it works on TCP protocol like that they said.
My question is,
The turn server works on TCP means, it is only for establishing a connection between turn server it works on TCP or for transferring a WebRTC media via turn server it uses the TCP protocol. For which purpose the TCP packet is used ?
Is it possible to transfer the WebRTC media via the TCP packet ?
Forcing WebRTC media over TCP is not recommended, its just a fallback option for strict firewalls.
If you specify ?transport=tcp in TURN urls, then WebRTC client will connect to TURN Server over TCP.
Clients will send STUN requests over TCP to allocate relay candidates (As far as i know, currently chrome/firefox only request UDP relay candidates).
To force strict TCP via TURN server:
Use only TURN url with ?transport=tcp
Specify iceTransportPolicy:"relay", so that all media will flow via TURN
After exchanging the relay candidates(udp) between peerConnections, the media path will be as below
P1 <--TCP--> P1TURN <--UDP--> P2TURN <--TCP--> P2
If both P1TURN & P2TURN are always same, then you can choose TURN relay path as LAN/lo interface i.e. you will get UDP relay candidates with LAN/lo IP.
If you want to avoid UDP & two times TURN in the media path, you need to use some SFU/SVC like Jitsi(supports pseudo-SSL candidates)/Janus.
Then media path will be as below
P1 <--TCP--> SFU/MCU <--TCP--> P2
Related
I have configured a coturn server which I need to use with DataChannel for a chat app.
I am trying to reach a point where I can get the coturn server provide me with a tcp allocation.
I am using the standard call of RTCPeerConnection in JS client, providing the turn URI, username and credentials.
The transport I am providing in the URI params is TCP ?transport=tcp.
With all this, I am always receiving a UDP allocation and the server logs ChannelBind requests (UDP based)
Question:
How can I achieve TCP allocations throught webRTC client, to guarantee proper data delivery of the chat app in case of using my relay server?
RFC 6062, opening a TCP port on the TURN server is not supported by WebRTC. It is optional in the spec and nobody needs it since reliability is provided by SCTP.
TCP in the turn uri refers to the protocol between the client and the TURN server
Let's assume that I start a server at one of the computers in my private network (192.168.10.10:9900).
Now when making a request from some other computer in the same network, how does the client computer (OS?) knows which protocol to use / which protocol the server follows ? [TCP or UDP]
EDIT: As mentioned in the answers, I was basically looking for a default protocol which will be used by the client in the absence of any transport protocol information.
TCP / UDP protocols work at the transport layer level (TCP / IP MODEL) and its main difference is that TCP has a method to ensure the arrival of messages while UDP is lighter because of its virtue is to be faster in Information delivery. The use of one protocol or another is always defined by the application that will use it.
So the reference you put on the private server with ip: port 192.168.10.10:9900 is very vague to be more precise we could say that we have an Apache web server running on the ip: port 192.168.10.10:9900 (the port for default is 80 when installing the server, but it can be changed in the configuration).
Now the web servers (apache, IIS, etc.) work using the TCP protocol because when a client (computer, cell phone, etc.) consults a page through a browser (Chrome, Firefox, etc.), the ideal thing is that all the website and not just some pieces. This is why this type of servers chose and use this protocol in the first instance since they seek that in the end the result is that the user obtains the complete page regardless of whether a few more milliseconds are sacrificed in the validations involved in using TPC.
Now going to the client side. The user when visiting a web page from any browser (Chrome, Firefox, etc.) will use TCP since this protocol is already configured in the browser to send the query messages and subsequently receive the messages with the same form Website information.
Now this behavior is going to be repeated for any client / server application. For example, to change the type of application on the UDP side, we can observe the operation of DHCP services which are used to receive an IP when connecting any device to a Wi-Fi network. In this case, this service seeks to be as fast as possible (instead of the most reliable) since you want the device to connect as quickly as possible to the network, so use the UDP protocol and in this case any equipment when connecting To a WIFI network you will send your messages using this protocol.
Finally, if you want to know promptly about the type of TCP / UDP protocol used by a specific application, you can search on the Wireshark application which allows you to scan the messages that leave the device or show the protocol used in the different layers of the application.
There is no reason any client would make a request to your server, so why would it care what protocol it follows? Clients don't just randomly connect to things to see if there's a server there. So it doesn't make any difference to any client.
Normally, the client computer will use the TCP protocol as default. If you start the server using UDP protocol mode, then when you use curl -XGET 192.168.10.10:9900/test-page, it will give you back an curl: (7) Failed to connect to 192.168.10.10 port 9900: Connection refused error. You can try it, use the nc -lvp 9900 -u, it will give you that result.
The answers here are pointing to some default protocol. Its' not that, Whenever you start an application let say HTTP server, the server's internal has code to open a socket(which can be TCP or UDP), since HTTP:80 is a TCP protocol the code creates a TCP socket. Similarly for other network application it depends on their requirement what kind of transport layer protocol to use (TCP Or UDP). Like a DNS client will create a UDP socket to connect to DNS server, since DNS:53 is mostly over UDP. Both TCP and UDP have different use cases, advantages and disadvantages. Depending on there uses cases / advantages / disadvantages of UDP/TCP decision is taken to implement server using either of them.
I am creating media server using WebRTC for video conferencing. As you might know when a user connects to the server two ports will be opened on the server side. RTP and RTCP ports over TCP. Thus, media server will need wide-range of available ports. The case here is not about multiplexing RTP and RTCP ports.
Assume that the media server is behind firewall and ports are blocked so that cannot open wide-range of ports. For example, the media server will use 8080 for signalling and 443 for RTP/RTCP. All video traffic will flow into 443 on the server side.
Is that possible?
It is possible, and many media servers provide that feature.
Wowza enables single port for WebRTC over TCP; Unreal Media Server enables single port for WebRTC over TCP and for WebRTC over UDP as well.
Technically, it's quite challenging to develop such a feature; especially for providing single port for WebRTC over UDP. You need to relay incoming WebRTC traffic, arriving to your single port, to internal endpoints of particular RTCPeerConnections in the server. Initial Stun requests carry information that helps you find the right context and map the external to internal.
I used to think Skype sends and receives UDP data packets for real-time audio communication so it cannot use HTTP proxy as HTTP is based on TCP, as what people usually think. But in the support site of Skype, there is an article about HTTP proxy saying that'll affect how Skype makes the communication.
Skype uses different protocols based on the capabilities of the network. If it is behind a firewall and can not call out directly with UDP it will try to detect a HTTP proxy and use it to tunnel the traffic using a proxy CONNECT request. This means it will use TCP in this case. While this might degrade the quality of the connection because latency is often better with UDP (at the cost of data loss), this is often better than no connection at all.
I've read about WebSockets and I wonder why browser couldn't simply open trivial TCP connection and communicate with server like any other desktop application. And why this communication is possible via websockets?
It's easier to communicate via TCP sockets when you're working within an intranet boundary, since you likely have control over the machines on that network and can open ports suitable for making the TCP connections.
Over the internet, you're communicating with someone else's server on the other end. They are extremely unlikely to have any old socket open for connections. Usually they will have only a few standard ones such as port 80 for HTTP or 443 for HTTPS. So, to communicate with the server you are obliged to connect using one of those ports.
Given that these are standard ports for web servers that generally speak HTTP, you're therefore obliged to conform to the HTTP protocol, otherwise the server won't talk to you. The purpose of web sockets is to allow you to initiate a connection via HTTP, but then negotiate to use the web sockets protocol (assuming the server is capable of doing so) to allow a more "TCP socket"-like communication stream.
Web browsers operate at the Application layer, whereas TCP operates at the Transport Layer. As a web application developer, it's easier to send messages over the wire via the Application Layer instead of raw bytes at the Transport Layer.
Underlying WebSockets is TCP, it's just abstracted away for simplicity.
Websocket is a application layer protocol while TCP is transport layer protocol. At transport layer, we usually have TCP and UDP protocol. Any message from application layer need to go through transport layer to be transmitted to other machine. Hence, websocket and tcp have a relationship to each other and can not be comparable.
To make it simple, the websocket communications are done over TCP port number 80 (or 443 in the case of TLS-encrypted connections), which is of benefit for those environments which block non-web Internet connections using a firewall.
Would you like to use existed TCP port or open a new TCP port that might be blocked by firewall?