Pascom Cloud und Zoiper / Android SIP Client

Hallo zusammen,

hat es jemand von euch geschafft einen generischen Endpoint per Zoiper bzw. per Android SIP Client funktionsfähig zu bekommen? Der Mobile-Client ist einfach zu instabil. Er wacht oft einfach nicht auf, legt Anrufe auf oder Verbindungen brechen im laufenden Gespräch ab. Deswegen überlegen wir mobil auf einen stabileren SIP-Client zu wechseln, allerdings habe ich die Konfiguration nicht hinbekommen.

Ich habe zwar dies hier gefunden:
https://www.pascom.net/doc/de/endpoints/other/#neue-basiskonfiguration-erstellen

Aber wirklich helfen konnte mir dieser Artikel nicht.

LG

Hallo @hazington,

nicht unbedingt Zoiper, aber microSIP. Zumindest sollte sich die Konfiguration ableiten lassen.

Gruß,
Rapha

Hallo @hazington,

klar kannst Du versuchen ein andere Softphone dranzumachen. Ich befürchte nur, es wird Deine Probleme nicht lösen. Zoiper und Co müssen laufen um Calls annehmen zu können. Nach kurzer Zeit werden diese aber aus dem Hintergrund gekillt. Eine Push-Integration wie beim pascom Client ist schwer möglich.

Besser würde ich es finden, Deine Probleme mit dem Android Client anzugehen.

Ja, es gab Probleme mit der Telekom IPv6 Umstellung die zu Abbrüchen bzw. Problemen beim Annehmen der Calls führten. Diese sollten aber behoben sein.

Auch beim Pushen auf Android haben wir einiges verändert und pushen jetzt nur noch Calls mit High Prio (vorher auch Chat), sodass wir von Google nicht automatisch in der Prio zurückgestuft werden.

Hast Du die beschriebenen Probleme wirklich noch mit der aktuellsten Version?

LG
Mathias

Der Android Client ist in den letzten 12 Monaten deutlich besser geworden, ohne Zweifel. Allerdings ist er noch immer nicht zuverlässig genug. Bis auf meinen privaten Vertrag (Vodafone), sind alle meine Kollegen im Telekom-Netz. Wobei es eigentlich keine Rolle spielt, ob WLAN oder LTE ob Telekom oder Vodafone. Es spielt auch keine Rolle welches Smartphone und auch die Signal-Stärke des Netzwerks ist nicht unbedingt entscheidend.

Ich habe in allen Smartphones die Akku-Optimierung ausgeschaltet, Pascom unrestriktierten Datenzugriff im Hintergrund gewährt und sowohl bei mir zu Hause, wie auch im Büro das WLAN Netz auf 5 GHz umgestellt, weitere APs aufgestellt und das Netzwerk mehrfach gemessen und überprüft, um Störungen auszuschließen.

Bei mir zu Hause im Arbeitszimmer habe ich beispielsweise das schlechte Signal in meiner Wohnung, aber selbst hier zeigt mir Android die Signalstärke noch als “Fair” an und ich habe einen Receive/Transmit Link Speed von über 150 Mbps und einen RSSi von -67db. Sprich, das WLAN Netzwerk ist störungsfrei und das Signal stabil und gut, selbst in der schwächsten Ecke meiner Wohnung.

Dennoch wacht der Client nach einer längeren Inaktivität oft nicht auf. Wenn ich beispielsweise 3 Stunden oder auch mal einen Tag keine Aktivität im Pascom-Client hatte, dann öffnet sich die App bei einem eingehenden Anruf kurz und schließt sich sofort wieder. Es fängt gar nicht an zu klingeln. In der Gesprächshistorie sehe ich dann einen verpassten Anruf. Das Problem hierbei ist dann, dass es für den Anrufer weiter klingelt, ich aber keine Möglichkeit habe den Anruf anzunehmen. Es sei denn, ich starte die App manuell und der Anrufer blieb lang genug in der Leitung. Zumeist ist dies nicht der Fall, da, wenn dies passiert, der Anruf meist schon bis zu 15 Sekunden (selten mehr) beim Anrufer klingelte (getestet), ehe der Client überhaupt versucht hat den Anruf anzuzeigen (wodurch weitere Sekunden hinzukommen).

Ist der Pascom Client aber einmal beim Aufwachen gescheitert, dann wacht er für ein paar Minuten zuverlässig auf und das meistens mit wenigen Sekunden Verzögerung. Manchmal kommt es aber auch hier vor, dass ein Anruf mit 15 Sekunden angezeigt wird, mein Client aber nur 3 Sekunden klingelte. Das ist aber mit den letzten Versionen besser geworden. Wobei hier noch immer eine relativ stabile Netzwerkverbindung Voraussetzung ist. Bei schlechteren Netzen oder 3G, braucht man meistens gar nicht drauf zu hoffen, dass der Pascom Client aufwacht.

Wir nutzen bei uns alle die Beta-Version, daher habe ich auch die aktuellste Version. Als Nebengerät ist der mobile Pascom Client stand jetzt in Ordnung, aber als Hauptgerät, zumindest an Wochenenden bei Rufbereitschaft, müsste er zuverlässiger und schneller aufwachen. Mir ist als Software-Entwickler bewusst, dass das dieses Feedback nicht besonders hilfreich ist, aber ich frage mich, ob hier der mobile Pascom Client auch in realistischen Nutzungs-Szenarien getestet wird, weil es alle meine 13 Kollegen betrifft, die den mobilen Client unter Android nutzen.

Ich würde hier wirklich gerne besser weiterhelfen können, vor allem auch, da sowohl wir als Kunde, wie auch ihr als Anbieter davon profitieren würdet und habe daher u.a. mal den Feature-Request reingeschoben, eine Feedback-Funktion in den Pascom-Client zu integrieren, zumindest in die Beta-Version. Damit könnte ich als Benutzer aus der Anwendung heraus Feedback senden und ihr die Feedback-Funktion so gestalten, dass sie alle relevanten Logs mitsenden kann. Dann könnte man das Problem meiner Meinung nach besser analysieren. Hilfreich wäre es auch, wenn es eine Funktion gäbe, um die Pascom-App aus den Einstellungen heraus im Debug-Mode neuzustarten, falls ein erweiterter Log benötigt wird, der u.a. analysiert wie stabil und gut das Netzwerk war. Unter Windows und Mac sicherlich auch mit den Start-Parametern machbar, aber unter Android?

Hallo @hazington,

wenn ich das richtig verstehe, ist das verbleibende Problem das schnelle Aufwachen bei Pushes.

Ich möchte erst ein paar technische Details erklären und dann sehen ob man da noch was verbessern kann:

Generell braucht unsere App zum “Aufwachen” sobald sie einen Push bekommt 2-6 Sekunden. Je nachdem wie schnell das Handy ist und ob die App noch komplett im Speicher war.

In etlichen Versuchen haben wir bewiesen, dass wir immer reagieren, sobald wir einen Push bekommen und unsere App das nicht länger als die 6 Sekunden verzögert. Falls es ein Problem beim Start gab, melden wir das beim nächsten Login in die App. Wir “verschlucken” also keine Pushes.

Jetzt ist es aber mit den Pushes im Google Netzwerk wie folgt (Bei Apple ist das anders und wesentlich schneller):

Sendet man einen High-Prio Push und das Gerät hat schon lange keinen Push mehr über das Google Netzwerk erhalten oder ist im “Doze” Modus, kann es bis zu 15 Sekunden dauern, bis der Push ankommt. Addiert man dann die Worstcase 6 Sekunden dauert es 21 Sekunden, bis das Telefon klingelt.

Wenn Du jetzt das Telefon noch in einem Team eingebucht hast, passiert Folgendes:

  1. Das Team ruft das Mobile z.B. 15 Sek. Membertimeout
  2. Der Push kommt nach 10 Sekunden an
  3. Die App wacht auf und merkt zu Sekunde 16, dass der Call eigentlich schon zu Ende ist und legt sich wieder schlafen.
  4. Das Team hat den Call zwischenzeitlich in der Queue und stellt den evtl. wieder zu, gleiches Spiel von vorne

Hier kann man durch geeignete Konfiguration der Teams natürlich was verbessern.

Aber gegen die Worstcase, durch den Push verlorenen 15 Sekunden, können wir genau gar nichts machen.

Alternativ macht es evtl. Sinn, für sehr kritische Anrufe (Bereitschaft, etc) den GSM Modus einzuschalten?

Evtl. stellen sich die Probleme bei Dir aber ganz anders dar und haben mit den von mir beschriebenem Szenario nichts zu tun.

LG
Mathias

Hallo Mathias,

zunächst vielen Dank für das sehr umfangreiche und detaillierte Feedback!

Das kann ich im Großen und Ganzen bestätigen. Deswegen bekommen die Vertriebler auch die Info, die mobile Pascom App immer mal wieder zu öffnen.

Ich habe einige Male diese Fehlermeldung gesehen. Es ist weniger geworden, aber noch immer erhalte ich (wenn auch selten) die Info, dass der Pascom Client nicht aufgeweckt werden konnte. Grundsätzlich sehe ich immer, dass der Client versucht aufzuwachen.

Beim iPhone gibt es nur leider das Problem, dass hier keine Labels bei Anrufen angezeigt werden. Da wir aber verschiedene Marken und Abteilungen haben, die jedoch vom gleichen Team betreut werden, müssen die Kollegen aus dem Vertrieb das erste Label sehen, um entsprechend am Telefon reagieren zu können.

Ich hatte für das iPhone ein Feature-Request gesendet, nach dem es konfigurierbar sein sollte, was im Anruf-Fenster angezeigt werden soll. Ich dachte an folgende Auswahlmöglichkeiten: Rufnummer des Anrufers (Standard und Fallback), Name aus Telefonbuch oder eben ein x beliebiges Label. Wir würden dann in dem Falle das Label “1” auswählen, welches die Marke beinhaltet. Welche Nummer anruft, ist nicht so wichtig.

Das Feature wurde aber leider abglehnt, daher ist das iPhone keine Option. Evtl. kann man den Feature-Request wieder aufnehmen.

Das beschreibt die existieren Verzögerungen ziemlich genau.

Ich denke, dass bei unserer Team-Konfiguration leider nichts rauszuholen ist. Grundsätzlich ist es so, dass wir ein Timeout von 20 Sekunden haben und nach diesem wird der Anruf an eine externe Rufnummer (Call Center) abgeworfen. Ist kein Agent aktiv, erfolgt der Abwurf sofort. Das Timeout nochmal zu verlängern, würde nur dazu führen, dass der Kunde noch wahrscheinlicher auflegt, als nach den 20 Sekunden + X bis der Anruf im Call Center klingelt. Das Timeout sollte eigentlich bei 12 Sekunden liegen, allerdings auf Grund der möglichen Mobile-Client Verzögerungen eben 20.

Ich hoffe doch einfach mal, dass ihr es dennoch versucht. Evtl. gibt es ja doch eine Möglichkeit, das zu verbessern bzw. es folgt zukünftig eine. 15 Sekunden Verzögerung sind halt schon kritisch. Nicht viele Kunden bleiben so lange in der Leitung. Selbst mit Wartemusik nicht.

Ist hier die Push-Verzögerung denn anders? Tatsächlich haben die Mitarbeiter die Devise, unterwegs in den GSM Mode zu wechseln. Wir alle wissen ja, wie gut ausgebaut das deutsche Mobilfunk-Netz ist… Sofern es hier Unterschiede gibt, können wir durchaus, zumindest für die Kollegen in Deutschland, den GSM Mode zum Standard machen.

LG

Hallo @hazington,

kurz zur Erläuterung: Wenn der GSM Modus eingeschaltet ist, geht der Anruf vollständig an der pascom App vorbei. Der Server macht eine normalen ausgehenden Anruf (der dann natürlich einen Kanal im Amt belegt, bzw. zwei, da: Anrufer -> Amt -> Server -> Amt -> GSM Handy.

Da ist kein Push im Spiel, sondern nur die Verzögerungen die bei einem Standard GSM bzw. VoLTE Anruf an Handy selbst durch die beteiligten Provider entstehen.

Der Anruf erscheint dann auch entsprechend nicht im UI des Clients, und weitere Funktionen (Video, Transfers, Halten, etc.) stehen nicht zur Verfügung bzw. hängen von den Merkmalen des Handyvertrags ab.

Die Internetverbindung wird in diesem Fall in nicht verwendet.

Grüße,
Jan

Das können wir leider nicht machen. Das iPhone sieht dazu keine Option vor. Die Nummer und den Namen einfach anders zu setzen hat dann wieder X andere Nebenwirkungen.

Ja, aber das Google Netzwerk werden wir wohl nicht beschleunigen können, aber schön, dass Du uns das zutraust ;).

Wie Jan schon sagt: Das macht dann direkt GSM. Macht sicher Sinn den Timeout hierfür für kritische Anwendungen zu verringern. Dann kommt der Anruf jedenfalls per GSM durch.

LG
Mathias