Also das ist nun wirklich seltsam. Ich bin sicher, dass ich sowohl mit den Fanvil als auch mit dem Yealink telefonieren konnte.
Und nun - auf einmal kein Ton mehr.
Wobei - extern eingehend höre ich die Teilnehmer, die hören mich aber nicht
Intern sind die Leitungen in beide Richtungen still.
Gleichzeitig habe ich ein Fanvil aber auch - im gleichen Netz und hinter der selben Firewall - direkt bei Sipgate angeschlossen und damit telefoniere ich heute schon den ganzen Tag.
Also würde ich annehmen, es ist kein Firewall / NATin Problem. Sonst würde das Fanvil ja nicht problemlos funktionieren.
Bei internen Gesprächen haben wir ja wohl auch keinen exteren Provider im Spiel - wenn ich also kein Audio übertrage, dann muss es irgendwo schon im System ein Problem geben.
Die Anlage habe ich auch schon komplett gelöscht und wieder alle Geräte eingerichtet - zumindest das kann ich zwischenzeitlich im Schlaf
Mein Problem - morgen klemmt mir die Telekom das ISDN ab und ich portiere komplett zu Sipgate.
Und ich habe immer noch keine funktionierende Anlage …
Interne Telefone sollten an der ersten Schnittstelle der pascom hängen, am besten in einer DMZ der Firewall, aber es geht auch ohne (also zwischen Telefon und pascom keine FW).
Für die Rufsignalisierung wird SIP genutzt, also TCP/TLS an Port 5061, die Sprache wird über SRTP übertragen, also UDP. Da der Ruf signalisiert wird kann es nur am SRTP hängen. Das Fanvil wird jetzt ja nicht ein großer Außenseiter der IP-Telefone sein, sprich sollte auf RPORT hören und diesen für den RTP-Kanal nutzen den die pascom vorgibt.
Wir hatt mal ein DNS-Problem in zusammenhang mit dem pascom Client, kann sich aber evtl. auch auf andere Telefone auswirken.
Split-DNS: Intern zeigts auf die interne IP der pascom, Extern zeigts auf die externe WAN IP. Hier hatte sich die pascom die falsche IP via DNS geholt (die interne und nicht die externe). Es kam dann zu fehlender Sprache (also RTP) in beide Richtungen. Wenn du kein Split-DNS verwendest sollte das soweit sauber sein.
Du kannst den Traffic zwischen pascom und Fanvil ja mal mit Wireshark mitschreiben und schauen ob SRTP zur pascom geht oder ob das Telefon garnicht erst “sendet” und ob die Ports soweit stimmig sind.
Also, der aktuelle Stand:
Ich habe so ziemlich jede Fehlerquell durchprobiert.
Mit ausgeschalteter Firewall getestet - so kann die sicher nichts abfangen
Switch und PoE-Switch neu gestartet bzw. getauscht. Brachte nix.
Versucht die Pakete im Telefon, in der Firewall und am PC mit Wireshark zu “catchen” - im Ergebnis sah das sehr seltsam aus.
Also habe ich jetzt einfach die komplette Anlage als VM neu installiert. Das geht in 10 Minuten. Da habe ich schon Übung (leider).
Danach alle Installationssschritte wieder ausgeführt, in den Endgeräten die Anmeldenamen und Kennwörter getauscht, also keine Einstellungen verändert!!! Die DECTS wieder eingebucht und zunächst ohne Anlage getestet.
Man glaubt es nicht, die beiden Fanvils haben sich sofort miteinander unterhalten - Audio war da.
Jetzt machi ich erst einmal wieder ein Backup der Settings und dann kommen die nächsten beiden Schritte: Sipcom Amt anbinden und - das SSL Zertifikat tauschen.
Ich bin einmal gespannt, wie es danach aussieht.
ich könnte mir vorstellen du hattest ein Problem mit dem FQDN des verwendeten Interfaces, siehe Pascom 18 OnSite | Lösung für: keine Tonübertragung
Wenn du hier einen Namen einträgst, löst die Anlage zum Start des Interface containers (also i.d.R. nur beim Booten) diesen Namen auf und die hier ermittelte IP wird den Endgeräten in den SDP Informationen als Ziel für den RTP Traffic übermittelt.
Eingehend kommt dann der Ton zum Endgerät, aber das Endgerät sendet dann vermutlich nicht an die pascom.
Tatsächlich habe ich das falsch konfiguriert.
Weil der name der TK-Anlage das nicht anders erlaubt, habe ich diese abcde genannt.
Der Host im DNS entsprechend
abcde.abc-de.local
(weil abc-de.local die Domain ist)
Eingetragen habe ich aber
abcde.abcde.local und schon war es geschehen…
Ich liege dir zu Füßen und bitte um Gnade für diesen doofen Anfängerfehler
Das erklärt übrigens auch, weshalb sich das Yealink DECT nicht mehr einbinden konnte…
