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.
Related
if when i try to connect with webRTC from outside the local network, it uses a STUN server to exchange info like ip address, port..., and then once the two clients know each other they will directly connect, but the thing is, if any router by default blocks any port that's opened exept for 80, then how do the two clients connect, on what port?
WebRTC is an open framework and does not dictate how the connections are established between the communicating peers. Establishing the connection itself involves the following.
1-The peer discovery is made via Signaling for doing SDP exchanges and exchanging remote host identities. The Signaling can be done over any transport – UDP/TCP, any protocol and via any standard (SIP/XMPP) or custom application level protocol over HTTP/WebSockets etc. The choice of Ports for signalling traffic is left open to the application developer.
2-Once the peer discovery is complete, and the PeerConnections are established at each endpoints, the media data can be sent. Depending on the network topology of the Peers (whether they are in the same host network, or they are in different network (behind Nated IP address), they can choose to connect such that the media traffic is sent over UDP or over TCP. For a more protected environment, the peers may even need a TURN server to relay the media traffic on Peers behalf. Here again, the choice of Media Ports is left open and can be decided via the end application.
I found this on web I hope its helpful
I'm currently developing a "node-based" system where a server will send out a UDP broadcast on the private network (with a custom protocol), which will be received by several different clients which supports the specified protocol. The server will after the request pick between some of the clients for a more steady TCP connection.
Request for client sequence
Server broadcasting a request-for-ip message to every device/node on the network.
All available clients that supports the protocol will answer with their unique IP to the server.
Server chooses among the clients via a request-for-connection message.
Client that got choosen by the server connects to the server via TCP for a reliable connection.
My question
I've got pretty good knowledge about both TCP and UDP, but I've never designed a system like this before. Do you think this system is built in the right way or is there a more "standard" way doing something similar to this? What are your thoughts?
Thanks!
--- Edit ---
Added a diagram of the program.
There is a standard protocol to advertise services on the network, which you may like to consider: Simple Service Discovery Protocol, based on periodic UDP multicast:
The Simple Service Discovery Protocol (SSDP) is a network protocol based on the Internet protocol suite for advertisement and discovery of network services and presence information. It accomplishes this without assistance of server-based configuration mechanisms, such as Dynamic Host Configuration Protocol (DHCP) or Domain Name System (DNS), and without special static configuration of a network host. SSDP is the basis of the discovery protocol of Universal Plug and Play (UPnP) and is intended for use in residential or small office environments.
In this protocol clients join that UDP multicast group to discover local network services and initiate connections to them, if they wish to. And this is pretty much the intended use case for the protocol, which is somewhat different from your use case.
One benefit of IP/UDP multicast is that multicast packets can be dropped in the network adapter if no process on the host has joined that multicast group. Another one is that IP/UDP multicast can be routed across networks.
From the diagram you posted:
The server is the mediator (design pattern) whose location must be known to every other process of the distributed system.
The clients need to connect/register with the server.
Your master client is a control application.
It makes sense for the server to advertise itself over UDP multi-cast.
Online clients would connect to the server using TCP on start or TCP connection loss. If a client terminates for any reason that breaks the TCP connection and the server becomes immediately aware of that, unless the client was powered off or its OS crashed. You may like to enable frequent TCP keep-alives for the server to detect dead clients as soon as possible, if no data is being transmitted from the server to the clients. Same applies to the clients.
All communications between the server and the clients happen over TCP. Otherwise you would need to implement reliable messaging over UDP or use PGM, which can be a lot of work. Multicast UDP should only be used for server discovery, not bi-directional communication that requires reliable delivery.
The master client also connects to the server, possibly on another port, for control. The master client can discover all available servers (if there is more than one) and allow the user to choose which one to connect to.
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
Ive build a local multiplayer game (multiplayer over wlan network). Now, I want to add an online multiplayer feature..
Currently, the network communications consist mostly of "signals" (tcp/udp packets sent from game-host peer to the game-client peers). I would like to use this mostly signal based communication for my online multiplayer (because of performance and efficiency ), too . But, since the host peer is now replaced by a server there will be a lot problems with sending signals (NAT, firewall,...).
So is there good solution to implement these signals?
regards
there will be a lot problems with sending signals (NAT, firewall,...)_
What problems exactly?
Normally, the clients establish a TCP connection to the server and the server uses this TCP connection to communicate with the clients.
For UDP-based communication the clients use Internet Gateway Device Protocol to forward ports on the router, so that the server can send UDP datagrams to the clients.
Assuming your server is in public internet, not behind any NAT. All the clients must initiate the connection. Otherwise the server can't know clients credential and can't connect. As the server has no NAT it will accept connection from client. And this connection client must keep alive. So when server needs to send some data there should be no problem.
This will work for both UDP and TCP.
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?