Overview
L'invio di SMS in Egitto fallisce spesso per tre motivi: un ID mittente non registrato, un formato del numero errato o testo arabo inviato con una codifica errata. L'autorità di regolamentazione egiziana, la NTRA, richiede che gli ID mittente A2P siano preregistrati tramite un canale locale autorizzato: i mittenti non registrati vengono bloccati o il loro ID mittente viene sovrascritto. Registra l'ID mittente, invia i numeri nel formato 20XXXXXXXXXX senza + o 00 e utilizza il tipo=4 per l'arabo.
ID mittente non registrato (la causa più comune)
L'Egitto gestisce il traffico A2P solo su rotte autorizzate e approvate da NTRA, e ogni ID mittente alfanumerico deve essere preregistrato. L'invio con un ID mittente non registrato comporta la restituzione da parte del gateway del codice HTTP06 (ID mittente non valido) oppure il messaggio viene accettato ma bloccato/sovrascritto a valle, impedendone così l'arrivo con il proprio marchio. Registrare l'ID mittente con BroadNet prima dell'invio e inserirlo nel parametro sid esattamente come approvato. I nomi dei parametri (sid, mno, type) e i codici di errore HTTPxx in questa pagina sono quelli dell'API HTTP legacy (/websmpp); nell'API REST con token Bearer (POST /sms/sendSms) gli equivalenti sono senderId, destinationNumber e messageType (UNICODE per l'arabo).
- Egyptian A2P opera esclusivamente su rotte autorizzate da NTRA.
- ID mittente non registrato → HTTP06 o blocco silenzioso a valle.
- Registra prima l'ID del mittente; imposta il sid sul valore approvato.
- Controlla il codice di ritorno: HTTP06 punta direttamente all'ID del mittente.
Formato numerico errato
I numeri di destinazione in mno devono essere nel formato internazionale completo, solo cifre: prefisso internazionale 20 per l'Egitto seguito dal numero nazionale, senza +, 00 o 0 iniziali nella parte nazionale. Un numero non valido o non instradabile viene rifiutato con HTTP09 (Indirizzo di destinazione non valido). Normalizzare prima dell'invio.
- Formato: 20 + numero nazionale, solo cifre (es. 201001234567).
- Striscia +, 00, spazi e il leader nazionale 0.
- I numeri non validi restituiscono HTTP09 (Indirizzo di destinazione non valido).
- GET accetta fino a 100 destinatari, POST fino a 10.000.
Testo arabo inviato con codifica errata
I messaggi in arabo devono essere inviati con il tipo corretto. Utilizzare il tipo=4 per l'arabo (fino a 70 caratteri per segmento) o il tipo=2 per Unicode/UCS-2 generico; l'invio di messaggi in arabo come tipo=1 (inglese GSM-7) trasforma il testo in punti interrogativi o caratteri illeggibili. Inviare il corpo del messaggio codificato in UTF-8 e codificato in URL, e ricordare che i segmenti UCS-2/arabo sono di 70 caratteri, quindi i messaggi più lunghi vanno suddivisi in più parti (fatturabili).
- Arabo: tipo=4 (70 caratteri/segmento); Unicode generale: tipo=2.
- Il tipo=1 (GSM-7) corromperà il testo arabo.
- Inviare in formato UTF-8 e con codifica URL.
- Segmenti da 70 caratteri: i messaggi arabi lunghi costano più parti.
Confermare con il rapporto di consegna
Un messaggio accettato al momento dell'invio potrebbe comunque non essere recapitato correttamente sulla rete. Configura il tuo webhook DLR (oppure, sull'API HTTP legacy, recupera lo stato da /websmpp/websmsstatus) e leggi lo stato: DELIVRD significa che il messaggio ha raggiunto il dispositivo, UNDELIV significa che non l'ha raggiunto. Confronta i report tramite MessageId o BatchId e controlla HTTP18 (crediti insufficienti) se un intero batch si blocca.
- Accettato ≠ consegnato: controlla sempre il DLR.
- Stato DELIVRD vs UNDELIV; corrispondenza su MessageId / BatchId.
- Recupera lo stato su richiesta (API HTTP legacy: /websmpp/websmsstatus).
- Un batch bloccato può essere HTTP18 - crediti insufficienti.