Posts by Mantaray

    Seit dem Upgrade auf Version 7 (derzeit aktuell mit Version 7.3.1.3) treten in Verbindung mit Yealink (egal, ob T42/T46/T54/...) gehäuft Probleme auf:

    - Ladefehler bei Ruflisten

    - keine Tastenprovisionierung mehr aufs Telefon (im UCC wird es gemacht)

    - Telefone hängen sich auf (Restart hilft da meist noch)

    - Umbenennen von Benutzern auch hier ändert sich der Anzeigename beim Telefon bei Abmelden/Anmelden nicht, es bleibt der alte Name

    - Abmelden/anderen Benutzer anmelden - alter NAme nach wie vor am Display/bei Anrufen an anderen Telefonen

    Diese Dinge passieren vereinzelt oder in Kombination...

    Das einzige, was hilft ist: Telefon resetten, aus der Anlage löschen und neu einbinden, Zuweisen - Probleme sind weg

    (wer soll das bezahlen...)

    Ich habe den Eindruck, beim Upgrade auf Version 7 (welche Version kann ich nicht verifizieren) passierte eine Inkonsistenz bei der Datenbank

    "Weils immer schon so war..."

    Das ist der letzte Kunde, der unbedingt eine Amtsnull wollte. Da verstehe ichs bedingt, weil Sie in jedem Bundesland (=9x) eine Niederlassung haben und so schön interne Nummernkreise bilden können/konnten, inkl. 100-199, was die Starface ja auch nicht mehr will wegen Notrufnummern....

    Was ich nicht verstehe, ist diese Begrifflichkeit mit "Sonderrufnummer" - das sind stinknormale ortsunabhängige Vorwahlen, warum darf hier keine Amtsnull mehr gewählt werden? - Deutsches Bundesgesetz oder wie?

    Aber danke für eure Antworten, ich werds dem Kunden verklickern, dass er bei bestimmten Vorwahlen keine Amtsnull wählen darf, weil der Hersteller das so will.

    Tolles Phänomen neuerdings:

    Kunde kann keine 0800er Nummern über A1-Telekom (AUT) ISDN mehr wie gewohnt anrufen.

    Konfig: Es wird eine Amtsnull (Amtsholung) standardmäßig verwendet.

    Wählt er wie gewohnt am Telefon 0 (Amt) + 0800 xxx, dann kommt:

    - Baue Anruf auf

    - 3 Freizeichen

    - Anruf Fehlgeschlagen

    Jetzt hat der Kunde spaßeshalber versucht, ohne Amtsholung rauszurufen, also nur: 0800 xxx

    - Anruf funktioniert!

    Was soll das jetzt? Kunde meint, ihm kommt vor, dass dies seit dem Update auf 7.2 ist, allerdings kann man das nicht so festmachen, denn es ist nicht bekannt, wann das letzte Mal eine 0800er Nummer angerufen wurde.

    Wie kann es sein, dass eine externe Nummer, die mehr Zeichen als die internen Durchwahlen hat (3), nur ohne Amtsholung angerufen werden kann, mit Amtsholung (Pflicht) aber nicht?

    Zitat Kunde:

    "

    Wählen von 00800xxx führt zum Fehler!

    Wählen von 0800xx funktioniert einwandfrei.

    "

    Telefon funktioniert normal, ist in der Liste, dem User korrekt zugeordnet....

    Ich komme selbst nicht direkt hin, mir wurde der Screenshot vom "Telefonbeauftragten" des Kunden übermittelt...

    PS:

    Kunde wurde etwas vorsichtiger, denn mit dem Upgrade auf 7.2 haben sich Telefone unkontrolliert und zeitlich unabhängig verabschiedet, die man nur mehr durch Werksreset/löschen in der anlage wieder reinbrachte - obwohl die Anlage alles normal anzeigte...

    Daher bekomme ich jetzt jede Unregelmäßig gemeldet, habe ja sonst nichts zu tun...:-)

    Warum funktioniert auf eimal die Amtsholung nicht mehr korrekt?
    (Betrifft nur Rückrufe aus Ruflisten wie Telefon oder UCC!)

    Version 7.0.1.:
    - Yealink Telefone zeigten die Amts-0 nicht an, Rückruf war nicht möglich (eine 0 zuwenig, da "nur" 0049xxx)
    - UCC Client hat es gemacht (vermutlich wegen des Parameters)

    Version 7.0.2.1:
    - Yealink schmeissen nur mehr file-List-Error (nehme an wegen nun 4 0er bei den Rufnummern (z.B. 000049xxx)
    - UCC Client zeigt Rufnummer als zu wählend mit 00049xxx korrekt an, wählt aber dann doch 000049xxx (eine weitere 0 vorne dazu)

    Wie kann so ein Verhalten nach korrekter funktion bei den 6er-Versionen nun wieder auftauchen?

    ja, es wird die Amtsholung benötigt, denn im Anlagenverbund gibt es 3stellige Durchwahlen, die Notrufnummern entsprechen
    (in AUT erlaubt)
    wir haben 3stellige Rufnummern, jedes Bundesland hat einen eigen Nummernkreis (9 Bundesländer - die hängen im Verbund)

    Tja, habe mir den Spass erlaubt, ein Ticket zu eröffnen, um auf den Missstand wieder einmal hinzuweisen bzw. zu erfahren, wie denn der Ausblick auf Updates (Umstieg auf chan_pjsip lt. Partnertag) sein könnte.
    wie erwartet, nur folgendes:
    "...wie schon telefonisch mitgeteilt ist dieser Provider nicht verifiziert. Daher kann ich Ihnen hier keinen Support anbieten. Der Provider kann sich gerne unter http://www.siptrunk.de anmelden und ein Profil erstellen."

    Auf die Problematik an sich wird gar nicht eingegangen, man kann das ja als Featurewunsch einwerfen.
    Keine Hinweise auf Änderung, nur stur das Gebet mit der Verifizierung - als ob das große Provider interessiert, die sehen das eher umgekehrt...
    (A1 will ja über den Vertrieb "ihre" Anlagen verkaufen)

    Starface, so geht das nicht m.E.....

    Danke Dir, das habe ich befürchtet...
    (somit war die bisherige Gegenstelle auf A1 nur nicht so restriktiv, da durfte ich mir das "fromuser" sparen, obwohl auch in der Guideline 2.0 erforderlich)

    => der grösste Telefonieprovider in AUT wird im Bereich NGN auf der Starface nicht unterstützt
    (techn. Hintergrund hin oder her...)

    Hallo,
    nach längerer Zeit habe ich wiede reinen Kunden mit einem A1 NGN Trunk.

    Mittlerweile sind wir bei SIP-Richtlinie 4.1.

    Verstehe ich dich richtig, dass das Feld fromuser mit der Kopfnummer belegt werden muss wegen der Registrierung?
    ...und dadurch keine Durchwahlen im Header (from) mitgegeben werden können?

    Hast du da eventuell eine Lösung parat, wie man die komplette Rufnummer inkl. Durchwahl beim raustelefonieren mitgeben kann?

    Wäre dir sehr dankbar.

    PS: die Anlage mit der SIP-Richtline 2.0 (anderer Registierungsserver) funktioniert nach wie vor ohne diesen neuen "Gimmicks"...

    Hallo, wenn ich hier einhacken darf:

    Das Problem gibt es bei einem Kunden auch. Ein Benutzername wurde geändert.
    Wenn jemand nun nach dem neuen Benutzernamen sucht, zeigt das Ergebnis im UCC den alten Namen an (User wird gefunden, aber der alte Name angezeigt).
    Dabei geht es NICHT um eine Funktionstaste, sondern rein um die Suche im UCC.
    Das Suchergebnis ist dann ja so etwas wie eine temporäre "Taste"

    Wie bekommt man das aktualisiert?
    (Cache im suchenden UCC-Client?)

    Hinweis: die Suche geht anlagenübergreifend innerhalb eines Verbundes (Suchende ist an einer anderen Anlage als der zu Findende - Namensänderung schon einige Zeit her...

    Für einen Hinweis, diese "Inkonsistenz" loszuwerden, wäre ich sehr dankbar!

    Hallo!

    Hat jemand Erfahrung mit der Starface in Kombination mit der Loxone Intercom XL Gegensprechanlage?

    Meines Wissens nach ist die Intercom eine Baudisch Hardware (Baudisch gehört angeblich ja jetzt Loxone), allerdings mit anderer Firmware.
    ein echter SIP client wie bei Baudisch dürfte deaktiviert worden sein.

    Es scheint so, als würde die Loxone Intercom ausschliesslich via Loxone Cloud Server mit den Loxone Apps kommunizieren.
    Sprache läuft dann optional via externem SIP Account.
    (d.h. Türklingel geht nur mit aktivem Internet, aktivem Cloud Server und einem Handy/Tablet mit App drauf - wenn ich das richtig interpretiere)


    Ich hab es mal geschafft, die Intercon anzurufen und zu sprechen, die Gegenstelle hört man aber nicht. Klingeln (=Anruf auf Starface-Endgerät wie Yealink von der Gegensprechanlage) ging auch nicht.


    Hat da jemand eine Lösung parat, wie die Intercom zu einem "Endgerät" der Starface machen (ohne die firmware von Baudisch raufzuspielen - wegen Integration zu "Loxone Smart Home")?

    Hallo zusammen!

    Zur Infomation (weil eben produktiv gesetzt) hier Eckdaten zum SIP-Trunk der A1 Telekom Austria AG.
    (Die aktuelle Guideline sowie meine letzt bekannte Preisliste als Anhang...)

    A1_telekom_provider_konfig.jpg


    Benutzer: +43xxxxx (=Kopfnummer international)
    NGN-Route: 193.81.5.0/27,193.81.7.0/27


    In diesem Kundenfall:
    da bereits vorher ein Telekom LWL Anschluss gemacht wurde, wurde der NGV gesondert in einem eigenem Business Anschluss hergestellt (der aber eh über den gleichen LWL läuft, weil kein Kupfer mehr vorhanden).
    (Die Produktpolitik darf man eh nicht mehr hinterfragen)

    Preise sind gesalzen, m.E. teurer als ISDN bei Grundgebühr, Minuten etwas günstiger
    - Sprachkanäle bezahlt man extra
    - Herstellung extra
    - Clip-no-Screening extra
    Herstellungszeit war 8(!) Wochen
    Portierung intern wieder 2 Tage (weil man zu Testzwecken erst eine Interimsnummer bekommt)


    Trotzdem: Vielleicht kann sich Starface "erbarmen" und den Anschluss in die Standardproviderliste aufnehmen.
    Ich denke nicht, dass sich die A1 Telekom "zertifizieren" lässt (eher umgekehrt)...

    Hallo, vielen Dank für Deine Antwort.

    Mittlerweile hat der Businesspartner der A1 mir ein aktuelleres Dokument (SIP TRUNK Guideline Vers. 2.0) gegeben, da steht alles recht gut drinnen.

    Der host-Eintrag in der Provider Konfig ist nach wie vor aus deinem Screenshot - nur der funktioniert - dazu gibt das Dokument nichts her.
    Als NGN-Route haben die jetzt drinnen stehen: 193.81.5.0/27, 193.81.7.0/27
    A1_telekom_provider_konfig.jpg.

    Zur info meine Screenshots der Konfig für andere "Betroffene".


    HINWEIS: in der 6.5.1.9 gibt es einen Bug, da kann man keinen eigenen NGN-Provider (bzw. folgenden Anschluss) anlegen!!!
    Support sagt, der Bug ist in der GUI, es wird vergessen, die NGN Route in die Datenbank zu schreiben.
    die Leitung kann man dann weder editieren noch löschen (da muss dann der Support ran und die Route per Statement in die DB schreiben).

    Hallo Papyrus!

    wo hast du die Daten für die NGN-Route her?
    Müsste auch so einen Anschluss zum Laufen bringen, als einzige Daten bekam ich von der A1:
    - Benutzer (Rufnummer)
    - Passwort
    - SIP-IP-Adresse 10.x.x.x/32

    Die haben für den trunk einen eigenen Business-Anschluss gelegt (via LWL), über den ausschliesslich Sprachdaten geschickt werden.

    Ist deine IP-Adresse im HOST bzw. für die Route eine fixe Adresse? auch im SIP-Trunk-Guide der A1 hab ich nichts dazu gefunden?

    Bitte um einen Tipp...

    Die Springer arbeiten mit Laptop, aber es werden ausschließlich Standgeräte verwendet.

    Den Leuten ist es zu kompliziert, 2 Rufnummern zu haben bzw. sich 2 Serveradressen für die UCC-Anmeldung zu merken (und 2 Ruflisten zu haben,...)

    Headset hatte ich auch schon vorgeschlagen - wurde mit hochgezogener Augenbraue vom Tisch gefegt..:-(

    Im Endeffekt brauchst du ein Adapterkabel (RJ11 auf RJ45), weil der RJ11 nicht vernünftig in die RJ45 Dose passt.
    Könntest aber auch selbst machen, mithilfe der info von PhilippS.
    Du nutzt quasi das Datenkabel von der Dose zum Panel als Verlängerung.

    Gibt es im Handel, Beispiel bei Conrad, bei allnet wäre das Kabel günstiger...
    https://www.conrad.de/de/isdn-anschl…romSuggest=true

    Dieses Kabel brauchst du auf Beiden Seiten des Patch-Panels...

    Ich habe bei der Allnet mal 20 solcher Kabel (um die € 1,50 bei 3m)besorgt, die werden immer wieder mal benötigt...
    hier der Link:
    https://shop.allnet.de/detail/index/s…rch=RJ45%20RJ11

    Hallo, vermutlich ein unmögliches Nice-to-Have:

    - Kunde hat mehrere Anlagen im Anlagenverbund
    - jeder Standort muss unabhängig der VPN-Verbindung autonom funktionieren können
    - ISDN Anschlüsse
    - Einige Personen arbeiten variabel an mehreren Standorten (="Springer")
    - verwendet werden zum Telefonieren ausschließlich Standgeräte, Arbeitsplätze sind variabel

    Fallbeispiel:
    Anlage A
    Anlage B
    user x ist grundsätzlich Benutzer von Anlage A, hat aber auch einen user auf Anlage B
    user x fährt zu Standort B und möchte eigentlich den User von Anlage A verwenden

    Hintergrund:
    die Springer beim Kunden haben jetzt auf jeder anlage des Verbunds einen eigenen User mit eigenen Durchwahlen.
    Der UCC Client wird auch verwendet, allerdings nicht zum Telefonieren.
    Momentan meldet sich der UCC-Client logischerweise immer an der Anlage an, zu der er standardmäßig zugehörig ist (durch den VPN geht dies auch durch).
    Fährt der Springer nun zu einem anderen Standort, muss er auch die UCC-Anmeldung an die andere Anlage anpassen - das verstehen die Leute einfach nicht ("die Anlage muss das doch wissen, unsere Datenserver synchronisieren ja auch....blabla")
    Ein typischer Kunde halt, der trotzdem unmögliches haben möchte ("...mit der heutigen Technik darf das kein Problem sein...")


    Gäbe es theoretisch die Möglichkeit, den Benutzer x bei einem Telefon der Anlage B anzumelden, sodass die Benutzeranmeldung über den Anlagenverbund zur Anlage A durchgereicht wird?
    (im Prinzip eine Art Master-Slave Gegebenheit)
    Sonst wäre auch hilfreich, im UCC-Client die Benutzeranmeldung variabel zu gestalten (~Auswahlmenü der Identität)