Posts by Ulf

    @rok°!:


    Hat sich das so auf Dauer bestätigt?


    Ich habe hier einen Kunden, bei dem sich das BTH58 nach Anschluss eines Headsets abgemeldet hat und auf keinem Weg wieder verbinden lässt. Auch ein Werksreset hat nicht geholfen - dem Eintrag hier zu urteilen, handelt es sich um das gleiche Problem ...

    Ulf ich habe das von dir empfohlene modul zwar gekauft aber dann erfahren das ich die Compact Anlage updaten muss. Da die Version 6.0 nicht mit diesem Modul unterstützt wird?


    Liebe Grüße


    Ismail

    Das Modul sollte auch für die vorliegende alte Version lauffähig sein - die Module die im Shop angeboten werden funktionieren i.d.R. ab Version 6.x (bitte nur eben die richtige Version laden) und im Zweifelsfall gibt es auch ältere als dort angebotene Versionen oder das kann gegebenenfalls angepasst werden. Wenn die ladbare Version nicht funktioniert, einfach melden ... :)

    Diese Funktion habe ich im Admin Berreich unter Telefone nicht gefunlden? Liegt das eventuell an der Version 6.0?


    Liebe Grüße

    Ismail

    ismael: Die Lösung über eine Gruppenzugehörigkeit ist ein anderer Weg, der aber auch mit Nachteilen verbunden ist - nicht immer funktioniert das so ganz problemlos, da man vielleicht auch nicht jede Nummer erst durch eine Gruppe durchleiten will oder kann. Also abgesehen von der Starface-Version macht eine spezielle Modullösung dann schon auch weiterhin Sinn und bietet ein einfacheres Handling ohne Abhängigkeiten von Gruppenkonstrukten.

    Hallo,


    Ja - dafür gibt es u.a. das Modul CallDisplay, welches exakt für diese Einsatzzweck bestens geeignet ist und genau die beschriebene Funktion abbildet.

    Hey Ulf, das ist keine Lösung, wir haben eine aktuelle Software auf der Cloud-Anlage, mit der der 7er Client glaube ich gar nicht mehr funktioniert. Trotzdem danke für den Hinweis. Aber ich schule die Mitarbeiter hier nicht auf die alte Software um und investiere auch kein Geld hier überall die alte Software wieder einzurichten und zu konfigurieren :)

    Hallo Patrick,


    der 7er-Client funktioniert sicher noch - bei unseren Kunden nutzen den neuen 8er-Client im Produktiveinsatz m.W. gerade mal Einer von den auf 8.1 umgestellten Starface-Installationen. Alle anderen arbeiten noch mit dem 7er-Client und berichten auch von keinen Problemen. Technisch geht das also sicher und ist letztlich ja dann auch nicht soooo anders.


    Hier wurden die Kunden über die Wahlmöglichkeit 7/8er-Client informiert und können aktuell selbst oder gemeinsam mit uns bestimmen, wann gewechselt wird - das hat sich als entspanntere Lösung erwiesen und kein Kunde beginnt mehr, sich nötigen und/oder empfehlenswerten Updates zu verweigern. Letzteres bringt über kurz oder lang dann ganz andere Probleme und deutlich mehr Unzufriedenheit.


    Nicht das ich nicht verstünde, was beim geschilderten Effekt im aktuellen 8er-Client gemeint ist und wo Probleme gesehen werden. Bevor man aber bereit wäre, die ganze Starface-Installation in Frage zu stellen, wäre die Suche nach anderen Lösungswegen in meinen Augen dann schon eine Option. Aber wie es immer so ist - jeder darf das sehen, wie man will und bei dem Einem ist das Glas bei einem Problem halb leer und beim Anderem halt noch halb voll ... ;)


    Und das Gute: es ist als Fehler erkannt und wird wohl korrigiert (was im Übrigen auch mich im Sinne meiner Kunden beruhigt).

    Patrick:


    Wenn das Problem aktuell bei dem 8er-Client auftritt, wäre es doch vermutlich eine zumindest vorübergehende Lösung, die letzte 7er-Version des Clients zu nutzen, das sollte doch weitestgehend noch funktionieren und unter Windows sogar parallel zur 8er-Installation funktionieren, wenn ich mich nicht irre.


    Das wäre zumindest eine Lösung bis das beschriebene Problem gefixt ist.


    So aus dem Bauch heraus muss ich sagen, dass das - sollte das wirklich so wie beschrieben gewollt und nicht beeinflussbar sein, wirklich eine schlechte Idee wäre, da wüsste ich auch hier einige Kunden, die das ganz schlecht finden würden.

    Interessant, dann könnte es auch am Mobilteil liegen.

    Bin gespannt ob Du es finden kannst, halte uns auf dem laufenden.

    Da ich tatsächlich aktuell eben nur die SL750H hier habe, muss ich wohl oder übel mal neueres Modell ordern und damit testen. Wäre natürlich total blöd, wenn es tatsächlich eben speziell an jenem Modell liegen sollte (auch über mehrere Geräte).

    Ulf

    kannst Du denn im tcpdump die Sprache hören oder kommt es schon gar nicht soweit?

    slu:


    Bei normal aufgebauten Telefongesprächen enthält der Dump beide Sprachkanäle absolut einwandfrei - sind beide zu hören - am Telefon, welches an der N670 hängt aber nicht.


    ... und spannend:


    Ruft man vom Telefon, welches an der N670 hängt die Mailbox an, ist im Dump kein Audio enthalten. Im Vergleich mit anderem Telefon (z.B. über N510) - Audio ist problemlos (im Telefon und Dump) zu hören ...

    Ja - den Ansatz (zumindest die Kontaktaufnahme) hatte ich schon gestartet, bin dann aber beim Supporter der Distribution gelandet und das war letztlich gar nicht hilfreich (melde mich dazu per PN).

    slu:


    Da habe ich auch schion daran gedacht - eingesetzt werden hier SL750H Pro ... / getestet mit mehreren dieser Geräte. Unterstützt wird das SL750H ja - das hatte ich natürlich auf geprüft.


    Ticket ist jetzt mal bei Gigaset eröffnet. Das Problem muss natürlich gelöst werden.

    Kleine Korrektur dazu:


    In der Ausgangsfrage hatte ich mich leider bei den benannten Systemen vertan - die Systeme die bei Kunden laufen sind die alten N720 - nicht wie da ursprünglich stand N870 ...


    Und es kam wie es kommen musste und hier schon vermutet wurde: eine neue N670 verhält sich nach Anbindung an die Starface tupfengleich (kein eingehendes Audio an dem Handset, welches testweise an der N670 hängt). Dann läuft das jetzt auf ein Ticket raus ...

    was machen die GS denn dann im Rechenzentrum, wenn die nicht lokal stehen ??

    ;) gar nichts ... ich habe ja nicht geschrieben, dass die im Rechenzentrum stehen, sondern "im Rechenzentrumsbetrieb".


    Übersetzt: in Verbindung mit im Rechenzentrum virtualisierten Starface-Installationen, allerdings ist damit eben nicht die StarfaceCloud gemeint - die wird hier nicht genutzt, hier stehen dafür eigene Hosts.


    Die Grandstreams stehen selbstverständlich beim Kunden, jeweils dort wo sie gebraucht werden - was auch sonst?


    ;) ;) ;)

    Wie schaut es denn mit den Keep Alive - Einstellungen im HT8xx aus?


    Ich hatte solche Probleme hier auch zunächst beobachtet, nach Aktivieren des Keep Alive war das dann "repariert" - eine Lösung, die bisher bei allen Grandstreams geholfen hat (jedenfalls in unserem Umfeld - sowohl Lokal als auch im Rechenzentrumseinsatz).


    Das ist so nachvollziehbar bei SF 6.7.x, SF 7.x, SF 8.0.x und SF 8.1.x.

    das wäre ärgerlich, wenn das Gerät defekt ist .

    Jupp ... vor allem lag das gaaaaanz lange hier rum - hatte ich ins Lager gelegt (um es später mal zu testen), als die ganz neu raus kamen. Und wie es dann so ist, gab es so viele andere Projekte, dass man nie dazu kam und erst jetzt neu aufmerksam wurde, als die N510 vom Markt verschwindet.


    Aber da hilft jetzt kein meckern und sich darüber ärgern - ist mein ureigener Fehler gewesen, man lernt dazu :/ - gibt es halt auch mal.

    erkläre mir den Sinn hinter einer NAMENSTASTE.

    ich rede von Usern aus der Starface auf einem BLF.

    Wenn Du davon ausgehen möchtest, dass die Namensvorgabe, die für einen Benutzer vorgegeben wird, stur als gegeben vorgesetzt werden soll und niemand mehr was dran ändern darf, hast Du recht - dann wäre der Ansatz falsch, dass bei Änderungen im Backend diese in den BLFs im Frontend nicht mitverändert werden.


    Gehst Du aber davon aus, dass die Editiermöglichkeit für Benutzer im Frontend (Web, UCC) Sinn machen soll, dann klappt das mit dem "Sinn" schon nicht mehr und tatsächlich kenne ich wirklich viele Nutzer, welche die Beschriftuing auf den BLFs (bleibend) nach eigenem Geschmack ändern wollen. Das kann z.B. ein genau umgekehrter Ansatz der Kombination aus Nachname und Vorname sein - manchen Kunden mögen den Vornamen vorn, den Nachnamen hinten haben - die nächsten mögen das Komma auf den BLFs nicht und andere wollen nur den Vornamen dort stehen haben. Die nächsten mögen lange Bezeichnungen sinnvoll und nach eigenem Geschmack gekürzt haben usw. ... das könnte man beliebig fortführen.


    Will man das alles mißachten und diesen Wünschen nicht nachkommen, wäre es absolut zielführend, wenn Namensänderungen sich sofort auch auf den BLFs niederschlagen - in allen anderen Situationen gehts aber schlichtweg so simpel halt mal nicht und genau das meine ich auch, wenn ich sage, grundsätzlich sollte die Editierbarkeit bleiben. Ich möchte mir gar nicht vorstellen was passiert, wenn da plötzlich etwas überschrieben und "korrigiert" werden würde - einige Kunden würden das gar nicht danken. Insofern man einen anderen Ansatz aus automatischer Änderung (wenn z.B. erlaubt und gewünscht) und bleibender Editiermöglichlkeit mit Anpassungen der Namen bei Änderungen im Backend findet, gerne. Vorstellbar wäre technisch gesehen sicher, auf Übereinstimmung der BLF-Beschriftung mit alter Vorgabe bei den Userangaben zu prüfen und nur dann automatisch anzupassen, wenn das vorher nicht editiert/verändert war. Das wäre ein brauchbarer Kompromiss.


    Zumindest in unserem Kundenumfeld sind es derart viele Nutzer, die da selbst herumeditieren und andere Bezeichnungen setzen, dass man nicht mehr von Einzelfällen sprechen und das so einfach übergehen kann. Aber klar - technische Lösungen, das Beides geht, wären natürlich schön und würden in Standardfällen sehr helfen - das sehe ich absolut auch so.

    Ich habe an dem Gerät wirklich schon alles probiert, was man machen kann - inkl. Werksreset (nicht nur einmal) und alle möglichen und "unmöglichen" Einstellungen probiert. Es ist ja auch nicht so, dass ich jetzt als "blutiger Anfänger" mit diesen Dingen arbeiten würde, bin seit vielen Jahren im VoIP-Umfeld und speziell der Starface aktiv, hab auch durchaus "ungewöhlichere" Dinge als nur den vorgegebenen Standard implementiert und glaube eigentlich halbwegs zu wissen, was ich tue. Aber natürlich wird man gerade dann auch mal betriebsblind und auch ich möchte nicht ausschliessen, irgendwas banales aber wesentliches zu übersehen.


    Die N670 hatte ich mangels Bedarf tatsächlich das erste Mal in die Hände bekommen, aber gar nicht das Gefühl, hier vor einem "unlösbaren" Problem zu stehen - das System erschliesst sich ja schon und scheint auch nicht besonders komplex zu sein ... aber dann kommt plötzlich genau dieser un erwartete Punkt.


    An den Port-Einstellungen der N670 habe ich mangels Notwendigkeit nichts verändert - auch das sollte eigentlich alles stimmen.


    ... und - weiterer Test: auch an einer lokalen Installation (dann natürlich mit entsprechender NAT-Anpassung in den Starface.-Einstellungen) tritt das gleiche Problem auf und da ist noch nicht mal LAN-intern irgendwas von Seiten einer Firewall, was dazwischengrätschen kann ...


    Da die Geräte ja nun eigentlich funktionieren, werde ich dann mal den nächsten Schritt gehen und eine neue N670 ordern und damit nochmal testen.


    Für mich war jetzt erst mal wichtig mich umzuhören um ausschliessen zu können, dass ich irgendwas übersehe - aber das scheint gar nicht so zu sein ...

    ... Starface im Rechenzentrum und N670 hier lokal -> NAT-Einstellung beim N670 wie bei allen anderen lokalen Geräten = JA


    In dem Fall befindet sich zwischen SF und N670 ja auch eine NAT - bei allen anderen Engeräten (hier lokal) ist das exakt genau so.

    Betroffen sind alle Geräte, die ich an der betreffenden N670 angemeldet hatte (habe tatsächlich auch eben bewusst mit mehreren Geräten probiert, die vorher an einer N510 hingen und dort auch funktionieren). Verschlüsselung ist nicht aktiv - den Punkt hatte ich mir aber auch schon angesehen und mit und ohne Verschlüsselung getestet - Effekt immer gleich ...


    Ich bin eigentlich schon soweit, mal eine andere N670 zu testen um auch andere Probleme mit speziell jenem einem Gerät auszuschliessen.