Configuración y protocolo del conector SMS sms-connector-protocol

Información general overview

Los SMS pueden limitarse a enviar mensajes de texto cortos sin formato, pero su sencillez lo convierte en un valioso canal de comunicación.

Existen dos maneras principales de enviar un SMS:

Este documento le guiará a través de la conexión configurada entre Adobe Campaign y un proveedor SMPP.

Los proveedores de SMPP a veces pueden desviarse de la especificación oficial, pero el conector de SMS en Adobe Campaign ofrece muchas opciones para adaptar su comportamiento para que sea compatible con la mayoría de los proveedores.

Tipos de SMS sms-types

Al enviar SMS masivos a través de un proveedor de SMS, se encontrará con tres tipos diferentes de SMS:

Debe distinguir entre reconocimientos (RESP PDU, parte del protocolo SMPP) y SR: SR es un tipo de SMS que se envía a través de la red de extremo a extremo, mientras que un reconocimiento es solo una confirmación de que una transferencia se ha realizado con éxito.

Tanto los reconocimientos como SR pueden desencadenar errores. Si se distingue entre los dos, se ayudará a solucionar los problemas.

Información transmitida por un SMS information-sms

Un SMS lleva más información que texto. Aquí hay una lista de lo que puede encontrar en un SMS:

Protocolo SMPP smpp-protocol

Adobe Campaign Classic admite la versión 3.4 del protocolo SMPP. Este es un protocolo muy extendido que permite enviar SMS a un proveedor (SMSC) y recibir SMS, así como recibos. Para obtener más información, consulte la documentación de SMPP.

El equipo de red en el lado del proveedor de servicios SMS suele conocerse como SMSC.

Conexiones SMPP smpp-connections

Adobe Campaign se conecta al equipo de red del proveedor de servicios SMS a través de TCP. El protocolo SMPP establece conexiones TCP permanentes desde Adobe Campaign al proveedor. Adobe Campaign siempre inicia las conexiones TCP, incluso para recibir mensajes.
SMPP abre 1 o 2 conexiones TCP, dependiendo de su modo. Adobe Campaign siempre inicia todas las conexiones.

El protocolo SMPP puede funcionar en dos modos:

PDU SMPP smpp-pdu

Las unidades de transmisión SMPP ("paquetes") se denominan PDU. Una PDU contiene un comando, un estado, un número de secuencia y datos.

Cada PDU debe ser reconocida por una SMPP RESP PDU (respuesta sincrónica). Las solicitudes pueden canalizarse: el remitente puede enviar muchos comandos sin esperar RESP, el número de solicitudes que se pueden canalizar en cualquier momento se denomina ventana. RESP PDU puede llegar en cualquier orden, sin relación con el orden de su PDU iniciador correspondiente.

En el modo separado Transmisor+receptor, la conexión utilizada depende del tipo de mensaje transmitido. La conexión del transmisor se utiliza para MT y la conexión del receptor para MO y SR. Las solicitudes y respuestas para cada tipo de mensaje se envían a través de la misma conexión TCP.

Por ejemplo, al enviar un mensaje MT, se utiliza la conexión del transmisor y el RESP que reconoce el mensaje MT también se envía a través del canal del transmisor. Cuando recibe un MO (o un SR), la conexión del receptor se utiliza para recibir el MO y para enviar el RESP que reconoce el MO.

En Adobe Campaign Classic, para vincular SR con su MT correspondiente, SMSC devuelve un ID con los pasos SUBMIT_SM_RESP y DELIVER_SM. El identificador se almacena en el campo providerId de la tabla nms::providerMsgId y está vinculado a broadLogId y deliveryId. Esta operación de coincidencia se realiza mediante el proceso SMS al escribir en la base de datos.

Un SUBMIT_SM_RESP PDU exitoso activa el estado de mensaje "enviado" en el registro de envío, mientras que un DELIVER_SM (SR) PDU exitoso activa el estado de mensaje "recibido".

Aspectos de seguridad security-aspects

El protocolo en sí no está cifrado. La mayoría de los proveedores implementan una variante de IP en la lista de permitidos, por lo que las direcciones IP del servidor Adobe Campaign deben declararse al proveedor.

Adobe Campaign permite pasar un inicio de sesión y una contraseña durante la fase de enlace. También admite SMPP a través de TLS. Cabe señalar que los certificados son necesarios para garantizar la seguridad adecuada. Aunque el conector SMPP permite omitir las comprobaciones de certificados, solo debe utilizarse para pruebas, ya que TLS sin certificados proporciona un nivel de seguridad significativamente inferior.

El conector utiliza los certificados predeterminados proporcionados por la biblioteca openssl del sistema. Generalmente lo proporciona el directorio /etc/ssl/certs en Debian. Este directorio lo proporciona el paquete “ca-certificates” de manera predeterminada, pero se puede personalizar.

Información en cada tipo de PDU information-pdu

Cada tipo de PDU tiene campos distintos que llevan diferentes partes de información. Estas PDU se detallan en la especificación SMPP 3.4.

Cada sección a continuación describe la PDU y su respuesta sincrónica (*_RESP PDU). Todas las PDU deben ser reconocidas por una RESP correspondiente, es una parte obligatoria de la especificación.

Las PDU pueden tener campos opcionales. Aquí solo se describen los campos más comunes. Consulte la especificación SMPP 3.4 para obtener más información.

BIND_TRANSMITTER / BIND_RECEIVER / BIND_TRANSCEIVER

Esta PDU se utiliza para iniciar una conexión al SMSC. Los modos Transmisor, Receptor y Transceptor solo cambian el tipo de SMS que se permite transferir a través de esta conexión, específicamente:

Campos notables en una BIND_* PDU:

BIND_*_RESP no tiene un campo específico, confirma si la conexión se realizó correctamente o no.

UNBIND unbind

El sistema debe enviar esta PDU antes de desconectarse. Debe esperar la PDU correspondiente UNBIND_RESP antes de cerrar la conexión.

La conformidad con SMSC no debe cerrar la conexión, la conexión TCP está controlada por el conector Adobe Campaign.

SUBMIT_SM submit-sm

Esta PDU envía un MT al SMSC. Su PDU de respuesta proporciona el ID del MT.

Campos notables en una PDU SUBMIT_SM:

Adobe Campaign admite estos campos opcionales:

SUBMIT_SM_RESP submit-sm-resp

Esta PDU contendrá el ID del MT. Esto resulta útil para relacionarlo con SR entrante.

Algunos proveedores envían SUBMIT_SM_RESP después de enviar el SR. Para tener en cuenta ese comportamiento, Adobe Campaign espera 30 segundos antes de responder ID de mensaje no válido a un SR con un ID desconocido.

DELIVER_SM delivery-sm

El SMSC envía esta PDU a Adobe Campaign. Contiene un MO o un SR.

La mayoría de los campos tienen el mismo significado que su contraparte SUBMIT_SM. Esta es la lista de campos útiles:

Adobe Campaign puede leer el ID del mensaje en el campo opcional receipted_message_id con alguna configuración.

DELIVER_SM_RESP deliver-sm-resp

Adobe Campaign envía esta PDU para reconocer SR y MO.

Adobe Campaign Classic reconoce SR y MO una vez insertados en la base de datos. Algunos errores de procesamiento pueden ocurrir incluso si se ha enviado una PDU DELIVER_SM_RESP correcta. Esta limitación se debe a la arquitectura de software de Adobe Campaign Classic.

ENQUIRE_LINK enquire-links

Esta PDU solo se utiliza para comprobar que la conexión está activa. Su frecuencia debe establecerse de acuerdo con las necesidades del proveedor.

Los 60 segundos predeterminados deben coincidir con la mayoría de las configuraciones establecidas en la cuenta externa.

ENQUIRE_LINK_RESP enquire-links-resp

Esta PDU reconoce que la conexión está activa.

SMS de varias partes (SMS largos) multipart

Los SMS de varias partes, o SMS largos, son SMS que se envían en varias partes. Debido a limitaciones técnicas en el protocolo de red móvil, un SMS no puede superar los 140 bytes o deberá dividirse. Consulte la sección Codificación de texto SMS para obtener más información sobre el número de caracteres que pueden caber en un SMS.

Cada parte de un mensaje largo es un SMS individual. Estas partes viajan independientemente en la red y son montadas por el teléfono móvil receptor. Para gestionar reintentos y problemas de conectividad, Adobe Campaign envía estas piezas en orden inverso y solicita un SR únicamente en la primera parte del último mensaje que se envía. Dado que el teléfono móvil solo muestra un mensaje cuando se recibe la primera parte, los reintentos de partes adicionales no producirán duplicados en el teléfono móvil.

Se puede establecer el número máximo de SMS por mensaje por envío mediante la configuración Número máximo de SMS por mensaje en la Plantilla de envíos. Los mensajes que superen este límite fallarán al enviar un mensaje de error con el motivo SMS demasiado largo.

Hay dos maneras de enviar SMS largos:

Consulte la descripción de los campos esm_class, short_message y message_payload de la SUBMIT_SM PDU para obtener más detalles sobre el protocolo y los formatos.

Límite de rendimiento y basado en ventanas throughput-capping

La mayoría de los proveedores requieren un límite de rendimiento para cada conexión SMPP. Esto se puede lograr estableciendo un número de SMS en la cuenta externa. Tenga en cuenta que la limitación del rendimiento se produce por conexión, el rendimiento efectivo total es el límite por conexión multiplicado por el número total de conexiones. Esto se detalla en la sección Conexiones simultáneas.

Para alcanzar el máximo rendimiento posible, tendrá que ajustar la ventana de envío máxima. La ventana de envío es el número de SUBMIT_SM PDU que se puede enviar sin esperar a SUBMIT_SM_RESP. Consulte la sección Configuración de la ventana de envío para obtener más detalles.

SR y administración de errores (“Apéndice B”) sr-error-management

El protocolo SMPP define errores sincrónicos estándar en RESP PDU, pero no define códigos de error para SR. Cada proveedor utiliza sus propios códigos de error con su significado.

Se realiza una recomendación en la sección del apéndice B de la especificación del protocolo SMPP (página 167), pero esto no incluye los códigos de error reales ni su significado.

Para adaptarse a la administración de errores, se ha aprovechado el sistema de mensajes de banda ancha de Adobe Campaign para aprovisionar correctamente los errores y su gravedad (difícil, suave, etc.).

Como se mencionó anteriormente, hay dos tipos diferentes de errores:

Cuando se recibe un SR, el estado y el error se pueden encontrar en su campo short_message (por ejemplo, para implementaciones conformes con el Apéndice B). El campo short_message de la PDU se denomina generalmente campo de texto porque contiene texto en MT. En el caso de SR, contiene información técnica más un subcampo denominado Texto. Estos 2 campos son diferentes y short_message en realidad contiene el campo Texto y otra información.

Los conectores de Adobe Campaign Classic (excepto Extended SMPP) utilizan un comportamiento codificado que depende del proveedor seleccionado. El SMPP genérico solo distingue entre éxito y error, sin ningún detalle. El registro de envíos puede contener información que no está garantizada.

Formato de campo de texto SR sr-text-field-format

La especificación recomienda utilizar este formato para el campo de texto SR. Es una lista de subcampos, separados por espacios con dos puntos para separar el nombre del campo y su valor. Los nombres de campo no distinguen entre mayúsculas y minúsculas.

Ejemplo de un campo de texto SR que coincide con la recomendación del Apéndice B:

id:1234567890 sub:001 dlvrd:001 submit date:1608011415 done date:1608011417 stat:DELIVRD err:000 Text:Hello Adobe world

El campo id es el ID recibido en el SUBMIT_SM_RESP PDU, el reconocimiento del MT.

sub y dlvrd deberían contar la cantidad de piezas enviadas y mensajes enviados, pero Adobe Campaign no lo utiliza, ya que el sistema de banda ancha proporciona una información mejor y más integrada.

Los campos submit date y done date son marcas de hora indicativas de cuándo se envió el mensaje MT y cuándo el dispositivo móvil envió el mensaje SR. Se esperan algunos problemas con los husos horarios o incluso marcas de hora incorrectas proporcionadas por los móviles con una fecha establecida incorrectamente.

El campo stat es importante porque indica el estado del mensaje. El único estado importante es DELIVRD, UNDELIV y REJECTD. El estado DELIVRD indica un resultado exitoso, los otros dos indican un error. Otros valores son posibles, pero suelen ser notificaciones intermedias, por ejemplo, el MT llegó al operador de telefonía móvil, pero no el teléfono móvil. Adobe Campaign ignora estas notificaciones intermedias.

El campo err contiene el código de error específico del proveedor. El proveedor debe proporcionar una tabla de posibles códigos de error junto con su significado para poder interpretar este valor.

Finalmente, el campo de texto en general contiene el principio del texto de MT. Adobe Campaign lo ignora y algunos proveedores no lo transmiten para evitar fugas de PII y consumo de ancho de banda de la red. Se puede utilizar durante la resolución de problemas para localizar el SR que coincide con un MT de prueba más fácilmente leyendo este campo.

Ejemplo de procesamiento SR en SMPP genérico de Adobe Campaign Classic Extended sr-processing

Este ejemplo muestra el caso de una implementación que sigue a la recomendación del Apéndice B, los valores predeterminados en la cuenta externa y un mensaje SMS MT correcto.

id:1234567890 sub:001 dlvrd:001 submit date:1608011415 done date:1608011417 stat:DELIVRD err:000 Text:Hello Adobe world

En primer lugar, la regex id extraction se aplica para extraer el ID y reconciliarlo con el MT correspondiente.

A continuación, la regex status extraction y la regex error code extraction se aplican para extraer estos campos y se anexan a la cadena.

El mensaje del "broadlog" se construye con esta información y la cadena original sin modificar se anexa como referencia:

SR ExampleProvider DELIVRD 000|MESSAGE=id:1234567890 sub:001 dlvrd:001 submit date:1608011415 done date:1608011417 stat:DELIVRD err:000 Text:Hello Adobe world

A continuación, el mensaje se normaliza, eliminando la parte MENSAJE para poder hacer coincidir varios mensajes con los mismos códigos de estado y error.

SR ExampleProvider DELIVRD 000|#MESSAGE#

Si el mensaje no se ha aprovisionado ya en la tabla de mensajes de "broadlog", se creará una nueva entrada, con todo el mensaje como firstText y el mensaje normalizado. A continuación, el conector utiliza el éxito y la regex error para determinar si ha sido un éxito o un error:

De forma predeterminada, todos los errores se aprovisionan como errores leves. Esto significa que los errores graves deben aprovisionarse a mano.

Codificación de texto SMS sms-text-encoding

Siempre debe ponerse en contacto con el proveedor SMSC en caso de problemas de codificación. Solo los proveedores de SMSC tienen conocimiento de la codificación que admiten y de las reglas especiales que pueden aplicarse debido a las limitaciones en su plataforma técnica.

Los mensajes SMS utilizan una codificación especial de 7 bits, a menudo denominada codificación GSM7.

En el protocolo SMPP, el texto de GSM7 se expandirá a 8 bits por carácter para facilitar la resolución de problemas. El SMSC lo empaquetará en 7 bits por carácter antes de enviarlo al dispositivo móvil. Esto significa que el campo short_message del SMS puede tener hasta 160 bytes de longitud en el marco SMPP, mientras que está limitado a 140 bytes cuando se envía en la red móvil.

En caso de problemas de codificación, hay que comprobar algunos aspectos importantes:

El campo data_coding indica qué codificación se utiliza. Un problema importante es que el valor 0 significa codificación SMSC predeterminada en la especificación, que suele referirse a GSM7. Consulte con el socio de SMSC la codificación asociada con data_coding = 0 que solo admite Adobe Campaign. Otros valores data_coding tienden a seguir la especificación, pero la única manera de estar seguros es consultar con el proveedor SMSC.

El tamaño máximo de un mensaje depende de su codificación. Esta tabla resume toda la información relevante:

Parámetros de cuenta externa de SMPP SMPP-parameters-external

Cada implementación del protocolo SMPP tiene muchas variaciones. Para mejorar la compatibilidad y la adaptabilidad, hay muchos ajustes disponibles para cambiar el comportamiento del conector SMPP. Esta sección describe todos los parámetros y sus efectos en el conector.

Parámetros generales y enrutamiento general-parameters-routing

Limitar instancias de MTA para esta cuenta

Es posible establecer un límite en el número de instancias de MTA permitidas para conectarse al proveedor de SMPP. Cuando se selecciona, puede especificar cuántos MTA se pueden usar como máximo.

Esta opción permite un control más preciso del número de conexiones; consulte Conexiones simultáneas.

Si establece un valor mayor que el número de MTA en ejecución, todos los MTA se ejecutarán normalmente: esta opción es solo un límite y no puede generar MTA adicionales.

Si necesita controlar con precisión el número de conexiones, por ejemplo, el requisito del proveedor, se recomienda establecer siempre esta opción aunque la implementación actual tenga el número correcto de MTA en ejecución. Si después se agregan MTA adicionales, se respetará el límite de conexión.

Configuración de conexión connection-settings

Nombre de implementación de SMSC smsc-implementation-name

Define el nombre de la implementación de SMSC. Debe configurarse con el nombre de su proveedor. Póngase en contacto con el administrador o con el equipo de entregabilidad para saber qué añadir en este campo. La función de este campo se describe en la sección gestión de errores SR.

Servidor server

El nombre DNS o la dirección IP del servidor al que se va a conectar.

Puerto port

El puerto TCP al que se va a conectar.

Cuenta account

Inicio de sesión de la conexión. Pasado en el campo system_id de la PDU BIND.

Contraseña password

Contraseña de la conexión SMPP. Pasado en el campo de contraseña de la PDU BIND.

Tipo de sistema system-type

Valor pasado en el campo system_id de la PDU BIND. Algunos proveedores necesitan un valor específico aquí.

Número de conexiones secundarias MTA number-mta-child

En Adobe Campaign Classic, define el número de conexiones por elemento secundario MTA.

El conector SMPP extendido de Adobe Campaign Classic puede controlar el número de conexiones por elemento secundario de MTA. Para controlar el límite global de conexiones, tendrá que limitar el número de procesos secundarios de MTA, lo que a menudo significa tener una plataforma intermediaria dedicada para SMS.

Para Adobe Campaign Classic, puede haber un número diferente de conexiones de receptor y transmisor:

Como se ha sugerido anteriormente, el proceso SMS de Adobe Campaign Classic abre más conexiones de transmisores si la respuesta automática está activada. Estas conexiones adicionales se utilizan para enviar las respuestas automáticas.

Si configura respuestas automáticas, el proceso SMS abrirá pares de transmisores/receptores, aumentando el número de conexiones de transmisores. Si no configuró ninguna respuesta automática, solo se abrirán conexiones de recepción.

Habilitar TLS en SMPP enable-TLS

Utilice TLS para conectarse al proveedor. La conexión se cifrará. La conexión TLS es administrada por la biblioteca OpenSSL. Todo lo aplicable a OpenSSL será verdadero para esta conexión.

Habilitar los seguimientos SMPP detallados en el archivo de registro enable-verbose-log-file

Esta configuración elimina todo el tráfico de SMPP en los archivos de registro. A menudo es necesario ajustar los parámetros durante la configuración inicial. Esto debe habilitarse al solucionar problemas del conector y compararse con el tráfico que ve el proveedor.

En Adobe Campaign Classic, la salida de registro se encuentra en el registro MTA para el tráfico relacionado con MT y en el registro SMS para el tráfico relacionado con MO y SR.

Configuración de conexión del receptor receiver-connection

Esta sección solo está visible en el modo separado transmisor + receptor.

Usar parámetros diferentes para el receptor receiver-parameters

Cuando la casilla está desactivada, se utiliza la misma configuración para el transmisor y el receptor.

Cuando la casilla está activada, la configuración de la sección Configuración de conexión se aplicará al transmisor y la configuración en los ajustes de conexión del receptor se aplicará al receptor.

Servidor receptor, puerto, cuenta, contraseña, tipo de sistema

Esta configuración se aplica al receptor cuando se encuentra en modo transmisor+receptor. Funcionan como la parte del transmisor, ver arriba para más detalles.

Configuración de canal SMPP smpp-channel-settings

Permitir transliteración de caracteres allow-character-transliteration

La transliteración es el proceso de encontrar caracteres equivalentes a los que faltan. Por ejemplo, el carácter francés "ê" (e con acento circunflejo) no aparece en la codificación GSM, pero se puede reemplazar por "e" sin afectar a la legibilidad.

Cuando esta casilla no está marcada, la codificación de texto fallará si no puede codificar la cadena exactamente como está.

Cuando esta casilla está activada, la codificación de texto intentará convertir la cadena a una versión aproximada en lugar de generar errores. Si algunos caracteres no tienen equivalente en la codificación de destinatario, la codificación de texto fallará.

Consulte la Definición de una asignación específica de la configuración de codificaciones para obtener una explicación más general del proceso de codificación.

Almacenar el MO entrante en la base de datos incoming-mo-storing

Cuando se habilita, el MO entrante se almacena en la tabla inSMS de la base de datos. Esta tabla se puede consultar mediante la actividad de consulta de cualquier flujo de trabajo.

Adobe Campaign Classic siempre almacena todos los MO en la base de datos de inSMS, por lo que esta opción no está disponible.

Habilitar actualizaciones de KPI en tiempo real durante el procesamiento de SR real-time-kpi

Cuando se habilita, los KPI se actualizan en tiempo real en la página de envío principal cuando se recibe un SR de error.

La desventaja puede ser un bajo rendimiento debido al contenido de la base de datos que genera. Si se deshabilita, las estadísticas se actualizan mediante el flujo de trabajo syncfromexec, que se ejecuta cada 20 minutos.

Adobe Campaign Classic tiene un mecanismo completamente diferente para los KPI, por lo que esta opción no está disponible.

Número de origen source-number

Define la dirección de origen predeterminada para los mensajes. Esta configuración solo se aplica si el número de origen se ha dejado vacío en el envío.

De forma predeterminada, el campo de número de origen no se pasa, por lo que el proveedor lo sustituirá por el código corto.

Esto habilita la función de anulación de dirección de remitente/oADC.

Código corto short-code

Indica el código corto principal de la cuenta. Si se utilizan varios códigos cortos para esta cuenta o si se desconoce el código corto, deje este campo vacío.

Especificar código corto resulta útil para dos funciones:

TON/NPI de origen, TON de destino/NPI ton-npi

El TON (Tipo de número) y el NPI (Indicador del plan de numeración) se describen en la sección 5.2.5 de la especificación SMPP 3.4 (página 117). Estos valores deben configurarse según las necesidades del proveedor.

Se transmiten tal como están en los campos source_addr_ton, source_addr_npi, dest_addr_ton y dest_addr_npi de SUBMIT_SM PDU.

Tipo de servicio service-type

Este campo se transmite tal como está en el campo service_type del SUBMIT_SM PDU. Configure esto según las necesidades del proveedor.

Rendimiento y tiempo de espera throughput-timeouts

Esta configuración controla todos los aspectos de tiempo del canal SMPP. Algunos proveedores requieren un control muy preciso de la velocidad de mensajes, la ventana y los tiempos de reintento. Esta configuración debe establecerse en valores que coincidan con la capacidad del proveedor y las condiciones indicadas en su contrato.

Ventana de envío sending-window

La ventana es el número de SUBMIT_SM PDU que se pueden enviar sin esperar una SUBMIT_SM_RESP coincidente.

Ejemplo de una transmisión con una ventana máxima de 4:

La ventana ayuda a aumentar el rendimiento cuando el vínculo de red tiene una latencia alta. El valor de la ventana debe ser al menos el número de SMS/s multiplicado por la latencia del vínculo
en segundos, de modo que el conector nunca está esperando un SUBMIT_SM_RESP antes de enviar el siguiente mensaje.
Si la ventana es demasiado grande, puede enviar más mensajes de duplicado en caso de problemas de conexión. Además, la mayoría de los proveedores tienen un límite muy estricto para la ventana y rechazan los mensajes que sobrepasan el límite.

Calcular la fórmula óptima de la ventana de envío:

Ejemplo: Si tiene 300 SMS/s configurados en el rendimiento máximo de MT y hay una latencia de 100 ms entre SUBMIT_SM y SUBMIT_SM_RESP en promedio, el valor óptimo sería 300×0.1 = 30.

Rendimiento máximo de MT max-mt-throughput

Número máximo de MT por segundo y por conexión. Esta configuración se aplica estrictamente y el MTA nunca insertará mensajes más rápido que este límite. Resulta útil para los proveedores que requieren una limitación precisa.

Para conocer el límite de rendimiento total, multiplique este número por el número total de conexiones, tal como se detalla en la fórmula anterior.

0 significa que no hay límite, el MTA enviará MT lo más rápido posible.

En general, se recomienda mantener esta configuración por debajo de 1000, ya que es imposible garantizar un rendimiento preciso por encima de este número a menos que se haya realizado una evaluación adecuada de la arquitectura final y se haya solicitado específicamente al proveedor de SMPP. Puede ser mejor aumentar el número de conexiones para superar los 1000 MT/s.

Tiempo antes de la reconexión time-reconnection

Cuando se pierde la conexión TCP, el conector esperará este número de segundos antes de intentar realizar una conexión.

Período de caducidad del MT expiration-period

Tiempo de espera entre SUBMIT_SM y su coincidencia SUBMIT_SM_RESP. Si el RESP no se recibe a tiempo, el mensaje se considerará fallido y se aplicará la política de reintentos global del MTA.

Tiempo de espera de vínculo bind-timeout

Tiempo de espera entre el intento de conexión TCP y la respuesta BIND_*_RESP. Cuando se agota el tiempo de espera, la conexión se cierra mediante el conector de Adobe Campaign y esperará tiempo antes de volver a conectarse antes de intentarlo de nuevo.

período enquire_link enquire-link-period

enquire_link es un tipo especial de PDU enviado para mantener la conexión viva. Este período es en segundos. El conector de campaña solo envía enquire_link cuando la conexión está inactiva para conservar el ancho de banda. Si no se recibe ningún RESP después de dos veces este período, la conexión se considerará muerta y se activará un proceso de reconexión.

Detalles de SMSC SMSC-specifics

Estas configuraciones son ajustes avanzados que adaptan el conector de Adobe Campaign a la mayoría de las peculiaridades de implementación de SMPP.

Definir una asignación específica de codificaciones

Consulte la sección Codificación de texto SMS para obtener más información sobre la codificación de texto.

Esta configuración le permite definir una asignación de codificación personalizada, diferente de la especificación. Podrá declarar una lista de codificaciones, junto con su valor data_coding.

El MTA intentará codificar usando la primera codificación de la lista. Si falla, intentará usar la siguiente codificación en la lista, etc. Si no se puede utilizar ninguna codificación para codificar el mensaje, se producirá un error. Una vez encontrada la codificación, el MTA creará el SUBMIT_SM PDU con el texto codificado y el campo establecido data_coding con el valor especificado en la tabla.

El orden de los elementos de la tabla es importante: las codificaciones prueban de arriba abajo. Debe colocar la codificación más barata o recomendada en la parte superior de la lista, seguida de codificaciones más y más caras.

Tenga en cuenta que la UCS-2 nunca fallará, ya que puede codificar todos los caracteres admitidos en Adobe Campaign y que la longitud máxima de un SMS UCS-2 es mucho menor: solo 70 caracteres.

También puede utilizar esta configuración para forzar que una codificación específica se utilice siempre declarando solo 1 línea en la tabla de asignación.

La asignación predeterminada que se utiliza cuando la casilla de verificación no está marcada equivale a la siguiente tabla:

Esto significa que el MTA intentará codificar el mensaje en GSM. Si tiene éxito, lo enviará con data_coding establecido en 0.

Si el mensaje no se puede codificar en GSM, se codificará en UCS-2 y se establecerá data_coding en 8.

Habilitar message_payload enable-message-payload

Cuando no se selecciona, los SMS largos se dividen por el MTA y se envían en múltiples SUBMIT_SM PDUs con UDH. El mensaje será recompuesto por el teléfono móvil según los datos UDH.

Cuando se selecciona, se envían SMS largos en una PDU SUBMIT_SM, colocando el texto en el campo opcional message_payload. Consulte la especificación del SMPP para obtener más información al respecto.

Si esta función está habilitada, Adobe Campaign no podrá contar las partes del SMS de forma individual: todos los mensajes se contarán como enviados en una parte.

Enviar el número de teléfono completo send-full-phone-number

Cuando esta casilla de verificación no está activada, solo se envían dígitos del número de teléfono al proveedor (destination_addr campo del campo SUBMIT_SM). Este es el comportamiento predeterminado, ya que el indicador de número internacional, normalmente un prefijo +, se sustituye por los campos TON y NPI en el SMPP.

Cuando se marca la casilla de verificación, el número de teléfono se envía tal cual, sin preprocesamiento ni espacios potenciales, + prefijo o signos de almohadilla/asterisco.

Esta función también afecta al comportamiento de la función de respuesta automática de la lista de bloqueados: cuando la casilla de verificación no está marcada, se agrega un prefijo + a los números de teléfono insertados en la tabla de cuarentena para compensar la eliminación del prefijo + del número de teléfono por el protocolo SMPP mismo.

Omitir comprobación de certificado TLS skip-tls

Cuando TLS está habilitado, omitir todas las comprobaciones de certificado.

Cuando se selecciona, la conexión ya no es segura, por lo que no debe habilitarse en producción.

Puede resultar útil para depurar o probar.

Puede elegir entre tres valores diferentes para la validación del certificado:

Enlazar TON/NPI bind-ton-npi

TON (tipo de número) y NPI (indicador del plan de numeración) descritos en la sección 5.2.5 de la especificación del SMPP 3.4 (página 117). Estos valores deben ajustarse a lo que el proveedor necesite.

Se transmiten tal cual en los campos addr_ton y addr_npi de la BIND PDU.

Intervalo de direcciones address-range

Se envía tal cual en el campo address_range del BIND PDU. Este valor debe ajustarse a lo que necesite el proveedor.

Cuenta de reconocimiento de ID no válida invalid-id

Limita el número de Mensaje de ID no válido DELIVER_SM_RESP que se puede enviar para un único SR.

Esto solo debe usarse para solucionar problemas como solución alternativa y se establece en 0 en condiciones normales.

Ejemplo de Fox, cuando se establece en 2:

Si este campo se establece en 0, se deshabilita el mecanismo donde ID de mensaje no válido siempre se devuelve, este es un comportamiento normal.

Al establecer este campo en 1, el conector siempre responde "OK" aunque el ID no sea válido. Esto debe establecerse en 1 solamente bajo supervisión, para la resolución de problemas y durante el mínimo tiempo, p. ej.: para recuperarse de un problema del lado del proveedor.

Extracción del regex del ID en el SR regex-extraction

El formato SR no se aplica estrictamente en la especificación de protocolo SMPP. Es solo una recomendación descrita en el Apéndice B (página 167) del pliego de condiciones. Algunos implementadores SMPP dan un formato diferente a este campo, por lo que Adobe Campaign necesita una forma de extraer el campo correcto.

De forma predeterminada, captura hasta 10 caracteres alfanuméricos después de id:.

El regex debe tener exactamente un grupo de captura con una parte incluida entre paréntesis. Los paréntesis deben rodear la parte del ID. El formato regex es PCRE.

Al ajustar esta configuración, asegúrese de incluir el mayor contexto posible para evitar activaciones falsas. Si hay prefijos específicos, como id: en el estándar, inclúyalos en la regex. Utilice también delimitadores de palabras (\b) tanto como sea posible para evitar capturar texto en medio de una palabra.

No incluir suficiente contexto en la regex puede introducir un pequeño defecto de seguridad: el contenido real del mensaje puede incluirse en el SR. Si solo coincide con un formato de ID específico sin contexto, p. ej., un UUID, es posible que esté analizando el contenido de texto real, p. ej., un UUID incrustado en el campo de texto, en lugar del ID.

Regex aplicada para determinar el estado correcto/de error regex-applied

Cuando se encuentran mensajes con una combinación de campo stat/err desconocida, estas regex se aplican en el campo estadísticas ("stat") para determinar si el SR fue un éxito o un error. Se omiten los valores de SR con los valores estadísticos que no coinciden con ninguna de estas expresiones regulares.

De forma predeterminada, los valores de estadística comienzan por DELIV, p. ej.: DELIVRD en el Apéndice B, se considera que se ha entregado correctamente y todos los valores de estadística que coincidan con errores, p. ej.: REJECTED, UNDELIV, se consideran errores.

Formato de ID en reconocimiento MT id-format-mt

Indica el formato del ID devuelto en el campo message_id del SUBMIT_SM_RESP PDU.

Formato de ID en SR id-format-sr

Esto indica el formato del ID capturado por la regex Extraction del ID en el SR. Los valores tienen el mismo significado y el mismo comportamiento que el formato de MT anterior.

ID de SR o código de error en el campo opcional

Si se selecciona, el contenido de los campos opcionales se anexará al texto procesado por las expresiones regulares anteriores. El texto tendrá el formato 0xTAG:VALUE, 0xTAG siendo el valor hexadecimal de 4 dígitos de la etiqueta en mayúsculas, p. ej.: 0x002E.

Por ejemplo, es posible que desee capturar el ID en el campo receipted_message_id. Para ello, active esta casilla de verificación y el siguiente texto se agrega al estado:

0x001E:05e3299e-8d37-49d0-97c6-8e4fe60c7739

En este ejemplo, 0x001E es la etiqueta del campo opcional y UUID es el valor del campo.

Para capturar este valor, ahora puede establecer la siguiente regex en la regex de Extracción del ID en el campo SR:

\b0x001E:([0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12})\b

ID de SR o código de error en el campo de texto

Si se selecciona, el campo Texto se mantendrá durante el procesamiento del texto de estado del SR.

Esto resulta útil si el proveedor coloca datos importantes en este campo, como el ID o el estado. Normalmente, este campo se puede descartar de forma segura, ya que puede contener texto con una codificación que no sea ASCII e interrumpir el procesamiento de regex.

Si se habilita esta opción, puede que se produzca un error de seguridad muy pequeño si la regex del ID Extraction en el campo SR no es lo suficientemente específico. El contenido del campo Texto puede analizarse como un ID y un atacante puede utilizarlo para inyectar ID falsificados, lo que puede conducir a una situación de denegación de servicio parcial.

Etiqueta de ID de servicio

Permite añadir un TLV personalizado. Este campo establece la porción de etiqueta. El valor se puede personalizar por envío en el valor ID de servicio o programa en los parámetros avanzados del envío.

Esta configuración solo permite añadir una opción TLV por mensaje.

Respuesta automática enviada al MO automatic-reply

Esta función permite responder texto rápidamente a MO y controlar el envío de código corto a la lista de bloqueados.

Las columnas Palabra clave y Código corto definen condiciones para la activación de la respuesta automática. Si coinciden ambos campos, se envía el MO y se activa la acción adicional. Para especificar un comodín, debe dejar el campo vacío. La palabra clave coincide con la primera palabra alfanumérica del texto MO, omitiendo la puntuación y los espacios iniciales. Esto significa que el campo Palabra clave no puede contener espacios y debe ser una sola palabra.

La configuración Palabra clave es un prefijo. Por ejemplo, si especifica "AD", coincidirá con "AD", "ADAPT" y "ADOBE". Si tiene varias palabras clave con un prefijo común, debe prestar atención al orden, ya que las palabras clave se procesan de arriba a abajo.

La columna Respuesta es el texto que se va a responder. No hay personalización disponible en este campo. Si deja este campo vacío, no se responderá ningún mensaje, pero la acción adicional se activará de todos modos.

La columna Acción adicional proporciona una acción adicional cuando tanto la Palabra clave como el Código corto coinciden, el código corto vacío coincide con todos los códigos cortos. Puede enviar a la cuarentena o quitar de la cuarentena, ningún valor responde al texto. Si especifica una Acción adicional pero deja vacío el campo Respuesta, la acción se ejecutará pero no se enviará ninguna respuesta. La cuarentena solo se aplica al código corto especificado o a todos los códigos cortos si el campo se deja vacío.

Todas las entradas de la tabla se procesan en el orden especificado, hasta que una regla coincida. Si varias reglas coinciden con un MO, solo se aplicará la regla superior.

Parámetros de plantilla de envíos de SMS sms-delivery-template-parameters

Algunos parámetros se pueden definir por la plantilla de envíos.

Del campo from-field

Este campo es opcional. Permite anular la dirección del remitente (oADC). El contenido de este campo se coloca en el campo source_addr del SUBMIT_SM PDU.

El campo está limitado a 21 caracteres por la especificación del SMPP, pero algunos proveedores pueden permitir valores más largos. Tenga en cuenta también que en algunos países se pueden aplicar restricciones muy estrictas, como longitud, contenido, caracteres permitidos.

Parámetros de envío delivery-parameters

Número máximo de SMS por mensaje maximum-sms

Esta configuración solo funciona si la configuración Carga útil del mensaje está deshabilitada. Si el mensaje requiere más SMS que este valor, se activará un error.

El protocolo SMS limita los SMS a 255 partes, pero algunos teléfonos móviles tienen problemas para reunir mensajes largos con más de 10 partes, el límite depende del modelo exacto. Le recomendamos que no pase más de 5 partes por mensaje.

Debido a cómo funcionan los mensajes personalizados en Adobe Campaign, el tamaño de los mensajes puede variar. Si tiene una gran cantidad de mensajes largos, el coste del envío podría aumentar.

Modo de transmisión transmission-mode

Este campo indica el tipo de SMS que desea transferir: mensajes normales o flash, almacenados en el móvil o en la tarjeta SIM.

Esta configuración se transmite en el campo opcional dest_addr_subunit de SUBMIT_SM PDU.

Período de validez validity-period

El período de validez se transmite en el campo validity_period del SUBMIT_SM PDU. La fecha siempre está formateada con un formato de hora UTC absoluta, el campo de fecha finalizará con "00+".

Conector SMPP genérico extendido acc-extended-connector

Las flechas representan flujos de datos.

Al enviar partes de envío, el MTA genera elementos secundarios de MTA. El número de procesos secundarios de MTA es dinámico y depende de una configuración en serverConf.xml. Cada elemento secundario de MTA crea una instancia del conector CSmppConnectorWorker que se conecta al proveedor del SMPP. Las conexiones se mantienen activas mientras el elemento secundario de MTA se mantenga activo, también se puede configurar en serverConf.xml.

El proceso del SMS solo procesa SR, se conecta al proveedor y deja la conexión abierta. El proceso se vuelve a conectar cada 10 minutos para volver a cargar la nueva configuración, lo cual es normal.

Entradas de MT, SR y “broadlog” que coinciden matching-mt

Se utiliza una tabla intermedia nmsProviderMsgId para almacenar los datos de MT y SR temporalmente antes de enviarse asincrónicamente al "broadlog".

nmsProviderMsgId tiene 3 grupos de columnas:

Cuando haya terminado el procesamiento de MT y SR, debe tener líneas completas, con información de "broadlog" e información de estado.

Aquí, iMsgId está vinculado a la tabla nmsBroadLogMsg, lo que indica el mensaje de estado/error completo.

El proceso de SMS busca líneas completas cada minuto y luego las procesa asincrónicamente:

Conexión en paralelo y de rendimiento

Cada elemento secundario de MTA crea una cantidad configurable de conexiones, por lo que si se limita el número de elementos secundarios de MTA se limita el número de conexiones. Debido a que la correlación entre los procesos secundarios de MTA y el tráfico está correlacionado, se puede controlar de alguna manera pero sigue siendo impredecible.

Antes de empezar a usarlo checklist

Esta lista de verificación le proporciona una lista de las cosas que debe comprobar antes de empezar a usarlo. Una configuración incompleta puede provocar muchos problemas.

Comprobación de conflictos en la cuenta externa external-account-conflict

Compruebe que no tiene cuentas externas de SMS antiguas. Si deja desactivada la cuenta de prueba, corre el riesgo de que se vuelva a habilitar en el sistema de producción y se generen posibles conflictos.

Si tiene varias cuentas en la misma instancia de Adobe Campaign que se conectan al mismo proveedor, póngase en contacto con el proveedor para asegurarse de que realmente se distinguen las conexiones entre estas cuentas. Si tiene varias cuentas con el mismo inicio de sesión necesita una configuración adicional.

Habilitación de los seguimientos detallados del SMPP durante las comprobaciones enable-verbose

Siempre debe habilitar los seguimientos detallados del SMPP durante las comprobaciones.
Incluso si no puede comprobar los registros usted mismo, será más fácil para el Servicio de atención al cliente de Adobe ayudarle.

Prueba de SMS test

Compruebe las PDU check-pdus

Aunque los mensajes parezcan correctos, es importante comprobar que las PDU están formateadas correctamente.

Este paso es necesario cuando se conecta a un proveedor que no estaba conectado a Adobe Campaign anteriormente.

BIND bind

Verifique que BIND_* PDUs se envíen correctamente. Lo más importante que hay que comprobar es que el proveedor siempre devuelve BIND_*_RESP PDUs (command_status = 0) correctamente.

Compruebe que no hay demasiadas BIND_* PDU. Si hay demasiados, podría indicar que la conexión es inestable. Consulte la sección Problemas con conexiones inestables para obtener más información.

ENQUIRE_LINK enquire-link-pdus

Compruebe que las ENQUIRE_LINK PDU se intercambian regularmente cuando la conexión está inactiva.

SUBMIT_SM / DELIVER_SM

Envíe un mensaje y luego busque en los registros sus correspondientes SUBMIT_SM, SUBMIT_SM_RESP, DELIVER_SM y DELIVER_SM_RESP PDU.

Con el SUBMIT_SM PDU:

Con el SUBMIT_SM_RESP PDU:

Con el DELIVER_SM PDU:

Con el DELIVER_SM_RESP PDU:

Consulte con su proveedor provider

Aunque el SMS se haya enviado correctamente, póngase en contacto con el proveedor para ver si todo está en orden.

Deshabilite los seguimientos detallados del SMPP disable-verbose

Una vez completadas todas las comprobaciones, lo último que debe hacer es Deshabilitar los seguimientos detallados del SMPP para no generar demasiados registros. Puede volver a activarlos para solucionar los problemas incluso en sistemas de producción.