Overview
SMS nach Ägypten schlagen meist aus drei Gründen fehl: eine nicht registrierte Absenderkennung, falsches Nummernformat oder arabischer Text mit falscher Kodierung. Die ägyptische Regulierungsbehörde NTRA schreibt vor, dass A2P-Absenderkennungen über eine lizenzierte lokale Route vorregistriert werden müssen. Nicht registrierte Absender werden blockiert oder ihre Absenderkennung wird überschrieben. Registrieren Sie Ihre Absenderkennung, senden Sie Nummern im Format 20XXXXXXXXXX ohne + oder 00 und verwenden Sie für arabischen Text den Typ 4.
Absenderkennung nicht registriert (übliche Ursache)
In Ägypten wird A2P-Traffic ausschließlich über lizenzierte, von der NTRA genehmigte Routen abgewickelt. Jede alphanumerische Absenderkennung muss vorab registriert sein. Bei Verwendung einer nicht registrierten Absenderkennung gibt das Gateway entweder HTTP06 (Ungültige Absenderkennung) zurück oder die Nachricht wird zwar akzeptiert, aber im weiteren Verlauf blockiert/überschrieben, sodass sie nie unter Ihrer Marke ankommt. Registrieren Sie die Absenderkennung vor dem Senden bei BroadNet und übergeben Sie sie exakt wie genehmigt im Parameter „sid“. Die Parameternamen (sid, mno, type) und HTTPxx-Fehlercodes auf dieser Seite gehören zur Legacy-HTTP-API (/websmpp); in der REST-API mit Bearer-Token (POST /sms/sendSms) heißen die Entsprechungen senderId, destinationNumber und messageType (UNICODE für Arabisch).
- Egyptian A2P verkehrt ausschließlich auf von der NTRA lizenzierten Strecken.
- Nicht registrierte Absender-ID → HTTP06 oder stillschweigende Blockierung nachgelagerter Verbindungen.
- Registrieren Sie zuerst die Absender-ID; setzen Sie sid auf den genehmigten Wert.
- Prüfen Sie den zurückgegebenen Code – HTTP06 verweist direkt auf die Absender-ID.
Falsches Zahlenformat
Zielrufnummern in mno müssen im vollständigen internationalen Format vorliegen, nur Ziffern: Ländervorwahl 20 für Ägypten, gefolgt von der nationalen Rufnummer, ohne führendes +, 00 oder 0. Eine fehlerhafte oder nicht routbare Rufnummer wird mit dem HTTP-Fehler 09 (Ungültige Zieladresse) abgelehnt. Korrigieren Sie die Rufnummer vor dem Absenden.
- Format: 20 + nationale Nummer, nur Ziffern (z. B. 201001234567).
- Streifen Sie +, 00, Leerzeichen und die nationale führende 0.
- Fehlerhafte Nummern führen zu HTTP09 (Ungültige Zieladresse).
- GET akzeptiert bis zu 100 Empfänger, POST bis zu 10.000.
Arabisch wurde mit der falschen Kodierung gesendet.
Arabische Nachrichten müssen im korrekten Datentyp gesendet werden. Verwenden Sie Typ=4 für Arabisch (bis zu 70 Zeichen pro Segment) oder Typ=2 für allgemeines Unicode/UCS-2. Das Senden von Arabisch als Typ=1 (Englisch GSM-7) führt zu fehlerhaften Zeichenketten oder unleserlichen Zeichenfolgen. Senden Sie den Nachrichtentext UTF-8-kodiert und URL-kodiert. Beachten Sie, dass UCS-2/Arabisch-Segmente jeweils 70 Zeichen lang sind. Längere Nachrichten werden daher in mehrere (abrechnungsfähige) Teile aufgeteilt.
- Arabisch: Typ=4 (70 Zeichen/Segment); allgemeines Unicode: Typ=2.
- type=1 (GSM-7) wird arabischen Text verfälschen.
- Senden Sie UTF-8- und URL-codierte Daten.
- 70-Zeichen-Segmente – lange arabische Nachrichten benötigen mehr Teile.
Mit dem Lieferbericht abgleichen
Eine beim Absenden akzeptierte Nachricht kann im Netzwerk dennoch fehlschlagen. Konfigurieren Sie Ihren DLR-Webhook (oder rufen Sie den Status über die Legacy-HTTP-API unter /websmpp/websmsstatus ab) und lesen Sie den Status: DELIVRD bedeutet, dass die Nachricht das Endgerät erreicht hat, UNDELIV bedeutet, dass dies nicht der Fall ist. Vergleichen Sie Berichte anhand der MessageId oder BatchId und prüfen Sie HTTP18 (Unzureichendes Guthaben), falls ein ganzer Batch hängen bleibt.
- Angenommen ≠ zugestellt — immer den Zustellbericht prüfen.
- Status ZUGELASSEN vs NICHT ZUGELASSEN; Abgleich anhand von MessageId / BatchId.
- Status bei Bedarf abrufen (Legacy-HTTP-API: /websmpp/websmsstatus).
- Ein blockierter Batch kann auf HTTP18 – unzureichende Gutschriften – hinweisen.