Posts by cbka

    Hi!
    Schade nur, dass einige OpenStage in unseren Locationen stehen. NY, Singapore, UK, DE

    Und die haben dort andere IP Adressen natürlich.
    Deshalb werd ich die wohl mit Yealinks tauschen müssen.

    Da habt ihr doch bestimmt IPsec Tunnel hin, oder ? Also statische Site2Site...

    Sobald das der Fall ist, kannst du bei der Telefonsuche auch die IP angeben...
    Vorher wie oben beschrieben die FW aktualisieren und gut ist.

    Funktioniert bei mir auch quer durch die remote-Sites

    Hallo,

    Fabian: vielen Dank für den Input, werde ich prüfen


    Quote

    Was deinen Fall angeht: Wurde der sAMAccountName im AD denn geändert?
    Du schreibst von "firma-1", gibt es eine "firma-2" mit dem selben User, so dass vielleicht das falsche AD-Objekt verwendet wird?
    In der STARFACE Datenbank kannst Du einen Blick in die Tabelle accountlogin werfen. Dort findest Du die Spalte samaccountname, in der das gefundene Attribut steht. Wenn dort nichts steht, wurde keine Entsprechung für den User gefunden. Meist ist dann ein Schreibfehler in der Email oder es gibt immer noch den case-sensitiven Vergleich.

    Der sAMAccountname wurde nicht händisch geändert. Denke es liegt an der Case-Sens.... er kann ja nicht mal zuordnen, wie man an dem NULL Attribut in der Log sieht:

    Code
    [2018-04-01 21:37:18,636] DEBUG de.starface.core.component.activedirectory.config.ADValidator Active Directory user: sAMAccountName: Benutzer.Name
    Username: Benutzer.Name@domain.local
    Password: ??? 
    E-Mail: null
    Matched local accountID: null

    tdaber:
    Gut verstanden, ein LIKE ist wohl zu viel verlangt. Sag ich nun einfach nix dazu. Ich bin mir aber sicher, dass der ein oder andere aus der Entwicklung mit lesen wird. -> Jungs(&MäDels)... kommt schon.
    Ich spreche mal mit Niclas da drüber, vielleicht hat der da magische Worte für die Entwicklung...:rolleyes: ...

    Ich werde Reue zeigen und das Ticket, wenn dann alles geht schließen lassen.

    Man man man ... Freunde so macht das kein Spaß

    Hallo Fabian,

    vielen Dank für die kleine Nachhilfestunde in Windows-Domänen. *schmunzel*

    Interessant zu wissen wäre, ob es bei den Email Adressen auf groß / kleinschreibung ankommt.

    Wäre das der fall, würde ich das ebenfalls BUG nennen, weil sorry - aber das ist dann einfach nur zu einfach programmiert. Und einen LIKE Vergleich einem == Vergleich vorzuziehen, wäre dann schon sehr ... aber naja. ist ja bekanntlöich alles eine "Stilfrage o_0"

    wie ich schon geschrieben hatte (und du ebenfalls zitiert hast), ist der von der Starface ermittelte sAMAccountname nicht gleich dem, welcher im ADSI-Editor steht. (Das ist der von dir erwähnte Attributs-Editor)

    Ich mache ein Ticket auf, und kläre den >>BUG<< mit Starface.

    Danach werde ich natürlich gerne berichten.

    Cheers - Chris

    Hi, vielen Dank für die Antwort.

    Ich hatte vergessen zu erwähnen, dass die Mailadresse gleichzeitig der UPN vom User ist.
    In dieser Installation kann ich aufgrund von verschiedenen Umständen nicht über den DOMAIN\User.Name gehen.

    Beispiel:

    Benutzer: Max Mustermann
    Email: Max.Mustermann@firma-1.de
    UPN: Max.Mustermann@firma-1.de
    sAMAccountName: max.mustermann-firma1
    Domain-User DOMAIN\max.mustermann-firma1

    In der Starface:

    Vorname: Max
    Name: Mustermann
    Email: max.mustermann@firma-1.de
    Login-ID:235
    Passwort: blablabla

    Mit dem Effekt, dass die Starface den falschen sAMAccount annimmt und abzugleichen versucht.

    Ablauf:

    • User gibt seinen AD-Username mitsamt Kennwort im Starface-Loginfenster ein
    • Starface sucht im AD nach dem eingegebenen Usernamen und lässt sich die Mail-Adresse zurückgeben, wenn dieser gefunden wurde
    • Wird die erhaltene Mail-Adresse auch bei einem Starface-Benutzer gefunden und ist das eingegebene Kennwort vom AD-User korrekt, wird der passende Starface-Benutzer angemeldet.

    was mich vor allem wundert ist, dass der sAMAccountName falsch ist ...

    Denn, wenn die Starface den sAMAccountName tatsächlich aus dem AD abfragen würde, dann wäre der wohl kaum anders in der Log, als dieser im ADSI-Editor ist - oder ?


    Vielen Dank für die konstruktive Info,

    Cheers - Chris

    Hallo zusammen,

    wenn ich das richtig verstanden habe, generiert die Starface aus der angegebenen Email-Adresse den sAmAccountname, nach welchem sie dann im AD sucht.

    Was aber, wenn der sAmAccountname ein anderer ist ?

    Dann passiert in etwa das hier:

    Beispiel: Benutzer.Name@domain.tld

    Code
    [2018-04-01 21:37:18,636] DEBUG de.starface.core.component.activedirectory.config.ADValidator Active Directory user: sAMAccountName: [B]Benutzer.Name[/B]
    Username: Benutzer.Name@domain.local
    Password: ??? 
    E-Mail: [B]null[/B]
    Matched local accountID: [B]null [/B]

    Selbigen Fall habe ich gerade bei einem Kunden, bei welchem ich den Anlagenverbund komplett auf AD-Auth umstellen will ...

    Hat von euch jemand eine Idee ?

    Danke und frohe Ostern,

    Cheers - Chris

    Hallo Alex,

    siehe hier: https://support.starface.de/forum/showthre…-nicht-anmelden

    Ich kann es reproduzieren, bei mir hängt es am Benutzernamen.


    Gruß Wolfgang

    Howto Starface DB ent-dummen:

    1. Emailadresse von user auf irgendwas ändern
    2. LoginID ändern
    3. Anmeldung probieren .. geht natürlich nicht.
    (manchmal noch neuen User anlegen mit selber email-adresse wie von gewünschtem User)
    4. Alles wieder zurück ändern
    5. geht ...

    Grüße,

    Chris

    Hi Yasin,


    Chris, gibts bei dir schon was neues?
    Würde sehr ungern eine VOIP Anlage auf ISDN ändern. War schließlich die Idee, auf VOIP zu wechseln.

    Ja - es gibt tatsächlich was neues...

    Ich habe eine - jetzt - MultiWAN-Umgebung bei dem Kunden: UnityMedia BIZ + Telekom

    Nun hat sich herausgestellt, dass der bereits vorhandenen und damals auch extrem stabil laufende QSC Anschluss auch Probleme macht.

    Daraufhin habe ich mal etwas tiefer gegraben und probleme mit den SIP - Verbindungen festgestellt. Es sieht so aus, als wenn die NAT sessions nicht lange genug "offen" bleiben,
    damit die Verbindung zur Telekom resp. QSC nicht abbricht.
    Zudem wurde ein load-balancing über die beiden WANs betrieben, was natürlich auch noch Probleme gemacht hat.
    Habe daher nun eine Internal---->SIP--->Internet---->via Telekom Multipathregel angelegt. Siehe da, QSC geht zumindest wieder.

    Nun habe ich gelesen, dass der SIP Client, also die Starface eigentlich ein "Keepalive" schicken muss, damit die Verbindung und NAT Session eben nicht zusammen bricht, bevor sie erneuert wird.

    Wenn das richtig funktioniert, sollte man auch keine eingehenden Ports mit DNAT mehr benötigen, zumal die Verbindung ja schon besteht und nicht erneut aufgebaut werden muss!?! Niklas

    Noch was zum Thema NAT und SIP... Egal wo man im Internet nach liest, hat man eigentlich immer die selben Probleme. Am besten funktioniert das Ganze tatsächlich, wenn die Starface direkt am Internet hängt.

    Wenn ich das richtig verstanden habe, hast du ja auch noch "doppeltes" NAT ? Sprich zwei private Netze zwischen der Starface und der Telekom ?

    Fritzbox----192.168.178.X------Watchguard-----192.168.123.X----->Starface

    Könnte mir vorstellen, dass das zusätzlich Probleme macht. ...

    Grüße,

    Chris

    Hi Niklas,

    Hallo cbka, hallo Yasin,

    ich würde euch beiden empfehlen tcpdumps zu erstellen in denen das Problem auftritt. Mein Gefühl sagt mir, das hier was im SDP nicht stimmt.

    Das mit den TCPDUMPS ist generell eine feine Idee, sofern du diese auswerten magst.

    Ticket mache ich dann auf, sobald ich vom Kunden Rückmeldung bekomme, dass es wieder Probleme gab.

    Was allerdings komisch ist: Sporadisch müssen da auch Probleme im SIP selbst auftreten, da z.B. an den Telefonen laut log nur das RINGING kommt, aber trotz dem Abnehmen des Hörers durch den Benutzer kein ANSWER auftaucht ?!


    Yasin: Wenn du schon eine Fritzbox vorne dran hängen hast, würde ich dir empfehlen, zumindest als Workaround, an der Fritzbox direkt per ISDN in die Starface zu gehen, sofern du S0 (ISDN) Ausgänge(Ausgang) an der Fritzbox hast.


    Beste Grüße,

    Chris

    Hallo Jürgen,

    Wichtig für die Sprache sind hier die eingehenden Ports 10.000 - 20.000. Je nach verwendetem Router auch die ausgehenden Ports beachten. Die ausgehenden Ports können i.d.r bei "Privatkundenroutern" vernachlässigt werden da eh alles raus darf.

    Gerne auch mal in den Firewall-Logs nach drops schauen.

    danke für die schnelle Antwort... jedoch habe ich da jetzt ein paar Fragen:

    Wieso zur Hölle ist die liebe DTAG wiedermal der einzige Provider, bei welchem ich eingenden Ports freigeben muss ?

    QSC, Sipgate, etc. funktionieren alle ohne probleme. eben auch ohne die eingehenden Ports.
    Sowie ich dich oder einen Kollegen mal verstanden hatte, wird doch die SIP Session von der Starface initialisiert und dann mit Keep-Alive Packets aufrecht erhalten ?

    Wenn das der Fall ist, wieso brauche ich dann eine regel für eingehende Verbindungen ?
    ich meine - klar, SIp ist nicht RTP .. aber wieso geht's bei den anderen und bei der DTAG wieder mal nicht ?

    und was hat das ganze dann mit dem fehlenden Eintrag in den Logs zu tun ?

    Grüße,

    Chris

    Hallo,

    ich habe bei einem Kunden auf ALL-Ip umgestellt und seitdem das im Titel genannte Phänomen.

    Topologie:

    VDSL-Modem--->Sophos-UTM---->Switch---->Starface-Pro-Appliance

    Ich habe das "Glück" gehabt, live bei so einem Vorfall anwesend zu sein und folgendes in der PBX Log gefunden:

    Anruf 1 war alles ok
    Anruf 2 war dann kein TON für beide Seiten zu hören

    Starface steht auf "hinter NAT" und die externe (Statische IP) der telekom ist eingetragen.


    Wie man sieht, feht beim Anruf 2, welcher kein TON hat die Zeile

    Code
    res_rtp_asterisk.c:        > 0x7fe87c1497c0 -- Probation passed - setting RTP source address to 217.0.4.167:29408

    kennt jemand das Phänomen ?

    Bin echt ratlos ...

    Danke und Grüße aus Karlsruhe,

    Chris

    Hallo Wolfgang,
    nö - leider nicht

    Habe jetzt gerade ne frische win7pro vm aufgesetzt um zu testen.
    Nix ... 1603. Advanced Installer Logging bringt auch nix ...
    ich bin am verzweifeln ...

    Hallo,

    bin weiter gekommen ... der fehler liegt wohl am nicht vorhandenen .NET-Framework.
    Habe jetzt das 4.6.2 per GPO verteilt ... asynchron ... nun installiert der UCC Client .. beim start kommt nun noch ein vcredist fehler .. ihm fehlt das VC++ 2015 redist.

    nachdem ich das installiert habe startet nun auch der Client ... wenn ich dazu komme schreibe ich noch eine ausführliche anleitung ...

    grüße Chris

    Hallo,

    wir haben sowohl hausintern als auch bei einigen Kunden das Problem, dass sich der neue UCC Client gar nicht per MSI udn GPO verteilen lässt ...

    Alles standardmäßig eingerichtet:
    Computerkonfig -> Richtlinien -> Softwareeinstellungen -> Softwareinstallationen MSI via UNC eingebunden

    gpo.png


    Bekomme in der Eventlog nur:

    eventvwr.jpg

    Die Installation der Anwendung STARFACE UCC Client v6.4.1.13 der Richtlinie Starface-Client ist fehlgeschlagen. Fehler: %%1603

    Habt ihr das auch schon mal gehabt ?


    Vorab mal schöne Weihnachten :)
    Grüße aus Karlsruhe

    Hallo,

    hatte das Problem mit abbrechenden Sessions aufgrund von fehlerhaftem Masquerading durch einen LANCOM router ... Hab den Anschluss dann auf NGN umgestellt (QSC ex Connect R) ... seitdem alles supi ... werde wohl auch in zukunft lieber NGN nutzen als SIp nach außen auf zu machen... ein Blick in die Logfiles verrät meistens schon warum ... und zudem ... ein whitelisting in der FIrewall von nur dem Registrar-bereich von Sipgate .. funktiiniert bei den meisten FWs nur IP-Basiert ... zumindest bei den Home und Entry Lösungen ... daher ist das abschotten des NATs durch Firewallregeln nicht so easy ... pfSense kann das aber btw ...

    Schöne Grüße aus Karlsruhe,

    Chris

    Hallo,

    wer das Problem bekommt, dass die "neuen" openstages von Unify angeliefert werden und dann die Autoprovisionierung nicht mehr funktionier kann sich wie folgt helfen:

    Wie im Wiki beschrieben, eine manuelles Downgrade der Firmware auf die aktuelle Starface-release-version der frimware machen:

    http://wiki.starface.de/index.php/OpenStage_Autoprovisioning

    Wichtig: FW Validation vorher ausschalten !
    http://wiki.starface.de/index.php/Open…ware_V3_R3.32.0

    Folgende Prozedur beschreibt die Vorgehensweise: Login als Administrator auf dem Webinterface des Telefons > System > Security > System > das Flag "Validate SW Upgrade" abschalten > submit

    http://wiki.starface.de/index.php/Open…g#Ab_STARFACE_5
    Aministrator Pages → File transfer → Phone application

    Download method: HTTPS
    HTTPS base URL: https://<IP-Adresse der Anlage>:50081/ap/fw/siemens-ec/
    Filename: Dateiname des Firmware-Images (i.d.R. openstage-15,openstage-40 ....)
    After submit: start download

    Submit zur Ausführung klicken


    Danach die Telefonsuche im Admin-Bereich nutzen - geht ... zumindest bei mir :):cool::cool::cool:;)