Nur einseitige Übertragung des Tons bei myPortal @work VoIP-Client

michl76

Neuer User
Mitglied seit
6 Aug 2021
Beiträge
18
Punkte für Reaktionen
0
Punkte
1
Hallo zusammen!

Ich bin neu hier und habe folgende Problemstellung:

Wir haben im Büro eine Unify OpenScape Business X3 im Einsatz (Details zu SW-Stand etc. siehe unten). Nun haben wir die Anlage zur Nutzung von myPortal@work eingerichtet.

Das Problem ist nun, dass die Nutzung bei manchen im Team funktioniert, bei anderen nicht. Bei denen ist es dann so, dass sich das Tool ganz normal und problemlos mit der Anlage verbindet und alle Funktionen verfügbar sind. Man kann also Anrufe tätigen und entgegennehmen, die Verbindung wird ebenfalls aufgebaut. Man hört auch den Gesprächspartner. Nur wird der eigene Ton nicht an den Gesprächspartner übertragen.

Woran könnte das liegen? Unser erster Verdacht war, dass der ein oder andere Router die Pakete für den ausgehenden Ton nicht durch die Firewall lässt, aber auch wenn man die betreffenden Router testweise komplett freigibt, ändert sich nichts. Am Router im Büro kann es ja kaum liegen, sonst wäre das Verhalten ja bei allen Teilnehmern gleich. Bei zweien geht es aber problemlos.

In beiden funktionierenden Fällen sind im Homeoffice Fritz!Boxen im Einsatz, es gibt aber andere mit Fritz!Box, bei denen es nicht geht.

Habt Ihr Ideen oder Tipps woran es liegen könnte?


Hier mal noch die technischen Details:

Büro:
Telefonanlage: OpenScape Business X3 / Softwarestand: osbiz_v3_R1.1.0_302
Router: Fritz!Box 7530 / SW-Stand: FRITZ!OS 07.27
Provider: Deutsche Telekom, feste IP-Adresse

In den Homeoffices ist das natürlich alles unterschiedlich, es sind verschiedene Router (Fritz!Boxen, O2-Router, Vodafone-Router), verschiedene Provider und unterschiedliche Hardware im Einsatz.

Software ist aber immer Version myPortal @work 3.3.7 (3.3.7.190) und es sind alles Macs (was aber prinzipiell keine Rolle spielen sollte).


Wäre sehr dankbar, wenn jemand helfen kann. Mein Dienstleister ist leider selbst am Ende seines Lateins.
 
Das hört sich nach NAT / Firewall Problemen an. Ist denn ein STUN Server konfiguriert? Und sind die RTP Ports auf Seite der Firma, wo die Anlage steht freigegeben?
 
Nein, STUN Server ist keiner konfiguriert.
RTP Ports sollten soweit freigegeben sein, welche sollten es denn explizit sein?

Wobei es ja bei manchen Usern geht – sollte also auf Seiten der Firma soweit passen?
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:
Okay, schaue ich mir mal an, vielen Dank! Ich muss jetzt leider los, drum wird jetzt direkt keine Rückmeldung kommen, aber ich gebe auf jeden Fall Bescheid, ob/wie ich weitergekommen bin!
 
Die Einrichtung ist eigentlich sehr ähnlich, wie bei Device@home. Guck mal die Einstellungen hier durch und vergleich das mit deiner Anlage: https://blog.techniker-meyer.de/index.php/unify/openscape-business-device-home.html
Ein Hinweis zu dem Blog:
"Beim Update der OpenScape Business, kann das Device@Home nicht automatisch über den DLI geupdated werden (hier müssen die IP Telefone z.B. manuell geupdated werden)."
Stimmt so nicht, das geht sehr wohl. (Muß natürlich in der OSBiz explizit aktiviert werden)
Und für die myPortal@work Funktion fehlt die Portfreigabe 8802. (Dieser Port reicht bei myPortal@work alleine aus)

Gruß S
 
Vollzitat von darüber gemäß Boardregeln entfernt by stoney
Danke für den Hinweis. Das hat natürlich nichts mit der ursprünglichen Frage zu tun: aber wie kommt die OpenScape Business durch die Firewall beim Homeoffice um die contact-me Nachricht an das Telefon zu schicken (also die Aufforderung den DLI zu kontaktieren, um dann den Job zu bekommen zum Updaten)? Beim DLS benötigt man dafür einen DCMP (DLS contact-me Proxy) damit das Telefon proaktiv immer wieder an diesem Proxy nachfragt, ob ein neuer Job vorliegt. Und welche Einstellung meinst du, die man einstellen müsste. Danke schonmal für die Antwort.

Viele Grüße
 
Zuletzt bearbeitet von einem Moderator:
aber wie kommt die OpenScape Business durch die Firewall beim Homeoffice um die contact-me Nachricht an das Telefon zu schicken (also die Aufforderung den DLI zu kontaktieren, um dann den Job zu bekommen zum Updaten)?
Für HFA Telefone ist natürlich die Portfreigabe 18443 Pflicht, und:
Expertenmodus - Grundeinstellungen - Telefonparameter-Bereitstellung - aktivieren, und dann den Haken "SW an @Home-Geräte verteilen" setzen.

Gruß S
 
Großartig! Danke, das werde ich Montag gleich ausprobieren. Schönes Wochenende!
 
1628494575724.png
Bild gemäß Boardregeln als Vorschaubild eingebunden by stoney

@michl76 Guck mal bei den Usern was, bei denen es funktioniert, was in dem "STUN" Feld drin steht. Ich bin der Meinung mich zu erinnern, dass Unify da mal automatisch einen eingetragen hat ,dass nun aber nicht mehr darf...
 
Zuletzt bearbeitet von einem Moderator:
Ein STUN ist hardcodiert in jedem mp@work hinterlegt.

Und nebenbei:
Für das SW Update von HFA device@home Geräten muss neben 18443 auch 8804 weitergeleitet werden.
 
Also ich habe jetzt mal weiter getestet. Die ganzen entsprechenden Ports sind im Büro-Router freigegeben.

Leider nach wie vor das selbe Verhalten. Bei mir und einer Kollegin geht es einwandfrei, bei den anderen nicht.

In einem anderen Thread ist die Rede von einem Hotfix für osbiz auf v3_R1.1.1_004 > Kann mir jemand sagen, wo ich den herbekommen könnte?
 
Hallo,
in diesem Dokument auf der Unify Wiki Seite steht wie es genau geht: https://wiki.unify.com/images/8/8c/How_To_Tutorial_myPortal_@work_Scenarios_and_Configuration.pdf
Und: https://wiki.unify.com/images/d/de/[email protected]

Es ist ein bisschen wie eine Schnitzeljagd: Im HowTo myPortal@work steht, dass in dem anderen Dokument geguckt werden soll, wie man einen Stun einrichtet:
3.1 STUN server settings
Check chapter "Configuring STUN” in guide “How to configure system
device@home” and OpenScape Business V3, my Portal @work, User Guide
section “How to add a STUN server”

Also die TK-Anlage muss einen STUN Server konfiguriert haben. Wenn du einen SIP Trunk dran hast wird das vermutlich schon eingerichtet sein:
The integrated Session Boarder Controller (SBC) function of OpenScape Business must be able to detect its public IP-address and -
ports. This is done by using the STUN protocol.
In case that the system is already connected to an ITSP with activated STUN server, no additional configuration is required. The
system is able to detect its public IP-address and port
Weiter steht explizit drin, dass auch die Clients den STUN benötigen:
STUN connectivity is needed. In order to check STUN connectivity go to
Settings > VoIP > Advanced ICE settings > Check ICE status.
Ich hab mal ein alten Screenshot rausgekramt von myPortal@work:
stun_alt.png
Da kann man sehen, dass STUN defaultmäßig eingetragen war.

Nun ein neues Bild:
stun_neu.png
Hier ist kein STUN mehr vorkonfiguriert!

Also bitte mal bei den Clients nachgucken.

Bitte um Rückmeldung
 
Wie schon geschrieben, in der Version ist ein STUN hardcodiert im @work hinterlegt.
Steht auch in den Osbiz Release Notes, oder im @work user guide:
NOTICE: The default STUN server will not appear in the ICE
servers list and you can't remove it.
Sieht man auch im @work Log oder einem Wireshark Trace.

Wenn es bei einigen geht und bei anderen nicht, würde ich prüfen ob die, bei denen es nicht geht, IPv6 oder symmetrisches NAT
verwenden.
 
Zuletzt bearbeitet:
Ich hab grade mal die Releasenotes rausgekramt und wie @xsatze gesagt hat, stimmt es tatsächlich. Hier der Auszug:
STUN server is now preconfigured for myPortal @Work VoIP usage (on premise and @home clients). The user can manually add a STUN server
in the VoIP settings under section "Advanced ICE settings" and to "check ICE status".
Ein Kollege hat mir von einem Kunden berichtet, wo ICMP in den Routern freigegeben sein musste, damit STUN funktioniert. Hab ich nicht glauben wollen, geb es aber mal so weiter. Vielleicht hilft es ja.
 
Danke für Eure zahlreichen Beiträge!

Dann werde ich mal schauen, ob es was mit dem letztgenannten Tipp (ICMP) zu tun hat.

Eine Alternative, die vielleicht auch gehen könnte, wäre, via VPN zuzugreifen. Dann haben wir aber das Problem, dass die Anbindung im Büro nicht so schnell ist und dadurch der allgemeine Datenverkehr recht langsam wird. Ich habe schon überlegt, ob man es mit VPN Splitting versucht und dementsprechend das VPN nur für @work nutzt, aber auch da bin ich ein bisschen überfordert, was meine Kenntnisse betrifft.

Jetzt versuche ich erstmal das mit ICMP.
 
Hallo zusammen! Nachdem ich einige Wochen im Urlaub war, habe ich wieder begonnen, mich mit dem Thema auseinander zu setzen. Gestern mal einen Test gemacht, wo einer der betroffenen Mitarbeiter per VPN verbunden war, aber auch da war es das selbe Problem. D.h. es hat wohl nichts damit zu tun, ob man von extern oder intern verbunden ist. Der nächste Test ist dann mal wirklich physikalisch vor Ort im dortigen LAN – ich werde berichten.
 
Wir kommen der Sache näher. Es funktioniert auch im LAN nicht, hat also nichts mit der Verbindung zu tun. Die weitere Fehlersuche hat dann ergeben, dass auf dem Test-Mac die myPortal App keinen Zugriff auf das Mikrofon hat. Dann kann es natürlich nicht gehen. Auf meinem (eigentlich identischen) Mac hat die App diese Erlaubnis.

Bildschirmfoto 2021-09-29 um 15.25.45.png
[Edit Novize: Riesenbild gemäß der Forumsregeln auf Vorschau verkleinert]

Jetzt müssen wir nur herausfinden, wie man das manuell hinbekommt, das ist nämlich nicht so einfach möglich, da auf den betreffenden Rechner myPortal gar nicht in dieser Liste auftaucht, man also auch keinen Haken setzen kann. Ich werde berichten. (Oder weiß das evtl. jemand?)
 
Zuletzt bearbeitet von einem Moderator:
Das Mac Mikro Problem sollte ab V3 FR1 HF2 (005) gelöst sein.
 
Hmm... Ich habe aber das Problem ja nicht und wir haben auf beiden Rechnern die selbe Version der App (3.3.7.190)?
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
244,868
Beiträge
2,219,771
Mitglieder
371,585
Neuestes Mitglied
PauSchmitz
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.