Mobiles Softphone, bereit für White Label: so haben wir es gemacht
Kürzlich nahmen wir an der großen Telekommunikationskonferenz über Asterisk & VoIP teil und kündigten dort lang erwartete Softphone-Anwendungen für Android und iOS an. Und das haben wir gesagt.
Wer braucht mobile Softphones
Windows und macOS bilden ein Office-Ökosystem: Diese Betriebssysteme sind für Sekretärinnen, Anwälte, Buchhalter, Contact-Center-Agenten, Vorgesetzte und deren Führungskräfte gedacht. Deshalb gibt es in unserer Produktlinie Versionen sowohl für Windows als auch für macOS.
Mittlerweile haben viele Unternehmen Mitarbeiter, die mit Smartphones unterwegs sind: Verkäufer, Fahrer, Spediteure und so weiter. Kommunizieren sie mit Kunden, rufen sie sie an? Aber sicher, das versteht sich von selbst. Brauchen Arbeitgeber die Möglichkeit, ein Firmen-Smartphone mit einer Telefonanlage zu verbinden? Keine Frage.
Aus diesem Grund werden wir oft nach einem mobilen Softphone gefragt: Solche Fragen kamen sowohl von Unternehmen mit „Reisenden-Angestellter“ als auch von Telekommunikationsanbietern. Es ist klar, warum letztere auch darauf achten: sie wollen mit ersteren Geschäfte machen, indem sie nicht nur Desktop-Lösungen, sondern auch Android- und iOS-Versionen anbieten … idealerweise unter ihren eigenen Marken und Logos.
Als wir eine kritische Masse an Fragen hatten, dachten wir: Warum nicht? Und beschlossen: Wir machen es. Wir werden ein mobiles Softphone entwickeln, das bereit für White Label ist!
When a critical mass of the questions reached, we thought: why not? And decided: we’ll do it. We'll do a mobile softphone fit for White Labeling!
Entwicklungsaufgabenerklärung
Die wichtigsten Fragen waren die folgenden: Was ist besser für das Backend? Welche Sprachen und Frameworks sollte man wählen? Hat ein plattformübergreifender Ansatz eine Daseinsberechtigung? Und nicht zuletzt – was ist mit dem Tiefschlaf der App? Es ist sehr ärgerlich, wenn eine App nicht aus dem Ruhemodus geweckt werden kann. Außerdem führt dies zu verpassten Anrufen und verlorenen Clients. (Mit Blick auf die Zukunft haben wir das auch erfolgreich bewältigt, aber das ist ein Thema für einen anderen separaten Beitrag.)
Technologie-Stack: Framework, Programmiersprache und Erfahrungen anderer
Beim Durchsehen der Technologien haben wir etwas Interessantes über Acrobits, Zoiper (sie haben auch mobile Apps), WhatsApp und Telegram herausgefunden, die auch (mit etwas Übertreibung) als Softphones bezeichnet werden können, da es RTP-Verkehr gibt.
WWir haben beispielsweise festgestellt, dass sie für Windows alle in Java (Sprache) und Kotlin (Framework) geschrieben sind; für macOS sind es Swift beziehungsweise Objective-C.
Was das Backend betrifft, hat jeder seinen eigenen Weg: WebRTC, PJSIP oder sogar etwas Selbstgeschriebenes. Was hat es uns gebracht? Nur eine Vorahnung, dass unser Weg wahrscheinlich kein Kinderspiel sein wird :)
Auswahl zwischen plattformübergreifend und nativ
Wir haben die Frage aufgeworfen: Was wäre, wenn es eine Codebasis für iOS und Android gäbe? Wäre das besser? (Wir gingen davon aus, dass dies der Fall wäre, da sich die Arbeit und die Codemenge halbieren würden.) Wäre das einfacher?
Dann haben wir viele verschiedene Kombinationen ausprobiert: WebRTC und PJSIP dienten als Grundlage für die Datenübertragung, und Swift und Kotlin, die wir bereits als native Sprachen erwähnt haben, haben wir auch drei plattformübergreifende Frameworks ausprobiert: Qt, React und Flutter. Was wir schließlich bekamen, hatte sowohl Vor- als auch Nachteile. In keinem Fall gab es einen fehlerlosen Sieg, aber ein Paar erwies sich als eindeutiger Außenseiter: die Kombination Flutter + PJSIP funktionierte überhaupt nicht.
Die Abkömmlinge von Flutter und WebRTC erwiesen sich als lebendiger, aber das alles ist. Wir gruben tiefer (vielleicht funkt es?), gaben es aber bald auf: Eines Tages stießen wir auf ein Repository, in dem es einen Lösungsversuch gab. Die Community versuchte, ein ähnliches Problem wie unseres zu lösen … und der Quellcode hatte bereits 8.000 Zeilen, wobei es sich anscheinend nur um einen Anfang handelte.
In diesem Moment wurden wir nachdenklich und begannen zu zweifeln.
Also haben wir das Experiment abgebrochen. Damit war Flutter der erste, der das Projekt verlassen hat.
Dann haben wir uns mit der nächsten Gruppe von Versuchskaninchen, nämlich PJSIP, WebRTC und React, einem plattformübergreifenden Framework.
In beiden Paaren haben wir etwas zum Laufen gebracht, aber es was als ein Trailer für unineteresant Film: alle Pointen wurden bereits gezeigt, der Müll bleibt. Wir konnten das Gefühl einfach nicht loswerden, dass zwangsläufig verschiedene Nachteile auftreten würden. Nennen wir es Intuition. Es wurde eine bewusste Entscheidung getroffen, React von der Betrachtung auszuschließen.
Daher wurde die Liste auf einen Kandidaten aus der Cross-Plattform-Partei (Qt), einen aus der Android-Native-Partei (Kotlin) und einen weiteren von Apple (Swift) gekürzt. Sie sollten im Endkampf aufeinandertreffen.
Zeig mir dein Gesicht
WWir haben beschlossen, dass der erste (und wahrscheinlich einzige) Kampf mit dem Android-Vertreter stattfinden wird. Die Wettbewerbsregeln lauten: Wir bauen ein mobiles Softphone auf Qt und Kotlin; in beiden Fällen ist der Aufwand gleich; dann vergleichen wir die Ergebnisse. Sollte Qt untergehen, ist Swift automatisch auch ein Gewinner. Wenn Qt gewinnt, muss es einen weiteren direkten Kampf geben: Qt gegen Swift. Mit anderen Worten, die plattformübergreifende Essenz sollte immer die Überlegenheit beweisen, sonst verfehlt sie den Sinn der Nutzung.
Apropos, schauen Sie, wer hier ist, und raten Sie, wer wer ist.
Qt ist links, Kotlin ist rechts.
Auf den ersten Blick sehen sie ähnlich aus. Aber bei genauerem Hinsehen entdeckt man seltsame Schatten unter den Tasten, schmalen Freiraum auf der linken Seite und andere Details, die bei der Benutzung auftauchen. Kleinigkeiten und der Teufel dahinter.
Sicher, die linke Schnittstelle kann verbessert werden. Ja, technische Details könnten behoben werden. Aber es ist Mehrarbeit, obwohl wir die gleichen Ressourcen (Zeit und Aufwand) aufwenden wollten, ist das das Hauptkriterium.
Das plattformübergreifende Qt überließ also den nativen nachgegeben hat, was wiederum bedeutete, dass wir zwei Codebasen erstellen mussten, also doppelte Arbeit … natürlich, wenn wir Qualität brauchen. Klar, wir brauchen sie: Qualität ist unser zweiter Vorname. Wir lieben Kunden und kümmern uns um sie.
Heutzutage
Heute haben wir ein ansprechendes und stabiles mobiles Softphone, das sich für White Label eignet und unter Ihrem Brand und Logo verkauft werden kann. Die Android-Version ist in Kotlin geschrieben, die von iProne in Swift. Als Wecker, der rechtzeitig weckt und verpasste Anrufe verhindert, verwenden wir einen PUSH-Server.
Meine Damen und Herren, das heißt, wenn Sie ein White Label Mobile Softphone benötigen, wissen Sie, was zu tun ist. (Sagen Sie uns einfach Bescheid und senden Sie eine Nachricht an info@softphone.pro 😉)
Und möge die Macht der Mobilität mit Ihnen sein 📱
DAS KÖNNTE IHNEN AUCH GEFALLEN
Blog Softphone für Android: Schlaf oder Schlafentzug?
Help How to improve SIP call quality
