Da arbeitet wohl jemand an einer Neu-Definition von Nachtreten. ATO beschreibt ein Phänomen, dem man weiter nachgehen sollte. Der Ausweich auf TCP ist nämlich auch nur ein Workaround. Sein Phänomen könnte jederzeit nicht nur in UDP sondern auch in TCP auftreten.
Gegenbeispiel: 1&1 verlangt, dass im SIP der richtige Port seht. 1&1 schickt stur seine Antwort dorthin. Nur wenn man rport aktiviert, schickt 1&1 die Antworten auf den Quell-Port, also den Egress-Port des Routers. Später – bei eingehenden Anrufen – gehen diese auch mit rport stur an den SIP-Header Contact. Steht in diesem Header der falsche Port, dann hat man Pech. Das hat zwei Gründe: DrayTek verwendet in IPv4 einen anderen Port als der VoIP/SIP-Client; Nachrichten werden um-ge-mappt. Asterisk verwendet „received : rport“ nicht, um den eigenen SIP-Header Contact umzuschreiben. Weil Asterisk auch kein STUN kann, bleibt Dir nur das SIP-ALG (oder Port-Forwarding oder … oder …).
Über Ostern habe ich mir einen DrayTek Vigor2865 mit DrayOS 4.2 kommen lassen. Weil ich vor Ort war, konnte ich den WAN-Port in Wireshark mitschneiden. Ich fand keine Möglichkeit dieses Um-mappen zu vermeiden: Hoher Port, niedriger Port, Hardware-Beschleunigung … nix half. Klar, Port-Forwarding oder DMZ ginge. Ansonsten nimmt mein DrayTek das Datenpaket und schickt es auf einem anderen Port raus. SIP-ALG aktiviert, DrayTek schrieb die Request-Line und den Contact um, und 1&1 klappte „perfekt“. Spannend beim DrayOS SIP-ALG: Es achtet sowohl auf Quell- als auch auf Ziel-Port. In musste also nicht den Port auf den Quell-Port meines VoIP/SIP-Clients ändern, weil der Ziel-Port ja weiterhin 5060 ist.
Lange Rede kurzer Sinn: DrayTek macht nichts falsch. Jedenfalls sehe ich keinen Fehler. Es ist auch bei anderen Routern nicht unüblich, den Port um-zu-mappen. In Extremfällen macht das auch AVM FRITZ!OS – nur merken das Viele nicht und sind kurz nicht erreichbar. Daher, ATO, meine Tipps an Dich, DrayTek ist die falsche Baustelle:
Auf jeden Fall würdest Du der Community einen großen Gefallen tun, wenn Du meine beiden Tipps beherzigen würdest. Ja, viel Arbeit.
Dann war meine Erklärung undeutlich … wenn Dein Anbieter den SIP-Header Contact wörtlich nimmt, dann hast Du mit einem Asterisk einfach nur Pech. Daher ignorieren viele Anbieter „IP-Adresse : Port“ in jenem Header und ersetzen diese durch die Angaben, die Du im received bzw. rport siehst. Die Frage ist daher: Warum macht das die Telekom Deutschland an diesem Anschluss anders?
Gegenbeispiel: 1&1 verlangt, dass im SIP der richtige Port seht. 1&1 schickt stur seine Antwort dorthin. Nur wenn man rport aktiviert, schickt 1&1 die Antworten auf den Quell-Port, also den Egress-Port des Routers. Später – bei eingehenden Anrufen – gehen diese auch mit rport stur an den SIP-Header Contact. Steht in diesem Header der falsche Port, dann hat man Pech. Das hat zwei Gründe: DrayTek verwendet in IPv4 einen anderen Port als der VoIP/SIP-Client; Nachrichten werden um-ge-mappt. Asterisk verwendet „received : rport“ nicht, um den eigenen SIP-Header Contact umzuschreiben. Weil Asterisk auch kein STUN kann, bleibt Dir nur das SIP-ALG (oder Port-Forwarding oder … oder …).
Über Ostern habe ich mir einen DrayTek Vigor2865 mit DrayOS 4.2 kommen lassen. Weil ich vor Ort war, konnte ich den WAN-Port in Wireshark mitschneiden. Ich fand keine Möglichkeit dieses Um-mappen zu vermeiden: Hoher Port, niedriger Port, Hardware-Beschleunigung … nix half. Klar, Port-Forwarding oder DMZ ginge. Ansonsten nimmt mein DrayTek das Datenpaket und schickt es auf einem anderen Port raus. SIP-ALG aktiviert, DrayTek schrieb die Request-Line und den Contact um, und 1&1 klappte „perfekt“. Spannend beim DrayOS SIP-ALG: Es achtet sowohl auf Quell- als auch auf Ziel-Port. In musste also nicht den Port auf den Quell-Port meines VoIP/SIP-Clients ändern, weil der Ziel-Port ja weiterhin 5060 ist.
Lange Rede kurzer Sinn: DrayTek macht nichts falsch. Jedenfalls sehe ich keinen Fehler. Es ist auch bei anderen Routern nicht unüblich, den Port um-zu-mappen. In Extremfällen macht das auch AVM FRITZ!OS – nur merken das Viele nicht und sind kurz nicht erreichbar. Daher, ATO, meine Tipps an Dich, DrayTek ist die falsche Baustelle:
- Öffne bei Asterisk einen Feature-Request, damit received und rport ausgewertet und der SIP-Header Contact umgeschrieben werden.
- Haue die Telekom Deutschland an – ja, die werden als erstes die Leitung durchmessen – und frage dort nach, warum dieser Anschluss bei SIP-over-UDP den SIP-Header Contact wörtlich nimmt. Ob das Absicht oder ein Konfigurationsfehler ist.
Auf jeden Fall würdest Du der Community einen großen Gefallen tun, wenn Du meine beiden Tipps beherzigen würdest. Ja, viel Arbeit.
Bedeuten … Problem ist – Stand heute, nach 23 Jahren – dass Asterisk (immer noch) nicht als reiner SIP-Client hinter einer Firewall gedacht ist. Klar kann man jetzt Firewalls verteufeln … oder anfangen dem Asterisk-Team zu verklickern, dass es eben auch Nutzer gibt, die nach außen nur einen SIP-Client und nicht auch noch einen SIP-Server brauchen. Aktuell geht mit Asterisk vieles zufällig dann doch. Die Frage ist, ob man als Betreiber immer rennen möchte, wenn es sich aus-ge-zufallt hat. Daher die (ganz) obigen Tipps, den Netzübergang so zu gestalten, dass nicht Asterisk diesen überwinden muss.
Zuletzt bearbeitet:
