VoIP-Telefonie über SIP-Client "Zoiper" (FritzBox 7560 als Router)
Hallo,
habe da eine Verständnisfrage zur VoIP-Telefonie mit dem SIP-Client "Zoiper" (für Windows, Android).
Habe folgenden Testaufbau hier:
Internet -- FritzBox (7560), 192.168.1.1/24 --- 192.168.1.2/24 EdgeRouter (als Firewall) 192.168.2.1/24 -- Windows-PC (Windows 10), Subnetz 192.168.2.0/24
Auf dem EdgeRouter habe ich was die VoIP-Telefonie betrifft ausschließlich den SIP-Port 5060 (UDP-Protokoll) aus dem 192.168.2.0/24er-Netz
in Richtung der 192.168.1.1/24 (IP-Adresse der FritzBox) erlaubt.
Ansonsten habe ich für die VoIP-Telefonie keinerlei weitere Ports geöffnet / erlaubt.
Ich bin nur sehr verwundert darüber, dass trotzdem die VoIP-Telefonie problemlos funktioniert und zwar in beide Richtungen.
Sprich, ich kann den anderen Gesprächsteilnehmer hören und er mich ebenfalls.
Müssen für VoIP-Telefonie nicht normalerweise noch Ports für die Audioübertragung (RTP-Ports)
geöffnet werden?
Einen STUN-Server verwende ich übrigens nicht,
der ist in den Einstellungen von "Zoiper" (der SIP-Client auf dem Windows-PC) ausgeschaltet/deaktiviert.
Kann mir jemand erklären, warum die VoIP-Telefonie bei mir funktioniert,
obwohl ich nur den SIP-Port 5060 (UDP) in Richtung meiner FritzBox erlaubt habe?
Bin da wirklich sehr überrascht drüber und verstehe es nicht wirklich.
Habe erwartet, dass ich wie gesagt noch die RTP-Ports freischalten muss ^^.
Über hilfreiche Infos von Euch würde ich mich sehr freuen.
Gruß, Datax
habe da eine Verständnisfrage zur VoIP-Telefonie mit dem SIP-Client "Zoiper" (für Windows, Android).
Habe folgenden Testaufbau hier:
Internet -- FritzBox (7560), 192.168.1.1/24 --- 192.168.1.2/24 EdgeRouter (als Firewall) 192.168.2.1/24 -- Windows-PC (Windows 10), Subnetz 192.168.2.0/24
Auf dem EdgeRouter habe ich was die VoIP-Telefonie betrifft ausschließlich den SIP-Port 5060 (UDP-Protokoll) aus dem 192.168.2.0/24er-Netz
in Richtung der 192.168.1.1/24 (IP-Adresse der FritzBox) erlaubt.
Ansonsten habe ich für die VoIP-Telefonie keinerlei weitere Ports geöffnet / erlaubt.
Ich bin nur sehr verwundert darüber, dass trotzdem die VoIP-Telefonie problemlos funktioniert und zwar in beide Richtungen.
Sprich, ich kann den anderen Gesprächsteilnehmer hören und er mich ebenfalls.
Müssen für VoIP-Telefonie nicht normalerweise noch Ports für die Audioübertragung (RTP-Ports)
geöffnet werden?
Einen STUN-Server verwende ich übrigens nicht,
der ist in den Einstellungen von "Zoiper" (der SIP-Client auf dem Windows-PC) ausgeschaltet/deaktiviert.
Kann mir jemand erklären, warum die VoIP-Telefonie bei mir funktioniert,
obwohl ich nur den SIP-Port 5060 (UDP) in Richtung meiner FritzBox erlaubt habe?
Bin da wirklich sehr überrascht drüber und verstehe es nicht wirklich.
Habe erwartet, dass ich wie gesagt noch die RTP-Ports freischalten muss ^^.
Über hilfreiche Infos von Euch würde ich mich sehr freuen.
Gruß, Datax
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 426334
Url: https://administrator.de/forum/voip-telefonie-ueber-sip-client-zoiper-fritzbox-7560-als-router-426334.html
Ausgedruckt am: 25.12.2024 um 19:12 Uhr
29 Kommentare
Neuester Kommentar
Prinzipiell ist das richtig - jedoch: Wenn du dich als Client anmeldest musst du eigentlich überhaupt keine Ports manuell öffnen oder weiterleiten.
Die Router resp. deren NAT-Connectiontracker erkennen selbst, welche Pakete zu einer von innen nach außen geöffneten Verbindung gehören und welche nicht. Da Zoiper - wie alle ordentlichen SIP-Clients - symmetrisches RTP verwendet, passiert folgendes:
Sobald per SIP die Verbindung aufgebaut ist, beginnt Zoiper damit, RTP-Daten in Richtung Fritzbox zu senden.
Das geschieht von Source-Port 12345 zur FritzBox an Port 9876.
Der Connection-Tracker auf dem NAT registriert nun also, dass du Pakete von deiner Source-IP und Source-Port 12345 zur FritzBox schickst.
Die Fritte schickt nun ihrerseits von Port 9876 an deinen Zoiper auf Port 12345 die RTP-Pakete für die Gegenrichtung.
Bei diesen Paketen stimmen also Source-IP und Source-Port dahingehend überein, dass sie zu den Zieladressen passen, an die du bereits ausgehend RTP sendest.
Dein NAT-Router erkennt darin Antwort-Pakete zu deinem ausgehenden RTP-Stream und kann diese Pakete an dich zustellen.
Bei asymmetrischem RTP würden unterschiedliche Port-Kombinationen verwendet, bei denen nur in jeweils eine Richtung gesendet wird (also vom Client von Port A nach Port B und vom Server von Port C an Port D) - da ist der Connection-Tracker machtlos.
Da würde dann - falls der Edge-Router das kann und es aktiviert ist - SIP-ALG helfen, wo die SDP-Daten aus den SIP-Paketen ausgewertet werden um zu ermitteln, welche Ports für RTP benötigt werden, die dann entsprechend dem Connection-Tracker bereits vorab registriert werden, bevor überhaupt Traffic darauf entsteht.
Wenn du also nicht explizit ausgehenden Traffic vom LAN des Edge-Router nach außen hin eingeschränkt hast: Works as expected.
Die Router resp. deren NAT-Connectiontracker erkennen selbst, welche Pakete zu einer von innen nach außen geöffneten Verbindung gehören und welche nicht. Da Zoiper - wie alle ordentlichen SIP-Clients - symmetrisches RTP verwendet, passiert folgendes:
Sobald per SIP die Verbindung aufgebaut ist, beginnt Zoiper damit, RTP-Daten in Richtung Fritzbox zu senden.
Das geschieht von Source-Port 12345 zur FritzBox an Port 9876.
Der Connection-Tracker auf dem NAT registriert nun also, dass du Pakete von deiner Source-IP und Source-Port 12345 zur FritzBox schickst.
Die Fritte schickt nun ihrerseits von Port 9876 an deinen Zoiper auf Port 12345 die RTP-Pakete für die Gegenrichtung.
Bei diesen Paketen stimmen also Source-IP und Source-Port dahingehend überein, dass sie zu den Zieladressen passen, an die du bereits ausgehend RTP sendest.
Dein NAT-Router erkennt darin Antwort-Pakete zu deinem ausgehenden RTP-Stream und kann diese Pakete an dich zustellen.
Bei asymmetrischem RTP würden unterschiedliche Port-Kombinationen verwendet, bei denen nur in jeweils eine Richtung gesendet wird (also vom Client von Port A nach Port B und vom Server von Port C an Port D) - da ist der Connection-Tracker machtlos.
Da würde dann - falls der Edge-Router das kann und es aktiviert ist - SIP-ALG helfen, wo die SDP-Daten aus den SIP-Paketen ausgewertet werden um zu ermitteln, welche Ports für RTP benötigt werden, die dann entsprechend dem Connection-Tracker bereits vorab registriert werden, bevor überhaupt Traffic darauf entsteht.
Wenn du also nicht explizit ausgehenden Traffic vom LAN des Edge-Router nach außen hin eingeschränkt hast: Works as expected.
Natürlich, das waren nur beispielhafte Angaben.
Grundsätzlich kannst du natürlich beliebige Ports verwenden (mit Ausnahme des SIP-Ports, natürlich). Wie du richtig bemerkt hast, werden die beim Verbindungsaufbau ausgehandelt.
Dazu schickt beim INVITE einfach jede Seite als eine Art Anhang zur SIP-Nachricht den SDP (Session Description Protocol) mit.
Hier in diesem Fall ist das eine SIP-Nachricht, welche von meinem Telefon an den SIP-Server gesendet wurde.
Das Telefon hat die IP 192.168.1.8 und teilt dem SIP-Server mit, dass es Media-Streams unter dieser IP entgegen nimmt und diese an Port 16466 gerichtet werden sollen.
Dazu gibt es eine Liste von unterstützten Codecs, die in Reihenfolge der Präferenz dort aufgelistet sind. Es soll dann der Codec genommen werden, der als erster auf beiden Seiten unterstützt wird.
Hier siehst du auch den "Codec" "telephone-event" mit der ID 101. Das ist die Information, wie DTMF (also die Zifferntasten des Telefons) übertragen werden soll - in diesem Fall per SIP-Paket ("SIP INFO").
Es ist ein wenig komplizierter, da das Telefon unter Umständen verschiedene Typen Media-Streams über verschiedene Protokolle gleichzeitig empfangen könnte (z.B. Audio und Video und Text), deshalb werden die Ports für jedes Mediaformat separat angegeben. In der freien Wildbahn wirst du aber eigentlich immer nur die Situation haben, dass RTP/AVP als Transport verwendet wird und alle Mediaformate ("Codecs") den gleichen Port verwenden.
Lediglich bei Fax über T.38 wirst du manchmal etwas anderes erleben, da hier explizit zwischen Audioübertragung und der Übertragung einer TIFF- oder JPEG-Datei unterschieden werden muss. Da werden dann in der Regel unterschiedliche Ports für Audio und Bilddatei ausgehandelt.
Im oben gezeigten Beispiel hat das Telefon die IP 192.168.1.8 und Port 16466 bekannt gegeben.
Die Telefonanlage hat, was hier nicht zu sehen ist, ihrerseits IP-Adresse 192.168.0.3 und Port 44148 durchgesagt.
Beide haben sich auf den Codec G.722 geeinigt und so fließt dann jetzt auch der RTP-Stream (symmetrisch) entsprechend:
Dass die im SDP genannte IP-Adresse jetzt die IP-Adresse des Telefons ist, ist natürlich zu erwarten - muss aber nicht zwingend so sein.
Denn SIP ist ja erstmal nur dazu da, eine solche Verbindung zu steuern - was dann später über eine solche ausgehandelte Verbindung für Daten übertragen werden, interessiert SIP nicht
Es gibt daher durchaus SIP-Server, die unter IP-Adresse A erreichbar sind, aber angeben, dass die Media-Daten alle an IP-Adresse B gerichtet werden sollen (und natürlich dann auch von dort kommen), weil dort dann z.B. ein Media-Proxy läuft. Oder - bei internen Telefonanlagen - wird direkt die IP-Adresse des angerufenen Telefons dort angegeben, damit die RTP-Daten nicht erst noch einen Umweg laufen müssen.
Da diese Sache in SIP so vorgesehen ist, kannst du dir in Kombination mit NAT auch gewaltig in den Fuß schießen:
Denn um die IP-Adresse in den SDP schreiben zu können, muss der Client seine IP kennen. Und der nimmt natürlich an, dass dort die IP-Adresse hinein gehört, die an seinem Netzwerk-Interface konfiguriert ist.
Ein Telefon würde da also - wie hier - seine lokale IPv4-Adresse hinein schreiben, mit etwas Pech wird aber an irgendeinem Router NAT gemacht und die IP stimmt so nicht mehr.
Dann schickt die Gegenstelle den RTP-Stream an eine IP, die sie möglicherweise gar nicht erreichen kann - und dann hast du den Effekt, dass der Angerufene dich hort, aber kein Audio zu dir kommt.
Dazu würde der Client dann STUN oder ICE verwenden, um herauszubekommen welche IP per NAT herauskommt und diese dann stattdessen in den SDP schreiben.
Grundsätzlich kannst du natürlich beliebige Ports verwenden (mit Ausnahme des SIP-Ports, natürlich). Wie du richtig bemerkt hast, werden die beim Verbindungsaufbau ausgehandelt.
Dazu schickt beim INVITE einfach jede Seite als eine Art Anhang zur SIP-Nachricht den SDP (Session Description Protocol) mit.
Hier in diesem Fall ist das eine SIP-Nachricht, welche von meinem Telefon an den SIP-Server gesendet wurde.
Das Telefon hat die IP 192.168.1.8 und teilt dem SIP-Server mit, dass es Media-Streams unter dieser IP entgegen nimmt und diese an Port 16466 gerichtet werden sollen.
Dazu gibt es eine Liste von unterstützten Codecs, die in Reihenfolge der Präferenz dort aufgelistet sind. Es soll dann der Codec genommen werden, der als erster auf beiden Seiten unterstützt wird.
Hier siehst du auch den "Codec" "telephone-event" mit der ID 101. Das ist die Information, wie DTMF (also die Zifferntasten des Telefons) übertragen werden soll - in diesem Fall per SIP-Paket ("SIP INFO").
Es ist ein wenig komplizierter, da das Telefon unter Umständen verschiedene Typen Media-Streams über verschiedene Protokolle gleichzeitig empfangen könnte (z.B. Audio und Video und Text), deshalb werden die Ports für jedes Mediaformat separat angegeben. In der freien Wildbahn wirst du aber eigentlich immer nur die Situation haben, dass RTP/AVP als Transport verwendet wird und alle Mediaformate ("Codecs") den gleichen Port verwenden.
Lediglich bei Fax über T.38 wirst du manchmal etwas anderes erleben, da hier explizit zwischen Audioübertragung und der Übertragung einer TIFF- oder JPEG-Datei unterschieden werden muss. Da werden dann in der Regel unterschiedliche Ports für Audio und Bilddatei ausgehandelt.
Im oben gezeigten Beispiel hat das Telefon die IP 192.168.1.8 und Port 16466 bekannt gegeben.
Die Telefonanlage hat, was hier nicht zu sehen ist, ihrerseits IP-Adresse 192.168.0.3 und Port 44148 durchgesagt.
Beide haben sich auf den Codec G.722 geeinigt und so fließt dann jetzt auch der RTP-Stream (symmetrisch) entsprechend:
Dass die im SDP genannte IP-Adresse jetzt die IP-Adresse des Telefons ist, ist natürlich zu erwarten - muss aber nicht zwingend so sein.
Denn SIP ist ja erstmal nur dazu da, eine solche Verbindung zu steuern - was dann später über eine solche ausgehandelte Verbindung für Daten übertragen werden, interessiert SIP nicht
Es gibt daher durchaus SIP-Server, die unter IP-Adresse A erreichbar sind, aber angeben, dass die Media-Daten alle an IP-Adresse B gerichtet werden sollen (und natürlich dann auch von dort kommen), weil dort dann z.B. ein Media-Proxy läuft. Oder - bei internen Telefonanlagen - wird direkt die IP-Adresse des angerufenen Telefons dort angegeben, damit die RTP-Daten nicht erst noch einen Umweg laufen müssen.
Da diese Sache in SIP so vorgesehen ist, kannst du dir in Kombination mit NAT auch gewaltig in den Fuß schießen:
Denn um die IP-Adresse in den SDP schreiben zu können, muss der Client seine IP kennen. Und der nimmt natürlich an, dass dort die IP-Adresse hinein gehört, die an seinem Netzwerk-Interface konfiguriert ist.
Ein Telefon würde da also - wie hier - seine lokale IPv4-Adresse hinein schreiben, mit etwas Pech wird aber an irgendeinem Router NAT gemacht und die IP stimmt so nicht mehr.
Dann schickt die Gegenstelle den RTP-Stream an eine IP, die sie möglicherweise gar nicht erreichen kann - und dann hast du den Effekt, dass der Angerufene dich hort, aber kein Audio zu dir kommt.
Dazu würde der Client dann STUN oder ICE verwenden, um herauszubekommen welche IP per NAT herauskommt und diese dann stattdessen in den SDP schreiben.
Ich zitiere mich mal selbst:
Probier mal, ob Zoiper und FritzBox ICE können, dann sollte das Problem damit entfallen.
Ansonsten: Gibt es gute Gründe, innerhalb deines lokalen Netzes NAT zu machen? Eigentlich ist das etwas, was man aus Performance-Gründen dringend vermeiden möchte.
Da diese Sache [IP-Adresse in SDP abweichend von der IP der SIP-Gegenstelle] in SIP so vorgesehen ist, kannst du dir in Kombination mit NAT auch gewaltig in den Fuß schießen:
Denn um die IP-Adresse in den SDP schreiben zu können, muss der Client seine IP kennen. Und der nimmt natürlich an, dass dort die IP-Adresse hinein gehört, die an seinem Netzwerk-Interface konfiguriert ist.
Ein Telefon würde da also - wie hier - seine lokale IPv4-Adresse hinein schreiben, mit etwas Pech wird aber an irgendeinem Router NAT gemacht und die IP stimmt so nicht mehr.
Denn um die IP-Adresse in den SDP schreiben zu können, muss der Client seine IP kennen. Und der nimmt natürlich an, dass dort die IP-Adresse hinein gehört, die an seinem Netzwerk-Interface konfiguriert ist.
Ein Telefon würde da also - wie hier - seine lokale IPv4-Adresse hinein schreiben, mit etwas Pech wird aber an irgendeinem Router NAT gemacht und die IP stimmt so nicht mehr.
Probier mal, ob Zoiper und FritzBox ICE können, dann sollte das Problem damit entfallen.
Ansonsten: Gibt es gute Gründe, innerhalb deines lokalen Netzes NAT zu machen? Eigentlich ist das etwas, was man aus Performance-Gründen dringend vermeiden möchte.
dass ich auf der Schnittstelle des EdgeRouters zur FritzBox hin Masquerading aktiviere?
Das ist vermutlich zwangsweise aktiviert !M.E. ist der ER einer dieser billigen Provider
<edit>Falsch ! Er er ist ein kleiner mit halbwegs gutem Featureset ausgestatteter Router von Ubiquity aber mit einer sehr gruseligen und schwer verständlichen Konfig Syntax </edit>
Hier hat Kollege @LordGurke Recht das man, wenn immer möglich, sowas im internen Netz vermeiden sollte. Gerade wegen der oben schon angesprochenen Problematiken bei RDP und nicht nur da.
Details zum Thema Doppeltes NAT in Kaskaden und Nachteile findest du hier:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
und auch hier:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
@aqui:
Die Edge-Router lassen sich ziemlich gut anpassen. Schrott-Router würde ich nicht sagen, das ist ziemlich ordentliche Hard- und Software für das Geld.
Der Setup-Assistent ist aber halt darauf ausgelegt, dass es in 90% der Fälle sofort funktioniert - hier haben wir halt die 10%, wo man von Hand konfigurieren muss
Die Edge-Router lassen sich ziemlich gut anpassen. Schrott-Router würde ich nicht sagen, das ist ziemlich ordentliche Hard- und Software für das Geld.
Der Setup-Assistent ist aber halt darauf ausgelegt, dass es in 90% der Fälle sofort funktioniert - hier haben wir halt die 10%, wo man von Hand konfigurieren muss
Schrott-Router würde ich nicht sagen, das ist ziemlich ordentliche Hard- und Software für das Geld.
Betonung liegt auf "für das Geld" vermutlich. OK belassen wir es dabei der EdgeRouter-X kostet ca. 50 €.
Muss man dann auch sicher nicht weiter kommentieren...Verglichen mit dem
https://varia-store.com/de/produkt/33635-mikrotik-routerboard-rb941-2nd- ...
liegen da sicher Lichtjahre dazwischen wenns um das Feature Set geht.
Aber egal...jeder bekommt den Router den er verdient.
Für das Geld ist der schon echt super.
Eine Frage des Horizonts, wie immer.Konnte aber über die WAN-Schnittstelle problemlos eine SSH-Verbindung aufbauen.
Ist das irgendwie relevant für das eigentliche Thema oben ?Und das obwohl für das Subnetz des SSH-Servers das Masquerading auf "eth0" aktiviert ist.
Warum sollte es deiner meinung nach nicht gehen ? Für Outbound Session ist das doch absolut normales Verhalten.Vielleicht doch etwas Grundlagen dazu lesen:
https://de.wikipedia.org/wiki/Port_Address_Translation
dass ich trotzdem eine SSH-Verbindung aufbauen konnte ^^.
Oder falsche oder fehlerhafte Konfig. Oder auch Bug in der ER Firmware ?!Das Masquerading ist nicht zwangsweise aktiviert.
War auch nur eine Vermutung denn in der Regel ist das bei den billigen Provider Routern immer der Fall. Mag sein das der ER eine (sehr) seltene aber dann rühmliche Ausnahme ist. es war eine über die WAN-Schnittstelle eingehende Verbindung zur (privaten) IP-Adresse des SSH-Servers.
Oha, böses Faul ! Und das mit aktiviertem NAT ??Das sollte dir aber schwer zu denken geben, denn der NAT Prozess sollte sowas auch ohne Firewall sicher verhindern. Wenn du wirklich keinen Konfig Fehler gemacht hast ist das ziemlich beunruhigend, denn das lässt auf einen gravierenden Firmware Bug schliessen. Kann man sich sehr schwer vorstellen das sowas den Entwicklern nicht aufgefallen ist. Deshalb ist doch eher zu vermuten das du einen Konfig Fehler gemacht hast.
Wie Kollege LordGurke oben schon sehr richtig beschrieben hat kann eine inbound Session über ein aktives NAT OHNE gültigen Eintrag in der Session Tabelle niemals etabliert werden. Das wäre technisch unmöglich.
Bugfreies Verhalten mal vorausgesetzt.
ist das irgendwie komisch bei den "EdgeRoutern" oder ich konfiguriere es wirklich falsch.
Ist aber sehr zu vermuten das da was schief läuft...?!Hier steht wie man es richtig macht:
https://help.ubnt.com/hc/en-us/articles/204976494-EdgeRouter-Source-NAT
Du hast aber Recht: Die Konfig Syntax ist recht "schräg" um es mal vorsichtig zu formulieren.
Weiß noch nicht genau, warum die genannte SSH-Verbindung zustande kommt,
Wireshark ist wie immer dein bester Freund nicht die Antwortpakete des SSH-Servers (192.168.2.2) sehen
Wenn du an einem Switchport steckst kann das nicht gehen, denn der Switch forwardet das Paket ja nur an dem Port wo auch die Mac Adresse des SSH Servers ist.Wenn, dann musst du den Wireshark mit einer Bridge dort einschleifen:
https://www.heise.de/ct/artikel/Ethernet-Bridge-als-Sniffer-Quelle-22148 ...
Oder sofern du einen managebaren Switch hast musst du den Port über einen Mirror Port (Siegel- oder SPAN Port) auf den Wireshark spiegeln.
Warum das so ist ist hier erklärt:
https://www.heise.de/ct/artikel/Fehler-erschnueffeln-221587.html
Abschnitt: "Hardware aufsetzen".
weil es in der NAT-Tabelle keinen Eintrag gibt, der besagt wo dieses betreffende Antwortpakete hingeschickt werden soll!?
Wenn es keine inbound Session dazu in der NAT Session Tabelle gibt dem die Antwortpakete zugeordnet werden können dann ja.Du kannst niemals an einem NAT/Masquerading Port eine Session von außen initiieren. Dazu kann es ja keinen NAT Session Eintrag geben und der NAT Router verwirft (dropped) dann solche Pakete logischerweise sofort.
Das ist der NAT Firewall Effekt. Guckst du auch hier:
https://de.wikipedia.org/wiki/Netzwerkadressübersetzung
Nicht zwingend. Wenn die Anlage ein Keepalive macht oder ALG hat dann hält sie den Port in der NAT Firewall offen. Auch bei Verwendung von STUN benötigt man es in der Regel nicht.
Oft löst aber rein nur die Weiterleitung von TCP/UDP 5060 (SIP) auf die IP der dahinterliegenden Anlage so manches Problem.
Kollege @LordGurke hat ja oben schon alle diese Mechanismen hinreichend erklärt !
Oft löst aber rein nur die Weiterleitung von TCP/UDP 5060 (SIP) auf die IP der dahinterliegenden Anlage so manches Problem.
Kollege @LordGurke hat ja oben schon alle diese Mechanismen hinreichend erklärt !
Kollege @LordGurke hat es oben doch im ersten Post wunderbar erklärt. Da muss man eigentlich nichts mehr hinzufügen.
https://kompendium.infotip.de/voip-voice-over-ip.html
https://de.wikipedia.org/wiki/IP-Telefonie#Verbindungsaufbau_mit_SIP
usw.
https://kompendium.infotip.de/voip-voice-over-ip.html
https://de.wikipedia.org/wiki/IP-Telefonie#Verbindungsaufbau_mit_SIP
usw.
dass ich in der Firewall des EdgeRouters keinerlei RTP-Ports freigegeben habe.
Dann hat die FW des Routers ein Voice Application Gateway SIP-ALG) und macht das automatisch.Kann der EdgeRouter also in die SIP-Verbindung "reinschauen" und erkennen,
Ja, die ALG Funktion "sieht" dann ins Paket.
Das machen die für DAUs die nicht wissen was STUN und SIP Keepalives sind und die oft auch noch billige Provider Schrottrouter haben one Voice Application Gateway in der Firewall um auf Nummer sicher zu gehen das die nicht immer die Hotline anrufen.
Es gibt eben mehrere Schrauben zum Finetuning. Mit einem Port Forwarding forwardest du ja zwangsweise immer eingehende SIP Calls am Router auf die Telefone oder Telefonanlage so das diese Calls immer (DAU) sicher ankommen.
Mit Keepalives, Voice Application Gateways oder STUN geht es aber eben auch ohne.
Es gibt eben mehrere Schrauben zum Finetuning. Mit einem Port Forwarding forwardest du ja zwangsweise immer eingehende SIP Calls am Router auf die Telefone oder Telefonanlage so das diese Calls immer (DAU) sicher ankommen.
Mit Keepalives, Voice Application Gateways oder STUN geht es aber eben auch ohne.