Help Needed: Outgoing SIP REGISTER vanishes inside Edgeport, despite connectivity

[dwulfing]

Hi everyone,

I'm facing a tough routing issue with a Docker-based Routr setup and would appreciate any insights.

The Goal:
My Routr instance needs to register as a client with an external trunking provider (sip1.budgetphone.nl).

The Problem:
The outbound REGISTER request, initiated by the registry service, is correctly created by the requester and sent to the edgeport container. However, the packet never leaves the host. It's not visible in tcpdump on the external interface and seems to be silently dropped by the edgeport.

What I've already confirmed and ruled out:

• Ingress works perfectly: External SIP clients can register with my server successfully.
• Container Networking is OK: From within the edgeport container, both nslookup sip1.budgetphone.nl and ping 8.8.8.8 work perfectly. The container has DNS resolution and basic outbound connectivity.
• Routr Configuration:
  • The edgeport is configured to forward all traffic to the dispatcher (spec.processor.addr: dispatcher:51901), as required by the docs.
  • The internal Docker network (172.18.0.0/16) is added to spec.localnets in edgeport.yaml, and the logs confirm this config is loaded correctly.
  • The registry correctly points to the edgeport as its required edgePorts gateway.

The Core Mystery:
The edgeport receives the REGISTER request from a trusted internal source (requester). The destination (sip1.budgetphone.nl) is clearly external. Per its configuration, it should forward this message to the dispatcher. But the message simply disappears without any trace in the logs of edgeport, dispatcher, or connect.

Why is the edgeport not forwarding the message to the dispatcher as configured, and also not sending it to the external network? It feels like it's getting caught in a logical black hole.

Has anyone encountered a similar issue or has an idea what internal logic within the Edgeport could cause it to silently drop a message under these specific conditions (request from a localnets source to an external SIP URI)?

Thanks for any help!

Deutsche Übersetzung

Hallo zusammen,

ich stehe vor einem kniffligen Routing-Problem mit meinem Docker-basierten Routr-Setup und würde mich über jeden Einblick freuen.

Das Ziel:
Meine Routr-Instanz soll sich als Client bei einem externen Trunk-Anbieter (sip1.budgetphone.nl) registrieren.

Das Problem:
Die vom registry-Dienst initiierte ausgehende REGISTER-Anfrage wird korrekt vom requester erstellt und an den edgeport-Container gesendet. Allerdings verlässt das Paket niemals den Host. Es ist nicht im tcpdump auf dem externen Interface sichtbar und scheint vom edgeport stillschweigend verworfen zu werden.

Was ich bereits bestätigt und ausgeschlossen habe:

• Eingehender Verkehr funktioniert perfekt: Externe SIP-Clients können sich erfolgreich an meinem Server registrieren.
• Netzwerkkonfiguration des Containers ist OK: Innerhalb des edgeport-Containers funktionieren sowohl nslookup sip1.budgetphone.nl als auch ping 8.8.8.8 einwandfrei. Der Container hat also DNS-Auflösung und grundlegende ausgehende Konnektivität.
• Routr-Konfiguration:
  • Der edgeport ist laut Doku so konfiguriert, dass er allen Verkehr an den dispatcher weiterleitet (spec.processor.addr: dispatcher:51901).
  • Das interne Docker-Netzwerk (172.18.0.0/16) ist in der edgeport.yaml zu spec.localnets hinzugefügt, und die Logs bestätigen, dass diese Konfiguration korrekt geladen wird.
  • Der registry-Dienst verweist korrekt auf den edgeport als sein benötigtes edgePorts-Gateway.

Das zentrale Rätsel:
Der edgeport empfängt die REGISTER-Anfrage von einer vertrauenswürdigen, internen Quelle (requester). Das Ziel (sip1.budgetphone.nl) ist eindeutig extern. Gemäß seiner Konfiguration sollte er diese Nachricht an den dispatcher weiterleiten. Aber die Nachricht verschwindet einfach ohne jede Spur in den Logs von edgeport, dispatcher oder connect.

Warum leitet der edgeport die Nachricht weder an den dispatcher weiter (wie konfiguriert) noch sendet er sie ins externe Netzwerk? Es fühlt sich an, als würde sie in einem logischen schwarzen Loch verschwinden.

Ist jemand schon einmal auf ein ähnliches Problem gestoßen oder hat eine Idee, welche interne Logik im Edgeport dazu führen könnte, eine Nachricht unter diesen spezifischen Bedingungen (Anfrage von einer localnets-Quelle an eine externe SIP-URI) stillschweigend zu verwerfen?

Danke für jede Hilfe