NFON Cloud Telefonie beim Einsatz von DATEVNET -Erfahrungen

[#1]

Hallo,

hat hier jemand schon Erfahrungen mit einem Cloud Telefonie Anbieter gesammelt und gleichzeitig DATEVNET im Einsatz?

Wir möchten uns von unserer alten Telefonanlage verabschieden und die "Anlage" in die Cloud verlagern.

Des weiteren sollen möglichst keine IP-Telefone mehr am Arbeitsplatz eingesetzt werden, sondern sog. Softphones am PC, Tablet oder Handy, um überall unter der Bürodurchwahl erreichbar zu sein, ohne Umleitungen einrichten zu müssen.

Dazu haben wir uns bislang die Cloud-Lösung "Cloudya" von der Firma NFON angeschaut.

Diese macht im Großen und Ganzen das was sie soll (CTI, NCTI und DATEV-Telefonie sind nicht zwingend erforderlich).

Mit DATEVNET läuft es allerdings nicht, da die notwendigen Ports (???) nicht so ohne weiteres freigeschaltet werden können.

Den DATEV-Router mit einer Schleife zu umgehen wird von uns nicht favorisiert.

Vielen Dank schon mal für die Hilfe 🙂

[#2]

---

@lübbobroers schrieb:

hat hier jemand schon Erfahrungen mit einem Cloud Telefonie Anbieter gesammelt und gleichzeitig DATEVNET im Einsatz?

---

Jap, @rahagena nutzt diese Kombination aber mit Swyx. Aber mehr schlecht als Recht bzw. nicht so, wie man sich das in 2021 vorstellt, so wie sich das HIER liest. 

Der ganze Thread von vorne: Telefonanlagen für DATEV Telefonie

Statt nFON würde ich eher QSC / Nouvelcom empfehlen. Falls angedacht ist, ins DATEVasp zu wechseln, sind laut DATEV nFON und Nouvelcom die einzigen Anbieter, die es technisch sauber mit den DATEV Sicherheitsvorgaben lösen können. 

---

@lübbobroers schrieb:

Mit DATEVNET läuft es allerdings nicht, da die notwendigen Ports (???) nicht so ohne weiteres freigeschaltet werden können.

---

Das wird wohl bei vielem der Knackpunkt sein. Ports sind wie Türen im Internet zu verstehen. Port 80 ist für das unverschlüsselte surfen zuständig; Port 443 für Verschlüsseltes; Port 25 ist für E-Mail reserviert und für Telefonie gibt es eigene "Türen", die DATEV aber im DATEVnet aus Sicherheitsgründen schließt. Ob man sich die öffnen lassen kann, muss man mit der DATEV klären. Nouvelcom reichen 443 und 80 meine ich aus. Das lässt auch DATEV ohne Änderung durch. 

Tatsächlich würde ich aber, wenn CTI und der grüne Hörer egal sind, das voneinander trennen und die CloudPBX von außen via SDSL anbinden und DATEVnet so "umgehen". Eigenen Switch oder VLAN dazu. Eigenes DHCP und IP-Telefone dazu. Dann wird so eine Umsetzung von Softphones aber schwierig, weil die Geräte ja in einem anderen Netz hängen und sich nicht sehen. 

[#3]

Nach intensiven Gesprächen mit weiteren Anbietern zeigt sich, dass DATEVnet in Verbindung mit Homeoffice und IP-Telefonie aus der Cloud die Spaßbremse ist. 

Deshalb wird bei uns die VPN Verbindung künftig nicht mehr über DATEVnet hergestellt, dann kommen auch die Kollegen im Homeoffice rein. 

Wenn Anbindung an DATEV nicht notwendig ist, ist ein gesonderter Internetzugang für die Telefonie nicht das Einfachste, sondern auch das Sicherste, denn so bleibt das Kanzleinetz frei von selbstgebauten "Türen". 

[#4]

Hallo,

das mit dem "umgehen" war auch die Antwort vom DATEVnet-Support.

Das ist aber ja nicht Sinn der Sache. Wir wollen natürlich die Sicherheit von DATEVnet beibehalten.

Ein weiteres eigenständiges Netz aufzubauen, gibt die Infrastruktur im Hause nicht her (nur max. eine Netzwerkdose/Arbeitsplatz vorhanden). Da bliebe nur noch ein VLAN. Dann "sehen" sich die Netze jedoch i.d.R. nicht.

Wenn doch, hat man sich eine Sicherheitslücke gebaut. Da würde ich dann doch vorziehen, einzelne Ports und Zieladresse bei DATEVnet freischalten zu lassen.

[#5]

---

@lübbobroers schrieb:

Wir wollen natürlich die Sicherheit von DATEVnet beibehalten.

---

Müsste man so einrichten können, dass die Sicherheit nicht arg drunter leidet.

---

@lübbobroers schrieb:

Ein weiteres eigenständiges Netz aufzubauen, gibt die Infrastruktur im Hause nicht her (nur max. eine Netzwerkdose/Arbeitsplatz vorhanden).

---

Von wann ist die Verkabelung im Haus? 😳 Wenn die Grundlagen nicht stimmen, würde ich mich erst darum kümmern, weil eine aktuelle CAT7 / Glasfaserverkabelung der Grundstein einer jeden Kommunikation für alle Geräte ist und z.B. PoE meist nur mit aktueller Verkabelung gut und dauerhaft funktioniert. Nicht, dass auch nur 4 Adern an der Dose aufgelegt sind? Dann sind maximal 100Mbits möglich. Technik von 198x. 

---

@lübbobroers schrieb:

Da würde ich dann doch vorziehen, einzelne Ports und Zieladresse bei DATEVnet freischalten zu lassen.

---

Wenn DATEV das für Sie macht. Wenn DATEV dadurch die eigene Sicherheit gefährdet sieht, wird DATEV die Ports trotz Antrag nicht öffnen. So würde ich zumindest verfahren und handeln, wenn es DATEV intern Vorschriften gibt. 

[#6]

Ich schreib hier jetzt mal über den aktuellen Stand unserer Bemühungen. 😀

Nach einigen Gesprächen mit dem DATEVnet- und dem NFON-Support, wurden folgende Änderungen nach und nach vorgenommen:

- SIP-ALG wurde im Router aktiviert => hat aber nichts gebracht.

- Der SIP-Port 5060 und das Zielnetz 109.68.96.0/21 (NFON) wurden freigeschaltet => Dadurch waren die IP-Telefone erreichbar (haben geklingelt 😉 und konnten provisioniert werden. Man konnte jemanden anrufen, aber nicht hören. 😶

- Die RTP-Port 4000-4999 und 10000-60000 wurden freigeschaltet => Dadurch konnte jetzt mit den IP-Telefonen telefoniert werden und die Sprache wurde übertragen. Allerdings fehlten Funktionen, wie Telefonbuch etc.

Wir werden also Wohl oder Übel ein weiteres Gateway öffnen müssen. Dies kann dann z.B. auch eine FritzBox 7490 sein. So in etwas realisiert auch die Firma Passcom (und viele Andere auch) ihre "DATEV-Lösung". 

Die IP-Telefone bekommen eine feste IP-Adresse und als Gateway die 2. neu vergebene Gateway-Adresse.

Die PC's werden weiterhin über DHCP bedient und gehen ausschließlich über DATEVnet ins Internet.

Dann kann man zwar immer noch nicht mit dem Softphone telefonierten; jedoch können dessen weiter Funktionen an das IP-Telefon weitergegeben werden.

Dadurch wäre die Sicherheit von DATEVnet weitestgehend gewährleistet, eine Umstellung auf IP-Telefonie vollzogen und das Home-Office mit eingebunden.

Die nächste Idee dazu ist die Einbindung von Microsoft Teams.

DATEV kann ja mit Teams umgehen und NFON auch.

Wenn man dann das Softphone durch Teams ersetzt, sollten doch alle Beteiligten miteinander kommunizieren können. 😅

Wir bleiben also am Ball. 👍

[#7]

---

@lübbobroers schrieb:

So in etwas realisiert auch die Firma Passcom (und viele Andere auch) ihre "DATEV-Lösung". 

---

Das verstehe ich nicht? 🤔  PASCOM und DATEVasp gehen nicht direkt, weil sich das DATEV RZ nicht mit der PASCOM Cloud TK unterhalten kann und man deshalb via PASCOM roter Box den Traffic aus dem DATEVasp zur Cloud TK leiten muss. 

---

@lübbobroers schrieb:

Die nächste Idee dazu ist die Einbindung von Microsoft Teams.

---

Teams? Aka Microsoft aka Microsoft365 aka DSGVO DATEV Fragen und so weiter? 😂

---

@lübbobroers schrieb:

DATEV kann ja mit Teams umgehen und NFON auch.

---

Wie meinen? 🤔  Dann bräuchten wir ja erst gar keine DATEV Idea dazu: MS Teams an DATEV Telefonie anbinden

[#8]

- Es ging mir hier in erster Linie um die Problematik beim Einsatz von DATEVnet. DATEVasp ist hier nicht mein Thema.😀

- Bei Teams habe ich mich wohl falsch ausgedrückt. Ich meinte, obwohl man DATEVnet verwendet, funktioniert Teams. 😅. Eine direkte Anbindung brauche ich nicht.

[#9]

Hallo,

habe den Beitrag eher zufällig gesehen.  Der betrifft eins meine Spezialgebiete uns so freue ich mich, auch einmal helfen zu können anstatt nur Anfängerfragen zu stellen.

"Spaßbremse" bei "Cloud-Telephonie" ist nicht DATEV-NET, sondern das verwendete Protokoll SIP.  Bei dessen Design ging man davon aus, daß jedes Endgerät eine eigene, öffentlich erreichbare IP-Adresse hat.  Ist doch auch logisch, wenn ich von der Ferne aus erreichbar sein will.  Irgendwann aber wurde der IPv4-Adreßraum zu klein (oder die Anzahl der PCs zu groß, ich tendiere zu letzterem).  Daher hat man sich vor einem Vierteljahrhundert ein Nachfolgeprotokoll ausgedacht, das so schlecht ist, daß es keiner ohne Not benutzt.  Stattdessen haben sich alle möglichen Leute irgendwelche Flickschustereien ausgedacht, die mal funktionieren und mal nicht.   Damit sind insbesondere die "Portweiterleitungen" im Zusammenhang mit sog. "NAPT" gemeint.

Das KANN klappen bei einem Telephon, das geht aber sehr gerne schief bei mehreren angeschlossenen Telephonen.

Und bevor hier wieder ketzerische Bemerkungen aus Iserlohn kommen:   Die UDP-Haltezeit der meisten Router beträgt 20 Sekunden, und nein, die auf 120 Sekunden hochzusetzen ist i.d.R. keine gute Idee, wel bei zu viel DNS- und sonstigem UDP-Traffic die Tabellen gerne einmal überlaufen.

Ein "SIP-ALG", also "Application Level Gateway", kann hilfreich sein.  Vor allen Dingen, wenn es sich um ein einziges Telephon handelt.

"DATEV-Net" setzt glaube ich einen LANCOM - Router voraus.   Das ist von Hause aus nicht die schlechteste Option.  Für Ihren LANCOM können Sie sich eine Option besorgen namens VCM, "Voice Call Manager".   Das ist im Prinzip nix anderes als eine Telephonanlage, die unter der (öffentlichen!) Router-IP zu erreichen ist.

Dort registrieren Sie jetzt alle Ihre gebuchten Accounts.   Sie können auch sofort sehen, ob das geklappt hat.   Ihre Telephone im LAN registrieren Sie jetzt wiederum auf dem LANCOM, nachdem Sie für diese Accounts angelegt haben.   Nun legen Sie eine Routing-Tabelle an zwischen den NFON- Accounts und den internen Telephonen.

Und schon klappt es, der LANCOM-VCM übernimmt (soweit er das kann) auch die Priorisierung der VoIP - Pakete.   NOCH BESSER:  Sie können ganz selektiv den Telephonverkehr über einen andern (Backup-) Netzprovider auslagern.

Dann hätten Sie, für 60,--, Ihr Problem gelöst.

So wirklich einfach ist das nicht, aber ich bete Sie gern durch, 0171-3758928.

Wenn Sie erstmal einen Anschluß erstellt haben, können Sie den Rest kopieren.

Die beschriebene Lösung ist solide.

Dennoch rate ich von CLOUD-Telephonie ab, das trenne ich innerhalb eines gesonderten Beitrages ab.

[#10]

---

@Koppelfeld schrieb:

So wirklich einfach ist das nicht, aber ich bete Sie gern durch, 0171-3758928.

---

Beten 🙏 muss man auch noch? Na das klingt jetzt aber nicht wirklich zuverlässig in meinen Ohren 😄🙊.

---

@Koppelfeld schrieb:

Dennoch rate ich von CLOUD-Telephonie ab, das trenne ich innerhalb eines gesonderten Beitrages ab.

---

In Bezug auf DATEVnet oder allgemein? 🤔 Ich kann mir nichts besseres vorstellen, wenn man wirklich zu 100% flexibel sein will und/oder mehrere Standorte auch ohne VPN und Co. verbinden möchte; aber trotzdem alle Vorteile einer TK (statt pro Standort) zu nutzen. 

PASCOM macht's vor, was wie alles geht 😎. 

[#11]

Verstehe ich das richtig, dass ich mir damit die Gateway-Spielereien für Verbindung vom Telefon in die Telefoncloud sparen kann? Hilft mir das für Softphone aus dem Homeoffice unter DATEVnet (Cloud Telefonanlage)? 

[#12]

Was spricht unterdessen GEGEN Cloud-Telephonie ?

Die Telephongebühren sinken ständig.  Ein Kunde ist, bei besserem Service, von 2.000,--/Monat auf unter 200,-- / Monat "gerutscht".  Die Provider machen sich natürlich Gedanken, wie sie ihre Kunden "binden" können - und das hatte doch schon mit den "Händy's" ganz prima geklappt -- warum nicht also Telephone subventionieren ?

Nach kurzer Zeit zahlt man als Kunde dabei drauf, weil man seinen Telephonieprovider natürlich nicht wechseln kann.

In Deutschland gibt es keine Idee, die so hirnverbrannt sein könnte, daß sie nicht sofort umgesetzt würde.  Deswegen telephonieren manche Menschen innerhalb der "Cloud" von Schreibtisch zu Schreibtisch, in unmittelbarer Hörweite, mehrere tausend Kilometer durchs Internet.

Jeder Dorfelektriker weiß:   "Habe ich ein großes Haus, dann sehe ich für jede Etage eine Unterverteilung vor".  Es käme auch niemand auf die Idee, seine eigene Wasserleitung direkt zum Wasserwerk zu führen.   Wirklich niemand?  Doch, die Post machte es so; jeder Teilnehmeranschluß besaß eine "gewidmete" Doppelader zum "Amt".   Deswegen (psst, geheim) wurde übrigens ISDN erfunden, um so eine Doppelader wenigstens mehrfach nutzen zu können.

Jetzt kommt noch das in meinem vorherigen Beitrag beschriebene "NAT" resp "NAPT" dazu und dann wird es ganz übel.

Und so passiert etwas ganz lustiges am Markt:  Man kann, in Losgrößen von 20 bis 50 Stück, regelmäßig kaum gebrauchte (teilweise sind noch die Folien auf dem Display) Telephone am Markt kaufen, und wenn man nachschaut, dann sind die allesamt "provider-gebrandet".   Das sind alles Remittenden aus gecrashten "Cloud-Projekten", und das gibt mir dann zu denken.

SO haben wir neulich die "Cloudtelephonie" genutzt:   25 beinahe neue Telephone "Yealink T48S" beim Broker gekauft, für 70,-- das Stück.  Dazu eine "normale" VoIP-Anlage, die auch über eine öffentliche statische IP verfügt.  Das praktsche dabei:  Die können von Haus aus VPN, ein Mitarbeiter bekommt also ein zweites Telephon mit nach Hause, steckt es in seine "Fritzbox" und kann telephonieren.   Dazu noch einen "x2go"-Client auf dem privaten PC und fertig ist der Arbeitsplatz.

Im Ursprungsposting wurde aber noch etwas anderes angesprochen:

Die bekannte Kabelknappheit.  Nicht wenige benutzen ja das LAN-Kabel zum Zugriff auf WTS oder Fileserver, ich finde das ja eher gruselig.   Aber jetzt auch noch so einen "Chinakracher" dort hineinhängen, der ja im Prinzip nix weiteres ist als ein Linux-Computer, der mit zahlreichen Backdoors ausgestattet ist ?

Also, da sollte man, wie schon vorgeschlagen, VLANS nehmen, also

- VLAN- und PoE - fähigen Swich

- Telephon erhält aus der "Produktiv-EDV" eine temporäre DHCP-Adresse und die Option 132 "Dein Ziel-VLAN ist die 16 (beispielsweise)"

- Telephon startet neu und kippt sein "Produktiv-VLAN" hinten am eingebautes Switch ab, benutzt aber INTERN die zugewiesene 16.

So kann das einfach funktionieren, aber nicht mehr mit einem "Nfon-Provisioning".

[#13]

---

@rahagena  schrieb:

Verstehe ich das richtig, dass ich mir damit die Gateway-Spielereien für Verbindung vom Telefon in die Telefoncloud sparen kann? Hilft mir das für Softphone aus dem Homeoffice unter DATEVnet (Cloud Telefonanlage)? 

---

Aber JA.   Weil ja Sie entscheiden, in welchem Netz die Telephone betrieben werden, wobei es egal ist, ob es ein Softphone oder ein "richtiges" ist.

[#14]

---

@metalposaunist  schrieb:

---

@Koppelfeld schrieb:

So wirklich einfach ist das nicht, aber ich bete Sie gern durch, 0171-3758928.

---

Beten 🙏 muss man auch noch? Na das klingt jetzt aber nicht wirklich zuverlässig in meinen Ohren 😄🙊.

Ich wünschte, ich wäre gläubig, dann hätte ich noch eine zusätzliche Option für den Fall, daß hier wieder ein Windows-Update danebengeht.

Die Gebrüder Pasquay leisten gute Arbeit (kommen ja, wie wir auch, aus der IBM-Ecke), aber zaubern können die auch nicht.

Wenn Sie maximale Flexibilität wollen, dann nutzen Sie tatsächlich die eingebaute OpenVPN-Funktionalität im Telephon selbst.   Natürlich komplett ins Provisioning eingebunden.

Das hat sich bei uns "in Corona-Zeiten" als absolut zuverlässig erwiesen.

DATEV NET mit Clientsoftware ist auch keine schlechte Option, nur  --  je nach Qualität des Headsets schwankt die Qualität der Echokompensation doch heftig.

Aus dem Krankenhaus heraus konnte ich ohne Probleme mit Blackberry + VPN + Softphone telephonieren, über Krankenhaus-WLAN.   Das KANN klappen, muß aber nicht.

[#15]

Hallo,

klingt alles interessant.

Jedoch haben DATEVnet-Nutzer keinen Zugriff auf den LANCOM-Router und können somit bislang auch keine VCM-Option hinzubuchen.

Also doch wieder der Umweg über ein zweites Gateway. 🤔

[#16]

Hallo,

ein zusätzliches Gateway bringt eher nichts, es sei denn, Sie verfügen über ein eigenes (v4-) Netz, z.B. ein /29er, aus dem Sie dem "Zusatzgateway"  eine Adresse zuweisen können.

Soweit ich mich aber erinnere (habe es seinerzeit nicht selbst konfiguriert):

Sie können den Router zurücksetzen.  Dann istallieren Sie den VCM und legen einen zweiten administrativen User an.   Dann geben Sie die Provider-Zugangsdaten ein.

Schlußendlich fürhren Sie die DATEV-Konfiguration mit einem Windows-Tool durch, welches DATEV bereitstellt (für TR-069 ist man sich zu fein).