CC::Blog

Kurzer Merker für mich (Bezgl.: Endgeräte werden in bestimmten Konstellationen bei überlangen SMS zugespammt.)

Beim Versand von SMSsen über UCP/EMI (Command 51) gibt es zwei Möglichkeiten wie man mit “überlangen” SMS (>160 GSM-Chars) umgehen kann:

1. Concatenated Messages. Man teilt die Messages in 160er Chunks auf und sendet im UDH (User Data Header) folgendes für die Einzelteile:
   1. 0x00 = Concatenated Message
   2. 0x03 = Länge des Infoelements (Folgt jetzt)
   3. 0xC0 = Referenz-ID (kann ausgewürfelt werden. Ist Unique auf Receipient und diese ID)
   4. 0x02 = Anzahl der einzelnen Mulitpart-SMSsen
   5. 0x01 = Diese Message ist Part 1 von dem was in Byte 4 steht.
2. LongMessage (Feature muss SMS-C seitig aktiviert sein). In dem Falle geht das Ding mit dem Standard UDH in einem Block raus (Maximale Länge ist beim SMSC zu erfragen – in meinem Fall waren 550 Chars durchaus machbar)

So, und nun wird es spannend.

Acknowledgehandling

Im Fall 1 wird

• jeder einzelne Part fein vom SMSC eingequed,
• ans SS7 überstellt und
• für jeden einzelnen Part ein ACK generiert – SS7 generiert das Acknowledge, wenn die (Teil-)Message beim Empfänger angekommen ist, und übergibt das ACK dann ans SMSC welches dieses per UCP/EMI an mich weitergibt.

Das ist ne ziemlich zeitaufwendige Angelegenheit, die man wirklich extrem spürt. Der Durchsatz SMS/sec ist halt nur 1/n so groß wie wenn ich nur eine 160er Nachricht versende (n=Anzahl der Parts).

Fall 2 ist da schon (vermeintlich) eleganter. Wir überstellen den “Blob” ans SMS-C und bekommen (bei erfolgreicher delivery) genau ein ACK zurück. Und hier liegt der Hase im Pfeffer. Aufgefallen ist mir das ganze, weil es Empfänger gibt, die sich bei mir über nicht aufhörend wollende SMSsen beschwert haben (Empfänger bekommt die selbe SMS wieder und wieder. Hört so gut wie nicht auf. 2000 sind keine seltenheit). Also der Sache auf den Grund gegangen:

1. die LongMessages werden per UCP/EMI mit ACK-Req (ohne geht nicht) ans SMSC übergeben.
2. SMSC schiebt die LongMessage ans SS7 durch.
3. SS7 merkt “Oh, ne LongMessage” und splitted die in 160er Chunks (Auch wenn es LongMessages gibt. GSM/SMS kann – egal wie – nur 160er Chunks)
4. Gleichzeitig schiebt das SS7 ein(!) ACK ans SMS-C zurück, wenn der erste Part zugestellt wurde.
5. ACK kommt via UCP/EMI bei mir an

Schaut man sich das jetzt genauer an, stellt man fest, dass das ACK schon beim ersten erfolgreichen Zustellversuch des ersten Chunks kommt. Jetzt gibt es da draussen irgendwelche irren Endgeräte, die das ACK in genau diesem Fall nicht sauber senden. Mit dem unschönen Nebeneffekt, dass das SMSC für die nicht geackten Chunks immer wieder dem SS7 auf die Füße tritt (“Send nochmal”). Je nach unglücklicher Konstellation ist das Endgerät nun in einem ewigen loop.

Fragt mich bitte nicht, warum das im Fall 1 nicht auch passiert. Laut meinem SMSC Kontakt liegt es am Zusammenspiel SMSC/SS7. Einzige Abhilfe war, alles auf MuPart umzustellen. Mit all den häßlichen Nebenwirkungen bezgl. Durchsatz und Co.

Ich denke die einzige Alternative dagegen wäre es, sich selbst ein SS7-Account zu besorgen. Ob man das aber will (zum rumspielen bestimmt mal gerne – aber produktiv)…

 

Vielleicht hat ja einer meiner Leser da ein paar mehr Hintergründe (Jetzt bitte kein: Nimm doch SMPP. Hat sich nämlich rausgestellt, dass überall wo “Simple” im Protokollnamen vorkommt, es alles andere als Simpel ist. Stehe nicht so auf irre XML/SOAP-Requests)