1781VA: SIP-ALG vs. SBC vs. All-IP-Option vs. Telekom All-IP

[Richard]

Hallo,

ich muss meinen Anschluss auf einen Telekom All-IP-Tarif umstellen. Ich möchte eine VOIP fähige TK Anlage der Telekom hinter dem Router betreiben. Laut der Lancom Anleitung soll es reichen "SIP-ALG" zu aktivieren und dann müsste die VOIP Anlage direkt an dem Anschluss funktionieren. So sagt es zumindest die Anleitung.

Nun sagt mit die Telekom aber ich muss den Router um die zusätzliche zubuchbare "All-IP Option" von Lancom erweitern damit es tut. So wie ich das verstanden habe ist die nur notwendig, wenn man eine TK-Anlage per ISDN an den Lancom hängen will....Ich nutze aber eine VOIP-Anlage.

Allerdings habe ich jetzt auch noch was vom Lancom SBC gelesen, dass irgendwelche dynamischen Freigaben für VOIP in der Firewall einrichten soll. SBC gibts offenbar nur mit der "All-IP Option". Benötige ich nun die "All-IP Option" oder nicht und warum? Muss ich ohne "All-IP Option" irgendwelche Firewall-Freigaben oder Portforwardings manuell konfigurieren?

[Koppelfeld]

Hallo!

Es mag sein, daß es sehr einfache Konstellationen gibt, in denen das SIP - ALG funktioniert. Beim Privatkundenanschluß der Telekom gibt es aber einige "Extrawürste", die einen stabilen Einsatz verhindern.

Deswegen ist es gut und in der Praxis zielführend, die 60 Euro zusätzlich zu investieren.

Eine öffentlich erreichbare TK-Anlage braucht auch eine öffentlich erreichbare IP-Adresse und kein RFC 1918-Gedöns.

Man muß es klar sagen, NAT / NAPT und SIP / RTP passen so gut zusammen wie der Islam und Deutschland.
Verkniffene Mergel-Fans lassen sich sowas einfallen wie STUN, ALG oder Subsidiarität -- aber der Endkunde hat bloß Ärger damit.

[Richard]

Es gibt da glaube ich ein Missverständnis. Alle Telefone sind lokal an die TK angeschlossen. Die TK selbst muss nur mit dem. Telekom sip Server reden können. Brauche ich dafür wirklich den ganzen Quatsch?

[Koppelfeld]

Nein, es liegt kein Mißverständnis vor.
Ja, Du brauchst den ganzen Quatsch.

Deine IP-Anlage schreibt ihre (1918-) privaten IP-adressen in die Header. Rausgehen tut sie aber mit einer öffentlichen IP. Das kann man als Provider akzeptieren, muß man aber nicht.
Das ist aber nicht alles: Via SIP und SDP kungeln Provider und TK-Anlage aus, auf welchen Ports die eigentliche Kommunikation stattfinden soll. Nun müßte die "Firewall" mitlesen, um die nötigen Verbindungen durchschalten zu können.

Ein Blick in die Linux-Netfilter - Module, z.B. 'nf_conntrack', illustriert, wie bizarr dieses Unterfangen ist.

[cpuprofi]

Hallo Richard,

...Allerdings habe ich jetzt auch noch was vom Lancom SBC gelesen...dass irgendwelche dynamischen Freigaben für VOIP in der Firewall einrichten soll. SBC gibts offenbar nur mit der "All-IP Option"...

tja, die "dynamischen Freigaben" in der Firewall funktionieren auch nur bei IPv4 und nicht bei IPv6...

Den "tollen" Rat vom Lancom-Support die "IPv6 Firewall ausschalten" habe ich natürlich nicht befolgt, da "Sicherheitstechnischer Selbstmord" mir nicht liegt.

Grüße
Cpuprofi

[Dr.Einstein]

Hi Richard,

wenn du einen stabilen Betrieb der Telefonie gewährleisten möchtest, folge Koppelfelds Rat. Alle Ausführungen inkl. der Veranschaulichung mit Realitätsbezug stimmen.

Gruß Dr.Einstein

[hyperjojo]

hallo,

ich stimme Koppelfeld zu, mit der ALL-IP Option läuft das wirklich sauber und fein.

Vielleicht noch ergänzend: Welche TK-Anlage nutzt du? Welchen Telekom-Anschluss? Bestimmte Anlagen sind mit LANCOM getestet, dass auch eine direkte Kommunikation ohne ALL-IP Option mit Telekom-Anschlüssen einwandfrei funktioniert.

Gruß hyperjojo

[Richard]

Eine Octopus FX3 mit IP Readiness-Option

Ps: Hat jemand von euch vielleicht einen Link zu einer Seite wo diese Thematik genauer beschrieben wird? Ich bin Informatiker, hatte aber leider bis jetzt nicht viel mit VOIP/VOIP-Anlagen zu tun. Ich hatte jetzt ganz naiv gedacht die TK-Anlage baut einfach selbst eine Verbindung zum SIP-Server der Telekom auf (durch das NAT) und kommuniziert dann wechselseitig über diese offene Session. Offenbar ist das Problem ja doch deutlich komplexer.

[hyperjojo]

Hallo,

die FX3 sollte problemlos - genau wie du es möchtest -auch ohne die ALL-IP Option am Telekom Anschluss funktionieren. Den SIP-ALG musst du dabei ausschalten, die ALL-IP Option ist hier nicht erforderlich.
Das Szenario ist getestet und offiziell freigegeben.

Wenn die IP-Readiness gebucht wurde, sollte sich die Fernbetreuung der Anlage um die Umstellung kümmern. Du brauchst da eigentlich selbst nichts zu tun.

Gruß hyperjojo

[Richard]

Danke für die Antwort. Dann ist soweit alles klar.

Aber noch kurz eine Rückfrage nur(!) zum Verständnis : Was ist jetzt genau der Unterschied zwischen SIP-ALG und SBC(Session Border Controller)? SIP-ALG soll ja (irgendwie) die nötigen Ports in der Firewall öffnen, damit die Kommunikation (automatisch) abläuft. Bei SBC steht das Gleiche. Oder ist SBC einfach der Oberbegriff und SIP-ALG der ausführende Teil von SBC?

[Dr.Einstein]

@hyperjojo: Müsste dann nicht im Lancom der UDP Timeout erhöht werden? Die Default Werte vertragen sich soweit mir bekannt ist nicht mit dem ReRegister der Unify.

Gruß Dr.Einstein

[hyperjojo]

hallo,

das ist mir nicht bekannt. Habe auch gerade nochmal nachgeschaut und keine dementsprechende Info gefunden.

Gruß hyperjojo

[Koppelfeld]

Moinsen !

Danke für die Antwort. Dann ist soweit alles klar.

Hahahahahahahahahaha, der war gut. Habe ich in der Informationstechnologie seit 30 Jahren nicht mehr gehört.

Und nein, es ist gar nix klar:
"Oktopus F X 3", das ist etweder die infame SIEMENS-Wandwarze (die würde ich gleich auf die Sondermülldeponie bringen) oder aber eine SIEMENS HIPATH 3500. Gut, mittlerweile hat sich die Farbe geändert, sie kommt jetzt in Grün daher, aber das kaputte Netzteil ist gleichgeblieben.
Also ehrlich, da ist die "IP-Readiness" noch Dein kleinstes Problem, hier meine letzten Erlebnisse damit:
http://telefonanlagenforum.de/forum/thr ... nder.5795/

Wenn Du dir trotzdem den Ärger antun willst und ein kühles Plätzchen gefunden hast:
Es handelt sich bei diesem System um eine reinrassige ISDN-Anlage, die zwar "IP" kann (es gibt eine lokale Netzwerkkarte zur Systembedienung, aber darüber läuft kein VoIP), ansonsten aber über ein klassisches TDM-Koppelfeld verfügt. Man kann allerdings eine "HXGS" - Karte 'reinstecken, das ist sehr edle Hardware, aber ich würde mich nicht trauen, diesen proprietären Klunker an einem Privatkundenanschluß zu betreiben. Man muß auch einmal an Sicherheits- und Kostenaspekte denken, gerade erhalten viele unserer Kunden Anrufe an die Nebenstelle 0037-xxxxxxx. 0037, das ist Bhutan.
Da kannst Du die Gebührenuhr als Ventillator benutzen. Es gibt ein Telekom-Team, das nichts anderes tut, als im Netz nach falsch konfigurierten SIEMENS-Anlagen zu suchen, um die Kunden vor dem Schlimmsten zu schützen. Schon mit ISDN brachte man am Wochenende leicht 6.000,-- zusammen (mit einem Primärmultiplexanschluß auch 20.000,--, haben Kunden von uns schon unfreiwillig getestet), aber mit einem leistungsfähigen Internetanschluß "schafft" man ein Vielfaches.

Bevor man also einen solchen Havaristen aus dem vorigen Jahrhundert mit dem nackten Arsch ins Internet läßt, freut man sich über einen "Session Border Controller".

Aber noch kurz eine Rückfrage nur(!) zum Verständnis : Was ist jetzt genau der Unterschied zwischen SIP-ALG und SBC(Session Border Controller)? SIP-ALG soll ja (irgendwie) die nötigen Ports in der Firewall öffnen, damit die Kommunikation (automatisch) abläuft. Bei SBC steht das Gleiche. Oder ist SBC einfach der Oberbegriff und SIP-ALG der ausführende Teil von SBC?

Jein.
Der "Voice Call Manager" ist kein vollwertiger SBC, aber aktuell hat irgendein Vertriebsschwafler den Begriff irgendwo gehört und weiterverbreitet, sodaß aktuell jede Hobbynutte mit Anrufbeantworter und Weiterleitung aufs "Händi" einen "SBC" will. Da konnte LANCOM nicht zurückstehen!

Es ist eher so:
Das "ALG" kannst Du ganz vergessen, es ist nur noch drin, damit die "Testonkel" diverser Verdummungsorgane wie "Connect" oder "Funkschau" ein Feature zum "Abhaken" haben.

Der "VCM" ist das eigentliche Gateway auf Applikationslevel.

[Richard]

Der "Voice Call Manager" ist kein vollwertiger SBC, aber aktuell hat irgendein Vertriebsschwafler den Begriff irgendwo gehört und weiterverbreitet, sodaß aktuell jede Hobbynutte mit Anrufbeantworter und Weiterleitung aufs "Händi" einen "SBC" will. Da konnte LANCOM nicht zurückstehen!

Es ist eher so:
Das "ALG" kannst Du ganz vergessen, es ist nur noch drin, damit die "Testonkel" diverser Verdummungsorgane wie "Connect" oder "Funkschau" ein Feature zum "Abhaken" haben.

Der "VCM" ist das eigentliche Gateway auf Applikationslevel.

Leider scheint der SBC keine eigene Dokumentation zu haben....Habe mir jetzt die Doku zum VCM angesehen. Da finde ich aber keine Angaben zum Betrieb einer echten VOIP TK Anlage hinter dem Lancom. Bei allen Angaben in der VCM-Doku wird der Lancom so konfiguriert, dass er selbst eine Verbindung zum SIP Registrar aufbaut bzw. mit den Zugangsdaten des Registrars konfiguriert werden muss. (Die ich natürlich nicht habe, wenn T-Offline die Anlage managed). Gibt es bei der All-IP Option noch zusätzliche Firewall-Regeln für VOIP oder ist davon tatsächlich für mein Szenario nichts zu gebrauchen?

Nachtrag: Oder ist mit SBC im Lancom-Bereich lediglich die SIP-Proxy-Funktion gemeint? (IP-Telefon verbindet sich lokal zu Lancom-Router und der Lancom-Router baut eine eigene Verbindung zur Gegenstelle auf?)

[Jirka]

Hallo Richard,

Bei allen Angaben in der VCM-Doku wird der Lancom so konfiguriert, dass er selbst eine Verbindung zum SIP Registrar aufbaut bzw. mit den Zugangsdaten des Registrars konfiguriert werden muss.

genau so wird es gemacht.

Die ich natürlich nicht habe, wenn T-Offline die Anlage managed.

Der Kunde bekommt in jedem Fall seine Zugangsdaten.

Oder ist mit SBC im Lancom-Bereich lediglich die SIP-Proxy-Funktion gemeint?

Ja, das ist so gemeint.

IP-Telefon verbindet sich lokal zu Lancom-Router und der Lancom-Router baut eine eigene Verbindung zur Gegenstelle auf?

Telefon oder Telefonanlage, ja. Zur Gegenstelle = zum SIP-Provider.

Viele Grüße,
Jirka