Overview
Los SMS a Egipto suelen fallar por tres razones: un ID de remitente no registrado, un formato de número incorrecto o texto en árabe con codificación errónea. El organismo regulador egipcio, la NTRA, exige que los ID de remitente A2P estén preregistrados a través de una ruta local autorizada; los remitentes no registrados son bloqueados o su ID de remitente se sobrescribe. Registre el ID de remitente, envíe los números como 20XXXXXXXXXX sin + ni 00, y use type=4 para el árabe.
El identificador del remitente no está registrado (la causa habitual).
Egipto solo gestiona el tráfico A2P a través de rutas autorizadas y aprobadas por la NTRA, y cada ID de remitente alfanumérico debe estar preregistrado. Si se envía con un ID de remitente no registrado, la pasarela devuelve HTTP06 (ID de remitente no válido) o bien el mensaje se acepta, pero se bloquea o sobrescribe posteriormente, impidiendo que llegue con su marca. Registre el ID de remitente en BroadNet antes de enviarlo e introdúzcalo en el parámetro sid tal como está aprobado. Los nombres de parámetros (sid, mno, type) y los códigos de error HTTPxx de esta página corresponden a la API HTTP heredada (/websmpp); en la API REST con token Bearer (POST /sms/sendSms) los equivalentes son senderId, destinationNumber y messageType (UNICODE para árabe).
- El servicio Egyptian A2P opera únicamente en rutas autorizadas por la NTRA.
- ID de remitente no registrado → HTTP06 o un bloqueo silencioso de la conexión descendente.
- Primero registre el ID del remitente; establezca sid al valor aprobado.
- Comprueba el código devuelto: HTTP06 apunta directamente al ID del remitente.
Formato de número incorrecto
Los números de destino en mno deben estar en formato internacional completo, solo dígitos: el código de país 20 para Egipto seguido del número nacional, sin signos +, 00 ni 0 iniciales en la parte nacional. Un número mal formado o no enrutable se rechaza con HTTP09 (Dirección de destino no válida). Normalice antes de enviar.
- Formato: 20 + número nacional, solo dígitos (por ejemplo, 201001234567).
- Tira +, 00, espacios y el líder nacional 0.
- Los números con formato incorrecto devuelven HTTP09 (Dirección de destino no válida).
- GET acepta hasta 100 destinatarios, POST hasta 10.000.
Árabe enviado con la codificación incorrecta
El árabe debe enviarse con el tipo correcto. Use type=4 para árabe (hasta 70 caracteres por segmento) o type=2 para Unicode/UCS-2 general; enviar árabe como type=1 (inglés GSM-7) distorsiona el texto, convirtiéndolo en signos de interrogación o caracteres ilegibles. Envíe el cuerpo codificado en UTF-8 y en URL, y recuerde que los segmentos UCS-2/árabe tienen 70 caracteres, por lo que los mensajes más largos se dividen en más partes (facturables).
- Árabe: tipo=4 (70 caracteres/segmento); Unicode general: tipo=2.
- type=1 (GSM-7) corromperá el texto árabe.
- Enviar en UTF-8 y codificado en URL.
- Segmentos de 70 caracteres: los mensajes largos en árabe cuestan más partes.
Verificar con la confirmación de entrega
Un mensaje aceptado al enviarse aún puede fallar en la red. Configure su webhook DLR (o, en la API HTTP heredada, consulte el estado en /websmpp/websmsstatus) y lea el estado: DELIVRD significa que llegó al dispositivo, UNDELIV significa que no llegó. Compare los informes por MessageId o BatchId y verifique HTTP18 (créditos insuficientes) si se bloquea un lote completo.
- Aceptado ≠ entregado: compruebe siempre el DLR.
- Estado ENTREGADO vs. NO ENTREGADO; coincidencia por MessageId / BatchId.
- Consulte el estado bajo demanda (API HTTP heredada: /websmpp/websmsstatus).
- Un lote detenido puede deberse a HTTP18: créditos insuficientes.