XMPP Klasse für C# in Verbindung mit C#

  • Hallo Zusammen,


    da leider die RESTApi leider noch keine Rufsteuerung kann, muss ich auf die XMPP Schnittstelle zurückgreifen.
    Kennst jemand eine gute Klasse für C# mit der er in Verbindung mit Starface gute Erfahrungen gemacht hat?


    VG Thomas Lauer

    Thomas Lauer
    Geschäftsführer
    _____________________________
    Glöckler & Lauer GmbH & Co. Systemhaus KG
    Böttgerstrasse 1
    D-89231 Neu-Ulm


    Tel. +49 731 97401-0
    Fax +49 731 721243
    Lauer@glsh.net
    http://www.glsh.net

  • Hallo Thomas,


    unabhängig vom weltbesten UCC Client ? ;)


    Dann schau Dir mal das Programmverzeichnis vom Client an. Daselbst findest Du die uci-all.net.dll, welche eine cross compiled UCI Client-Implementierung und Smack enthält. Damit kannst Du alles programmieren, was auch der Client mit dem Server anstellt. Aber beachte: Das ist nicht weiter dokumentiert und subject to change, da es eine interne Bibliothek ist. Wenn Du die UCI Doku kennst und dich über Smack schlau machst, kommst du damit weiter.


    Gruß Wolfgang

  • Hallo Thomas


    Aus meinem Alten Programm (Code eventuell veraltet)


    Code
    public void ConnectSF()
            {          
                string restPath = string.Format("http://{0}/rest/", ServerIP);
                wrapper.Connect(restPath, Username, Password); //Zuvor definierter Wrapper (Je nachdem welche komponente bezogen wird)
                if (wrapper.IsLoggedIn)
                {
                    stat_lbl_Connection.Text = "Verbunden";
                }
            }


    MfG


    Fabian

  • Hallo Thomas,


    auf Basis der Client-Implementierung gibt es verschiedene Ansätze.


    Diese Varianten erfordern einen UCC Client mit angemeldetem Benutzer. Alle Aktionen werden im Kontext des angemeldeten Benutzers ausgeführt. Der UCC Client ist sichtbar und zeigt die Rufe auch an.
    Sie sind offiziell unterstützt und werden auch ggf. supported:

    • Wählen per Kommandozeile: StarfaceUcClient.exe /PHONENUMBER="42"
    • Wählen per Callto / phone / tel / sip URL: <a href="callto:+4972112345678">Ruf an via callto link</a><br>
    • TAPI
    • Verwendung der UccWrapper.dll und WCF TCP Binding


    Es gibt weitere Alternativen, die offiziell nicht unterstützt sind und auch nicht supported werden. Dies wäre ein Weg, wenn man partout eine andere UI haben möchte oder eine zentrale, serverbasierte Rufsteuerung für mehrere Benutzer implementieren will.

    • Verwendung der UccAPI.dll um eine alternative UI zu implementieren
    • Verwendung der UccAPI.dll im Headless-Modus um mehrere User parallel anzumelden. Dies verwende ich selbst für automatisierte Integrations-Tests. Ruf-Steuerung, Chat etc. ist aus einem Prozess heraus für mehrere Benutzer möglich.
    • Verwendung der uci-all.net.dll um direkt mit der cross-compiled (Java -> .NET) UCI zu arbeiten. Das wäre die hardcore Variante.


    Welches Schweinderl hätten S' denn gern?


    Gruß Wolfgang

  • Hallo Wolfgang,


    eigentlich wollten wir direkt mit dem XMPP Server kommunizieren. Leider haben wir hier sein ca. 10 Monaten ein Problem, dass auch schon beim Support [Call#1068692] liegt,
    dass der XMPP Server sehr spät Call Events (z.B. Hangup) sendet. da wir im Moment nicht an eine Lösung vom Support glauben, suchen wir einen anderen Weg.


    Wir sind im Moment an der UccAPI.dll (da undokumentiert, beisen wir uns durch - dotpeek sei dank).


    Super wäre kleine Beispiele in C#.


    Den Unterschied zwischen UccAPI.dll und der uci-all.net.dll habe ich leide rnicht kapiert.


    VG Thomas

    Thomas Lauer
    Geschäftsführer
    _____________________________
    Glöckler & Lauer GmbH & Co. Systemhaus KG
    Böttgerstrasse 1
    D-89231 Neu-Ulm


    Tel. +49 731 97401-0
    Fax +49 731 721243
    Lauer@glsh.net
    http://www.glsh.net

  • Hallo Fabian,


    wenn es dich nicht geben würde ;-). Super vielen Dank.
    Im Moment helfen wir uns mit dotpeek aus um zu verstehen was wo läuft.


    VG Thomas

    Thomas Lauer
    Geschäftsführer
    _____________________________
    Glöckler & Lauer GmbH & Co. Systemhaus KG
    Böttgerstrasse 1
    D-89231 Neu-Ulm


    Tel. +49 731 97401-0
    Fax +49 731 721243
    Lauer@glsh.net
    http://www.glsh.net

  • Hallo Thomas


    Hier wäre sonst aus meinem alten Projekt den ganzen Ablauf für den Import:


    http://module.nucom.ch/forum/5780/Adressbook.rar



    MfG


    Fabian

  • Hallo Thomas,



    eigentlich wollten wir direkt mit dem XMPP Server kommunizieren. Leider haben wir hier sein ca. 10 Monaten ein Problem, dass auch schon beim Support [Call#1068692] liegt,
    dass der XMPP Server sehr spät Call Events (z.B. Hangup) sendet. da wir im Moment nicht an eine Lösung vom Support glauben, suchen wir einen anderen Weg.


    das Ticket habe ich zur Kenntnis genommen, da habe ich aber keine Aktien drin. Als Client konsumiere ich dieselben XMPP / UCI Events wie Du. Abgesehen von den optimierbaren Zustandsübergängen (insbesondere wenn Module im Spiel sind) kann ich nicht bestätigen, dass die Events allgemein zu spät kommen. In der Regel funktioniert dies. Andernfalls wären unsere Clients ebenso gestört. Falls bei Eurer Installation mit der bisherigen Implementierung die Events - warum auch immer - zu spät kommen, werden diese auch in einem .NET Client entsprechend spät aufschlagen. Oder wie verhält es sich damit?



    Den Unterschied zwischen UccAPI.dll und der uci-all.net.dll habe ich leide rnicht kapiert.


    • uci-all.net.dll ist die cross compiled Java UCI. Da ist die UCI drin, Smack und noch ein paar Abhängigkeiten
    • UccSipPhone.dll enthält den SIP Stack inkl. managed wrapper
    • UccAPI.dll setzt auf diesen beiden auf und baut damit das Call Modell (Verknüpfung von UCI und SIP Calls) für den Client etc


    In der UccAPI.dll sieht der Login Code etwa so aus (unter Verwendung der uci-all.net.dll):


    Code
    var xmppTransportFactory = new XmppUcpTransportFactory(applicationName, networkHost, uciPort, true);
    var proxyFactory = UciProxyFactory.createWithTransportFactory(xmppTransportFactory);
    m_proxy = proxyFactory.createUciProxy(loginId, PasswordEncryption.GetXmppSecret(loginId, m_connectionSettings.SecurePassword, m_serverIsUsingActiveDirectoryAuthentication));
    m_proxy.connectAsync();
    m_proxy.addConnectionEventListener(this);


    Wenn die Anmeldung erfolgreich ist, wird der Callback aufgerufen, in welchem Du Zugriff auf die weiteren UCI Interfaces holen kannst:


    Code
    public void receiveConnectionState(bool newConnectionState)
          {
              m_proxy.subscribeEventsAsync(this, typeof(UciUserStateEvents));
              m_userStateRequests =(UciUserStateRequests) m_proxy.getRequests(typeof(UciUserStateRequests));
          }


    etc. Du musst in Deiner Klasse diverse Interfaces implementieren, damit Du die Events bekommst: UciConnectionEvents, UciUserStateEvents, UciSystemEvents, ...


    Das war die Hardcore-Variante.


    Gruß Wolfgang

    Development


    STARFACE GmbH | Adlerstraße 61 | 76137 Karlsruhe | www.starface.com

    Einmal editiert, zuletzt von Wolfgang ()

  • Hallo Wolfgang,


    wir haben jetzt mal einen Dump der Starface Anlagen Antworten gemacht, in dem man sehr schön sieht, wann was von der Starface zurückkam. Folgende XML-Sätze habe ich dazu an die XMPP Schnittstelle gesendet.



    <stream:stream to="${host}" xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams" version="1.0"><?xml version='1.0' encoding='UTF-8'?>


    <iq id="${shortid()}" type="get"><query xmlns="jabber:iq:auth"><username>uci-${user}</username></query></iq>


    <iq id="${shortid()}" type="set"><query xmlns="jabber:iq:auth"><username>uci-${user}</username><password>${password}</password><resource>StarfaceUcClient_v6.4.2.81-b83fabba-8dc8-470f-938e-ecb9015569a1</resource></query></iq>


    <iq id="${shortid()}" to="starface.xmpp.uci@${host}/STARFACE" from="uci-${user}@${host}/StarfaceUcClient_v6.4.2.81-b83fabba-8dc8-470f-938e-ecb9015569a1" type="set"><query xmlns='jabber:iq:rpc'><methodCall><methodName>ucp.v30.requests.connection.login</methodName></methodCall></query></iq>


    <iq id="${shortid()}" to="starface.xmpp.uci@${host}/STARFACE" from="uci-${user}@${host}/StarfaceUcClient_v6.4.2.81-b83fabba-8dc8-470f-938e-ecb9015569a1" type="set"><query xmlns='jabber:iq:rpc'><methodCall><methodName>ucp.v30.requests.service.subscribeEvents</methodName><params><param><value><string>ucp.v30.events.call</string></value></param></params></methodCall></query></iq>


    Die Platzhalter wurden selbstverständlich ersetzt. Den Mitschnitt der Antworten der Starface XMPP Schnittstelle sind als Datei im Anhang (log.txt). Zur Info: Der Anruf wurde direkt wieder aufgelegt. Die XML Dumps zeigen aber, dass nach 3 Minuten erst ein CONNECTED state gemeldet wird.


    Ich hoffe das hilft, den Sachverhalt zu verstehen. Der UC-Client zeigt die Stati in-time und korrekt an. Aber was mache ich falsch?


    Viele Grüße,
    Domink

  • Hallo,


    wo bekomme ich die Klasse PasswordEncryption her?
    Wofür steht applicationName?


    Die Klasse PasswordEncryption ist intern. Die Funktion GetXmppSecret berechnet das zu übertragene Passwort / Secret gemäß den Regeln aus dem "Cheatsheet zum sicheren Login für UCI, Chat und Adressbuch.pdf". Siehe unter https://knowledge.starface.de/…age.action?pageId=7864733


    Das zu übertragene Secret unterscheidet sich für die Use Cases "Active Directory Authentication" und "normale Starface Authentication".


    Der Application-Name ist ein Name für Deine Anwendung. Daraus wird die Resource für die Jabber ID Deines Clients gebildet.


    Gruß Wolfgang

  • Hallo Dominik,


    ich verstehe noch nicht ganz, was Ihr hier gemacht habt.


    Ihr habt als fake eine Anmeldung eines StarfaceUcClient_v6.4.2.81 emuliert und simultan mit einem echten UCC Client angemeldet. Dann habt Ihr mit Eurer Anwendung die XMPP Nachrichten mitgeschnitten?
    In Eurer Anwendung kommen die Events zeitversetzt, aber der gleichzeitig laufende UCC Client bekommt die Nachrichten sofort?


    Vielleicht habt Ihr in Eurer Anwendung auch ein Problem mit dem Threading? Kommen andere Events (user state change etc.) ebenfalls zeitversetzt?


    Gruß Wolfgang



  • Hallo Wolfgang,


    wir nutzen jetzt die uci-all.net.dll in unserem Projekt. Das funktioniert eigentlich sehr gut.
    nur wenn der UCC Client nicht vorhanden ist, bekomme ich diese Fehlermeldung


    de.starface.integration.uci.v30.client.UcpConnectionFailedException: Could not start XMPP transport.


    Brauche ich da noch mehr DLLs?


    VG Thomas

    Thomas Lauer
    Geschäftsführer
    _____________________________
    Glöckler & Lauer GmbH & Co. Systemhaus KG
    Böttgerstrasse 1
    D-89231 Neu-Ulm


    Tel. +49 731 97401-0
    Fax +49 731 721243
    Lauer@glsh.net
    http://www.glsh.net

  • Hallo Wolfgang, ich komme nochmals auf diesen Thread zurück.


    Im Moment nutzen wir die UCI zur Authentifizierung. Dazu verwenden wir diesen Code:


    Code
    var transportFactory = UciProxyFactory.createWithTransportFactory(new XmppUcpTransportFactory(applicationName, domain, 5222, true));
    var hashedPassword = PasswordEncryption.GetXmppSecret(loginId, password, true, false);
    _uciProxy = transportFactory.createUciProxy(loginId, PasswordEncryption.GetXmppSecret(loginId, password, true, false));
    _uciProxy.connect();


    Nun haben wir die Anforderung die ActiveDirectory Authentifizierung zu implementieren.
    Hast du mir dazu ein paar Tipps?


    VG Thomas :rolleyes:

    Thomas Lauer
    Geschäftsführer
    _____________________________
    Glöckler & Lauer GmbH & Co. Systemhaus KG
    Böttgerstrasse 1
    D-89231 Neu-Ulm


    Tel. +49 731 97401-0
    Fax +49 731 721243
    Lauer@glsh.net
    http://www.glsh.net

  • Hallo Thomas,


    versuch's mal mit:

    Code
    _uciProxy = transportFactory.createUciProxy(loginId, PasswordEncryption.GetXmppSecret(loginId, password, true, true));


    Gruß Wolfgang

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!