Vodafone IP SIP-Trunk am COMmander Basic.2

[Toni76]

Hallihallo,

eine kleine Ergänzung: Ich bin auch gerade dabei, unsere COMmander Basic.2 auf IP bei Vodafone umzustellen. Sie läuft seit momentan 14,5 Jahren einwandfrei mit Vodafone-ISDN und hat die 8er-VoIP-Karte drin. Heute habe ich die Testzugangsdaten bekommen und musste als VoIP-Neuling zwar erstmal ein bisschen experimentieren und die VoIP-Konfigurationsoptionen von Vodafone und der Anlage kennenlernen, aber nach etwa zwei Stunden läuft es jetzt super mit rein- und raustelefonieren auf der Testnummer (mit FRITZ!Box als NAT-Router). Verschlüsselung (SRTP) habe ich noch nicht aktiviert, das probiere ich vielleicht später noch, ob das auch funktioniert.

Also ich will eigentlich nur sagen, man braucht nix anderes, die COMmander Basic.2 funktioniert.

 

[PJD Berlin]

Hi Toni!

Das klingt toll! Hast Du denn einen ISDN oder Anlagenanschluss und jetzt neu IP- oder SIP-Trunk? Vielleicht kannst Du ja deine Daten geschwärzt hier zeigen, falls noch Jemand so einen Anschluss umstellen will.

Liebe Grüße

Philipp

 

[Toni76]

Wir haben einen Anlagenanschluss mit 2 ISDN-Leitungen (4 Kanäle) und jetzt dann bald neu 4 SIP-Kanäle mit 2-stelliger Durchwahl, also SIP-Trunk. Unten die Einstellungen dazu, in eckigen Klammern [] sind die Zugangsdaten von Vodafone im Testmodus. Die Testdaten muss ich dann später bei Aktivierung gegen die echten ersetzen und die Amtzugangsziffer muss vermutlich wieder eine 0 werden.

Anbieter
Domain = [SIP Domain]
Registrar = <aus>
NAT-Traversal = aktiviert
NAT-Keep-Alive = 35s
Outbound-Proxy = manuell [VF-SBC] Port 5060
SIP-Port = 5062
SIP-Session-Timer = 30m
Nur Blockwahl = <aus>
SIPS = <aus>
Stammzertifikat = <keins>
SRTP-Modus = deaktiviert
NAT-Traversal = deaktiviert
DTMF-Signalisierung = Outband (RFC 2833)
Echokompensation = <ein>
Jitterbuffer = 50ms
Codec-Einstellungen = G.711, G.729, G.723
STUN-Server = <aus>
Unteranlagenbetrieb = <aus>
Audio durchschalten = <aus>
T.38 = <ein> RFC-konform <oder aus, wenn kein Faxgerät vorhanden>
Format eigenen/angerufenen Rufnummer = +49...
Art der Rufnummernübermittlung = RFC3325 mit P-Asserted-Identity
Methode der Rufnummernunterdrückung = Anonymous
Übermittelter Rufnummer vertrauen = <aus, oder nach Belieben>
Unbekannte Rufnummern internationalisieren = <aus, oder nach Belieben>
Art der Auswertung = Standard <evtl. funktioniert auch RFC3325>

Account (Anlagenanschluss)
Landesvorwahl = 0049
Ortsvorwahl = 089 <bei mir München>
Land = Deutschland
Amtzugangsziffern = 99 <oder irgendeine andere unbenutzte interne Nummer>
Benutzername = [SIP Username] <bei mir Test-Stammnummer mit Ortsvorwahl>
Passwort = <irgendwas, wird ignoriert>
Authentifizierungs-ID = <leer>
Anlagenrufnummer = [Test-Rufnummer] <Test-Stammnummer ohne Vorwahl>
Durchwahlblock (DDIs) = 0 bis 9 <bei mir von Vodafone für Test-Nummer so festgelegt>

FRITZ!Box
Zwei Port-Forwardings für TCP und UDP jeweils von 5060 bis 5068 (4 Kanäle, 2 Ports je Kanal) zur internen IP-Adresse der Anlage. Der SIP-Port muss nach außen 5060 sein, nicht 5062 wie oben bei Anbieter eingestellt. Da wir schon einige interne IP-Telefone haben, waren dafür 5060/5061 aber bereits belegt und statt die Ports in der Anlage anzupassen, habe ich einfach im Port-Forwarding der FRITZ!Box die Zielports angepasst - hat auch funktioniert.

 

[4Halix]

FRITZ!Box
Zwei Port-Forwardings für TCP und UDP jeweils von 5060 bis 5068 (4 Kanäle, 2 Ports je Kanal) zur internen IP-Adresse der Anlage. Der SIP-Port muss nach außen 5060 sein, nicht 5062 wie oben bei Anbieter eingestellt. Da wir schon einige interne IP-Telefone haben, waren dafür 5060/5061 aber bereits belegt und statt die Ports in der Anlage anzupassen, habe ich einfach im Port-Forwarding der FRITZ!Box die Zielports angepasst - hat auch funktioniert.

Vorsicht bitte bei dieser Geschichte! Denn eingehend öffnet man somit normalerweise den SIP Zugang, und ermöglicht Hinz & Kunz sich auf der Anlage anzumelden.

Eingehend (also das übliche forwarding) ist normalerweise nichts zu öffnen. Maximal 5070, 5080 und die RTP Ports der Anbieter und/oder verwendeten Geräte.

5060 wird ausgehend durch die Anlage initiiert, Richtung Provider. Das dürfte im Normalfall keiner Einstellung bedürfen am Router. Da der lokale Port normalerweise nicht statisch ist, können auch beliebig viele Geräte ein Ziel auf Port 5060 rufen.

Das Ganze nur als gutgemeinten Tipp. Das kann durchaus enorme Kosten verursachen.

 

[mipo]

Hallo Toni,

eine ganz gefährliche Geschichte, den Port 5060 per Portforwarding vom Internet auf Deine Anlage freizuschalten! Wenn Du da nicht absolut sichere Passwörter für Deine
interne Telefonie nutzt und/oder die Anlage irgendwelche Security Bugs hat, kann Hinz- und Kunz auf Deine Kosten telefonieren. Ich hatte das mal vor Jahren mit meinen
Asterisk Experimenten gehabt. Gottseidank nur mit einm Sipgate Prepaid Account (dummerweise mit automatischer Aufladung von jeweils 25 Euro). Das Vergnügen hatte
mit 75 Euro "Lehrgeld" gekostet. Hätte ich dieses mit meinem Telekom ISDN Anschluss gemacht, wäre ich mit der nächsten Rechnung pleite gewesen. Da waren laufend
Überseegespräche nach Kuba usw. für 3,63 / Minute dabei.

Kann mich also nur der Warnung an @4Halix anschließen.

Die Kommunikation von Deiner Anlage Richtung Provider (Vodafone) handelt Dein Router vollkommen selbstständig und braucht keinerlei Portforwardings. Ausnahme
können die RTP Ports sein, die sind allerdings für die Gebühren unrelevant.

Gruß
Michael

 

[Toni76]

Mir ist klar, dass Port-Forwarding im Allgemeinen immer von dem "Problem" betroffen ist, dass dadurch ein Dienst aus dem Internet direkt zugänglich gemacht wird und besagter Dienst durch potentielle Sicherheitslücken angreifbar ist. Das ist aber einfach eine gängige Praxis und für SIP nicht riskanter als für irgendwelche anderen Dienste, sondern davon abhängig, ob der jeweilige Dienst im Speziellen sicher implementiert und konfiguriert ist.

Ich kann zur Sicherheit der Implementierung von Auerswald natürlich keinerlei Aussage machen, sondern muss ihr einfach vertrauen. Die Verbindung bzw. Ports nach außen sind in der Anlage als externe Kanäle definiert und sollten damit schon mal grundsätzlich keinen freien Zugriff auf irgendwelche anderen Telefoniedienste oder Zielnummern als die anlageninternen erlauben.

Die FRITZ!Box kann leider beim Forwarding keine Absender-IPs filtern, sonst könnte man den externen Zugriff auf den Vodafone-SBC beschränken und den Zugang damit zumindest halbwegs vernageln. Allerdings habe ich es bisher bei rudimentären Tests auf Port 5060 der externen IP auch nicht geschafft, irgendeine SIP-Verbindung aufzubauen. Evtl. hat Vodafone bereits eine Firewall davor und lässt nur den SBC rein.

Ansonsten habe ich mich dafür an die Schnittstellenbeschreibung von Vodafone für den Anlagenanschluss gehalten, in der das Port-Forwarding explizit beschrieben wird. Und sofern nicht irgendeine andere Art Signalisierung angewendet wird, ist das ist natürlich notwendig, damit externe Anrufe überhaupt reinkommen können. Diese werden dann entsprechend der Schnittstellenbeschreibung je gebuchtem IP-Kanal den jeweiligen Ports zugeordnet.

Da die FRITZ!Box auch selbst SIP bzw. SIP-Trunking kann, versuche ich noch herauszufinden, ob ich sie irgendwie als ALG oder Proxy bzw. SBC passend konfiguriert bekomme, so dass das Ganze auf SIP-Ebene durchgeleitet wird, anstatt über die Ports mit direktem Zugriff auf die Anlage. Aber bisher weiß ich nicht wie genau und es erscheint mir kompliziert...

 

[mipo]

Ich kann zur Sicherheit der Implementierung von Auerswald natürlich keinerlei Aussage machen, sondern muss ihr einfach vertrauen. Die Verbindung bzw. Ports nach außen sind in der Anlage als externe Kanäle definiert und sollten damit schon mal grundsätzlich keinen freien Zugriff auf irgendwelche anderen Telefoniedienste oder Zielnummern als die anlageninternen erlauben.

Toni, das ist ja gerade der Gag ... Ein User aus dem Internet greift über Deine öffentliche IP und Port 5060 auf eine interne Rufnummer zu und registriert sich erfolgreich. Wenn Du hier nicht sichere Passwörter verwendest, sondern aus Faulheit irgend etwas "einfaches" wie geheim123 oder noch besser Rufnummer 123, Passwort 123 kann dieser wie eine interne Nebenstelle natürlich externe Gespräche aufbauen ...

Und die können kosten. Wenn Vodafone und/oder ein SBC diese Zugänge sperren, dann funktioniert im Umkehrschluss doch nicht das von Dir eingerichtete Portforwarding. Du gibst ja explizit Port 5060 auf Deine
Anlage frei. Soll also doch funktionieren. Oder irre ich mich?

Letztendlich mir egal, ist Dein Geld. Wollte nur darauf hinweisen, dass man den Port 5060 nicht freigibt.

Mir ist klar, dass Port-Forwarding im Allgemeinen immer von dem "Problem" betroffen ist, dass dadurch ein Dienst aus dem Internet direkt zugänglich gemacht wird und besagter Dienst durch potentielle Sicherheitslücken angreifbar ist. Das ist aber einfach eine gängige Praxis und für SIP nicht riskanter als für irgendwelche anderen Dienste, sondern davon abhängig, ob der jeweilige Dienst im Speziellen sicher implementiert und konfiguriert ist.

Es kommt auf den Dienst drauf an. Wenn ich meinen Mailserver öffentlich zugänglich mache und er als OpenRelay fehlkonfiguriert ist, habe ich "nur" das Problem, dass ich binnen kürzester Zeit auf diversen Spam Blacklists sitze und ich keine Mails mehr versenden kann. Empfänger blocken meine IP im Regelfall, wenn ich auf der Blacklist stehe. Aber ich weiß ja nicht wie Du finanziell aufgestellt bist, aber wenn hier echte Kosten auflaufen und Du merkst es 4-6 Woche später, kann es bitter weden. Hier ist auf Kunlaz der Provider wohl nicht zu hoffen.

Viele Grüße
Michael

 

[Toni76]

Hallo Michael, ich glaube, hier liegen mehrere Missverständnisse vor:

Die von außen erreichbaren SIP-Ports sind in der Anlage als externe Schnittstellen definiert. Darauf kann sich keine interne Rufnummer registrieren (und nebenbei hätten diese Nebenstellen lange, generierte, kryptische Passwörter). Zu diesem Zweck gibt es in der Anlage für die internen Nummern eine eigene Schnittstelle auf einem anderen Port, der nur intern erreichbar ist.

Und die können kosten. Wenn Vodafone und/oder ein SBC diese Zugänge sperren, dann funktioniert im Umkehrschluss doch nicht das von Dir eingerichtete Portforwarding. Du gibst ja explizit Port 5060 auf Deine Anlage frei. Soll also doch funktionieren. Oder irre ich mich?

Diese Erklärung kann ich nicht nachvollziehen. Vodafone kann jederzeit eine Firewall ihrerseits so konfigurieren, dass ihr SBC auf unsere IP freien Zugriff hat, das restliche Internet aber nicht. Eben so, wie ich es auch in der FRITZ!Box konfigurieren würde, wenn diese das zulassen würde. Wie zuvor erwähnt, scheint mir das seitens Vodafone so der Fall zu sein, da ich unseren Port 5060 aus dem öffentlichen Internet nicht erreichen kann, habe es aber nicht tiefergehend untersucht.

Deinen Hinweis, dass der Port nicht freizugeben ist, müsstest Du an Vodafone weiterleiten. Dort wurde die Schnittstellenbeschreibung als Handreichung für Geschäftskunden mit Anlagenanschluss erstellt. Sofern ich die FRITZ!Box nicht als ALG oder ähnliches konfiguriert bekomme, um es anderweitig durchzuleiten, ist das aus meiner Sicht auch sinnvoll: Der bezüglich Sicherheit einzig relevante Unterschied ergibt sich dadurch, dass ich dann der Sicherheit der SIP-Implementierung von AVM vertrauen muss, anstatt der von Auerswald. Und da ich dazu keinen objektiven Vergleich kenne, erscheint mir momentan Auerswald subjektiv in Ordnung. Für tatsächliche bzw. bestmögliche Sicherheit müsste ich mir voraussichtlich eine dahingehend zertifizierte Lösung anschaffen und vor die Anlage schalten.

Der Vergleich mit einem Open-Relay ist übrigens weit hergeholt und hat mit meiner, von Dir zitierten und sehr allgemeinen Aussage nur insofern zu tun, dass es ein Beispiel für irgendeinen beliebigen DIenst ist, den man falsch konfigurieren und dadurch irgendeinen beliebigen Schaden hervorrufen kann.

 

[sonyKatze]

[Port-Forwarding] ist aber einfach eine gängige Praxis …

Nö … leider kann ich Dir aus Ermangelung Deines Anschlusses nicht konkret(er) helfen. Normalerweise wird das NAT-Binding in der Router-Firewall (genauer NAT-Session-Table) durch eine Telefonanlage dahinter aufrechterhalten, indem man auf alle IP-Adresse des Registrar periodisch etwas schickt. Aber bei diesem speziellen Vodafone-Anschluss schickt Vodafone von sich aus SIP-OPTIONS. Das hast Du vermutlich abschalten lassen. Vodafone Schnittstellen-Beschreibung sagt eigentlich nur, dass sie bei einem Port-Forwarding nichts machen, also keine Firewall für Dich vorhalten. Dass Du Deine funktionierende Konfiguration postest ist schön. Aber jemand mit mehr Zeit, sollte sich diesen Punkt nochmals anschauen.

 

[Toni76]

Hallo Katze, ein Zitat verfälscht aus dem Zusammenhang zu reissen bzw. umzuinterpretieren, ist nicht wirklich ideal. Ich habe nichts darüber geschrieben, wie irgendetwas üblicherweise bei SIP gehandhabt wird.
Ich vermute, Du beziehst Dich auf das NAT-Szenario mit TCP und TLS. Falls ich die Anlage irgendwie so konfiguriert bekomme, dass sie das unterstützt (schätze ich als unwahrscheinlich ein), wäre das natürlich eine Lösung ohne SIP-Forwarding, dann bleiben nur die RTP-Ports zum forwarden.
Die Schnittstellenbeschreibung sagt, wie Du auch sagst, dass "alle Pakete aus dem Internet" durchgeleitet werden, ich habe es nur bisher nicht so gesehen (heisst natürlich nichts).
Ich habe gar kein Problem, bei dem ich Hilfe benötige. Meine Konfiguration funktioniert einwandfrei, ist aus meiner Sicht bis auf mögliche Optimierungen nicht problembehaftet und ich habe Sie auf Bitte des Threaderöffners gepostet.

 

[sonyKatze]

verfälscht

Genauso habe ich es aber verstanden. Dass Du meinst, es wäre allgemein bei SIP so üblich. Und selbst wenn Du es lediglich auf Vodafone SIP-Trunk beziehst, ist es auch dort nicht üblich sondern erstmal nur der letzte Ausweg.

Ich vermute, Du beziehst Dich auf das NAT-Szenario mit TCP und TLS.

Nein.

Ich habe gar kein Problem, bei dem ich Hilfe benötige.

Leider doch. Eine Auerswald ist nicht dafür gehärtet bzw. unabhängig getestet, einfach so im Internet zu stehen. Frag Auerswald. Die werden Dir sagen, dass es nur für „Hinter-NAT“ gedacht ist. Das ist das Problem. Das ist eben kein Apache HTTP-Dämon, IMAP-Server oder VPN-Einwahlknoten. Es ist eine Client-Anwendung, die leider aufgrund des Protokoll-Designs auch als Server agieren kann.

ich habe es nur bisher nicht so gesehen

Hatte ich gelesen. Kann ich ohne den Anschluss zu haben, nicht einschätzen.

 

[mipo]

Hallo Toni,
ich gebe zu, ich weiß nicht, welchen Anschluss Du bei Vodafone letztendlich hast. Wenn Vodafone auf Deinem Anschluss eine vorgeschaltete Firewall betreibt,
einen SBC (wohl auf Deiner Seite?), handelt es sich wohl um einen speziell für VoIP abgeschotteten Anschluss. Gehe ich von von einem Standardanschluss
mit einem NAT Router aus, ist es schon ein Risiko den Port 5060 DEINER Anlage aus dem Internet verfügbar zu machen.

Davon einmal abgesehen, ist die COMmander Basic 2 schon lange EOL und mit Sicherheit nicht mit den aktuellen Security Patches ausgestattet. Sprich es
sind mit Sicherheit veraltete Verschlüsselungsverfahren (TLS, SSL usw.) im Einsatz, die von Internet Seite kompromittiert werden können. - Die @sonyKatze
ja schrieb "#31 Frag Auerswald ..." ist es halt eine Gefahr.

Wenn Vodafone den Port 5060 natürlich vom Internet her sperrt sind alles Spatzen gefangen ... Dann haben wir uns wohl irgendwo beim Begriff "Portfor-
warding" verrannt und/oder sind von falschen Voraussetzungen ausgegangen.

Somit ist alles gesagt ...

Viele Grüße + Erfolg
Michael

 

[Toni76]

Dass Du meinst, es wäre allgemein bei SIP so üblich. Und selbst wenn Du es lediglich auf Vodafone SIP-Trunk beziehst, ist es auch dort nicht üblich sondern erstmal nur der letzte Ausweg.

Nein, bitte genau lesen. Es ging dabei nur darum, dass Port-Forwarding eine gängige Praxis ist, um einen Dienst (hinter einem NAT-Router) aus dem Internet erreichbar zu machen. Das wiederum hatte nur den Hintergrund, dass Port-Forwarding nicht pauschal negativ zu bewerten ist. Dazu, ob es bei SIP oder einem anderen spezifischem Dienst XY ein mehr oder weniger üblicher Lösungsweg ist, habe ich gar nichts gesagt und ich könnte auch keine wirklich fundierte Aussage dazu machen.

Frag Auerswald. Die werden Dir sagen, dass es nur für „Hinter-NAT“ gedacht ist.

Mag sein, ändert aber nichts an meiner Aussage zu Vertrauen (gestern 14:30). Dazu Zitat aus dem Auerswald-Konfigurationshandbuch: "Achten Sie darauf, dass der verwendete Router ausdrücklich für VoIP-Datenverkehr ausgelegt ist („SIP aware“). Ist dies nicht der Fall, müssen im Router einige, für den VoIP-Datenverkehr benötigte Ports (RTP-Port und SIP-UDP-Ports) freigeschaltet werden (Portweiterleitung/Portfreigabe)."

Es ist eine Client-Anwendung, die leider aufgrund des Protokoll-Designs auch als Server agieren kann.

Mag auch sein, aber das Protokoll kann ja designed sein wie es will, wenn der Endpunkt gar keine Anmeldung/Registrierung zulässt und (in diesem Sinn) nicht als Server agiert.

[Edit Novize: Beiträge zusammengefasst - siehe Forumsregeln]

Mir war 2x aufgefallen, das die Auerswald mit der anderen MSN am Handy ankam, ich fand das ^^ Ich wollte schon aufgeben, bi

mit Sicherheit nicht mit den aktuellen Security Patches ausgestattet

Das stimmt sicherlich. Andererseits müsste jemand für diese spezielle Implementierung und Plattform erstmal einen funktionierenden Angriffsvektor suchen und finden und dann auch noch genau unsere Anlage als geeignetes Zielsystem ausmachen und dann tatsächlich erfolgreich einbrechen. Ob das in der Realität wahrscheinlicher ist, als ein erfolgreicher Angriff eine potentiell sicherere, aktuelle und verbreitetere Plattform ist zwar Spekulation, aber halte ich für eher unwahrscheinlich. Da es keine 100%ige Sicherheit gibt, ist das letztlich für egal welche Lösung immer eine Risikoabwägung.

sind mit Sicherheit veraltete Verschlüsselungsverfahren (TLS, SSL usw.) im Einsatz

Die Anlage unterstützt TLSv1.2, so wie es von Vodafone gefordert wird. Das ist zwar nicht der aktuellste Stand, aber auch nicht veraltet.

Frag Auerswald

Dort brauche ich eigentlich nichts ernsthaft anzufragen. Die lachen mich eher aus und werden mir recht wahrscheinlich erzählen, dass sämtlicher Support dafür ausgelaufen ist und sie daher gar nicht empfehlen können, das Gerät mit einer Internetverbindung zu betreiben, und ich mir was aktuelles kaufen soll.

 

[4Halix]

Bevor die Diskussion in eine falsche Richtung abdriftet. Ich habe mich hier nur kurz eingebracht weil die Anleitung bzw. das Beispiel jetzt anderen Lesern suggeriert, dass es sinnvoll sein könnte, die SIP Ports 5060 usw eingehen zu öffnen (sprich zu forewarden).

Das ist grundlegend falsch und unnütz. Man öffnet diesen Port nur aus einem Grund: man möchte eine Anmeldung aus dem Internet auf die eigene Anlage erlauben. Das mag für das eigene Gerät ausser Haus vielleicht Sinn machen, dann aber bitte in einem VPN verpackt und nicht am Port 5060 usw.

Die Anlage baut andersherum natürlich seine Verbindung zu Vodafone oder sonstwem von alleine auf. Dabei braucht man nur beachten, dass die Anlage über 5060 raus kann. Das lassen die allermeisten Router zu. Eingehend, weil meist nur lose verbunden, öffnet man die RTP (Audio) Ports, weil die sonst manchmal "abprallen" am Router. Die erlauben keine Anmeldung und sind weitestgehend ungefährlich.

Wenn es für das obige Szenario dann doch anders Sinn macht, kann man den Grund ja vielleicht auf 1-2 Sätze eingedampft hier nochmal klar stellen. Mir hat er sich absolut nicht erschlossen.

Grüße

 

[Toni76]

Wenn es für das obige Szenario dann doch anders Sinn macht, kann man den Grund ja vielleicht auf 1-2 Sätze eingedampft hier nochmal klar stellen.

Vodafone betreibt keinen STUN-Server und listet in seiner Schnittstellenbeschreibung vier mögliche Optionen zur NAT-Konfiguration auf. Die ersten beiden (OPTION Pings über UDP oder TCP) habe ich mit der vorhandenen Hardware nicht funktionierend konfiguriert bekommen, die dritte ebenfalls nicht und erfordert ALG-Funktionalität im Router, die vierte ist Port-Forwarding.

Das schließt nicht aus, dass eine der ersten drei Optionen doch irgendwie funktionieren könnte, oder dass man als fünfte Option z.B. die FRITZ!Box als Proxy oder ähnliches konfiguriert bekommt und letztendlich den Port nicht forwarden bzw. öffnen muss. Man könnte aber z.B. auch den Port auf eine interne Firewall zwischen-forwarden, die alles außer der IP des eingehenden Vodafone-SBC blockiert, um in der Beziehung sicherzugehen. Noch mehr Varianten mit individuellen Vor- und Nachteilen lassen sich sicherlich vielfach weiter konstruieren. Eine funktionierende Alternative zum Port-Forwarding fände ich zwar auch begrüßenswert, allerdings sehe ich in diesem Fall darin nicht so ein großes Problem wie einige der Diskussionsteilnehmer.

 

[koyaanisqatsi]

Moinsen


Aber @Toni76, ein STUN Server braucht die anglogermanische Firma nicht zu betreiben, da jeder funktionierende STUN Server eines Drittanbieters das leistet, wozu diese Firma anscheinend nicht in der Lage ist.
Wie wäre es denn mit dem eines Konkurrenten?

nmap -sU -p3478 stun.1und1.de                                                                                  
Starting Nmap 7.70 ( https://nmap.org ) at 2021-09-21 16:23 CEST
Nmap scan report for stun.1und1.de (212.227.67.33)
Host is up (0.031s latency).
Other addresses for stun.1und1.de (not scanned): 212.227.67.34

PORT     STATE         SERVICE
3478/udp open|filtered stun

Nmap done: 1 IP address (1 host up) scanned in 6.32 seconds

Unser Hauptsponsor schreibt dazu...

Was ist ein STUN-Server?

Ein STUN-Server ermöglicht NAT-Clients den Kommunikationsaufbau mit VoIP-Anbietern außerhalb des lokalen Netzwerks. ☛ Details bei ❱ 3CX®

www.3cx.de

 

[Toni76]

Ich vermute, der STUN-Hinweis war etwas irreführend, da das Raustelefonieren auch ohne STUN und ohne Portfreigaben mit der Einstellung "NAT Traversal" einwandfrei funktioniert. Warum, weiß ich nicht. Ich vermute, dass es was damit zu tun haben könnte, dass Vodafone fixe Portnummern für jeden Kanal annimmt und vielleicht packt die FRITZ!Box auch noch etwas Magie dazu, indem sie evtl. SIP mitliest.

Jedenfalls löst der STUN-Server anscheinend auch nicht das Problem, wie man ohne Port-Forwarding von außen reinrufen kann. Es lässt sich dafür bei Vodafone keine funktionierende Registrierung aktivieren, die irgendwas mit den STUN-Infos anfangen könnte. Evtl. habe ich SIP dafür noch nicht weit genug durchblickt, aber ich denke, dass ich es zumindest soweit verstanden habe.

 

[koyaanisqatsi]

STUN hält vorallem irgendeinen hohen Port ( von Innen nach Außen dynamisch geöffnet ) für eingehende Anrufe an der öffentlichen IPv4 offen.
(Welche dem Provider beim Registrieren mitgeteilt wird für den SIP Header Contact: )
Problem könnte dann natürlich noch sein: Keine erreichbare öffentliche IPv4 (CGNAT/DS-Lite).
Moment, ich check mal ob stun.1und1.de auch IPv6 kann, das muss ich erst aktivieren und meinen PC nochmal DHCP machen lassen...
Die Meisten können nämlich nur IPv4, gar nicht so einfach einen zu finden der auch via IPv6 erreichbar ist.
sip.1und1.de = Nein, nur IPv4...

$ nslookup stun.1und1.de 1.1.1.1
Server:        1.1.1.1
Address:    1.1.1.1#53

Non-authoritative answer:
Name:    stun.1und1.de
Address: 212.227.67.34
Name:    stun.1und1.de
Address: 212.227.67.33

Der hier sieht gut aus (ungetestet)...

$ nslookup stunserver.org 1.1.1.1
Server:        1.1.1.1
Address:    1.1.1.1#53

Non-authoritative answer:
Name:    stunserver.org
Address: 67.227.226.240
Name:    stunserver.org
Address: 2600:3c02::f03c:91ff:fee2:5b0f

Quelle...

STUN server list

STUN server list. GitHub Gist: instantly share code, notes, and snippets.

gist.github.com

 

[Toni76]

Das hatte ich zuvor schon so verstanden, dass durch STUN auch eingehende Anrufe ermöglicht werden - allerdings nur, wenn basierend darauf auch eine Registrierung des Clients mit IP und Port erfolgen kann. Daher hatte ich im letzten Post erwähnt, dass die Registrierung bei Vodafone nicht möglich ist. Zumindest gibt es weder in der Vodafone-Schnittstellenbeschreibung eine STUN-basierte Konfigurationsoption, noch wird in den Zugangsdaten ein Registrierungsserver gelistet, noch gelingt die Registrierung durch die Anlage mit aktiviertem STUN auf dem SBC. Die STUN-Abfrage ansich funktioniert laut Anlagenstatus einwandfrei, hilft alleine aber natürlich ziemlich wenig.

Der Internetverbindung ist eine feste externe IPv4 speziell für die IP-Telefonie zugewiesen.

 

[mipo]

Hi Toni,

mir erschließt sich einfach nicht Dein Setup. Denke die anderen User haben ähnliche Probleme. Wo sitzt der von Dir so oft zitierte SBC? Kannst Du das vielleicht
einmal beschreiben oder noch besser eine kleine Grafik hier hochladen? Welchen Router, SBC, welcher Vodafone Tarif, welcher Vodafone Anschluss Typ?

Liege ich richtig?
Du kannst also über den Anschluss nur telfonieren? Also nicht ins Internet? Du kommst auch vom Internet nicht auf die öffentliche IPv4 Adresse? Vodafone
schirmt diese quasi vom Internet ab und lässt nur eine Vodafone VoIP -> Router zu?

Dann halte ich Dein Portforwarding natürlich für unkritisch. Kommt ja kein "Hacker" auf Deine Telefonanlage ...

Viele Grüße
Michael