Best way to create a network link between mobile devices and main office

I have some max br1s in the field that are used at events to stream video.

We currently use sfc protect to utilize a cellular connection along with any ethernet wan’s we can get and wifi wans.

This works ok, but we have a peplink in our main office where we stream the video to. Would it be more beneficial to have those units to connect to that router through a vpn to stream the video that way? We’re on average running 5-10mb streams to our ingest server then it gets distributed out from there. We use srt which is pretty forgiving but sometimes we have issues with packet loss.

I’m thinking if instead of going through the sfc endpoint and then to the office if we could go straight to the office, that would yield better results.

Another option would be to create an sfc endpoint at the office.

I’m not sure what the best way to make this work better for us.

I have several peplink devices and they are all great but even in 2024 its hard at times to get a solid connection. But our business is streaming and we need to do anything we can to make sure it’s 100% up.

I’m thinking about getting starlink devices for the worst spots but even then we’d need to hit our servers so I think the vpn or an sfc would be the way to go.

thoughts?

What is the model of Peplink you have at the office?

What is the WAN connectivity you have at the office in terms of bandwidth and do you have public IPs available?

How many BR1s do you have in the field, how many are in use concurrently at any one time?

Do you use InControl to manage all the devices at the moment?

Depending on the answers to the above might change what is possible for you.

Other things to consider would be redundancy, if you only have a single ISP at the office or single Peplink router is a pretty large single point of failure - do you need to mitigate that risk?

Starlink is useful for this, but do not rely on it alone for streaming but in combination with SpeedFusion and some other connectivity it can provide a useful service.

Building out your own VPN across the remote sites is certainly not a bad idea, it potentially adds other value to how you operate things too as it would if designed and configured correctly provide you with a nice way of accessing all of your remote equipment as well as potentially carrying other traffic for you (comms, talkback etc. could all be funnelled through that VPN).

Depending on your appetite you could go as far as looking at how your entire system is put together, especially if redundancy and continuity of service is important to you - as a pretty extreme example we’ve designed some systems for clients where the entire production workflow is basically inside AWS using Peplink routers at their MCR and for remote sites and then using FusionHubs in the cloud to provide a means to join it all together, but that may not be appropriate depending on your workflow :slight_smile:

It might be worth seeing if there is a local friendly Peplink partner in your neighbourhood that would work with you to come up with something based on what hardware you have at the moment and your requirements.

We have a B One there. I do have a balance 20x at my home office but the b one was a better price and had the connectivity we needed there.

It’s on a symmetrical 1gb pipe with a block of ips available.

I have 4 BR1s in the field. They usually are only up one at a time but at times we could have all 4 up. Depending on how the day goes. We might have 4 live events at once. It’s rare at the moment but hoping it becomes more common. :slight_smile:

The longer term plans include us shipping a br 1 with a video capture encoder to a client and they just feed their video in to that and the rest is handled by our infrastructure. Kind of like a live u but more flexible.

We do use incontrol to manage everything at the moment.

We already do have a redundancy plan in place by having the ability to spin up our ingest servers in data centers on rented servers. But we are currently in the process of installing our first dc which will have a peplink at it as well. Ultimately everything will go there once its done.

Then the plan (when budget becomes available) is to expand in to a second dc for redundancy. Not only for our ingest streams but for our minio storage. Right now we back up to s3 but that’s becoming expensive.

I used to be in radio engineering, which is how I found peplink. I had peplink routers at every tower we managed and had dsl with cellular links and a mesh network between all the towers and the main studio. It worked well but was kind of slow.

When I moved in to this venture I’ve continued using peplink routers because it’s always been a solid brand to work with. I just usually stuck with the lower end models. We’re looking at putting a b one or a balance 20x in the datacenter because we will only have a gigabit link to start but as we grow, I will upgrade to a 10gb link and at that point either invest in a better peplink or go back to ubiquiti that I used to use.

If I can find a way to make the most stable link from the field to the office, I’d rather stick with peplink.

So the B-One as long as it is kept under PrimeCare gives you 5x SpeedFusion VPN peers.

As you have a block of public IPs available (and assuming one is configured direclty on the WAN of your B-One) you can have the remote sites build their SFVPN direclty to the B-One.

That would cut out the need to go through SFC, it would also mean in theory that you don’t need to expose any ingest ports in your server directly to the internet as the encoders behind the BR1s will be able to reach it via the VPN.

B-One is good value, but it is somewhat low end / entry level and its performance is as such where SpeedFusion throughput is concerrned, that said it can do ~200Mbps with tunnel encryption enabled, more without so it should be adequate for your needs depending on your other traffic (those figures on the datasheet are generaly quoted in isolation i.e. to get ~200Mbps encrypted VPN through the B-One you would be maxing out its CPU).

Ideally you need to come up with an IP schema for each of your remote sites that makes them distinct and unique and they should not overlap to avoid needing to use NAT within the SFVPN network.

I.e.

B-One = 192.168.0.0/24
BR1-1 = 192.168.1.0/24
BR1-2 = 192.168.2.0/24
BR1-3 = 192.168.3.0/24
BR1-4 = 192.168.4.0/24

Or something like that, you might want to consider how your system might grow in the future and whether additional subnets per remote site for other uses might be worth building in at this point.

For your encoders and other devices if they move around between remote kits you could do DHCP reservations for them to make the setup process a bit easier, or just accept you would need to do some amount of staging / config on them.

In terms of the config for the above I’d manage everything I could through Ic2 personally, probably a group for each device / location, configure all the IP subnets and so on then do the SF config and once all the tunnels are up and running start pruning routes and set up appropriate firewall rules to isolate devices as necessary.

Going forward if you did add a remote DC location you could use a FusionHub VM to bring traffic into it, likewise if you upgraded to a 10gb circuit at your office and wanted to use another vendor for the mian router you could use a FusionHub VM to terminate the SFVPN tunnels onto and then route traffic from that into the rest of your network (this is how we do it in a lot of setups).

1 Like