Zeige Ergebnis 1 bis 10 von 10

Thema: App / UCC Client von extern kein Ton

  1. #1
    STARFACE User

    Registriert seit
    28.07.2017
    Beiträge
    54

    Frage App / UCC Client von extern kein Ton

    Moin Zusammen,

    ich habe bei einem Kunden massive Probleme von extern über die Anlage zu telefonieren.
    Die Ports sind alle entsprechend dem Manual von extern an die SF weitergeleitet (Speedlink 5501).
    Intern funktioniert alles (inkl. extern Telefonie ein- und ausgehend über easybell Trunk und Telekom All IP MSNs) reibungslos, sowohl über LAN als auch WLAN, sowohl UCC als auch App.

    Von extern klappt die Anmeldung und die Nutzung (Anrufen, annehmen, etc.) sowohl in der App als auch dem UCC Clienten.

    Lediglich der Ton in BEIDE Richtungen bleibt aus.

    Habe schon versucht mit tcpdump mehr herauszufinden. Leider kommen keine UDP Pakete im Bereich 10.000-20.000 auf der Starface an.
    tcpdump auf der Starface gibt mir nur eine Kommunikation auf Starfaceport 5222 und 5061 in beide Richtungen mit dem Clienten.

    Selbst mit dem Packettracer im Speedlink 5501 kommt hier scheinbar nichts aus dem Portbereich als UDP auf dem WAN Interface an.

    Senden die App und der UCC Client noch über UDP im entsprechenden Portbereich oder ist das mittlerweile verschlüsselt oder über TCP?

    In der Starface ist konfiguriert, dass diese hinter einem NAT ist und als externer Host der Entsprechende Hostname eingetragen, der sowohl intern (intern aufgelöst) als auch extern (über externe IP und NAT) erreichbar ist. Der gleiche Hostname ist auch als XMPP Hostname und Hostname der Starface selbst konfiguriert.

    Jemand hier einen nützlichen Tipp? Langsam bin ich mit meinem Latein am Ende.

    Grüße
    Arne
    Geändert von aeichhorn (13.08.2019 um 19:18 Uhr)

  2. #2
    STARFACE Crew
    STARFACE User

    Registriert seit
    05.06.2019
    Ort
    Bochum
    Beiträge
    10

    Standard

    Zitat Zitat von aeichhorn Beitrag anzeigen
    Habe schon versucht mit tcpdump mehr herauszufinden. Leider kommen keine UDP Pakete im Bereich 10.000-20.000 auf der Starface an.
    Hi Arne, das ist auf jeden Fall der richtige Ansatz um das Problem einzugrenzen.

    Zitat Zitat von aeichhorn Beitrag anzeigen
    Senden die App und der UCC Client noch über UDP im entsprechenden Portbereich oder ist das mittlerweile verschlüsselt oder über TCP?
    Ja genau so ist es, die Apps und Clients verschlüsseln komplett, deswegen siehst Du das im Wireshark nicht als RTP. Die Verschlüsselung lässt sich auch nicht deaktivieren. Daher am besten mal mit einem Tischtelefon testen, falls Du Modelle verwendet wo verschlüsselt wird kann man dies unter "Telefone, Erweiterte Einstellungen, "Verschlüsselung zu unterstützten Telefonen aktivieren" ausschalten".

    Gruß
    Andreas

  3. #3
    STARFACE User

    Registriert seit
    28.07.2017
    Beiträge
    54

    Standard

    Moin Andreas,

    welche Ports sind denn für die App und ggf. den UCC Clienten explizit notwendig für eine korrekte Funktionsweise?
    Eingehend TCP: 5222, 433 und 5061
    Das müsste dann ja vom Prinzip reichen oder nicht?

  4. #4
    STARFACE Expert
    Benutzerbild von nucom
    Registriert seit
    11.12.2012
    Ort
    9443 Widnau
    Beiträge
    1.554

    Standard

    Ein Trick zum abhören des ganzen ist, den Mitschnitt (*1) während des Rufs zu aktivieren.

    Wenn du das machst, nimmt die STARFACE das Gespräch auf.
    Aufgrund davon was du hörst, oder nicht hörst lässt sich einschränken, wo das Problem liegt.

    Kannst du mal noch Versuchen ein Gespräch aufzubauen, und anschliessend *1 drücken. Dies aktiviert die Aufzeichnung des Gesprächs.

    Anschliessend versucht von beiden Seiten etwas zu sagen, und hör dir das Ergebnis an.

    Wenn du den Internen Teil hörst, aber den externen nicht gehen die Eingehenden Pakete schon vorher verloren (Firewall Eingehend), während deine ausgehenden Sprachpakete nach der Starface Verloren gehen (Vermutlich auch Firewall ausgehend)
    Hörst du beide Seiten, Verlieren sich die Pakete irgendwo im Netz (Routing hausintern)

    Das Gesprächsfile geht an die E-Mail Adresse des internen SF-Benutzers, der die Aufzeichnung ausgelöst hat.
    //edit: Recycled von: https://support.starface.de/forum/sh...nzufügen/page2

    MfG

    Fabian
    Geändert von nucom (16.08.2019 um 09:16 Uhr)
    Modulhersteller aus der Schweiz
    __________________________________________________ ________
    STARFACE Excellence Partner: Info | Certified Module Creator Kontakt

  5. #5
    STARFACE User
    Benutzerbild von t.meyer
    Registriert seit
    14.05.2018
    Beiträge
    73

    Standard

    Nur zum Verständnis: unter Server/Netzwerk/SIP Einstellungen steht als Externe Adresse der Hostname drin (also z.B. pbx.domain.de) oder die tatsächliche externe IP ? Wenn dort der Hostname drin steht wird der ja über den DNS auf die interne IP aufgelöst - das geht dann nicht.

    Viele Grüße,
    Torsten

  6. #6
    STARFACE User

    Registriert seit
    28.07.2017
    Beiträge
    54

    Standard

    Zitat Zitat von t.meyer Beitrag anzeigen
    Nur zum Verständnis: unter Server/Netzwerk/SIP Einstellungen steht als Externe Adresse der Hostname drin (also z.B. pbx.domain.de) oder die tatsächliche externe IP ? Wenn dort der Hostname drin steht wird der ja über den DNS auf die interne IP aufgelöst - das geht dann nicht.

    Viele Grüße,
    Torsten
    Also würde es ggf. etwas helfen, wenn ich hier den dyndns reinschreibe, der intern nicht direkt aufgelöst wird, sodass die Starface den Hostnamen immer gegen eine Externe IP auflöst?
    Der Hostname zeigt von extern per CNAME auf den dyndns und intern auf die starface IP.
    Das scheint ein guter Anhaltspunkt zu sein.
    Wie verhalten sich dann die internen Telefone? Versuchen die dann ihre SIP Pakete auch auf die externe Adresse zu schicken, oder bleiben die trotz dessen intern?

    UPDATE: Habe das eben angepasst. Die App läuft nun tadellos! Meine Güte... Die Frage mit den internen Telefonen wäre dann noch zu klären. Wäre ja blöd, wenn die nun den Umweg über den Router versuchen zu gehen, als den direkten weg.
    Geändert von aeichhorn (16.08.2019 um 14:48 Uhr)

  7. #7
    STARFACE Expert
    Benutzerbild von andreas.stein
    Registriert seit
    04.12.2014
    Ort
    Bitburg
    Beiträge
    483

    Standard

    Zitat Zitat von aeichhorn Beitrag anzeigen
    Also würde es ggf. etwas helfen, wenn ich hier den dyndns reinschreibe, der intern nicht direkt aufgelöst wird, sodass die Starface den Hostnamen immer gegen eine Externe IP auflöst?
    Der Hostname zeigt von extern per CNAME auf den dyndns und intern auf die starface IP.
    Das scheint ein guter Anhaltspunkt zu sein.
    Wie verhalten sich dann die internen Telefone? Versuchen die dann ihre SIP Pakete auch auf die externe Adresse zu schicken, oder bleiben die trotz dessen intern?

    UPDATE: Habe das eben angepasst. Die App läuft nun tadellos! Meine Güte... Die Frage mit den internen Telefonen wäre dann noch zu klären. Wäre ja blöd, wenn die nun den Umweg über den Router versuchen zu gehen, als den direkten weg.
    Wie sich die internen Telefone verhalten, hängt ganz von deinem internen DNS-Server ab. Ich würde für interne DNS-Anfragen im lokalen DNS-Server (Firewall/DomainController/whatever) einen A-Record für den Hostname der Starface anlegen, der auf die interne IP der Starface verweist. Damit ist dann alles in Butter.
    Viele Grüße,

    Andreas Stein
    IT Fabrik Systemhaus GmbH & Co. KG

    STARFACE Excellence Partner

  8. #8
    STARFACE User

    Registriert seit
    28.07.2017
    Beiträge
    54

    Standard

    Zitat Zitat von andreas.stein Beitrag anzeigen
    Wie sich die internen Telefone verhalten, hängt ganz von deinem internen DNS-Server ab. Ich würde für interne DNS-Anfragen im lokalen DNS-Server (Firewall/DomainController/whatever) einen A-Record für den Hostname der Starface anlegen, der auf die interne IP der Starface verweist. Damit ist dann alles in Butter.
    Genau das ist ja der Fall, wie ich ja oben auch schon geschrieben habe.
    Also ist den internen Telefonen egal, was bei SIP-Einstellungen Hostname/IP Adresse steht?
    Da es ja offensichtlich so ist, wird dort ein Hostname eingetragen, wird dieser von der SF aufgelöst und nicht der Hostname in die SIP Header eingebaut? Aus diesem Grund ging es ja nicht. Würde ich hier nun wieder einen Hostnamen eintragen, der intern direkt aufgelöst wird, dann funktioniert es ja wieder nicht. So war ja die Ausgangssituation.

    Wie macht die SF die Differenzierung? Bei den Telefoneinstellungen gibt es ja die NAT Option. Bei den App Clients steht dort "Ja".
    Bei den internen Telefonen steht dort "Standard". Der Standard wäre ja aber vermutlich "NAT", wenn unter "SIP-Einstellungen" "hinter NAT" aktiviert ist?!

    Grüße
    Geändert von aeichhorn (19.08.2019 um 09:09 Uhr)

  9. #9
    STARFACE Expert
    Benutzerbild von andreas.stein
    Registriert seit
    04.12.2014
    Ort
    Bitburg
    Beiträge
    483

    Standard

    Hallo Andreas,

    ich komm da nicht mehr ganz mit. Wir sollten mal den Begriff „Hostname“ in diesem Kontext definieren. Wenn ich vom Hostname spreche, rede ich vom XMPP Hostname in der Starface. Dieser wird für mehr verwendet, als man denkt - u.A. auch für die Autoprovisonierung (kommt eine Anfrage für eine Config File vom Telefon, gibt die Starface die URL zum Download zurück und verwendet dabei die XMPP Domäne).

    Was sich mir ebenfalls nicht erschließt: Du redest davon, dass du in der Starface „Hinter NAT“ aktiviert hast und dort dann die WAN IP eingetragen hast. Gleichzeitig verwendest du aber eine Dyndns. Hat der WAN Anschluss denn überhaupt eine statische IPv4 Adresse? Die Frage stellt sich bei mir automatisch wenn jemand mit einer Dyndns um die Ecke kommt.

    Eine funktionierende Konfiguration sieht im Grunde ganz einfach aus:
    - In der Starface einen XMPP Hostname verwenden, der von extern und von intern auflösbar ist
    - Starface NAT Einstellungen passend konfigurieren (meistens „hinter NAT“ aktivieren und WAN IP setzen.)
    - dafür sorgen, dass der XMPP Hostname von Geräten im selben Subnetz über den lokalen DNS-Server auf die lokale IP Adresse aufgelöst wird (oder alternativ sicherstellen, dass Router bzw. Firewall auch Anfragen von intern an die eigene WAN IP durchlassen. Stichwort Hairpin NAT).


    Für interne Geräte ist die NAT Einstellung in den Endegräten völlig egal. Die kommen nie zur Anwendung, wenn sich die Starface im gleichen Subnetz befindet.

    Was ich noch anmerken möchte. Ein Router, der selbst für VoIP konzipiert ist und entsprechende Ports gerne mal für sich selbst reserviert, ist für so eine Konstellation eher hinderlich bzw. eine unerwünschte Störquelle. Wenn möglich verwende ich bei Kunden mit lokaler Starface immer Router bzw. Modem-Firewall-Kombinationen ohne integrierte SIP Funktionen. Gerade der 5501 kann da ziemlich nervig sein - insb. wenn der über BNG an einer Telekom Leitung hängt.
    Geändert von andreas.stein (19.08.2019 um 21:41 Uhr)
    Viele Grüße,

    Andreas Stein
    IT Fabrik Systemhaus GmbH & Co. KG

    STARFACE Excellence Partner

  10. #10
    STARFACE User

    Registriert seit
    28.07.2017
    Beiträge
    54

    Standard

    Hallo Andreas,

    ich komm da nicht mehr ganz mit. Wir sollten mal den Begriff „Hostname“ in diesem Kontext definieren. Wenn ich vom Hostname spreche, rede ich vom XMPP Hostname in der Starface. Dieser wird für mehr verwendet, als man denkt - u.A. auch für die Autoprovisonierung (kommt eine Anfrage für eine Config File vom Telefon, gibt die Starface die URL zum Download zurück und verwendet dabei die XMPP Domäne).
    um den XMPP Hostnamen ging es hier jedoch gar nicht.
    Lies hierzu noch einmal die lösungsbringende Nachricht von Torsten.

    Was sich mir ebenfalls nicht erschließt: Du redest davon, dass du in der Starface „Hinter NAT“ aktiviert hast und dort dann die WAN IP eingetragen hast. Gleichzeitig verwendest du aber eine Dyndns. Hat der WAN Anschluss denn überhaupt eine statische IPv4 Adresse? Die Frage stellt sich bei mir automatisch wenn jemand mit einer Dyndns um die Ecke kommt.
    Das ist ganz üblich, dass hier ein DynDNS hinterlegt wird. Wenn man eine statische IP hat bräuchte man kein DynDNS

    Die IP bzw. den Hostnamen, den man unter Server -> Netzwerk -> SIP Einstellungen hinterlegen kann, und zwar nur, wenn hier "Hinter NAT: Ja" gewählt ist, hat eine andere Funktion als die XMPP Domain, von der du sprichst.
    Unter anderem wird anhand dieser Adresse geregelt, wie der SIP Traffic geleitet wird, also wie die Sprache den Weg zum Server zurück findet. Die Pakete müssen hinter einem NAT anders gekapselt werden, sonst weiß der Client nicht wohin mit den Paketen.
    Wäre es ein Problem mit der XMPP Domain, dann hätte das eher ein Problem mit der Anmeldung in der App oder dem UCC Clienten mit sich gebracht, aber keines mit ausblendender Tonübertragung.

    Letzten Endes auch total logisch. Was ich nur nicht auf dem Schirm hatte, ist, dass die Starface den besagten Eintrag (Externe Adresse) intern erst zu einer IP Adresse auflöst und diese dann in die SIP Header integriert.
    Wenn man dann so schlau ist, und wie ich einen Hostnamen wählt der intern zu der internen LAN IP der Starface auflöst und extern zu der externen IP (CNAME zum DynDNS, sprich der Dynamischen IPv4) dann kann das so natürlich nicht mehr funktionieren, weil die Starface nun in die SIP Header für externe Geräte eine lokale IP Adresse schreibt. Das erklärt auch warum der UCC Client bzw. die App keinen Ton mehr zurückgeschickt hat.
    Nach Anpassung dieses Eintrages (Server -> Netzwerk -> SIP-Einstellungen) auf einen Hostnamen (DynDNS) der IMMER sowohl intern, als auch extern, zu der externen IP auflöst ist das Problem ja verschwunden.

    Eine funktionierende Konfiguration sieht im Grunde ganz einfach aus:
    - In der Starface einen XMPP Hostname verwenden, der von extern und von intern auflösbar ist
    - Starface NAT Einstellungen passend konfigurieren (meistens „hinter NAT“ aktivieren und WAN IP setzen.)
    - dafür sorgen, dass der XMPP Hostname von Geräten im selben Subnetz über den lokalen DNS-Server auf die lokale IP Adresse aufgelöst wird (oder alternativ sicherstellen, dass Router bzw. Firewall auch Anfragen von intern an die eigene WAN IP durchlassen. Stichwort Hairpin NAT).
    Genau hier war das Problem, der selbige Hostname, wie für XMPP (intern -> interne IP, extern -> externe IP) wurde von mir unter Server -> Netzwerk -> SIP-Einstellungen hinterlegt. Das haut dann so nämlich einfach schlichtweg nicht hin, wenn die Starface diesen Hostnamen erst intern zu einer IP auflöst. Das muss man ganz einfach wissen. Hinterlegt man hier statt eines Hostnamen einfach eine IP Adresse, wenn man z. B. eine statische externe hat, dann wird man mit dieser "Problematik" nie in Berührung kommen.

    Für interne Geräte ist die NAT Einstellung in den Endegräten völlig egal. Die kommen nie zur Anwendung, wenn sich die Starface im gleichen Subnetz befindet.
    Und da bist du dir sicher?
    Wozu gibt es dann bei den einzelnen Endgeräten die Einstellung "NAT" unter "Erweiterte Einstellungen" mit den Optionen "ja" "nein" und "Standard"?
    Bei internen Geräten ist hier standardmäßig "Standard" eingestellt. Bei den Apps "ja".

    "Ja" erschließt sich mit in dem Sinne, dass hier für die SIP Header per default die externe IP (Server->Netzwerk->SIP-Einstellungen) verwendet wird.
    "nein" bedeutet für mich, dass hier die interne Adresse gewählt wird?
    "Standard" würde für mich dann aber bedeuten, dass wenn unter Server->Netzwerk->SIP-Einstellungen "Hinter NAT" auf "Ja" steht, eben dies auch einem "ja" entspricht, also immer die Externe Adresse genutzt wird für die SIP Header.
    Dann würden die internen Telefone den Umweg zum Edgerouter machen und von dort wieder zurück zur Starface kommen, was eigentlich etwas unschön ist, wenngleich es natürlich funktioniert.

    Was ich noch anmerken möchte. Ein Router, der selbst für VoIP konzipiert ist und entsprechende Ports gerne mal für sich selbst reserviert, ist für so eine Konstellation eher hinderlich bzw. eine unerwünschte Störquelle. Wenn möglich verwende ich bei Kunden mit lokaler Starface immer Router bzw. Modem-Firewall-Kombinationen ohne integrierte SIP Funktionen. Gerade der 5501 kann da ziemlich nervig sein - insb. wenn der über BNG an einer Telekom Leitung hängt.
    Joa das kann wohl durchaus nervig sein, und ich mag den Speedlink eh nicht so gerne, wobei es letzten Endes ziemlich trivial war und auch gar keine Kompilationen bzgl. der Ports gab, und nach dem Hinweis des intern aufgelösten Hostnamen von Torsten auch astrein funktioniert.

    -----

    Wie gesagt für mich wäre dann noch zu klären, ob den internen Telefonen immer egal ist, was bei "Erweiterte Einstellungen->NAT" bei dem jeweiligen Endgerät konfiguriert ist.

    Grüße
    Arne

Ähnliche Themen

  1. Antworten: 11
    Letzter Beitrag: 09.07.2019, 15:53
  2. Problem Darstellung extern verschickte Chat Nachricht im Windows UCC Client
    Von pkaiser im Forum STARFACE Erweiterungen & Integrationen
    Antworten: 10
    Letzter Beitrag: 17.01.2017, 16:18
  3. Kein Softphone mehr im UCC Client Mac
    Von moritz im Forum STARFACE Benutzerfrontend
    Antworten: 2
    Letzter Beitrag: 02.03.2016, 11:02
  4. Snom extern/Kein Ton
    Von Nili1968 im Forum STARFACE Einrichtung & Administration
    Antworten: 2
    Letzter Beitrag: 03.01.2010, 14:55
  5. Unterschiedliche Signalisierung zwischen Ruf nach Extern und Rufumleitung nach Extern
    Von indeva im Forum STARFACE Einrichtung & Administration
    Antworten: 0
    Letzter Beitrag: 04.01.2008, 15:21

Lesezeichen

Forumregeln

  • Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
  • Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
  • Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
  • Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.
  •