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

    2 Mal editiert, zuletzt von aeichhorn ()


  • 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.



    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

    Presales Manager


    STARFACE GmbH | Adlerstraße 61 | 76137 Karlsruhe | www.starface.com

  • 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?

  • 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.



    //edit: Recycled von: https://support.starface.de/forum/showthread.php?5531-Telemaxx-als-SIP-Provider-hinzufügen/page2


    MfG


    Fabian

  • 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

  • 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.

    Einmal editiert, zuletzt von aeichhorn ()

  • 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 PLUS Partner

  • 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

    Einmal editiert, zuletzt von aeichhorn ()

  • 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.

    Viele Grüße,


    Andreas Stein
    IT Fabrik Systemhaus GmbH & Co. KG


    STARFACE Excellence PLUS Partner

    Einmal editiert, zuletzt von andreas.stein ()

  • Hallo Andreas,


    Zitat

    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.


    Zitat

    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.


    Zitat

    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.


    Zitat

    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.


    Zitat

    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

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!