Was ich vergessen hatte zu erwähnen: Es muss natürlich eine COR-Regel vorhanden sein, die auf den ausgehenden Anruf zutrifft, sonst sind keine Anrufe möglich.
Beiträge von fwolf
-
-
Bitte die Routingstrategie auf "COR" stellen. Beim Leitungsrouting wird zunächst die zur Rufnummer gehörende Leitung verwendet.
-
Die Telekom bietet CLIP-No-Screening nur für Anlagen- oder Primärmultiplexanschlüsse an — egal ob Privat- oder Geschäftskunde. Wenn es sich also um einen Mehrgeräteanschluss handeln sollte (auch die kann man als Geschäftskunde bekommen), wird's leider nichts mit CLIP-No-Screening.
In diesem Fall empfehle ich eine zusätzliche Leitung in der STARFACE anzulegen (sipgate, QSC, toplink, HFO,...), über die das Merkmal verfügbar ist und über die ausgehende Gespräche bzw. Weiterleitungen geroutet werden. Eingehend verwendet man dann die bestehenden ISDN-Leitungen und deren Rufnummern. Ausgehend wird über SIP telefoniert mit beliebiger Rufnummer. -
Geht es um den Anschluss in der Firma? Da bin ich mir relativ sicher, dass CLIP-No-Screening in der Anlage aktiviert ist (zumindest war es das ;)).
Der Patton ist auf jeden Fall so konfiguriert, dass er die Caller-ID, die die STARFACE setzt verwendet.Bei den Provider-Hotlines ist es wichtig, an jemanden zu geraten, der weiß was CLIP-No-Screening ist — am Besten man läßt es sich erklären Ansonsten kann es sein, dass es nicht geschaltet wird, oder dass Merkmale geändert werden, die "so ähnlich klingen" — z.B. COLP. Alles schon erlebt.
-
Ah! Ich verstehe... Die Provisionierung der Funktionstasten erfordert, dass die STARFACE einen Zugriff auf das Telefon initiieren kann. Ich glaube dass sie das bei den snom über Port 80 macht. Deshalb funktioniert die Funktionstastenbelegung bei ge'NAT'eten Telefonen auch nicht.
Bei der Autoprovisionierung über Port 50080 holt sich das Telefon Firmware, Konfigurationsdateien, etc. — die Initiierung der Verbindung durch das Telefon funktioniert bei NAT. -
Die Telefonnummern aus der Region müßten dann einfach mit Vorwahl gewählt werden. Auf die Frage "[...] wie wir diese Problem lösen können?" wird vermutlich nur der Verzicht auf die Amtsholung als Antwort bleiben. Denn wenn das Callhandling der STARFACE einen Fehler macht, ist das nichts, was man als User beheben kann.
-
Zero-Touch Autoprovisionierung wird von extern ohnehin nicht funktionieren, es sei denn die Autoprovisionierungs-URL ist bei snom auf dem Provisionierungsserver für die MAC-Adresse des Telefons hinterlegt.
Am Besten das Telefon einmal im lokalen Netz autoprovisionieren und dann die Server-IP/URL anpassen, so dass diese von extern erreichbar ist. -
Bisher keine
-
Die STARFACE kennt ihre internen Rufnummern und Nebenstellen. Eine Null für das Amt ist hier nicht notwendig. Wenn man intern Notrufnummern vergeben möchte sieht das anders aus, davon würde ich jedoch stark abraten.
Viele Dinge funktionieren mit Amtsholung nicht so sauber, grundsätzlich würde ich es nur benutzen, wenn es aufgrund bestimmter Routinganforderungen nicht anders geht. -
Die Gigasets erkennen aufgrund ihres optischen Sensors nicht immer das Abheben des Hörers. Ob das Telefon das Abheben erkennt, sieht man an einer Veränderung des Displays.
-
Die Uservoice-Anforderung habe ich fertig als Modul vorliegen, sogar mit Anzeige der Umleitung im Display. Das Modul gibt es für netto 400 Euro.
DND wir hier im Post zu durchbrechen ist komplizierter
-
Gibt es einen Grund für die Amtsholungs-Null? Ist die nur aus Gewohnheit aktiv? Vor einer tiefergreifenden Anpassung würde ich diese Deaktivieren und prüfen, ob sich das Problem damit gelöst hat.
-
Die Entwickler waren nicht untätig. Der Bug ist bereits gefixt, allerdings ist in der Zwischenzeit noch kein Release erschienen, mit dem der Fix hätte veröffentlicht werden können Ich schätze mal, dass er im nächsten Release drin ist.
-
Wie ist die Amtsanbindung realisisert? ISDN oder SIP und welcher Provider? Wie sehen die Einstellungen der Leitungskonfiguration bzgl. Landes- und Ortsvorwahl aus?
Gibt es einen Updatevertrag, so dass auf die 5.7.0.7 aktualisiert werden könnte?
-
Das perfekte Telefon gibt es nicht — viele Dinge sind auch einfach Geschmacksache. Aus der Erfahrung und dem Feedback beim Kunden hätte ich ein Gerät empfohlen, dass Du aufgrund seines "China-Looks" bereits ausgeschlossen hast. Während ich bei den Vorgängern zugestimmt hätte, kann ich das bei den aktuellen Modellen nicht nachvollziehen. Aber da ist es wieder, das subjektive Empfinden
Alle geforderten Punkte wirst Du in keinem Gerät finden — speziell auf den DND-Status auf den BLFs wirst Du am Telefon höchstwahrscheinlich verzichten müssen. Am Nähesten dran ist vermutlich das Yealink T48G, bei dem Du aber noch etwas abwarten solltest.
-
Die einzelnen Yealink-Geräte unterscheiden sich in der Firmware mehr als man normalerweise annehmen würde
-
Die gewünschte Funktion läßt sich grundsätzlich als Modul umsetzen, allerdings müßte dieses erst entwickelt werden.
-
Es gibt aktuell keine Möglichkeit, das STARFACE Adressbuch Dritt-Geräten, wie iPhones zur Verfügung zu stellen. Von autoprovisionierten Anlagentelefonen hingegen hat man in der Regel Zugriff auf das STARFACE Adressbuch.
Ein gangbarer Weg wäre, die STARFACE gegen externe Adressbücher zu synchronisieren. Zum Beispiel ein zentraler LDAP, gegen den die iPhones und die STARFACE die Adressen auflösen. Alternativ ein zentraler CardDAV-Server. Den kann man im iPhone direkt einbinden. Für die STARFACE gibt es ein Modul, das die Adressen von dort importiert.
-
Ein Angreifer aus dem internen Netzwerk könnte bei ausreichender Fachkenntnis die XML-Menüs, die sonst auf den Telefonen angezeigt werden (Ruflisten, Adressbuch, etc.) auch ohne ein Telefon abrufen, um so Kenntnis von den Inhalten fremder Ruflisten oder Adressbücher zu erhalten. Ob weitere Informationen verfügbar wären, müßte ich allerdings erst prüfen.
Aus dem Stehgreif wissen das die STARFACE-Entwickler besser. Da die hier auch mitlesen, meldet sich vielleicht der ein oder andere noch zu Wort. -
Wenn Du fritz.box als FQDN verwendest und sich die Fritz!Box meldet, verwendest Du sicherlich den Nameserver der Fritz!Box über das interne Interface.
Das/Die internen Interface(s) hat sicherlich eine IP-Adresse aus einem privaten Adressbereich. Entsprechend muß diese IP-Adresse in der STARFACE eingetragen werden. Ist vielleicht in der STARFACE ein anderer Nameserver als die Fritz!Box eingetragen? Sprich: Kann die STARFACE fritz.box überhaupt auflösen?
Meine Vermutung ist immernoch, dass es an der Erreichbarkeit der Fritz!Box scheitert.Im Moment kommen noch sehr viele mögliche Ursachen in Betracht. Könntest Du nähere Ausführungen zur Konfiguration machen (Netzwerkkonfiguration der beteiligten Geräte, Verkabelung, Informationen zum SIP-Account in der Fritz!Box, etc.).