Skip to main content
Un proveedor es una conexión saliente a quien lleve tu tráfico. Las claves se establecen como outSms.instance.<name>.<key>. Consulta Niveles de propiedades. Cada worker también tiene los ajustes base.

​
Conectando

​
Número de binds

Los recuentos aplican a través de normal, extra.hosts y backup.hosts.
Una sesión puede llevar tráfico hacia afuera si es un transceiver, o un transmitter en una sesión cliente. Un proveedor solo-receiver hace bind con éxito y no envía nada. Por lo que el panel reporta bound_transmittable separado de bound. Si difieren, esa es la razón.

​
Keep-alive y timeouts

​
Clasificación de reintentos

maxRetries acota el total de submit_sm que un mensaje puede costar en este proveedor, a través de reintentos dentro del worker y re-enrutamientos del router. Antes de que eso fuera cierto, un valor de 1 junto a 20 intentos de enrutamiento significaba que un proveedor podía ver aproximadamente 100 PDUs por un mensaje. Fallar hacia un proveedor diferente inicia un presupuesto nuevo.
ESME_RSUBMITFAIL (0x45, decimal 69) se trata como permanente: una ruta rechazada con él falla en la primera respuesta en lugar de tras unas veinte. Los operadores que significan sobrecarga transitoria con él se vuelven a activar por proveedor con status.retry.worker = 20,88,69.

​
Acuses

Apagarlo significa que este proveedor deja de reportar resultados, así que cada mensaje a través de él se resuelve como EXPIRED al vencimiento en lugar de DELIVERED o FAILED. Y tu tasa de entrega para ese proveedor se vuelve sin significado en lugar de cero.

​
TLVs

El mandatory.tlvs.submit del lado del proveedor se comprueba contra lo que realmente va por el cable. Tras default.tlvs.submit, y tras que registered.tlvs.submit haya filtrado. Un mensaje al que le falte uno se rechaza con un acuse FAILED, un reembolso y una fila cdr_rejected. No se re-enruta.Requerir un tag que no esté también en registered.tlvs.submit nunca puede satisfacerse, y se advierte al cargar.

​
Mensajes entrantes

mo.route está apagado por defecto porque una pasarela cuya última regla de enrutamiento es un catch-all de lo contrario enviaría sus propios mensajes entrantes directamente de vuelta a un proveedor.Es independiente de forward.mo.url: con ambos establecidos, cada MO se reenvía y se enruta.
Consulta Webhooks para los ajustes de salida que gobiernan el reenvío.