SIP-Probleme - same procedure as every thread
-
Das würde mich jetzt (rein aus akademischen Gründen ;D ) auch brennend interessieren. Geht das bei Dir so?
Bei meinem Gigaset DX800A ging das so ja. Auch mit einer FrizBox hatte ich das schon so und es ging.
Daher interessiert es mich eben auch ob das allgemein gültig ist :)Gehen müsste es dann wenn das Gerät die RTP Pakete eben genau auf dem Port erwartet mit dem es seine auch verschickt was ja auch machbar ist.
Habe das mal nachgelesen.
Erstmal eine kleine Korrektur: Ich habe weiter oben geschrieben, daß Paare von Ports benutzt werden für eingehende und ausgehende Audio-Daten. Das ist falsch. Korrekt ist: Es wird ein Paar benutzt, wobei ein Port mit gerader Nummer für die media-Daten verwendete wird (RTP-Protokoll), der darauffolgende ungerade Port dann für die Steuerungsinformationen (RTCP-Protokoll).
Im SIP-Protokoll wird beim SIP-INVITE ein payload mitgesendet. Hierfür wird SDP verwendet. Damit wird u.a. spezifiziert, wie die Audio-Daten transportiert werden sollen. Der Absender des INVITE (Anrufer) gibt den gewünschten (geraden) port für RTP-Audio-Daten an. (Der darauffolgende ungerade Port für RTCP ist implizit mit spezifiziert.) Nennen wir diesen Port "A".
Bei der Antwort gibt der Eingeladene seinerseits per SDP auf gleiche Weise einen Port für RTP-Daten an. Diese Ports können komplett unterschiedlich sein. Das soll Port "B" sein.
Der Anrufer baut eine RTP-Verbindung von einem selbst gewählten Source Port (z.B. "a") zur Zieladresse mit Port B auf und sendet dort Audiodaten. Der Angerufene baut eine RTP-Verbindung von einem beliebigen Source-Port (hier "b") zu Port A auf der IP-Adresse des Anrufers auf und sendet dort seine Audiodaten.
Die Firewall des Anrufers muß folgendes leisten:
-
Ausgehendes RTP vom Port a zu port B erlauben
-
Eingehendes RTP vom Port b zu Port A erlauben
-
Eingehendes Audio auf die VoIP-Anwendung weiterleiten.
ad 1. Hierfür braucht die Firewall eine Regel auf der LAN-Seite. Der Zielport B ist niemals bekannt, da er von der Gegenseite festgelegt wird. Die Regel kann aber den Source-Port filtern, sofern ein Port-Range dafür bekannt. VoIP-Geräte verwenden wohl in der Regel feste Port-Ranges dafür. Eine FB macht das jedenfalls so. Hierfür wird wohl der Port-Range 7078 bis 7110 verwendet.
ad 2. Der Firewall ist Port b niemals bekannt. Eine Regel kann nur Port A kennen. Hierfür muß bekannt sein, welcher Portrange dafür durch die VoIP-Anwendung genutzt wird. Das ist bei der FB wieder der Portrange 7078 bis 7110.
ad 3. Das erfordert eine Weiterleitungsregel. In der oben beschriebenen Form existiert keine bestehende Verbindung, der Traffic kann also durch die Firewall nicht zugeordnet werden.
Ich habe jetzt mal nachgelesen, warum das auch anders geht: Offenbar ist es tatsächlich die Regel, daß VoIP-Geräte gleiche Ports benutzen. Sprich: im o.a. Beispiel verwenden Anrufer und der Angerufene jeweils die von ihnen festgelegten Zielports auch als Source Ports. (b ist also gleich B, a ist gleich A).
Nun baut also der Anrufer eine RTP-Verbindung von Port A nach Port B auf und sendet Audio. Der Angerufene sendet vom Port B zu Port A ebenfalls Audio. Damit hat die Firewall eine bestehende Verbindung, der sie den eingehenden Traffic zuordnen kann. Das funktioniert auch mit Firewalls auf beiden Seiten. Sitzen beide Seiten hinter einer Firewall, dürften anfangs höchstens ein paar Pakete verlorengehen, bis beide Firewalls eine bestehende Verbindung erkennen.
Für die Firewall verbleibt dann nur diese Anforderung:
- Ausgehendes RTP zu port B erlauben (mit B aus dem Portrange der VoIP-Anwendung)
Eine Firewall, die jeden ausgehenden Traffic erlaubt, wäre damit automatisch richtig für RTP konfiguriert.
Wir können festhalten: Es ist zwar nicht standardkonform, aber für die meisten VoIP-Geräte müßte das Setup auch ohne mit den weniger umfangreichen Regeln funktionieren. Jetzt wäre es noch interessant zu wissen, ob es überhaupt Geräte mit abweichendem Verhalten gibt und ggf. welche.
Wichtig: Es reicht nicht, wenn sich nur eine Seite, z.B. das eigene Gerät, so verhält! Wenn die Gegenstelle nicht so arbeitet, wie hier beschrieben, dann braucht es das volle Set an Regeln. D.h. es kann in der Regel funktionieren, aber abhängig von der Gegenstelle fallweise scheitern. ::)
-
-
Danke für die ausführliche Beschreibung.
Man kann also sagen kommt immer drauf an ;) was man selbst als Gerät hat und welche Gegenstelle es ist.
Bei Telekom und FritzBox kann man sich wohl das eingehende NAT sparen.Ich hoffe das man sich hier auch mal auf einen Standard einigen kann.
-
Also leider doch noch nichts ganz positives zu vermelden…
Es hat rund 24 Stunden gut funktioniert, dann ging es wieder los mit Kommunikationsfehlern.
Ich habe dann festgestellt, dass scheinbar auch noch andere Ports verwendet werden - sah ziemlich zufällig aus.
Irgendwo im Internet habe ich dann gelesen, dass scheinbar bei manchen Providern die Ports 10000-65355 ebenfalls für RTP-Mediadaten verwendet werden können.Diese Portrange habe ich also entsprechend freigegeben. Zusätzlich ist mir aufgefallen, dass die Verbindungen immer aus dem IP-Netz 62.245.0.0/16 kommen, woraufhin ich die Regeln entsprechend angepasst habe (es kamen nämlich zwischenzeitlich auch "fremde" Pakete auf dem 5060er an - zwar nichts gefährliches, aber es wurde fleissig gescannt)
Nun, seitdem ist zwar die Firewall clean (also es kommen in Richtung SIP/Fax keine Blocks mehr), aber es geht trotzdem nicht richtig.
Und zwar funktioniert es konkret so:- Telefon rein/raus scheint zu funktionieren
- Faxe raus von hinterhalb PfSense funktionieren auch wunderbar
- Fax von einer FritzBox auf die FB hinter PfSense -> GEHT!
- Fax von Faxgeräten auf die FB hinter PfSense -> Kommunikationsfehler & Abbruch. Wenn man mithört, dann hört es sich so an, als würden 1-2 Sekunden des Fax-Handshakes vorne verschluckt?!
Wie gesagt, Firewall sieht soweit gut aus - irgendwelche Ideen?
Ich hab schon an der FB mit der Einstellung "is_nat_aware = yes" rumgespielt, aber dann melden sich die Nummern gar nicht mehr an.
Außerdem habe ich natürlich T.38 an und aus gemacht (und jetzt auch aus gelassen), aber ändert sich ebenfalls nix.Screenshots der aktuellen Rules liefere ich in Kürze nach...
Edit: 00:26 Uhr - Beim Faxempfang ist ein Übertragungsfehler aufgetreten. Das Dokument wurde nicht empfangen oder ist unvollständig. (via Fax)
00:28 Uhr - Senden OK (via Fax)
01:12 Uhr - Beim Faxempfang ist ein Übertragungsfehler aufgetreten. Das Dokument wurde nicht empfangen oder ist unvollständig. (via Fax)
01:16 Uhr - Beim Faxempfang ist ein Übertragungsfehler aufgetreten. Das Dokument wurde nicht empfangen oder ist unvollständig. (via FritzBox)
01:20 Uhr - Senden OK (via FritzBox)
??? ??? ??? ???Und die Einstellungen sind jetzt auch da… Dieses sporadische funktionieren, nicht funktionieren geht mir dermaßen auf den Nerv >:(
Natürlich funktioneren die verwendeten Faxe zueinander (also von Anschluss B zu C - beide ohne PfSense) zu 100% zuverlässig!Achso, wegen MNet... Auskünfte kann man da vergessen. Wie gesagt, die Box ist modifiziert und ohne direkten Zugriff darauf durch den Support wird sofort jeglicher Support abgeblockt.
Und zum Third Level Support lassen die mich erst recht nicht durch (der Typ damals hat leider auch mit unterdrückter Nummer angerufen :D )
SIP Ping meinte er aber sei normal komplett deaktiviert - was ja auch klar ist, weil bei der "Zwangsbox" ja zwingend gar keine Firewall dazwischen sein darf... "Normal" kann man die Zwangsbox ja nichtmal so konfigurieren, dass es möglich wäre.
-
bei manchen Providern die Ports 10000-65355 ebenfalls für RTP-Mediadaten
Das wäre ja nur dein Ziel wichtiger für dich ist ja auf was deine Geräte den RTP erwarten.
Vom LAN ins WAN ist normal nicht so das Problem.Was mir noch auffällt ist deine Floating Regel für was hast du die drin?
Diese Regel erlaubt auf allen Interfaces TCP auch auf dem WAN und das wollen wir ja eigentlich nicht.Dann hast du Im LAN Regel die gar nicht zu tragen kommen.
Erst erlaubst du aus den LAN TCP und UDP mit einer /24 Maske und ICMP wieder mit einer /16 Maske.
Und dann erlaubst du nochmal Port 5060 von deiner FritzBox. Das hast du ja aber schon mit der ersten Regel gemacht und bringt daher nix.Wake on Lan basiert auf MAC Adressen bleibt daher lokal und damit hat die PfSense nix zu tun muss also auch nicht freigegeben werden.
Wake on Lan schicken kann sie trotzdem da geht ja nix in das LAN InterfaceAuch auf dem WAN sind ein paar Regeln die wohl so nicht zum tragen kommen und ich glaube das du hier etwas falsch verstanden hast.
Die Regel gelten immer für Pakete die auf dem Interface eingehen.
Weil du hast da auf dem WAN eine Regel die als Destination 62.245.0.0/16 hat. Aber auf dem WAN Interface können bei dir keine Pakete Richtung 62.245.0.0/16 gehen weil das bedeuten würde das diese Netz hinter deiner PfSense sein müsset was ja aber nicht so ist.
Nur aus dem LAN kann etwas Richtung 62.245.0.0/16 gehen. Aber das hast du mit deiner TCP/UDP Regel und dem * ja schon drin.Auch z.B. mit dem Regel "Dropbox outgoing" erlaubst du jedem von extern vollen Zugriff auf das Webinterface deiner PfSense. Ist das gewollt? Im Normalfall nicht
Ich würde das erst mal alles überarbeiten und dann nochmal schauen wie es sich verhält.
Wegen dem FAX hast du T.38 mal ein bzw. ausgeschaltet und damit mal getestet?
-
@FFK:
Edit: 00:26 Uhr - Beim Faxempfang ist ein Übertragungsfehler aufgetreten. Das Dokument wurde nicht empfangen oder ist unvollständig. (via Fax)
00:28 Uhr - Senden OK (via Fax)
01:12 Uhr - Beim Faxempfang ist ein Übertragungsfehler aufgetreten. Das Dokument wurde nicht empfangen oder ist unvollständig. (via Fax)
01:16 Uhr - Beim Faxempfang ist ein Übertragungsfehler aufgetreten. Das Dokument wurde nicht empfangen oder ist unvollständig. (via FritzBox)
01:20 Uhr - Senden OK (via FritzBox)
??? ??? ??? ???Ist das ein Auszug aus dem Log der FB?
Dann dürfte die Verbindung zwischen den Geräten ja grundsätzlich zustandekommen, aber die Kommunikation schlägt fehl. Das heißt, daß das Problem nicht in der Firewall liegt.
Bzgl. T.38: Ich habe kein Fax und auch keine entsprechenden Erfahrungen mit Fax über VoIP. Aber was ich über T.38 weiß ist, daß das genau dafür da sein sollte, um das zu ermöglichen. Die Modems der Faxgeräte können über die Codes bei VoIP halt nicht vernünftig kommunizieren.
Ein möglicher Workaround (oder eine dauerhafte Lösung?) wäre eine Fax-Nummer über einen Provider, der eine Fax-to-Mail-Funktion anbietet.
-
Bzgl. T.38: Ich habe kein Fax und auch keine entsprechenden Erfahrungen mit Fax über VoIP. Aber was ich über T.38 weiß ist, daß das genau dafür da sein sollte, um das zu ermöglichen. Die Modems der Faxgeräte können über die Codes bei VoIP halt nicht vernünftig kommunizieren.
Das Stimmt es ist genau dafür gemacht. Ich mache das auch beruflich und ich weiß aus der Praxis das es mehr Probleme macht als es hiflt.
In der Regel fährt man mit G.711 besser. Ist zwar doof aber leider ist es in der Praxis so.Wenn ein Connect zustande kommt aber kein Fax drüber geht könnte es immer noch eine einseitige Verständigung sein also doch ein Firewall Thema.
Leider steht ja im Log nur Fax wurde nicht empfangen oder ist unvollständig.
Die Programm geben da oft leider zu wenig Infos. -
Ich kann kann nur spekulieren … Aber wenn Telefon zuverlässig komplett geht, dann ist one way audio ja offenbar kein Problem. Beide Geräte sollten sich also gegenseitig hören können. Es ist also mit sagen wir mal "sehr hoher Wahrscheinlichkeit" ein Codec-Problem.
Habe ich das richtig im Kopf, daß eine Einstellung von G.711 auch eine Sache des Providers ist? Oder ist das eine reine Client-Angelegenheit?
-
Was mir noch auffällt ist deine Floating Regel für was hast du die drin?
Diese Regel erlaubt auf allen Interfaces TCP auch auf dem WAN und das wollen wir ja eigentlich nicht.Diese Regel wurde mir im Support-Chat empfohlen. In der Regel selbst ist "Any Flags" und "Sloppy State" aktiviert. Das sollte wohl verhindern, dass bereits getrennte Verbindungen einen Firewall-Eintrag generieren, wenn sie erneut per TCP Paket getrennt werden.
Was bedeutet die Floating-Regel eigentlich? Wann kommt die genau zum Tragen?Erst erlaubst du aus den LAN TCP und UDP mit einer /24 Maske und ICMP wieder mit einer /16 Maske.
Soweit sollte das doch passen oder? Ich will aus dem 192.168.0.0/16er ICMP erlauben, aber nur aus dem /24er TCP und UDP erlauben. ICMP ist ja, dachte ich, Ping und TCP/UDP "Diverses"
Und dann erlaubst du nochmal Port 5060 von deiner FritzBox. Das hast du ja aber schon mit der ersten Regel gemacht und bringt daher nix.
Ja, das ist korrekt, das ist wohl doppelt gemoppelt. Liegt daran, dass es die Regel zuerst gab und die erste Regel erst später dazukam… Werde ich deaktivieren.
Wake on Lan basiert auf MAC Adressen bleibt daher lokal und damit hat die PfSense nix zu tun muss also auch nicht freigegeben werden.
Wake on Lan schicken kann sie trotzdem da geht ja nix in das LAN InterfaceHmm, die hatte ich aber komischerweise im Firewall Log drin? Hab die von dort übernommen und nur die IP "gewildcarded". Eventuell wurde hier eine falsche Anfrage generiert, sprich das WoL an die falsche IP geschickt, sodass es "raus" ging.
Eventuell weil sie an die Broadcast-Adresse ging oder so? Werde ich bei Gelegenheit prüfen.Die Regel gelten immer für Pakete die auf dem Interface eingehen.
Ja, das dachte ich auch, bis auf einmal merkwürdige Sachen im Log dazu standen. Kann ein Rechner im LAN Pakete auf das WAN-Interface schicken oder ist dann was größeres kaputt? :D
Weil du hast da auf dem WAN eine Regel die als Destination 62.245.0.0/16 hat. Aber auf dem WAN Interface können bei dir keine Pakete Richtung 62.245.0.0/16 gehen weil das bedeuten würde das diese Netz hinter deiner PfSense sein müsset was ja aber nicht so ist.
Nur aus dem LAN kann etwas Richtung 62.245.0.0/16 gehen. Aber das hast du mit deiner TCP/UDP Regel und dem * ja schon drin.Das ist aber genau das, was passiert ist, meine ich… Aber ich werde es nochmal prüfen, vielleicht habe ich mich da verguckt.
Auch z.B. mit dem Regel "Dropbox outgoing" erlaubst du jedem von extern vollen Zugriff auf das Webinterface deiner PfSense. Ist das gewollt? Im Normalfall nicht
Jetzt hast du mir kurz einen Schrecken eingejagt :D Nein, das soll natürlich nicht so sein. Geht aber auch nicht (habs gerade getestet).
Die Regel lässt Traffic durch, der als Source die WAN-Adresse (also die eigene IP) hat und als Ziel-Port 443 (also https).
Hier bin ich mir 100% sicher, dass das so im Log stand! Die eigene WAN-IP-Adresse hat eine Verbindung zu 5.9x.xxx.xxx:443 hergestellt. Recherchen und Hostname-Auflösung haben zu Dropbox geführt (die wir auch nutzen). Ist wohl was zum syncen.
Aber bitte frag mich nicht, wieso das auf dem Interface WAN lief! Ich hab mich auch gewundert.Wegen dem FAX hast du T.38 mal ein bzw. ausgeschaltet und damit mal getestet?
Ja, hab ich gemacht. Kein Unterschied festzustellen. Laut Recherchen unterstützt MNet sowieso kein T.38 (was auch meine bisherigen Erfahrungen bestätigten).Ist das ein Auszug aus dem Log der FB?
Dann dürfte die Verbindung zwischen den Geräten ja grundsätzlich zustandekommen, aber die Kommunikation schlägt fehl. Das heißt, daß das Problem nicht in der Firewall liegt.Ja, aus der FB. Wie gesagt, ich habe an der Firewall auch nichts gesehen. Beim Fax kann man ja "mithören" und ich höre ganz kurz das Quietschen. Also die Verbindung steht erstmal.
Anschließend wird die Verbindung entweder schlagartig durch die Firewall getrennt oder die FritzBox legt auf, weil der Handshake nicht klappt - letzteres wäre halt komisch, weils mit einer anderen FB ja klappt.
Dieses sporadische funktionieren und nicht funktionieren würde zwar auch für Kommunikationsfehler sprechen, aber wenn ich die FritzBox ohne PfSense hinhänge ist die Erfolgsquote 99,9% - war das Setup im letzten halben Jahr, weil PfSense nicht erfolgreich eingerichtet werden konnte…Ein möglicher Workaround (oder eine dauerhafte Lösung?) wäre eine Fax-Nummer über einen Provider, der eine Fax-to-Mail-Funktion anbietet.
Leider nein… Wir haben das Problem, dass die Faxe dem Dienstgeheimnis unterliegen (wir sind eine Feuerwehr) und wir das so nicht machen dürfen. Deswegen muss die FritzBox auch hinter die Firewall und darf nicht davor stehen... Sind spezielle Sicherheitsregelungen.
Das Stimmt es ist genau dafür gemacht. Ich mache das auch beruflich und ich weiß aus der Praxis das es mehr Probleme macht als es hiflt.
In der Regel fährt man mit G.711 besser. Ist zwar doof aber leider ist es in der Praxis so.Die Erfahrung habe ich auch gemacht. 90% der Fälle kommt sowieso ein Fallback auf G.711, weil Sender, Emfänger oder Knoten dazwischen T.38 nicht unterstützt. Und wenn es doch mal geht, dann geht's meistens auch nicht :D
Wenn ein Connect zustande kommt aber kein Fax drüber geht könnte es immer noch eine einseitige Verständigung sein also doch ein Firewall Thema.
Leider steht ja im Log nur Fax wurde nicht empfangen oder ist unvollständig.
Die Programm geben da oft leider zu wenig Infos.Gibts denn eine Möglichkeit das irgendwie mitzuschneiden/zu loggen, was genau passiert? Mit dem Packet-Capture evtl? (Ich werde da nur nicht so schlau draus…)
Ich kann kann nur spekulieren … Aber wenn Telefon zuverlässig komplett geht, dann ist one way audio ja offenbar kein Problem. Beide Geräte sollten sich also gegenseitig hören können. Es ist also mit sagen wir mal "sehr hoher Wahrscheinlichkeit" ein Codec-Problem.
Habe ich das richtig im Kopf, daß eine Einstellung von G.711 auch eine Sache des Providers ist? Oder ist das eine reine Client-Angelegenheit?
Gute Frage. Jedoch sehe ich im Log der FritzBox, dass eben jener Codec verwendet wurde. Siehe Screenshot.
-
Jetzt hast du mir kurz einen Schrecken eingejagt :D Nein, das soll natürlich nicht so sein. Geht aber auch nicht (habs gerade getestet).
Die Regel lässt Traffic durch, der als Source die WAN-Adresse (also die eigene IP) hat und als Ziel-Port 443 (also https).
Hier bin ich mir 100% sicher, dass das so im Log stand! Die eigene WAN-IP-Adresse hat eine Verbindung zu 5.9x.xxx.xxx:443 hergestellt. Recherchen und Hostname-Auflösung haben zu Dropbox geführt (die wir auch nutzen). Ist wohl was zum syncen.
Aber bitte frag mich nicht, wieso das auf dem Interface WAN lief! Ich hab mich auch gewundert.Stimmt hatte mich verschaut.
Aber wichtig ist nicht alles was im Firewall log steht wird geblock weil die Ports nicht offen sind. Kann auch sein das das TCP Syn nicht richtig gelaufen ist.
Wenn die Firewall z.B. ein SYN-ACK bekommt ohne vorher ein SYN dann blockt sie das auch. Daher können so Einträge kommen.
Wenn du vom LAN zum WAN Dropbox machen willst brauchst du diese spezielle Regel nicht.Floating Regeln sind Regeln die für alle Interfaces gelten braucht man nicht soo oft.
Wegen dem FAX hast du T.38 mal ein bzw. ausgeschaltet und damit mal getestet?
Ja, hab ich gemacht. Kein Unterschied festzustellen. Laut Recherchen unterstützt MNet sowieso kein T.38 (was auch meine bisherigen Erfahrungen bestätigten).Dann ausschalten.
Gibts denn eine Möglichkeit das irgendwie mitzuschneiden/zu loggen, was genau passiert? Mit dem Packet-Capture evtl? (Ich werde da nur nicht so schlau draus…)
Kann man nur die Analyse ist eben nicht so einfach gerade bei Fax braucht man da spezielle Tools. Leider bin ich was das angeht auch nicht so fit.
Man kann da nur mal schauen ob es da vielleicht Delay, Paketloss oder Jitter gibt.
Bei normaler Sprache ist das nicht ganz so schlimm bei Fax müssen diese Werte stimmen. -
Aber wichtig ist nicht alles was im Firewall log steht wird geblock weil die Ports nicht offen sind. Kann auch sein das das TCP Syn nicht richtig gelaufen ist.
Wenn die Firewall z.B. ein SYN-ACK bekommt ohne vorher ein SYN dann blockt sie das auch. Daher können so Einträge kommen.
Wenn du vom LAN zum WAN Dropbox machen willst brauchst du diese spezielle Regel nicht.Dafür ist angeblich die Floating-Regel. Dass genau diese Einträge eben nicht mehr erscheinen - so hab ich das zumindest verstanden… Englische Fachbegriffe sind ja so eine Sache^^
Dann ausschalten.
Ist aus.
Übrigens:
Heute haben alle Faxe auf Anhieb funktioniert (bisher 5 oder 6 Stück an der Zahl). Keine Fehler, keine Probleme, egal von welchem Gerät.
Ich habe seit gestern noch nichts weiter geändert. Die einzige Änderung ist, dass sich der PfSense nachts neu eingewählt hat.
Kann man da evtl. auch einfach mal ne scheiss Leitung erwischen? Gerade wenn ich PfSense 30x neu starte…
Das würde zumindest einiges erklären! -
Klingt doch schon mal besser.
Die einzige Änderung ist, dass sich der PfSense nachts neu eingewählt hat.
Warum macht sie das?
Hast du das eingestellt?
Weil normal wenn du VDSL hast oder VOIP sollte es keine Zwangstrennung mehr geben.
Bei der Telekom ist das so.Wäre ja auch doof wenn man mal nachts telefonieren will und hat dann Zwangstrennung.
Weißt du ob dein Provider Zwangstrennung macht?
-
Warum macht sie das?
Hast du das eingestellt?
Weil normal wenn du VDSL hast oder VOIP sollte es keine Zwangstrennung mehr geben.
Bei der Telekom ist das so.Wäre ja auch doof wenn man mal nachts telefonieren will und hat dann Zwangstrennung.
Weißt du ob dein Provider Zwangstrennung macht?
Ja, ich gehe stark davon aus. Bisher habe ich nur davon gehört, dass es bei Telekom und Kabel Deutschland Business wohl weggefallen ist.
MNet hat bisher immer getrennt.Und ja, beim Telefonieren ist das sehr nervig :D Beim alten Privatanschluss von KabelD hatte ich das sehr häufig, wenn ich nachts telefoniert habe…
-
Moin,
habe gerade mal nachgeschaut: KD, jetzt Vodafone, verbunden seit 26.11.2015, 09:22 Uhr, also fast schon statische IP ;)
-teddy
-
Finde ich persönlich ja ein Unding.
Wenn dann All over IP dann aber auch immer IP da.
Weil egal wann du die Zwangstrennung machst irgendwann wird auch bestimmt da mal telefoniert oder IP TV geschaut.Bei der Telekom habe ich das Problem zwar nicht, würde mich bei meinem Provider aber mal beschweren wenn ich das so hätte, weil so kann das ja nicht sein finde ich.
-
Um nochmal ein abschließendes Feedback zu geben:
Alles funktioniert wie es sein sollte - endlich…Sollte jemand mal diesen Thread finden und Hilfe brauchen - einfach kurz eine PN mit Verweis auf einen eigenen Thread an mich schicken! Werde es mir dann mal ansehen...
Danke an alle für die großartige Hilfe!
