[FRAGE] SNOM statt GRANDSTREAM wegen größerer Anzahl der Adressbucheinträge?

[Junialter]

Hallo,

habe bislang Grandstream (GXP-2xxx) Apparate eingesetzt mit einer leichten Enttäuschung, dass das Telefonbuch nicht mehr als etwa 80 Einträge verträgt. Ich versteh nicht bei heutigen Chippreisen, wei soetwas sein kann.
Nun überlege ich auf SNOM umzusteigen. Ich habe mir selbst ein web-interface auf php-basis programmiert in dem man einen Kundenstamm pflegen kann. Nun sollen da auch gut und gerne ein paar hundert Rufnummern drin sein. Kommt eins der SNOMs da in Frage oder welche Alternativen gibts, die auch XML lesen können (am besten per http)?

Ausserdem würde ich gerne wissen ob die BLF-Funktion mit asterisk einwandfrei läuft und die pickup() funktion, mit der man sich Gespräche zu seinem Apparat ziehen kann.

Danke!

 

[Junialter]

Von Snom habe ich die Info erhalten, dass die Geräte bis 360 etwa 100 Einträge aufnehmen kann, das 370 bis zu 200 Einträge. Das ist ja auch nicht die Welt...
Gibt es da keine Hersteller, die etwas mehr bieten?

 

[anhalter42]

Ich weiß zwar nicht, ob andere da mehr Platz anbieten, frage mich aber, wer um Himmels willen mehr als 100 Kontakte *ständig griffbereit* braucht. Aber egal.

Snom kann, wie Du richtig festgestellt hast, nur 100 (snom370 offenbar 200) Einträge im Telefon selbst speichern. Es gibt aber, und das ist bei Snom hinreichend dokumentiert, die Möglichkeit, per XML ein externes Telefonbuch einzuspielen. LDAP ist glaube ich bei den neuesten Firmware-Versionen auch schon drin.

Ich benutze selbst ein Snom320 und finde schon ca. 30 Einträge im Telefon-Telefonbuch mühsam zu durchsuchen. Ist dann nicht ein gutes CTI für Deine Zwecke geeigneter? Ich meine, die Oberfläche per Webfrontend, und das Snom dann ab und zu mal klingeln lassen?

 

[Ciscofreak]

Ausserdem würde ich gerne wissen ob die BLF-Funktion mit asterisk einwandfrei läuft und die pickup() funktion, mit der man sich Gespräche zu seinem Apparat ziehen kann.

Danke!

beides funktioniert einwandfrei !! hab selber Grandstreams und ein SNOM370 alles top

 

[Junialter]

Ich frage mich umgekehrt, was man mit einem Telefon will, was nur 100 Einträge verwalten kann? Ich halte das für lachhaft. Mein Adressbuch im Handy/Computer (sync) enthält locker an die 500 Einträge und, ja: ich brauche die alle. 100 Einträge konnten ja sogar schon die Handys aus den Neunzigern. Ich halte das für schönrederei. Meiner Meinung nach sollten mind. 1000 Einträge nicht nur machbar sondern auch state-of-the-art sein.

Es ist tatsächlich so, dass ich die Adressdaten bereits extern speichere, i.e. in einer mysql-Datenbank. Bei Grandstream scheint das aber relativ egal zu sein wo die tatsächlich liegen. Bei ca. 80 Einträgen ist Schluss.

Wenn das SNOM die Einträge nicht wirklich herunterladen würde, sondern die aus der XML-Datei nur anzeigen würde, hätte man das Problem natürlich nicht mehr, aber das bezweifle ich hier leider auch.

Also dauert die Suche nach einem geeigneten Telefon immer noch an...

 

[Tiny_Dragon]

Wenn das SNOM die Einträge nicht wirklich herunterladen würde, sondern die aus der XML-Datei nur anzeigen würde, hätte man das Problem natürlich nicht mehr, aber das bezweifle ich hier leider auch.

Wenn du deine Zweifel beseitigen möchtest, lese dir mal folgendes durch:

http://wiki.snom.com/Minibrowser#PhoneBook_for_Snom-Phones

Am besten lädst du dir auch das Paket einmal herunter und liest dir dann auch die Dokumentation durch.

BR

 

[pwalker]

Meine zwei oder drei Tipps:
- Snoms (sind nämlich ziemlich brauchbar) verwenden nicht Grandstream GXP-2xxx. Oder alternativ Aastra 5xi (habe ich nicht im Einsatz, machen aber auch einen guten Eindruck)
- XML-Telefonbuch verwenden (kann sowohl snom als auch Aastra).
Und - obwohl in mich damit wiederhole:
- Ein (XML-)Telefonbuch mit über 50 .. 100 Einträgen halte ich für unbrauchbar (evtl. kategorisieren)
- LDAP in Erwägung ziehen (kann snom direkt einbinden)

 

[Junialter]

@pwalker
Snom hört man ja nur gutes drüber. Ich werde mir mal eins besorgen um mein System damit zu testen.
Ich verstehe nicht, was an einem großen Addressbuch so seltsam ist. Firmen haben nun mal häufig mehr als 100 Kontakte die sie verwalten (und BENUTZEN) müssen. Ich würde sogar behaupten es kaum Firmen, die weniger als 100 haben.
Kategorien gibt es in meinem web-interface, ich wüsste aber nicht, wie ich dem Grandstream diese beibringen sollte. Wie das bei SNOM etc. funktioniert werd ich mir dann mal ansehen, wenn ich eines habe. Darüber hinaus schmälern Kategorien den gesamten Adressumfang tatsächlich nicht.
LDAP ist eine Überlegung wert, darüber werde ich mir auch mal Gedanken machen. Eine der Hauptfragen ist für mich, ob es da auch wirklich einfache Interfaces zum pflegen der Adressdaten gibt, womit auch der unbedarftere Mitarbeiter klar kommt, ohne sich mit "organisational units" etc. rumhantieren zu müssen.

 

[pwalker]

Snom hört man ja nur gutes drüber.

Nicht "nur", aber schon auch viel Gutes...

Ich werde mir mal eins besorgen um mein System damit zu testen.

Guter Ansatz!

Ich verstehe nicht, was an einem großen Addressbuch so seltsam ist.

Wenn alles in einer Liste steht (z.B. das in den snoms im Telefon integrierte oder einfach ein langes XML-Telefonbuch) wir'd recht mühsam zum Handhaben, siehe den anderen Thread.

Kategorien gibt es in meinem web-interface, ich wüsste aber nicht, wie ich dem Grandstream diese beibringen sollte.

Bei GS wohl gar nicht, ist ja auch das snom-Forum hier

Wie das bei SNOM etc. funktioniert werd ich mir dann mal ansehen, wenn ich eines habe.

Mittels SnomIPPhoneMenu und SnomIPPhoneDirectory.

Darüber hinaus schmälern Kategorien den gesamten Adressumfang tatsächlich nicht.

Nein, aber das Telefonbuch wird dadurch übersichtlicher die Suche evtl. einfacher. (Ich habe ja nicht grundsätzlich was gegen grosse Adressbücher, sondern nur gegen mehr als ca. 50 Einträge in einer Liste!

LDAP ist eine Überlegung wert, darüber werde ich mir auch mal Gedanken machen. Eine der Hauptfragen ist für mich, ob es da auch wirklich einfache Interfaces zum pflegen der Adressdaten gibt, womit auch der unbedarftere Mitarbeiter klar kommt, ohne sich mit "organisational units" etc. rumhantieren zu müssen.

Als Webfrontend (für LDAP) evtl. mal ConTagged anschauen.