Softphone móvil apto para White Label: cómo lo hicimos
Recientemente participamos en una gran conferencia de telecomunicaciones sobre Asterisk y VoIP y allí anunciamos una aplicación de softphone para Android muy esperada, así como una aplicación de softphone para iOS, no menos esperada también :)
Y esto es lo que hemos dicho.
Quién necesita un softphone móvil
Windows y macOS forman un ecosistema de oficina: estos sistemas operativos son para secretarias, abogados, contables, agentes de centros de contacto, supervisores y sus superiores. Por eso, en nuestra línea de productos hay soluciones tanto para Win como para macOS.
Mientras tanto, muchas empresas tienen empleados que viajan con teléfonos inteligentes: vendedores, ingenieros, conductores, transportistas, etc. ¿Interactúan con los clientes, los llaman por teléfono? Por supuesto, eso se sobreentiende. ¿Necesitan los empleadores la oportunidad de conectar un teléfono inteligente de la empresa con un PBX? Sin duda.
Por eso, a menudo nos preguntan por un softphone móvil: estas preguntas provienen tanto de empresas con “viajeros” como de proveedores de telecomunicaciones. Está claro por qué los segundos también prestan atención: quieren hacer negocio con los primeros ofreciendo no solo soluciones de escritorio, sino también versiones para Android e iOS… idealmente con sus propios nombres y logotipos.
Según nuestros chicos, los trabajadores que no se desprenden de sus smartphones parecen tener esa apariencia. De hecho, si el smartphone es el único canal y las llamadas son muchas y necesitan ser respondidas… bueno, ya saben :)
Cuando se alcanzó una masa crítica de preguntas, pensamos: ¿por qué no? Y decidimos: lo haremos. ¡Haremos un softphone móvil apto para White Label!
Principales cuestiones a resolver
Las cuestiones clave fueron las siguientes: qué es mejor para el backend; qué lenguajes y frameworks elegir; si el enfoque multiplataforma tiene derecho a existir. Y por último, pero no por ello menos importante, ¿qué pasa con el modo de suspensión profunda de la aplicación? Es muy molesto cuando una aplicación no puede despertarse del modo de suspensión; además, esto está plagado de llamadas perdidas y clientes perdidos. (De cara al futuro, también lo hemos solucionado con éxito, pero ese es un tema para otra publicación).
Pila de tecnología: marco, lenguaje y experiencia de otros
Al ordenar las tecnologías, descubrimos algo interesante sobre Acrobits, Zoiper (también tienen aplicaciones móviles), WhatsApp y Telegram, a los que también se puede hacer referencia como softphones (aunque con cierta exageración), ya que existe tráfico RTP.
Por ejemplo, descubrimos que para Windows todo está escrito en Java (lenguaje) y Kotlin (marco); para macOS, Swift y Objective-C respectivamente.
En cuanto al backend, cada uno tiene su propia manera: WebRTC, PJSIP o incluso algo escrito por ellos mismos. ¿Qué nos dio? Solo una premonición de que nuestro camino probablemente no será pan comido :)
Elegimos entre multiplataforma y nativo
Planteamos la pregunta: ¿qué pasaría si hubiera una base de código única para iOS y Android? ¿Es mejor? (Supusimos que sí debido a la reducción a la mitad del trabajo y la cantidad de código). ¿Es más fácil?
Luego probamos muchas combinaciones diferentes: WebRTC y PJSIP actuaron como base para la transferencia de datos, y ya mencionamos Swift y Kotlin como lenguajes nativos. También probamos tres frameworks multiplataforma: Qt, React y Flutter. Lo que finalmente obtuvimos tenía pros y contras. En ningún caso hubo una victoria impecable, pero una pareja resultó ser un claro perdedor: la combinación Flutter + PJSIP no funcionó en absoluto.
La descendencia de Flutter y WebRTC resultó ser más viable, pero eso es todo. Investigamos más a fondo (ver si tenemos suerte), pero pronto nos dimos por vencidos: un día nos topamos con un repositorio donde había un intento de solución. La comunidad intentó resolver un problema similar al nuestro... y el código fuente ya tenía 8 000 líneas en las que parecía ser solo el comienzo.
En ese momento nos quedamos pensativos y empezamos a sentir dudas.
Así que detuvimos el experimento. Esto convirtió a Flutter en el primero en ser excluido del proyecto.
Luego trabajamos con otro conjunto de tecnologías: PJSIP, WebRTC y React, un marco multiplataforma.
En ambos pares, algo funcionó (eso ya es algo, los pros), pero parecía que había un tráiler de una película aburrida: ya se había mostrado todo lo interesante, pero quedaba basura. No podíamos quitarnos de encima la sensación de que seguramente surgirían varios inconvenientes (los pros y los contras son como yin y yang). Digamos que fue una intuición. Se tomó una decisión voluntaria de excluir a React de la consideración.
Así, la lista se redujo a un candidato de un partido multiplataforma (Qt), uno de Android (Kotlin) y otro de Apple (Swift). Se enfrentarían en la batalla final.
Сoncurso de belleza y desfile en bikinis
Decidimos que la primera (y probablemente la única) batalla será con el hombre verde. Las reglas de la competencia son: armamos un softphone móvil en Qt y Kotlin; en ambos casos, el mismo esfuerzo a invertir; luego comparamos los resultados. Si Qt pierde, Swift también se convierte automáticamente en ganador. Si Qt gana, debe haber una batalla más: Qt vs Swift. En otras palabras, la esencia multiplataforma debe demostrar la superioridad en todo momento, de lo contrario, pierde el sentido de su uso.
Hablando de eso, mira y adivina quién es quién.
Qt está a la izquierda, Kotlin está a la derecha.
A primera vista parecen similares, pero si nos fijamos bien, descubrimos sombras extrañas debajo de los botones, desigual espacio izquierdo y espacio derecho y otros detalles que aparecen durante el uso. Son pequeñas cosas, y el diablo está ahí.
Por supuesto, la interfaz de la izquierda se puede mejorar. Sí, se podrían arreglar los detalles técnicos, pero implica trabajo adicional, mientras que el criterio clave es la igualdad de recursos invertidos (tiempo y esfuerzo).
Así que la multiplataforma Qt cedió poderes a los lenguajes nativos, y esto a su vez significó que debíamos crear dos bases de código, es decir, trabajo doble… por supuesto, si necesitamos calidad. Claro que la necesitamos: la calidad es nuestro segundo nombre. Amamos a nuestros clientes y los cuidamos.
Hoy en día
Hoy tenemos un softphone móvil guapo y estable, apto para White Label y listo para venderse con su nombre y logotipo. La versión para Android está escrita en Kotlin y la de iProne en Swift. Como despertador que permite despertar a tiempo y evita llamadas perdidas, utiliza un servidor PUSH.
Damas y caballeros, eso significa que si necesitan un White Label softphone móvil, ya saben qué hacer. (Sólo háganoslo saber y envíenos un mensaje a info@softphone.pro 😉)
Y que la fuerza de la movilidad te acompañe 📱
TAMBIÉN TE PUEDE INTERESAR
Blog Softphones de pago vs. dialers gratuitos
Blog Softphone en realidad: lo que dice la gente
Blog VoIP vs SIP, dialers VS softphones: diferencias y similitudes
Help How to improve SIP call quality
