[Frage] Kompletter VoIP-Newbie...

Wenn Du noch ein par Monate/Jahre Zeit hast ?

Besorg dir über Ebay günstig ein par IP-Telefone, und lass Router und Modem so wie es ist

Für interne Telefongespräche hat man ja auf DD-WRT und Open-WRT den Milkfish-Service - Du mußt dann nur darauf achten, das bei den IP-Telefonen min. 2 Accounts aktiv sein können (geht bei den meisten neueren Modellen).

Und Nein - man braucht für VoIP/SIP keine gebrandete Providerbox, damit es stabil läuft - es ist auch kein Portforwarding oder STUN oder sonst Was nötig, um mehrere IP-Telefone hinter einer Router-NAT zu betreiben - der Troll, der diesen Unsinn aufgebracht hat, sollte lebenslang Internet-Verbot bekommen :meinemei:

Generell gibt es bei 1&1 keinen Routerzwang, ob Du deren Geräte (die Du günstig bekommst) nimmst oder nicht, ist Dir überlassen. Da aber eben auch nicht geknebelt wird, kannst Du auch ohne Einschränkung deren Router im Austausch zum Modem nehmen und das OpenWRT-Gerät Deines Vertrauens wie selbst vorgeschlagen als DMZ dranhängen. An der Fritzbox richtest Du nur die Telefonie ein und am S0-Bus kannst Du Deine Geräte wie bisher betreiben.

Providereigene Geräte erhöhen die Ausfallsicherheit nicht, da wäre - wenn das wichtig ist - eine netzseitig bedingte Rufumleitung auf ein Handy - die bessere Lösung. Das Mobilfunk geht meistens auch noch wenn es bei Internet/Festnetz eine Störung gibt.

andiling schrieb:

Generell gibt es bei 1&1 keinen Routerzwang ...

Zum Vergrößern anklicken....

Doch!
Wenn zB beim Vertragsabschluss eine 1und1-7490 geordert wurde, aber eine rote 3390 an der DSL-Leitung hängt, keine Verbindung zustande kommt, besteht der 1und1-Service knallhart darauf, die 7490 anzuschließen. Ansonsten wird keine Störungsmeldung an die T. weitergereicht.

Wo steht denn, dass die verpflichtend genutzt werden muss?

Bei meinem Vater verkaufe ich alle zwei Jahre diese schönen Boxen und bei (seltenen) Störungsmeldungen hatte ich nie das Problem.

@MuP
das kann ich nicht bestätigen - hab an einem Neu-Anschluss 7490 geordert und dort aber eine 7330 im Einsatz. Die Tickets werden problemlos erfasst und geprüft, sogar in sogenannten "Spezial-Abtlg. der Technik".
Es kann nur zur Problemen führen, wenn VoIP bspw. reklamiert wird und lediglich eine "Internet-Box" angeschlossen ist, denn dann wird VoIP-Fremdhardware eingesetzt, die nicht unterstützt wird.

Perceptron schrieb:

Oder könnte ich auch die aller-einfachste 1u1-Variante nehmen (sofern die S0-Anschlüsse hat - ich hab halt ISDN-Telefone/ABs usw...), und der das NAT und WLAN abdrehen, so dass ich da nur meinen bestehenden OpenWRT-Router dahinter klemmen brauche?

Zum Vergrößern anklicken....

Das verstehe ich vom Anliegen her nicht.

Der Provider (1&1) bietet Dir einen NGN-Anschluß an, wo "netzseitige" Telefonie über VoIP realisiert wird. Die FB kann das jetzt an ISDN-Geräte am internen S0 "übersetzen", aber doch nur dann, wenn sie ihrerseits auf der IP-Seite der "Ansprechpartner" für 1&1 ist. Wenn Du der Box jetzt das NAT abdrehst und Dein OpenWRT-Router die öffentliche IP-Adresse zugewiesen bekommt, wie soll die FRITZ!Box dann ihrerseits die Verbindung zum Provider per IP aufbauen ? Als Client, der dann vom OpenWRT wieder geNATted wird ? Es gibt (gab ?) zwar einige wenige Provider, dir für die Telefonie einen zweiten ATM-VCC benutzen (auch mit einer zweiten IP-Adresse), aber 1&1 gehört m.W. nicht dazu. Die FRITZ!Box am DSL-Anschluß erst einmal nur als Modem einzusetzen, dann aber ihre Netzwerk-Funktionen als Client wieder nutzen zu wollen, funktioniert m.W. auch nicht, die Pfade können da nicht getrennt werden.

Irgendwo habe ich auch das Stichwort "Exposed Host" gelesen. Selbst für ein so freigegebenes internes Gerät an einer FRITZ!Box (das könnte dann der OpenWRT-Router sein), macht die FB noch NAT (inkl. CT mit TO) und (vermutlich) auch QoS. Es würde zwar ein einfaches "rewrite" der Paketadressen ausreichen, aber der Anzeige nach zu urteilen (cat /proc/kdsld/dslifaces/internet/ipmasq/mappings) "merkt" sie sich ihrerseits schon, was da so passiert. Auch hätte der OpenWRT-Router dann keine öffentliche Adresse (was in der Regel aber lösbar ist, jedoch bei DynDNS u.ä. zu berücksichtigen wäre).

Eine FRITZ!Box wird jedenfalls Deine Vorbedingungen eher nicht erfüllen können. Die gesamten Telefoniefunktionen sind "closed source", auch der Netzwerk-Teil ist (trotz veröffentlichter Sourcen für Kerneltreiber) absichtlich so aufgeteilt, daß wichtige Quellen zur Behandlung von Netzwerk-Paketen (nicht jedes Paket wird durch den kompletten Netzwerk-Stack "geschleust") nicht aufgrund von Lizenzbestimmungen veröffentlicht werden müssen.

In Deinem Fall müßte das (so Du kein OpenWRT-fähiges Gerät mit integriertem (A/V)DSL-Modem und internem (funktionierendem) S0-Bus findest) also ein DSL-Modem, dahinter der OpenWRT-Router und hinter diesem dann wieder eine TK, die intern S0 und extern SIP "spricht", sein.
Da wird das Mantra der "absoluten Kontrolle" dann schnell recht teuer und aufwändig ... so sehr ich den prinzipiellen Wunsch auch nachvollziehen kann und einige Punkte an der AVM-Firmware kritisiere.
Spätestens bei der TK-Anlage ist es mit OSS dann aber sicherlich auch wieder Essig, wenn da ein "fertiges" Gerät zum Einsatz kommt. Deiner Beschreibung nach zu urteilen, hängen die ISDN-Geräte derzeit bei Dir ja direkt am Mehrgeräteanschluß des Providers, Du brauchst also irgendein neues Gerät als "Umsetzer".

Aber es gibt natürlich für so ziemlich jeden in Frage kommenden Teilaspekt auch eine OSS-Implementierung. Leider aber wohl keine Geräte, die die dabei unterstützten Hardware-Komponenten (bei osmocomDECT z.B. nur die SC14421/14424-Prozessoren) auch ein einem einzigen Gerät integrieren (die Adlerbox lasse ich mal außen vor, die Hardware ist ja nun alles andere als aktuell).

Für die Umsetzung eines internen S0-Busses eine "herkömmliche" ISDN-Karte (gibt es die überhaupt noch zu kaufen ?) einzusetzen, ist m.E. genauso unsinnig, wie das Betreiben eines 19"-Servers als Router und Telefonanlage im privaten Haushalt, möglichst noch mit redundanten Netzteilen an derselben Steckdose (alles schon gesehen, es könnte ja ein Netzteil kaputt gehen). Da stimmen dann einfach die Betriebskosten nicht mehr in der heutigen Zeit. Andere Alternativen, wie ISDN-Adapter als USB-Devices, scheitern m.W. an der fehlenden Treiberunterstützung auf der Linux-Seite.

Das bestechendste Merkmal einer FRITZ!Box ist nun einmal ihre Integration vieler Dienste und Funktionen, für andere ist das auch wieder ein Grund, sie abzulehnen.

BTW: Die allereinfachste Variante bei 1&1 hat i.d.R. keinen internen S0-Bus. Aber auch die luxuriöseste Variante einer FRITZ!Box ist bei 1&1 für Neukunden zum Schnäppchenpreis zu erwerben und die hat dann viele nützliche Funktionen, sie überwacht sogar die Arbeitsmoral und den Alkoholkonsum, wenn es sein muß. Dann meinetwegen - wenn es unbedingt sein muß - noch den OpenWRT-Router (trotz NAT) als ExposedHost dran und man hat mit zwei kleinen Geräten schon sehr viel Komfort (und bei einer 7490 im Moment auch genug Reserven an Prozessorleistung für zusätzliche Aufgaben, die man ihr aufbürden möchte).

PeterPawn schrieb:

aber 1&1 gehört m.W. nicht dazu.

Zum Vergrößern anklicken....

Doch. Zumindest teilweise. Hängt vom Vorleister ab.
Bei QSC und Telefonica gibt es einen 2. PVC.
Bei Vodafone vermutlich auch einen 2. PVC.
Nur bei Telekom nicht.

eisbaerin schrieb:

Doch. Zumindest teilweise. Hängt vom Vorleister ab.

Zum Vergrößern anklicken....

Ah ja, wußte ich nicht.

Dann wäre natürlich theoretisch die Aufteilung der Adressen auf zwei Geräte denkbar, mit aktueller Firmware aber meines Wissens auch nicht zu realisieren, da die Box keinen Modus hat, in dem sie das Interface "dsl" bei zwei PVCs in "internet" und "voip[+tr069]" aufteilt und sich auf "internet" dann nur wie eine Bridge verhält.

wenn man das Eingangspost nimmt, fehlt doch nur noch opencloud, Asterisk & Co.
danach kommt dann direkt - "Hilfe mein System wurde gehackt" und Sammelklage

das gleiche sieht man auch in anderen Bereichen/Foren, wo manche Linux-User nicht mal Updates hinbekommen.
vielleicht sollte einfach Komfort, Sicherheit, Service und Umsetzung/Können mal abgewogen werden.

eisbaerin schrieb:

Bei QSC und Telefonica gibt es einen 2. PVC.
Bei Vodafone vermutlich auch einen 2. PVC.

Zum Vergrößern anklicken....

Das wird dann mit einem OpenWRT-Router eine recht komplexe Angelegenheit, der kann das zwar vom Grundsatz ("multiwan"), die Verteilung des traffics auf den richtigen PPPoE wird aber dann eine Herausforderung. Das würde ich dann doch lieber einem Gerät überlassen, dass das nativ kann (eben z.B. Fritzbox).

Interessant ist noch: Wenn man bei Easybell ist, die ja auch über Telefonica schalten, bekommt man keinen 2. PVC.

@eisbaerin
bei einem 1&1 NGN-Anschluss - Neuabschluss vor ca. 8 Monaten = Vodafone = 2.PVC (dh. vermutlich kann "entfernt" werden)

Bei der Frage "2.PVC oder nicht ?" spielt es sicherlich auch eine Rolle, wie gut die Infrastruktur insgesamt ausgebaut ist und wie die Anbindung des DSLAM dann aussieht. Basiert diese auf ATM, kann man einen zweiten PVC einrichten, bei einer Ethernet-Anbindung wäre das m.W. alles zusätzlicher Ballast, der erst einmal emuliert werden muß.

Eine ATM-Anbindung erlaubt also den Einsatz eines zweiten PVC, der dann seine eigene garantierte Bitrate erhält und somit den notwendigen Durchsatz einer VoIP-Verbindung (auf Layer 2) auch dann sicherstellen kann, wenn das DSL-Modem oder der -Router seinerseits (auf Layer 3) keine entsprechenden Vorkehrungen trifft, sie erfordert ihn aber nicht.

Zumindest die Telekom baut nach eigenen Verlautbarungen das ATM-Netz nicht weiter aus, sie stellt inzwischen auch vorhandene ATM-Netze auf Ethernet um.

Macht dann bei einer Ethernet-Anbindung das Endgerät (also z.B. die FRITZ!Box) seinerseits kein ordentliches QoS/ToS-Tagging und die Ethernet-Router können daher nicht richtig priorisieren, hat ein Anschluß an einer VSt nach der Änderung der Anbindung (und der wahrscheinlich notwendigen Umstellung von Zugängen und älteren DSL-Endgeräten, also geht das ohne TR-069 am Kunden eigentlich nicht komplett vorbei) u.U. vorher nie gekannte Probleme.

EDIT:
Aus der Umstellung auf Ethernet-Anbindung resultieren ja auch die Bestrebungen, ISDN-Anschlüsse schrittweise zurückzudrängen. Kein ATM heißt eben auch kein ISDN. Eine Emulation wie "ATM-over-Ethernet" (manchmal auch "Cell in Frame (CIF)" genannt) wurde mal vor 15-20 Jahren versucht einzuführen, ist aber m.W. nie aus einer Nische herausgetreten.
Und der ganze Aufwand mit dem Mischen und Splitten der Frequenzen fällt dann ja auch weg, damit wieder mehr Raum für weitere DSL-Träger usw.

Also kann ich (nicht nur aus betriebswirtschaftlicher Sicht) die Abkehr schon nachvollziehen, die Argumentation mit der höheren Störfestigkeit und der Verfügbarkeit im Katastrophenfall ist zwar richtig, aber da übernimmt eben der Mobilfunk (und auch Tetra oder, wenn alle Stränge reißen, der Satellit) immer mehr diese Rolle. Daß das nicht immer sinnvoll sein muß, kann man kurz nach dem Jahreswechsel gut sehen, wenn die Mobilfunknetze (zumindest in Großstädten) immer kurz in die Knie gehen. Das war aber schon zu Zeiten analoger Hebdrehwähler auch nicht anders. Statistik und mittlere Verfügbarkeit sind eben so eine Sache, das Beispiel mit der mittleren Temperatur von 310 K kennt auch jeder.

GottSeth schrieb:

Und Nein - man braucht für VoIP/SIP keine gebrandete Providerbox, damit es stabil läuft - es ist auch kein Portforwarding oder STUN oder sonst Was nötig, um mehrere IP-Telefone hinter einer Router-NAT zu betreiben

Zum Vergrößern anklicken....

Da habe ich noch Verständnisprobleme: woher weiss denn der Tel-Provider, wohin er seine Päckchen senden soll?

Irgendwie ist es schon seltsam: Im Gegensatz zu H.323 kommt ja SIP aus der IP-Welt. Und in diesem Umfeld ist NAT ja nun wirklich kein Neuland. Die Verfasser der RFCs müssen sich doch was dabei gedacht haben?

Wie würde denn das Setup idealerweise (also ohne STUN/Forwarding) funktionieren?

Wenn Du Zuhause an mehreren PCs gleichzeitig was googelst - woher weiß Google, wer welche Anfrage gestellt hat ?

Richtig - jedes Paket hat einen Header, wo drin steht von welchem LAN-Clienten es geschickt wurde - und genauso funzt das auch mit mehreren VoIP-Telefonen - das Telefon schickt seine Registrierung an den Server - wenn der Server es klingeln lassen will steht im Header die Adresse des Telefons mit drin, so das der Router weiß, welches Telefon das Paket bekommen soll

Idealerweise macht man gar Nichts - einfach die Telefone an nen Switch gehängt, und den Router Alles machen lassen - obwohl ich gerne statische IPs verwende, damit ich das Web-Interface des Telefons gezielt aufrufen kann - wird bei mehreren identischen Telefonen schwierig, die sich alle mit der selben Kennung im Router anmelden

GottSeth schrieb:

Wenn Du Zuhause an mehreren PCs gleichzeitig was googelst - woher weiß Google, wer welche Anfrage gestellt hat ?

Zum Vergrößern anklicken....

Hier macht der Router NAT auf TCP-Ebene. Da TCP verbindungsorientiert ist, geht die Antwort schlicht an die Adresse+Port zurück, die der Router in den TCP-Header eingefügt hat. Der Router weiss dies dann auch dem Gerät im LAN zuzuordnen.
Innerhalb HTTP/HTML hat der Router nichts herumzufingern. Und der Browser stopft auch keine IP-Adressen in HTTP/HTML hinein.

Richtig - jedes Paket hat einen Header, wo drin steht von welchem LAN-Clienten es geschickt wurde - und genauso funzt das auch mit mehreren VoIP-Telefonen - das Telefon schickt seine Registrierung an den Server - wenn der Server es klingeln lassen will steht im Header die Adresse des Telefons mit drin, so das der Router weiß, welches Telefon das Paket bekommen soll

Zum Vergrößern anklicken....

Und genau hier ist doch der Haken.

Routing passiert hier auf UDP-Ebene. Ohne STUN stopft das SIP-Telefon aber seine private IP (also irgendwas aus 192.168.1.0/24) in den SIP-Header. Der Router macht NAT lediglich UDP-Ebene. Innerhalb des SIP-Headers hat der nichts herumzufingern. Also versucht der Sip-Provider mit 192.168.1.irgendwas zu reden. Wie das funktionieren soll, habe ich noch nicht nachvollziehen können.

woj schrieb:

Also versucht der Sip-Provider mit 192.168.1. irgendwas zu reden. Wie das funktionieren soll, habe ich noch nicht nachvollziehen können.

Zum Vergrößern anklicken....

Dem Server ist wurstegal, welche private IP da mit drin steht, der ermittelt die öffentliche IP einfach selbst - SIP steckt ja nicht mehr wie vor 20 Jahren in den "Kinderschuhen" - da hat die letzten 20 Jahre schon Etwas an Entwicklung stattgefunden :ziggi:

Fakt ist, Heutzutage brauchst Du dir über die Nat-Problematik keine Gedanken mehr zu machen - Router, Telefon und Server sind ohne dein Zutun in der Lage, das ganz alleine zu managen !