app_header es un sender ID aprobado, emparejado sin distinción de mayúsculas, con alcance a una
cuenta y un producto. En varios mercados un sender ID comercial es un registro y no una
cadena que un cliente escoge. El operador ha aprobado ACMEIN para una empresa y espera que el tráfico
que lo lleva sea suyo.
Aprobado no es lo mismo que entregable
Una aprobación hace dos trabajos, y fallan de forma independiente. Decide si el mensaje coincide en este gateway, y lleva los TLVs que se estampan en el mensaje al salir. Bajo DLT, el identificador de entidad que exige el operador. El informe de cobertura de TLV del panel existe precisamente para esto. Por fila aprobada, nombra qué tags obligatorios nada suministrará, y por qué:Es un informe, nunca una barrera. Un login no está atado a un listener y las reglas de ruta eligen el
proveedor, así que nada aquí puede estar seguro de que un mensaje dado llegue a un listener dado. Rechazar un guardado por ello
bloquearía configuraciones que funcionan. Y cada frase que produce dice que un cliente que envíe el
propio tag hace la pregunta irrelevante.
vendorDrops merece leerse dos veces: un tag que el proveedor no ha registrado se descarta en la
salida, después de que el registro de llamada ya lo haya anotado como presente. El registro muestra que se envió y
el cable no lo lleva. Consulta TLVs en una conexión.
Alcance: cuenta, producto y opcionalmente un login
Una fila es por(cuenta, producto), con un producto vacío que significa cada producto. Una lista específica de
producto se combina sobre la lista de cualquier-producto de la cuenta. Las dos se unen, no se elige entre ellas.
system_id afina más. NULL significa cada login de la cuenta, que es lo que significaba cada fila
antes de que existiera la columna, así que un despliegue sin tocar coincide exactamente como lo hacía y no se
necesitó ningún backfill. Dos logins de la misma cuenta pueden mantener el mismo sender ID.
Quién propone y quién aprueba
1
El cliente pide
Desde el portal. Todo lo que un cliente escribe llega como
PENDING, con su propia nota adjunta. Bajo
DLT, su referencia de registro. El gateway sirve una fila solo cuando está enabled y
APPROVED, así que una solicitud se almacena, es visible para ambas partes, y es inerte.2
Un operador decide
Aprobar o rechazar, en la página de la cuenta o en la lista entre cuentas. Un rechazo mantiene la fila y
lleva una razón que se muestra al cliente. Por eso no hay rechazo en bloque, solo aprobación en bloque.
3
Entra en servicio en el siguiente sondeo
Sin reconectar. Ver abajo.
status y enabled son columnas separadas que hacen trabajos separados. Aprobar escribe status y registra
al revisor. Desmarcar escribe enabled = false y deja status en paz: retirar algo no es
des-aprobarlo, y una fila retirada vuelta al servicio no debería necesitar aprobarse de nuevo.
Un cliente que lee la API ve la retirada, desde el gateway 0.9.8. Como las dos columnas están
separadas, la API de registros solía reportar una fila retirada como
APPROVED: lee la decisión de
aprobación, y esa no había cambiado. Un cliente que la consultaba para decidir desde qué enviar
recibía que el remitente estaba aprobado mientras el gateway rechazaba todos sus mensajes.Ahora reporta un cuarto estado, WITHDRAWN, así que la API y la pantalla del portal del cliente
coinciden entre sí y con lo que el gateway hace realmente. Nada de su lado cambió; desmarcar sigue
escribiendo una sola columna.Los TLVs que un cliente puede proponer pero no establecer
Ambas tablas de registro llevan dos columnas TLV.
Bajo
replace la estampa sobrescribe lo que el cliente afirmara, y esa sobrescritura es la
aprobación. Un cliente que pudiera escribir la columna servida podría afirmar el registro de otro
mientras envía la redacción aprobada, y el registro de llamada informaría entonces el valor que él eligió como
aprobado. Ese comportamiento está fijado por un test, así que no derivará.
La recompensa es para el cliente: una propuesta no cambia nada de lo que se sirve, así que a diferencia de una edición del
sender ID no suspende la fila. Un registro aprobado sigue funcionando mientras un operador
considera la propuesta. Aceptar mueve el valor y estampa al operador como su dueño;
descartar borra la solicitud y deja tlvs exactamente como estaba. Ninguna toca status.
Lo que el panel se niega a guardar
64 es generoso más que correcto. SMPP limita
source_addr a 21 octetos, así que nada más allá puede
entregarse sobre un bind. Pero rechazar en 21 aquí también rechazaría ediciones a filas que ya existen,
y “no puedes entregar esto” es una decisión distinta de “no puedes guardar esto”.Aprobar no requiere reconectar
El whitelist se relee en el sondeo de configuración y cada snapshot lleva una generación. Una sesión SMPP conectada durante semanas recoge un sender ID recién aprobado sin reconectar. Lo cual importa, porque el cliente cuyo tráfico se está rechazando suele estar al teléfono mientras alguien lo aprueba.Plantillas de contenido
La otra mitad de la misma aprobación, y la gramática de placeholders.
Desplegar el whitelisting
Informe antes de aplicar, y los diagnósticos en
/ops/health.