Hallo zusammen,
wir haben in unserer Software eine XMPP Schnittstelle bei der wir eingehende Anrufe auswerten können.
Leider kommen im XML Stream seit 2-3 Wochen keine Events mehr zu eingehenden Anrufen an.
Die IQ Pings funktionieren ganz normal und auch einen ausgehenden Anruf können wir initiieren => das heißt die Verbindung steht.
Habt ihr eine Idee woran das liegen könnte?
Hi Kammerlohr,
Kind regards,
Stefan
Hi Stefan,
we re using the pascom Cloud :slight_smile 
Our ClientInfo is correct because we can start outgoing calls and receive pings.
We subscripe for module: base type: * scope: user but changed nothing here.
Hi,
wir werden das in dem offenen Support Ticket klären.
Viele Grüße,
Sebastian
Hallo @Kammerlohr,
es sollte so sein:
Wenn Du das Modul base mit dem scope user abonnierst, dann siehst Du nur Events die den User direkt betreffen. Also Calls an ihn oder eine Queue in der er Mitglied ist.
Wenn der User alle Calls sehen kann, muss er zum einen XMPP Superuser sein und zum anderen musst Du den scope öffnen.
Natürlich möchte ich auch eine Veränderung des Verhaltens oder einen Bug auf unserer Seite nicht ausschließen.
Um das einfacher beurteilen zu können habe ich hier ein kleines Go Testprogramm:
package main
import (
"crypto/tls"
"log"
"os"
"gosrc.io/xmpp"
)
func main() {
config := xmpp.Config{
Address: "pascom.cloud:5222",
Jid: "cbrown@pascom",
Password: "",
StreamLogger: os.Stdout,
TLSConfig: &tls.Config{InsecureSkipVerify: true},
}
router := xmpp.NewRouter()
client, err := xmpp.NewClient(config, router)
if err != nil {
log.Fatalf("%+v", err)
}
cm := xmpp.NewStreamManager(client, xmpp.PostConnect(clientInfo))
log.Fatal(cm.Run())
}
func clientInfo(c xmpp.Sender) {
c.SendRaw(`<iq id="9WTfy-9" type="get">
<cmd xmlns="http://www.pascom.net/mobydick" module="xmppuser">
<ClientInfo>
<os>Mac OS X 10.9</os>
<osUser>cbrown</osUser>
<clientVersion/>
<user/>
<jid/>
<clientIp/>
<AddSubscription>
<Subscription module="event" type="*" scope="user"/>
<Subscription module="base" type="*" scope="user"/>
<Subscription module="journal" type="*" scope="user"/>
<Subscription module="base" type="ChannelEvent" scope="supervisor"/>
</AddSubscription>
</ClientInfo>
</cmd>
</iq>`)
}
Hier musst Du noch Jid und Passwort anpassen. Bei mir hat dieser Testclient (XMPP Supervisor vorausgesetzt) alle eingehenden Calls angezeigt. Calls werden generell erst angezeigt, wenn auch ein Peer läutet. Also nicht z.B. während der Anrufer noch eine Ansage bekommt, etc.
LG
Mathias
Hallo @Mathias
wir haben base / user abonniert - jedoch stellt jeder Client seine eigene Verbindung zu pascom.cloud her (mit den eigenen Anmeldedaten, wie im Pascom Client) und hat dann auch in der Vergangenheit die Anrufe der Queue bekommen (wenn er Mitglied ist) und seine eigenen. Somit muss der Service User garnicht XMPP Superuser sein, sondern jeder Software-Benutzer kann Pascom Einstellungen mit angeben.
Soweit ich sehe, wird die ClientInfo korrekt übertragen, die UserInfo kommt zurück und dann kommen nur noch Pings an. Außgehende Anrufe können initiiert werden jedoch kommen keine ChannelEvents mehr an.
PS: Wenns weiter hilft, kann ich alles nötige in eine C# Testanwendung kopieren und hochladen.
Viele Grüße
Matthias
Verstehe. So sollte es auch sein. Bekommt der User in Deinem Fall dann noch seine eigenen ChannelEvents und nur die der Queue nicht oder gar keine mehr?
Danke, vorerst nicht. Denke, ich kann er auch so reproduzieren, sobald ich Dein Szenario genau verstanden habe.
LG
Mathias
Es kommen keine ChannelEvents mehr an - weder Gruppenanrufe noch von der Queue.
Grüße
Matthias
Hallo Matthias,
also: Ich sehe ChannelEvents bei Queue-Anrufen als “normaler user” nur, wenn ein Kanal zu meinem User aufgebaut werden kann. Wenn also
Anrufe an andere Queue-Teilnehmer (z.B wenn die Rufstrategie “nacheinander” ist) sehe ich nicht. So sollte es aber auch sein, wenn ich kein Supervisor bin.
LG
Mathias
Hallo Mathias,
mein Testaufbau ist folgender.
Ich melde mich mit unserem c# XMPP Client an und die Verbindung bleibt bestehen (pings kommen an).
Mein User ist in der Queue angemeldet - Rufstrategie “alle anklingeln”
Wie gesagt, es hat sich unsererseits nichts geändert und mit die ChannelEvents kommen erst seit dem letzten Update nicht mehr an. Ich kann mir auch nicht wirklich erklären woran es liegt. Das Problem besteht auch an verschiedenen PCs / Internetleitungen / Standorten.
Grüße
Matthias
Hallo Matthias,
das ist wirklich seltsam. Ist es Dir möglich mein Go Programm zu verwenden, um zu testen, ob Du da die ChannelEvents erhältst?
LG
Mathias
Hallo Mathias,
ich habe nun etwas mehr Zeit benötigt, da ich verschiedene Testfälle probiert habe.
Ergebnis ist, dass der GO Code funktioniert und die Channel Events dort ankommen.
Mein nächster Gedanke war, dass es an der C# Library liegen könnte - ich habe dann Wireshark installiert. Laut Wireshark kommen bei gestartetem C# Testprogramm zum Zeitpunkt des Anrufes keine Pakete an (tcp.port == 5222) - ich sehe jedoch die Pings und ClientInfo (laut Zeitstempel).
Jetzt ist natürlich die Frage woran des dann noch liegen könnte…
EDIT: Das Problem besteht über verschiedene Internetleitungen, Mobilfunk und mehrere Standorte hinweg. Auch in einer “frisch” installierten VM besteht das Problem. Wie angesprochen funktionierte unter einer lokalen Testumgebung 18.03 noch alles und nach dem Upgrade auf 18.09 nicht mehr…
Hallo zusammen,
die Ursache liegt in einer recht subtilen Verhaltensänderung in der aktuellen Openfire-Version. Damit ein Client die ChannelEvents weitergeleitet bekommt, muss dieser nach dem Login mindestens ein <presence /> Paket an den Server gesendet haben, damit die Session tatsächlich “available” wird.
Die im Go-Programm von Mathias verwendete Library macht das automatisch, die aus dem C#-Testprogramm tut das nicht.
Ohne Presence werden die Pakete von Openfire silent verworfen, man findet das nur im Debugger oder möglicherweise bei eingeschaltetem Debug-Logging. Für uns (im Sinne von “pascom Quellcode”) gibt es an der Stelle leider auch keine einfache Möglichkeit das festzustellen - wir werden aber entsprechende Hinweise in unsere API-Dokumentation (die noch im Entstehen ist) aufnehmen.
Grüße,
Jan