BaccaConnect

BaccaConnect sends audio directly between your computer and your session partner over UDP (port 4464). This is called a peer-to-peer connection — the audio never passes through our servers.

When you start a session, both sides discover their network addresses and try to reach each other. The first address that works becomes the audio path. This usually takes less than a second.

If both sides can't reach each other directly (usually because of firewalls or NAT), BaccaConnect falls back to a TURN relay hosted by Cloudflare. Your audio is still encrypted end-to-end — the relay can't listen in — but it adds a small amount of latency and the traffic costs us money.

The connection badge in the top bar shows whether you're on a direct connection or a relay. Direct is always better.

BaccaConnect needs:

• UDP port 4464 — open for inbound and outbound traffic
• ~2.5 Mbps upload and download (for stereo 24-bit @ 48kHz)
• Low jitter — a stable connection matters more than raw speed

A wired Ethernet connection is strongly recommended. WiFi adds variable latency (jitter) that causes audio glitches.

Most home and studio networks use NAT (Network Address Translation) — your router has one public IP address shared by all your devices. When someone outside your network tries to send audio to your computer, the router doesn't know which device to forward it to. Port forwarding tells the router: "send anything arriving on UDP port 4464 to this specific computer."

Without port forwarding, the other side's probe packets can't reach you, and BaccaConnect falls back to the TURN relay.

The steps are similar on most routers:

1. Find your computer's local IP address

   # macOS — Terminal
   ipconfig getifaddr en0
   
   # Windows — Command Prompt
   ipconfig | findstr "IPv4"

   You'll see something like 192.168.1.100.
2. Log into your router's admin page (usually 192.168.1.1 or 192.168.0.1 — check your router's manual)
3. Find the Port Forwarding section (sometimes called "Virtual Server", "NAT", or "Applications")
4. Create a new rule:

   Field	Value
   Name / Description	BaccaConnect
   Protocol	UDP
   External Port	4464
   Internal Port	4464
   Internal IP	Your computer's local IP (e.g., 192.168.1.100)

5. Save and apply the rule

UniFi / Ubiquiti

1. Open the UniFi controller → Settings → Firewall & Security → Port Forwarding
2. Click Create New Port Forward
3. Name: BaccaConnect, Port: 4464, Forward IP: your Mac's IP, Protocol: UDP
4. Save

Netgear Nighthawk

1. Go to 192.168.1.1 → Advanced → Advanced Setup → Port Forwarding
2. Click Add Custom Service
3. Service Name: BaccaConnect, Protocol: UDP, External Port: 4464, Internal IP: your Mac's IP
4. Apply

TP-Link

1. Go to 192.168.0.1 → Advanced → NAT Forwarding → Virtual Servers
2. Click Add
3. Service Type: BaccaConnect, External Port: 4464, Internal IP: your Mac's IP, Protocol: UDP
4. Save

Apple AirPort (Time Capsule / Express)

1. Open AirPort Utility → select your router → Edit → Network tab
2. Click the + under Port Settings
3. Description: BaccaConnect, UDP Port: 4464, Private IP: your Mac's IP
4. Update

Eero

1. Open the Eero app → Settings → Network Settings → Port Forwarding
2. Tap Add a port forward
3. Select your Mac, Port: 4464, Protocol: UDP
4. Save

Generic / ISP-Provided Router

Look for "Port Forwarding", "Virtual Server", "NAT Rules", or "Applications & Gaming" in your router's admin panel. The fields are always the same: UDP, port 4464, forward to your Mac's local IP.

After setting up the port forward, you can test it:

1. Start BaccaConnect and make sure the agent is running
2. Ask someone outside your network to start a session with you
3. Check the connection badge — it should show Direct not Relay

You can also check from the command line on another machine (or ask a colleague to run this):

# From OUTSIDE your network, test if UDP 4464 is reachable
# Replace YOUR_PUBLIC_IP with your public IP address
nc -u -z YOUR_PUBLIC_IP 4464

With IPv6, every device on your network gets its own globally routable address. There's no NAT. No port forwarding needed. Your computer is directly reachable from the internet.

BaccaConnect automatically discovers your IPv6 addresses and tries them during connection setup. If both sides have IPv6, the probe typically succeeds in milliseconds — faster than IPv4 with NAT.

On your Mac, open Terminal and run:

# Check for IPv6 addresses
ifconfig en0 | grep "inet6"

# Look for a line like:
# inet6 2001:db8:1234::5678 prefixlen 64
# (starts with 2xxx: — that's a global IPv6 address)

If you see an address starting with 2 or 3, you have a globally routable IPv6 address. Addresses starting with fe80: are link-local only (LAN, not internet-reachable).

You can also visit test-ipv6.com to check your IPv6 connectivity from a browser.

Usually, no. If your ISP provides IPv6 and your router supports it, your Mac gets a global IPv6 address automatically. BaccaConnect discovers it and uses it.

The only thing you might need is a firewall rule allowing inbound UDP on port 4464. Since there's no NAT with IPv6, you don't need port forwarding — just an access control rule (ACL):

macOS Firewall

macOS's built-in firewall is application-based, not port-based. When BaccaConnect first tries to listen on a port, macOS asks "Allow incoming connections?" — click Allow. That's it.

Router Firewall (IPv6)

Some routers block all inbound IPv6 by default. If your sessions are falling back to relay despite having IPv6, check your router for an IPv6 firewall section and add a rule:

CGNAT (Carrier-Grade NAT) means your ISP puts you behind a second layer of NAT — even before your own router. You share a public IP address with dozens or hundreds of other customers. Port forwarding on your router has no effect because the ISP's NAT sits in front of yours.

To check if you're behind CGNAT:

1. Find your router's WAN IP (in the router admin page, look for "WAN IP" or "Internet IP")
2. Find your public IP: run curl -s ifconfig.me in Terminal
3. If they're different, you're behind CGNAT.

Common CGNAT IP ranges (your router's WAN IP will be in one of these):

100.64.0.0  – 100.127.255.255   (RFC 6598 — CGNAT block)
10.0.0.0    – 10.255.255.255     (sometimes used by ISPs)
172.16.0.0  – 172.31.255.255     (sometimes used by ISPs)

From best to worst:

1. Enable IPv6 Best
   Many ISPs that use CGNAT for IPv4 still provide full IPv6. Check your router settings — IPv6 might just need to be turned on. With IPv6, CGNAT doesn't matter because there's no NAT at all.
2. Ask your ISP for a public IPv4 address Good
   Some ISPs will assign you a dedicated public IP on request (sometimes called a "static IP" add-on). This usually costs $5-15/month but eliminates CGNAT entirely.
3. Use a different ISP connection Moderate
   If you have a backup connection (different ISP, business line), check if that one has a public IP. Business internet plans almost never use CGNAT.
4. Accept TURN relay Works
   If none of the above options work, BaccaConnect's TURN relay will handle your sessions. The audio is still encrypted, and the added latency (2-4ms per hop) is usually acceptable. Many professional sessions run fine over relay.

1. Check for CGNAT — compare router WAN IP to curl -s ifconfig.me
2. Check port forwarding — is UDP 4464 forwarded to the right local IP?
3. Check for IPv6 — run ifconfig en0 | grep inet6
4. Check firewall — macOS firewall should allow BaccaConnect incoming connections
5. Check your router's firewall — some routers have a separate "SPI firewall" or "DoS protection" that blocks unsolicited inbound UDP
6. Try both wired and WiFi — some WiFi access points have client isolation that blocks peer-to-peer

Bandwidth is almost never the issue (BaccaConnect uses ~2.5 Mbps). Audio quality problems are usually caused by:

• WiFi — switch to Ethernet. WiFi jitter is the #1 cause of audio glitches.
• Network congestion — close streaming, cloud sync, backups, software updates
• Buffer size too small — try increasing from 128 to 256 or 512 samples in BaccaConnect settings
• VPN — disable VPNs during sessions. They add latency and jitter.
• QoS settings — if your router has QoS (Quality of Service), prioritize UDP traffic on port 4464

Not bad — just not ideal. TURN relay adds 2-4ms of latency per hop and routes your audio through Cloudflare's network. The audio is still AES-256 encrypted end-to-end — the relay sees only ciphertext.

Many professional sessions run perfectly fine over relay. But if you can get a direct connection by port-forwarding or enabling IPv6, you'll get lower latency and a more consistent experience.