Skip to main content
Este es el lado del operador. Si eres un cliente cambiando tu integración, lee Migrar desde Jasmin en su lugar.

​
Desde Jasmin

La API es lo suficientemente parecida como para que la mayoría de los clientes cambien una línea. Tu trabajo es mayormente configuración y una conciliación. Los cambios visibles al cliente están en su página. Lo que te importa a ti:
Los mensajes ahora se facturan al accountId de la credencial, no a su nombre de login.Antes HTTP facturaba al nombre de usuario mientras SMPP facturaba al accountId, así que un cliente aparecía como dos identidades según cómo se conectara. accountId es tanto el alcance de rating como la clave de crédito prepago, así que los dos tenían que conciliarse antes de que el crédito pudiera funcionar sobre HTTP en absoluto.
Comprueba tu tabla de tarifas antes de cambiar. Si rates.conf tiene un [scope] nombrado por un nombre de usuario HTTP, renómbralo al accountId de esa credencial. De otro modo esos mensajes dejan de coincidir y se vuelven sin tarificar, lo que significa enviados y cobrados nada en lugar de rechazados.

​
Desde Kannel

GET /sendsms se ha eliminado. No hay capa de compatibilidad.
La escala coding cambió, y falla en silencio. Ahora es el campo data_coding de SMPP.Un cliente que envía coding=2 para UCS-2 ahora obtiene un alfabeto octeto sin especificar. Nada da error. El mensaje sale codificado incorrectamente. UCS-2 es 8.Barre las integraciones de tus clientes en busca de coding=2 antes del cambio, porque ninguno de los dos lados lo notará hasta que un destinatario reporte mojibake.
Los recibos de entrega también cambiaron. FireFlo hace POST de un body JSON por defecto, así que un handler DLR de Kannel que espera %d/%s sustituidos en un GET deja de funcionar. Establece smsg.dlr.forward.format = kannel para mantener el comportamiento anterior mientras los clientes migran.

​
El cambio de facturación que altera las facturas

La facturación es una unidad por request REST, sin importar cuántos segmentos ocupe el body.
Eso es más barato que el mismo mensaje sobre SMPP, donde cada PDU entrante se factura. Un cliente que mueva de SMPP a REST obtiene una factura más baja por tráfico idéntico, y uno que mueva al revés obtiene una más alta.Establece smsg.restapi.billing.units=segment para tarificarlos igual. Decide esto antes del cambio. Cambiarlo después parece una subida de precio.

​
Un orden de cambio que funciona

1

Concilia los alcances de tarifa a accountId

Antes de que nada se mueva. Un alcance sin coincidir significa tráfico sin tarificar, que es silencioso.
2

Decide la unidad de facturación REST

Request o segmento. Esta es una decisión de precios, no una técnica.
3

Establece el formato de recibo que los clientes esperan

kannel si tienen handlers de Kannel, para que su lado siga funcionando mientras migran.
4

Corre whitelisting solo-informativo por un periodo

whitelist_would_reject te dice lo que la aplicación rechazaría antes de rechazar nada.
5

Mueve primero una pequeña parte del tráfico

Compara tasas de entrega sabiendo que FireFlo reporta el peor segmento de un mensaje largo, así que sus cifras son legítimamente más bajas que un gateway que reporta el primero.

​
Relacionado

Avisos a clientes

Qué contar a los clientes, y cómo encontrar a quién afecta.

El lado del cliente

Lo que su integración tiene que cambiar.