Desktop-App erkennt die Mobiltelefone nicht

[mabuse]

Gibt es eine (reguläre) Möglichkeit, die Desktop-App dazu zubringen, ausgehende Gespäche auch an die Mobiltelefone (hier: Yealink W56H), die mir nicht als Option angezeigt werden, zu übergeben?
Also, das ich in der App wählen kann (bzw. einen Kontakt anklicke) und mein Mobilteil klingelt und nach Abnahme gewählt wird.

Und bevor mich jetzt irgendein Schlauberger auf "Keine CTI-Unterstützung" verweist:
Das ist Unfug.

Sobald ich den Android-Client auf meinem Smartphone installiere und in der Desktop-App "Anrufen per Smartphone" einstelle, klingeln sowohl mein Smartphone als auch das Mobile Telefon, die Verbindung wird dann von dem Gerät aus aufgebaut, bei dem ich zuerst auf Abnehmen gehe.
Grundsätzlich kann die Anlage also mit dem Mobilteil verbinden, es wird mir nur in der Desktop-App nicht als Option angezeigt.

Aber diese Möglichkeit mit dem Smartphone ist natürlich nur für die Mitarbeiter brauchbar, die die App auch auf ihrem Smartphone haben wollen, aber nicht für die "normalen" Angestellten, die dies nicht wollen.

Als schnellen Workaround hab ich jetzt die App auf meinem alten Zweit-Handy, das ich eigentlich nur noch zum Pokemon Go-spielen benutze, installiert, alle Anschlüsse darauf eingerichtet und nach jeweils einem Testanruf die App wieder deinstalliert. Damit funktioniert es jetzt erst mal überall, wenn man in der Desktop-App "anrufen per Smartphone" auswählt. Anscheinend merkt der 3CX-Server nicht, das die Samrtphones nicht reagieren bzw. betrachtet die Mobilteile als Smartphone.
Aber so richtig gut finde ich so einen wüsten Hack bei einer professionellen Software, die produktiv genutzt wird ja nicht...

 

[bitn2]

Interessanter Workaround. Aber da es offiziell nicht unterstützt wird, fürchte ich das es hier dazu keine bessere Lösung geben wird.

 

[mabuse]

Was mich ehrlich gasagt so langsam dazu bewegt, doch nach einer anderen Software Ausschau zu halten.

Es geht, wird aber nicht unterstützt - was ist das denn für eine Ansage?

Auch die Sache mit den ReverseProxys nervt mich total. Jeder Sicherheitsexperte sagt, das ReverseProxys ein elementarer Schutzfaktor für die Server sind - aber 3CX unterstützt das nicht? Ich halte das für sehr bedenklich...

 

[bitn2]

Grundsätzlich verstehe ich das Dir das nicht gefällt, aber mit den DECT Telefonen und welche Funktionen zur Verfügung stehen, war ja vorher bekannt. Reverse Proxy ist eine feine Sache, aber auch nicht überall nötig oder sinnvoll. Das Debian ist über iptables schon dicht und in der Regel hat man davor noch eine Firewall. Wenn Du die Anforderungen an Deine Telefonanlage weisst, dann würde ich danach den Anbieter aussuchen und nicht umgekehrt.

 

[mabuse]

Nein, eigentlich nicht.
Ich (respektive unser IT-Dienstleister) wollte eigentlich eine andere Anlage haben (Asterixs/PBX), aber die war aus irgendeinem mir unerfindlichen Grunde nicht kompatibel mit dem SIP-Trunks der Deutschen Glasfaser. 3CX war eine schnelle Notlösung, die mir aber auf Anhieb erst mal gut gefallen hat. Die Ernüchterung kam dann erst hinterher.

Und was den Reverse-Proxy angeht: Der ist immer - immer, immer, immer! - sinnvoll. Schon alleine um die Anzahl der offenen Ports und damit die reine Angriffsfläche zu verkleinern. Von der doppelten Authentifizierung und den erweiterten Sicherheitsmaßnahmen ganz abgesehen.

Hab aber gestern eine Seite gefunden, auf der engagierte Hacker auch dieses Problem gelöst haben.
Es scheint so, als würde 3CX sein eigenes Produkt nicht vollständig verstehen - und im Zweifelsfalle alles mit "wird nicht unterstützt" abzublocken, anstatt sich weiter zu entwickeln.

Schade eigentlich, das Ding hätte Potential...

 

[bitn2]

Ich bin da sicherlich auch nicht mit allem zufrieden was 3CX angeht. Aber vieles lässt sich damit kostengünstig umsetzen und der Support im Forum und von 3CX ist sehr gut.

Die IPtables der 3CX ist eh schon so Dicht das nur die Ports offen sind die die Anlage braucht, alles andere mach ich über die davor geschaltete Firewall dicht. zb die SIP anfragen nur aus dem Netz des Anbieters usw. Mehr muss da eigentlich nicht sein. Reverse Proxy nutze ich nur diverse andere Dienste die von aussen zu erreichen sein müssen und dafür ist das wirklich sehr gut.

 

[mabuse]

Ja, genau.
Die Benutzerschnittstelle würde ich gerne über den RP schieben, es geht nicht um die Ports für die SIP-Trunks oder die Mobile App. Aber ich hab einen RP für unser ERP, Wiki, Kanbanboard und Mattermost (und früher das Telefonbuch von STOS), es wäre echt toll, wenn auch die Benutzerseiten von 3CX darüber laufen würden.
Der Traffic auf den anderen Ports dürfte aufgrund des Protokolls den üblichen Hackern eh unverständlich sein bzw. keine Angriffsfläche bieten.

Denn auch das Beharren von 3CX auf Port 443 geht mir auf die Nerven. Erstens ist das ein Port, der von Hacker/Scriptkiddies im 10 Sekundentakt abgeklopft wird, und wenn ich den Exchange-Server nicht schon nach außen verlagert hätte, würde der auch damit kollidieren. Mit einem RP wäre das alles kein Problem, der würde intern umleiten.

 

[bitn2]

443 ist bei mir dicht zur PBX, den nutze ich für den Reverseproxy. Was meinst Du damit das sie darauf bestehen? https läuft bei mir auf 5002 für PBX.

Du meinst den Webclient über den RP? Hmm, müsste ich mal testen.

 

[bitn2]

Admin Interface geht easy über reverse Proxy, grad mal ausprobiert.

 

[mabuse]

Wie hast du das gemacht?

Und was benutzt du als RP? Ich bin auf Hiawatha.

 

[bitn2]

NGINX Reverse Proxy, da musste ich nicht viel einstellen. Domain und meinen HTTPS Port 5002, weiterleitung auf meine interne IP der PBX

 

[mabuse]

Ja, den wollte ich mit auch mal ansehen <seufz> woher nur die ganze Zeit nehmen?

 

[bitn2]

Kann ich nur empfehlen, wirklich einfach zu administrieren. Hab den bei mir einfach als Docker laufen.

 

[bitn2]

Hier mal was zum Thema RP und 3CX: https://www.3cx.com/community/threads/security-client-ip-behind-reverse-proxy.74967/