iPhone-Registrierung funktioniert nicht zuverlässig

[robinsonR]

Ich habe heute meine PIAF-Installation auf die aktuelle FreePBX-Version (14.0.1rc1.8 https://www.freepbx.org/downloads/freepbx-distro/) migriert. Neu wird PJSIP eingesetzt und es gibt eine Responsive Firewall, die etwas tricky ist; evtl. rührt ja mein Problem daher, ich glaube aber nicht. Telefone im LAN funktionieren problemlos, nur Bria (3.9.3) macht Schwierigkeiten. Meine PBX läuft auf einer VM hinter einer pfSense-Firewall. Die pfSense löst mittels DNS Resolver FQDN im LAN auf; und hier kommt mein Problem: in Bria habe ich als Host pbx.domain.tld angegeben, damit ich mich auch von extern registrieren kann. Über 4G klappt die Registrierung sofort ohne Probleme, im WLAN nur mit Mühe ab und zu. Verwende ich zur Registrierung im WLAN die interne IP der PBX klappt es auch sofort. Es scheint ein Problem zu geben mit der DNS-Auflösung im lokalen Netz, obwohl ich bei den kabelgebundenen Telefonen auch pbx.domain.tld als Host angegeben habe.

Irgendeine Idee oder nützliche Tipps, wie ich das Problem lösen kann?

PS. Oft, aber nicht immer, bekomme ich in Bria die Fehlermeldung Unknown (503), was wohl darauf hindeutet, dass er die PBX nicht findet.

 

[rentier-s]

Ins Blaue hinein geraten, weil ich nämlich mit CSipSimple aufm Android ein ähnliches Problem hatte, Du hast in Bria STUN aktiv. Wenn das Programm nicht kapiert, dass es lokal ist, versucht es sich über die per STUN aufgelöste externe Adresse zu registrieren. Abhilfe bei mir war ein eigener STUN Server im LAN, der im Client eingestellte STUN Server stun.t-online.de wird per dnsmasq auf den lokalen Server umgebogen. Damit erhält der Client innerhalb des WLAN auf STUN Anfragen seine lokale IP-Adresse zurück.

 

[robinsonR]

Nein, STUN ist nicht aktiviert. Und es liegt auch nicht an Bria selber, mit Zoiper habe ich das gleiche Problem. Muss noch ein wenig weiter testen, um mehr Infos zu bekommen.

 

[koyaanisqatsi]

Abhilfe bei mir war ein eigener STUN Server im LAN, der im Client eingestellte STUN Server stun.t-online.de wird per dnsmasq auf den lokalen Server umgebogen. Damit erhält der Client innerhalb des WLAN auf STUN Anfragen seine lokale IP-Adresse zurück.

Respekt
Hab mich auch schon über die in den globalen Einstellungen manifestierte STUN-Aktivierung in CSipSimple geärgert.
Es gibt da aber eine Lösung für...
Jedes Konto lässt sich nachträglich (langer tapp aufs Profil)...

...mit "wähle Assistenten" in ein "Expert" Profil umwandeln, und in dem kann, nur für dieses Konto...

...STUN und Anderes (Verschlüsselung) de/aktiviert werden.

- - - Aktualisiert - - -

@robinsonR: Vielleicht ein IPv4/IPv6 Problem ? Denn in einer Dual Stack Umgebung wird IPv6 bevorzugt und es muss bei fehlender IPv6 ein Rücksprung (Fallback) auf IPv4 erfolgen.
Problem wird durch "DNS Umgehung" gelöst, wie an der direkten Registrierung mit IPv4 (?) ersichtlich.

 

[rentier-s]

und in dem kann, nur für dieses Konto STUN und Anderes (Verschlüsselung) de/aktiviert werden.

Nutzt aber nichts, wenn man sowohl innerhalb des eigenen Netzwerks als auch außerhalb das gleiche Konto benutzen möchte.

Zum Thema, robinsonR, kannst Du mal das SIP Debugging einschalten und dann das Telefon dazu bringen, sich zu registrieren, damit man das REGISTER Paket und die Antwort darauf sehen kann. Da stehen die Adressen drin, wer was wohin versucht zu senden. Idealer Weise, sofern Du das abwarten kannst, einmal erfolgreich und einmal fehlgeschlagen.

 

[robinsonR]

Danke, ja, SIP Debugging muss ich mal einschalten und testen. Bin bis jetzt noch nicht dazu gekommen und hatte eigentlich gehofft, es sei ein bekanntes Problem, da ich ja das neue PJSIP einsetze, das wohl noch nicht so ganz ausgereift ist. Habe jetzt auch festgestellt, dass sich ein altes Gigaset S450 IP zwar registriert, aber ab und zu beim Wählen Probleme macht (Wählvorgang dauert ewig und wird manchmal mit 603 abgebrochen).

PS. Überlege mir ernsthaft, die neue Installation zu schmeissen und wieder den alten Server in Betrieb zu nehmen. Ist zwar nur für zuhause, aber stundenlang basteln wollte ich eigentlich doch nicht.