Why does my SIP trunk to sipgate.de:5061 fail with "TCP connect failed"?

sipgate.de is Sipgate's web and marketing host (currently 217.10.79.9). Their SIP edge is a different pool, published under sip.sipgate.de (currently 217.10.77.242, 217.10.77.244, 212.9.44.242, 212.9.44.244). Only the sip.sipgate.de pool listens on TCP 5061 for SIP-over-TLS. Configure your outbound proxy to sip.sipgate.de and the connection succeeds. The registrar (SIP domain) stays sipgate.de because that is what appears in the AoR.

What port does Sipgate use for SIP over TLS?

TCP 5061 on sip.sipgate.de. Sipgate's own TLS configuration guide states this and their firewall documentation lists the same port. UDP 5060 remains available for the unencrypted path.

Why does Sipgate return 488 Not Acceptable Here on my calls?

When TLS signalling is on, Sipgate requires SRTP media. If the SDP does not carry a=crypto lines the answering side rejects the offer. Enable SDES SRTP on the trunk so every outbound INVITE advertises A-crypto and every answer accepts one.

Should I use the sips: or the sip: + transport=tls URI scheme?

Both work for authentication. The sip: + ;transport=tls form is safer for downstream in-dialog messages: sips: requires TLS hop by hop on every subsequent request in the dialog, which some carrier setups mishandle for ACK and BYE. sip: + ;transport=tls only mandates TLS on the trunk hop and leaves the downstream hops to their own transport.

Which IP ranges does Sipgate use for inbound calls?

Sipgate publishes 212.9.44.0/24 and 217.10.68.0/24 as their SBC outbound pools. Add both as inbound source CIDRs on the trunk so CodeB accepts inbound INVITEs from those ranges and drops anything else silently.

What does the log line "Attempting TCP connection ... to 217.10.79.9:5061" mean?

It means the bridge resolved the outbound proxy to 217.10.79.9 (Sipgate's web host) and is trying to open a TCP connection to :5061 there. That port is closed on the web host, so the handshake never completes and the trunk stays silent. Change the outbound proxy to sip.sipgate.de and the same log line will show 217.10.77.x or 212.9.44.x as the RemoteAddress and the handshake will complete.

Trunk configuration · SIP over TLS

Sipgate trunk over TLS — the sip.sipgate.de gotcha

If a Sipgate SIP trunk over TLS refuses to complete a REGISTER and you see nothing in the log but Attempting TCP connection to 217.10.79.9:5061, the trunk is pointed at the wrong host. This page documents the working configuration and the single field that fixes it.

Symptom

REGISTER goes out, nothing comes back

On the CodeB Sovereign SBC the bridge logs the REGISTER attempt cleanly, the outbound TCP connect is initiated, and then the trace goes silent. No 401 challenge, no TLS handshake completion, no REGISTER OK for Sipgate. Every other trunk on the same bridge (UDP or otherwise) completes its cycle in under a second.

REGISTER Sipgate scheme=sips Contact override: sips:...@<public-ip>:6061;transport=tls
<<<REQ REGISTER to=tls:217.10.79.9:5061 ruri=sips:sipgate.de:5061;transport=tls cseq=1
ConnectClientAsync SIP TLS Channel local end point of tls:0.0.0.0:6061 selected for connection to 217.10.79.9:5061.
Attempting TCP connection from tls:0.0.0.0:6061 to 217.10.79.9:5061.
— silence —

A one-line PowerShell test on the SBC confirms what the log is really saying:

PS> Test-NetConnection -ComputerName sipgate.de -Port 5061 -InformationLevel Detailed
WARNING: TCP connect to (217.10.79.9 : 5061) failed
PingSucceeded    : True
PingReplyDetails : 28 ms
TcpTestSucceeded : False

Root cause

sipgate.de is the web host. sip.sipgate.de is the SIP edge.

These are two different Sipgate hosts on two different IP pools. Only one of them listens for SIP.

sipgate.de A record

→ 217.10.79.9 — Sipgate's web / marketing host. No SIP.

sip.sipgate.de A records

→ 217.10.77.242

→ 217.10.77.244

→ 212.9.44.242

→ 212.9.44.244

Sipgate's SIP edge pool. UDP 5060 / TCP 5060 / TCP 5061 all listen here.

Sipgate's own TLS-configuration document explicitly separates the two roles:

Registrar / Domain = sipgate.de — the SIP realm that appears in the AoR, in the request URI, in the Contact header. This is a domain, not a target for TCP.
Outbound Proxy = sip.sipgate.de — the host your SBC actually opens a socket to. This is what DNS-resolves to the SIP edge pool.

If a trunk record has sipgate.de in both fields, DNS resolves the outbound proxy to 217.10.79.9, the OS opens a TCP SYN to :5061 on the web host, no listener answers, and the SBC receive loop waits until the app-layer Timer-B/F expires. From the outside it looks like Sipgate is broken. It is not; the trunk is pointed at Sipgate's marketing IP.

Fix

Split the two fields

On trunks-admin.html, open the Sipgate trunk record and set the fields as follows.

Label	`Sipgate` — used in logs and CDRs only.
Host	`sipgate.de` — the registrar / SIP domain. Do not change this.
Port	`5060` — the well-known SIP port on `sipgate.de`. Even with TLS enabled, this is the port the request URI will name.
Register on Startup	ON
Register Expiry (s)	`600`
TLS (SIPS)	ON
TLS Port	`5061` — Sipgate's dedicated SIP-over-TLS port. Applies to the outbound proxy, not the registrar.
Outbound Proxy	`sip.sipgate.de` — this is the field that fixes the "TCP connect failed" symptom.
SIPS Scheme	`sip: + transport=tls` — not the bare `sips:` scheme. See FAQ below for why.
SDES SRTP	ON — mandatory when TLS is on. Without it, Sipgate answers calls with `488 Not Acceptable Here`.
Send Contact with External IP	ON — makes the Contact URI advertise your public NAT address so in-dialog requests from Sipgate can reach you.
Session-Timer (RFC 4028)	ON, outbound advertise. Refreshes long-running dialogs and detects half-broken TLS connections.
Auth Realm Override	empty — the realm is server-provided in the 401 challenge.
Outbound Identity headers	`FROM` + `PAI`. Leave `PPI` and `RPID` off; Sipgate ignores them.
Inbound Source CIDRs	`212.9.44.0/24` and `217.10.68.0/24` — Sipgate's outbound SBC pools. Inbound INVITEs from any other source are dropped before they hit the routing engine.
Username / Password	Per contract with Sipgate — issued in your account portal.
Numbers (DIDs)	Per contract with Sipgate — each number in E.164 form with a leading `+`.

The one field that matters most is the Outbound Proxy. Everything else on this page has been the same on our working trunk for years. The trap is that a fresh trunk record inherits the registrar host into the proxy field by default, which is fine for most carriers but fatal for Sipgate.

Verify

Prove the socket works before you restart the bridge

Once the trunk is saved, before restarting the CodeB bridge run this on the SBC host from PowerShell:

Test-NetConnection -ComputerName sip.sipgate.de -Port 5061 -InformationLevel Detailed

You should see:

ComputerName        : sip.sipgate.de
RemoteAddress       : 217.10.77.242   (or 217.10.77.244 / 212.9.44.242 / 212.9.44.244)
RemotePort          : 5061
PingSucceeded       : True
TcpTestSucceeded    : True

If TcpTestSucceeded is True, the OS-level socket path works. Restart the bridge; the next boot log should contain REGISTER OK for Sipgate expires=600s within one second of the Attempting TCP connection line.

If it still fails, the OS itself is blocking outbound to Sipgate's edge pool. Check the outbound firewall on the SBC and the DNAT / MASQUERADE state on your edge router. Sipgate does not block outbound TLS from any source IP by default, so the block is on your side.

Optional

Raw TLS handshake test with openssl

Confirms cert chain and SNI in one shot. From WSL or Git-Bash on the SBC:

openssl s_client -connect sip.sipgate.de:5061 -servername sipgate.de -tls1_2 <<<""

Expect a CN=*.sipgate.net (or similar) leaf certificate with a valid chain, and a completed handshake in under a second. If the handshake fails, check the SNI value — it must be sipgate.de (the registrar domain), not sip.sipgate.de. The bridge does this automatically; the flag is here in case you are testing manually.

Frequently asked

Why is TCP:5061 on 217.10.79.9 closed when TCP:5061 on 217.10.77.x is open?

Because those are two separate Sipgate services on two separate IP pools. sipgate.de serves the Sipgate website. sip.sipgate.de fronts their SIP edge. They share a brand, not a listener. This is the same pattern most large SIP carriers use — the marketing IP and the SIP edge IP are always different, and always documented separately.

Why do I need to keep the Registrar as sipgate.de if the socket goes to sip.sipgate.de?

Because the registrar / domain is what appears in the SIP AoR (user@sipgate.de) and in the request URI, not the target of the TCP connection. Sipgate's account records key on the sipgate.de domain; if you replace it with sip.sipgate.de in the AoR, the registrar sees an unknown domain and returns 404 Not Found. The two fields describe two different things: the URI domain (registrar) and the outbound target (proxy). Only the proxy is a socket destination.

Should I use the sips: scheme or sip: + transport=tls?

Use sip: + ;transport=tls. Both authenticate the TLS trunk hop identically. The sips: scheme additionally invokes RFC 3261 §26.2.2 and requires TLS on every downstream hop of the resulting dialog. Sipgate's own edge is TLS-clean, but some in-dialog paths through their platform have historically dropped ACK and BYE that carry the sips-only constraint. sip: + ;transport=tls gives you the same on-the-wire TLS to Sipgate without the sips-anywhere requirement, and is what CodeB has been shipping to Sipgate reliably for years.

What does 488 Not Acceptable Here mean on a Sipgate call?

Almost always missing SRTP. When TLS signalling is on, Sipgate requires SRTP media in the SDP. If your a=crypto line is missing or the offered suite is not supported, Sipgate answers 488. Turn on SDES SRTP on the trunk and the outbound INVITEs will carry a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:..., which Sipgate accepts.

Which IPs should I whitelist for inbound calls?

Sipgate publishes 212.9.44.0/24 and 217.10.68.0/24 as their outbound SBC pools. Add both as inbound source CIDRs on the trunk and CodeB verifies them before accepting the inbound INVITE. Anything from outside these ranges is dropped silently to prevent inbound spoofing.

Do I need to open TCP:5061 for inbound on my SBC?

Not for Sipgate specifically. Sipgate honours RFC 5923 connection reuse, so responses (including in-dialog requests) come back on the outbound TLS socket you opened. That said, CodeB does open its public SIPS listener on TCP:6061 anyway, and the Contact URI it advertises to Sipgate points at that port. If a connection ever needs to be re-established from Sipgate's side after the outbound TLS lifecycle ends, it needs to be able to reach TCP:6061 on your public IP via the router's DNAT.

My log says liveTlsConns=-1 in the SIPS-trunk-diag line. Is that a problem?

No. That is a cosmetic marker meaning the bridge's diagnostic block could not reflect into the internal TLS connection dictionary on our CodeBSipTlsChannel subclass. It has no effect on trunk operation. Trunks continue to open, authenticate and pass calls normally.

How do I check the current DNS mapping in case Sipgate changes it?

Run:

Resolve-DnsName sipgate.de     -Type A
Resolve-DnsName sip.sipgate.de -Type A

Or from bash:

dig +short sipgate.de A
dig +short sip.sipgate.de A

The DNS values in this document are the ones observed on 2026-09-19. Sipgate may add or rotate IPs; the split between the two hostnames is the stable contract.

SIPS — SIP-over-TLS (RFC 5630) on the CodeB Sovereign SBC — the platform-level story: per-tenant SNI, ACL gate, /sip-tls/health.
Trunk REGISTER log — the operational view of your trunks.
Outbound caller-ID with PAI / PPI / RPID — the identity headers on outbound INVITEs.
Connect MicroSIP — a softphone-side companion how-to.