Connection Timeout is usually caused by the fact that the 2 EP cannot create the SRT connection on the selected UDP port. This can be caused either by a firewall configuration problem, or that the UDP port is currently being occupied. A previous connection to this port may also cause the port not to be released if the BirdDog Cloud worker is not properly being shut down. If the latter is the issue try to use a different port (enter manually the next port from what is being selected in auto mode) or restart the BirdDog Cloud Daemon.

If the problem seems to be firewall related:

When setting up a connection between 2 endpoints using SRT you have some choices on how the SRT connection is going to be set up:

1. Rendezvous
2. Caller --> Listener
3. Listener --> Caller

The default is connection method is Rendezvous, but this can be changed in the Company --> Overview section.

Using Rendezvous is great as it penetrates firewalls provided that the firewall supports UDP Hole punching. However, many firewalls do not support this. That means that the 2 endpoints cannot reach each other, hence the "Connection Time Out". For more information please download our Networking document found under the Download section (https://app.birddog.cloud/downloads)

However, SRT supports two other methods (or one, just reversed) and here is how Caller --> Listener should be set up in your firewall to get this to work.

The "Caller" side should be placed on the network where you do not have control over the firewall. This side will initiate a connection from the inside of the firewall (Northbound) and that is usually ok.

The "Listener" side should be put behind the firewall you can control so you can make sure that the SRT UDP traffic can be port forwarded to the local ip address of the endpoint that is the Listener. This can be different to set up for different firewalls, but the principle is the same, the outside UDP port has to hit the local ip address of the listener endpoint.

So that does mean a firewall opening (Southbound) in one side of this connection to allow for the connection (or connections, one UDP port pr SRT connection). 

What is practical with SRT is that you can reverse what endpoint you want to be Caller and Listener enabling the video direction to go either way.

Example: You are on a location outside your facility and want to send video from this location back to your main facility. Most likely you do not have control over the firewall on this outbound location so you will put the Caller there and in this case that will be your TX (Transmitting) endpoint. Then you put your RX (Receiving) endpoint as Listener behind the firewall you can control at your facility. So far so good, but what if you want to send video the other way? Well then the RX is actually located behind the firewall you cannot control. Then you use Listener --> Caller. As we see the Caller can initiate the SRT UDP connection even if it is the RX (Receiver of the video stream).