Posts by shenke

Geht uns ähnlich mit STARFACE v6.0.0.7 und unseren Yealinks.

Wir haben sporadische Probleme beim Transfer von Anrufern und auch noch andere Fehler. Der Support von STARFACE vertröstet nur auf das kommende Update Ende Juli.

Die Release Notes von Firmware v72 und v73 weisen da teils über solche korrigierten Fehler hin, da versteht man nicht, wieso nicht mal die Firmware neu angepasst wird.

Habe auch eben mal nachgeschaut. Die ausgelieferte Firmware ist vom 07.05.2014. Das kann also max. die x.72.0.25 vom 18.04.2014 sein, oder wohl eher noch älter. Die neueste Stock-Firmware ist vom 05.02.2015.

Hat jetzt (dank Probleme mit dem neuen Update) etwas länger gedauert.

Ich habe inzwischen das Problem lösen können. Es lag am Client (Jitsi), der alle gemachten Einstellungen ignoriert und mit dem gesonderten Port nicht klar kommt. Alle anderen Clients funktionieren jetzt problemlos.

Bin aber am überlegen ob die Variante über iptables nicht sinnvoller ist. Allerdings habe ich die Befürchtung, dass die Einstellungen nach einen Neustart/Update wieder verworfen werden. STARFACE holt sich die iptables-Info ja aus der Datenbank von STARFACE und generiert die Dateien unter /etc/sysconfig/ neu. Die allerdings enthält keine Einträge für die Tabelle PREROUTING.

Als Übergangslösung würde mir gerade nur ein Cronjob einfallen, der beim Systemstart die entsprechenden Einträge hinzufügt.

Grüße Sebastian

Hallo,
die Ansage hatte ich auch schon ein Mal (v6.0.0.7).

Nachdem ich bei einem Telefon den Namen (Benutzername/Telefonname) geändert hatte, kam auch diese Ansage.

"Diesem Telefon ist kein Benutzer zugeordnet. Sie können nur interne oder Notrufe tätigen"

Ursache dafür ist die falsche/veraltete Zuordnung beim Benutzer. Wenn man sich die zum Benutzer zugeordneten Telefone anschaute, stand der neue Name drin. In der Datenbank war aber immer noch die alte ID hinterlegt. Die Lösung war dann das Löschen und neu Hinzufügen des Telefons zum Benutzer. Zwischen beiden Schritten hatte ich dann jeweils noch gespeichert, damit die Änderungen in der Datenbank wirksam worden.

Grüße Sebastian

Fabian: Die Variante hatten wir schon getestet, allerdings wechselten die meisten Clients automatisch nach einiger Zeit selbstständig den SIP Port.
Bsp.: externer Client baut Verbindung über neuen Port auf, bekommt von der STARFACE die Kontaktdaten geschickt (welche den Standardport beinhaltet) und wechselt nach kurzer Zeit automatisch vom neuen auf den alten Port (der aber nur intern verfügbar ist).

Einzige Ausnahme war hier der SIP Client QuteCom.

Philipp: Danke für die Info. Ich bin davon ausgegangen, dass wenn STARFACE zur Generation der sip.conf den Datenbankeintrag heran zieht, dass auch die STARFACE Autoprovisionierung ihre Daten daraus bildet. Wäre für mich logisch gewesen.

Gruß
Sebastian

Hallo zusammen,
wir mussten bei unserer STARFACE den SIP Port ändern. Dies hat auch mit Hilfe der Anleitung im Wiki (https://wiki.starface.de/index.php/STARFACEhinterFritzbox) ganz unproblematisch geklappt.

Allerdings meldet der Provisioning-Server unserer Anlage immer noch den Standard-SIP-Port 5060 an alle Geräte, anstatt des neuen Ports. Resultiert am Ende darin, dass sich die Geräte auf dem "toten" Port versuchen anzumelden.

Gibt es noch eine andere Stelle die abzuändern wäre oder wo bezieht der Provisioning-Server seine Werte für die Configdateien ?

Anbei ein Auszug aus einem tcpdump.

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 01:00:00 CET
Content-Type: text
Content-Length: 5878
Date: Fri, 27 Feb 2015 17:32:48 GMT


#!version:1.0.0.1


##File header "#!version:1.0.0.1" can not be edited or deleted.##


#####Basic Settings file for Yealink T42 #####
...
account.1.sip_server.1.port = 5060
...
account.1.outbound_port = 5060

Sebastian