Amtsholung und Starface Client Anwahl

  • Guten Morgen, ich muss das Thema nochmals ansprechen. So langsam ist es echt nervig, weil wir alles von Hand wählen müssen.

    wir können weiterhin keine Anwahl aus unserem System heraus auslösen, weil diese Funktion geändert wurde, warum erschließt sich uns weiterhin nicht und es konnte mir bisher auch keiner schlüssig erklären. Statt normal die Nummer zu wählen, wählt die Starface unsere eigene Vorwahl zusätzlich. Also statt 089123456 wählt die Starface 0897142123456.

    Das ist nervig und schränkt uns wirklich sehr ein, allerdings habe ich auch keine Lust die Anlage umzustellen bzw. alle unsere Stammdaten zu ändern, sprich eine zusätzliche 0 vor die Nummern im System zu hängen. Für mich ist es völlig unverständlich und unklar warum bzw. wozu diese Funktion überhaupt geändert wurde, für mich ist das ein Fehler.

    NJ

  • Ich verstehe den Sachverhalt nicht ganz. Ist Amtsholung aktiv oder nicht? Was wird vom Benutzer gewählt?

    Ist die STARFACE der Ansicht, dass es sich nicht um eine vollständige Rufnummer handelt, wird diese vervollständigt und um Ländervorwahl und Ortsvorwahl erweitert. Das ist Teil der Leitungskonfiguration.

  • Also, wir setzen ein:

    Starface Client Mac 6.0.0.13 / Starface 6.0.2.X auf Starface Appliance

    Übergabe der Nummer erfolgt direkt von Filemaker aus an den Client per Script, die Nummer die übergeben wird ist korrekt und lautet z.b. 089123456, das Amt sollte sich der Client wie früher holen über eine "0" . Macht der Client aber nicht denn, drückt man auf wählen, wird :0897142123456 gewählt. Die 7142 entspricht der Vorwahl unseres Ortes, was natürlich völlig hanebüchen ist, wenn ich in München anrufen möchte. Der Grund soll die Amtsholung sein, vom Client wird die "0" nicht geholt.

    In der alten 5 er Version lief das problemlos auch in der 4 er davor.....und mit der 6 er ging das nicht mehr, wofür es meiner Ansicht nach keinen Grund gibt ( das hatte ich schon mehrfach hier angesprochen ) Die Konfiguration hat sich seit der 4er eigentlich nicht geändert und ich hätte einfach nur gerne das alte Verhalten der Anlage zurück.


    NJ

  • Ok,

    wie es auf dem Mac in diesem Szenario genau aussieht, muss ich noch intern nachfragen.

    Für beide Clients (Windows und Mac) ist hier der Sollzustand, dass die Rufnummer vom Client kanonisch zum Server übertragen wird:

    +4989123456

    und der Server macht es dann richtig. Der Client fragt vom Server die globale Leitungskonfiguration ab und kann die gewählte Rufnummer so in das kanonische Format übertragen.

    Beim Windows-Client ist es dann so:
    - Wenn eine Rufnummer im Client eingetippt wird, muss der Benutzer die Amtsholung mit eingeben
    - Bei allen anderen Wählvorgängen (callto Link, TAPI, Outlook, ...) geht der Client davon aus, dass die Rufnummer noch keine Amtsholung enthält

    Gruß Wolfgang

  • "Beim Windows-Client ist es dann so:
    - Wenn eine Rufnummer im Client eingetippt wird, muss der Benutzer die Amtsholung mit eingeben
    - Bei allen anderen Wählvorgängen (callto Link, TAPI, Outlook, ...) geht der Client davon aus, dass die Rufnummer noch keine Amtsholung enthält"

    Das ist irgendwie total unlogisch, entweder man muss die "0" eingeben oder nicht. Aber nicht in der Situation so und in der anderen Situation anders.....Das ist schon irgendwie nach Windows programmiert, gehe auf "Start" um auszuschalten...

    Es funktioniert nur wenn ich aus dem Mac Adressbuch wähle, nicht aber wenn eine Nummer per Script übergeben wird, von daher wird das ähnlich sein.
    Erklärt aber nicht warum das bis Version 5x problemlos ging und in 6x geht das nicht.

    NJ

    Edited once, last by Nili1968 (September 28, 2015 at 2:38 PM).


  • Das ist irgendwie total unlogisch, entweder man muss die "0" eingeben oder nicht. Aber nicht in der Situation so und in der anderen Situation anders.....Das ist schon irgendwie nach Windows programmiert, gehe auf "Start" um auszuschalten...

    Die Logik ist wie folgt:

    - 1) Die Amtsholung wird konfiguriert, damit ein Anwender gezielt intern oder extern wählen kann. Da es in Deutschland möglich ist, einen anderen Teilnehmer im selben Ort ohne Ortsvorwahl anzurufen, braucht man diese Unterscheidung gelegentlich.
    - 2) Wenn der Anwender selber eine Rufnummer eintippt, kann ich nach 1) erwarten, dass er dies berücksichtigt und die Amtsholung eintippt
    - 3) Rufnummern in CRM-Systemen etc. sollten ideal im kanonischen Format vorliegen, dann können die Telefonieprogramme automatisch entscheiden, was zu tun ist
    - 4) Im echten Leben sind die Rufnummern in CRM-Systemen aber oftmals nicht kanonisch, enthalten aber auch - wegen der Portabilität - keine Amtsholung
    - 5) Wenn dann die CRM-Software keine Konfiguration für "Diesen Präfix immer mitwählen" hat
    - 6) ist besagte Logik im Client die Lösung: Der Client geht davon aus, dass eine Rufnummer, die über TAPI, Outlook, Internet Explorer etc. gewählt wird niemals eine Amtsholung enthält

    Die Erklärung für die Änderung ist, dass wir wg. diverser Supportfälle im Kontext Amtsholung festgelegt haben, dass der Client in Richtung Server immer kanonisch wählt. Der Client weiß viel eher als der Server, woher eine Rufnummer kommt (Benutzereingabe im Client, Tapi, Adressbuch, ...) und hat somit mehr Informationen darüber, ob eine Amtsholung zu berücksichtigen ist oder nicht. Wenn der Client dann zum Server kanonisch wählt, kann der Server aufgrund der Leitungskonfiguration entscheiden, was zu wählen ist.

    Die Mac-Seite klären wir morgen.

    Gruß Wolfgang

  • Hallo,

    per AppleScript werden die Aufrufe der UCI zur Verfügung gestellt (siehe Wiki). Eine Unterscheidung nach der Quelle der Rufnummer findet an der Stelle nicht statt. Da sich das Verhalten der PlaceCall-Methode mit STARFACE 6 hinsichtlich der Amtsholung geändert hat müssen Skripte entsprechend angepasst werden.

    Es wäre natürlich möglich, den Client um eine AppleScript-Funktion zu erweitern, die das "Adressbuch-Verhalten" zur Verfügung stellt. Aber auch dann müssen vorhandene Skripte angepasst werden.

    Mit freundlichen Grüßen

    Tobias

  • Ich habe auch gerade ein Update von der 5.8 auf die 6.0 hinter mir. Seit heute morgen können die Anwender nicht mehr aus ihrem MAC-Adressbuch wählen, weil der Starface 1.7 und UCI Client oder die Anlage ein komplett anderes Verhalten zeigt als noch gestern mit der 5.8.
    Da war es so:
    Ich konnte im Starface Client ohne Orts- und Ländervorwahl wählen, wenn ich eine Nummer in Hamburg erreichen wollte. Ich konnte auch nur mit Ortsvorwahl von Hamburg wählen. Oder ich konnte mit +4940Nummer wählen. Alles wurde korrekt umgesetzt.
    Bei Ferngesprächen genügte die Angabe der Vorwahl - also 030-30192499 zum Beispiel, um eine Verbindung zu bekommen.
    Mit der 6 ist es so, dass im Client zwingend mit +4930301xxx gewählt werden muss - das ist unglaublich. Müssen jetzt alle Mitarbeiter alle ihre Adressbücher mit tausenden von Telefonnummern auf die +49-Variante umstellen?? Wer überlegt sich sowas?
    Und kann ich irgendwie das alte Verhalten wiederbekommen?

    Liebe Grüße,

    Dieter

  • Wenn ich mit dem neuen UCC Client for Mac einen Kontakt im lokalen Adressbuch mit einer lokalen Rufnummer (zB als 1234567 gespeichert, also ohne das "+49721"), und auf "Mit STARFACE wählen" klicke, dann kommt der Anruf richtig an. Sowohl mit der Premium (Softphone) variante als auch mit der kostenlosen Version (wählen über hardware-telefon). Funktioniert übrigens auch mit einer Amtsholung.

  • Aus dem Adressbuch geht es bei mir, allerdings haben wir bereits alle Nummern mit +49 abgespeichert....Wenn das mit dem Ändern des Scripts so einfach wäre, würde ich ja nichts schreiben , ist es aber nicht denn das Script muss vom Programmierer der Software angepasst werden oder ich muss alles Nummern im System ändern lassen. Die Frage ist ja, warum wurde das geändert? Wo ist der Sinn?

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!