| Sendning concatenated binary SMS |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through May 12, 2004 ⬆ |
◄ ► |
| Author | Message | |||
| David Olsson Unregistered guest |
Hello! I am trying to send a sequence of message blocks as separate binary messages by using the IEI 0x00. The receiveing phone understands that there are several parts and displays them all. That's not the problem. The thing is that I am trying to send text messages using the binary http interface (programmatically, not using the HTML pages) by encoding a textstring to the GSM alphabet and setting the UDH and DCS correctly. This works fine if the message doesn't have to be concatenated (no UDH) which I guess means the GSM alphabet encoding works. But as soon as the message must be concatenated and a UDH is added, all that arrives is garbage text. Is there some special packing that must be done if I have an UDH in a text message (though it's actually a binary message)? Thanks for any help! | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 2101 Registered: 10-2002 |
Hi David, Are you running a version of NowSMS v5.01? The reason that I ask is because we made a change in v5.01 to make it easier to send text messages that include UDH. You can just include a UDH paramter, and the message text, and we'll take care of the encoding. The problem is that when a message includes UDH, and the length of the UDH (including the length byte) is not a multiple of 7, this changes the offset at which you begin the GSM 7-bit packing. You can download v5.01 from the web site, and install it over an existing NowSMS installation without losing any configuration or serialisation information. -bn | |||
| David Olsson Unregistered guest |
Thanks for the answer. It seems rather clear to me that the problem is that the inclusion of an UDH changes the offset at which the GSM packing begins. However, the application I am working on needs to be able to send text messages as binary messages which makes it impossible for me to use the feature in v5.01 you're mentioning. It would be of great help to me if you could lead me in the right direction when in comes to how the offset of the packing changes when an UDH is included. Thanks in advance David Olsson | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 2165 Registered: 10-2002 |
Hi David, It's very hard to explain. Probably the best I can do is excerpt an explanation that I offered someone via e-mail recently. Customer question: > Hello Mr.Norwood, > > > May I ask you some question about GSM7bit encoding and decoding? > > I input "Italic http://www.fujitsu.com/" into Ericsson P800. > And, I got it after sending the SMS from the mobile phone to NowSMS via serial cable. > > > The SMS are as follows. > -------------------------------------------------------------- > [SMS-IN] > ModemName=Nokia 6310 (Cable) > Sender=+447816831813 > UDH=050A03000620 > Data=92F4303B3D06A1E974B8EEF5BADFEF2E735D9DA6CFEBAEF1BBFD02 > Binary=1 > -------------------------------------------------------------- > > However, the converted data and the format on the 3GPP specification were different. > I referred "6.1.2.1 SMS Packing, 3GPP TS 23.038" as 3GPP spec. > > Moreover, I converted the 8bit data to GSM7bit data manually. > As a result, the data are as follows. > > Why are the output data and the format on 3GPP specification different? > Could you tell me which specification is used to convert it on NowSMS? > > > The stored data on NowSMS: > -------------------------------------------------------------------------- --- > [UDH] > 05 // UDHL > 0A // IEIa(Text formatting) > 03 // IEIDLa > 00 // Start position > 06 // Text format length > 20 // Formating mode(00100000) #Italic > > [Data] > 92 F4 30 3B 3D 06 A1 E9 74 B8 EE F5 BA DF EF 2E > 73 5D 9D A6 CF EB AE F1 BB FD 02 > -------------------------------------------------------------------------- --- > > The manual conversion data: > -------------------------------------------------------------------------- --- > 49 7A 98 9D 1E 83 D0 74 3A 5C F7 7A DD EF 77 97 B9 AE 4E D3 > E7 75 D7 F8 DD 7E 01 > -------------------------------------------------------------------------- --- > Ascii(8bit) GSM7bit Conversion > I = 0x49 = 01001001 -> 01001001 = 0x49 > t = 0x74 = 01110100 -> 01111010 = 0x7A > a = 0x61 = 01100001 -> 10011000 = 0x98 > l = 0x6C = 01101100 -> 10011101 = 0x9D > i = 0x69 = 01101001 -> 00011110 = 0x1E > c = 0x63 = 01100011 -> 10000011 = 0x83 > SP = 0x20 = 00010000 -> 11010000 = 0xD0 > h = 0x68 = 01101000 -> 01110100 = 0x74 > t = 0x74 = 01110100 -> 00111010 = 0x3A > t = 0x74 = 01110100 -> 01011100 = 0x5C > p = 0x70 = 01110000 -> 11110111 = 0xF7 > : = 0x3A = 00111010 -> 01111010 = 0x7A > / = 0x2F = 00101111 -> 11011101 = 0xDD > / = 0x2F = 00101111 -> 11101111 = 0xEF > w = 0x77 = 01110111 -> 01110111 = 0x77 > w = 0x77 = 01110111 -> 10010111 = 0x97 > w = 0x77 = 01110111 -> 10111001 = 0xB9 > .. = 0x2E = 00101110 -> 10101110 = 0xAE > f = 0x66 = 01100110 -> 01001110 = 0x4E > u = 0x75 = 01110101 -> 11010011 = 0xD3 > j = 0x6A = 01101010 -> 11100111 = 0xE7 > i = 0x69 = 01101001 -> 01110101 = 0x75 > t = 0x74 = 01110100 -> 11010111 = 0xD7 > s = 0x73 = 01110011 -> 11111000 = 0xF8 > u = 0x75 = 01110101 -> 11011101 = 0xDD > .. = 0x2E = 00101110 -> 01111110 = 0x7E > c = 0x63 = 01100011 -> 00000001 = 0x01 > o = 0x6F = 01101111 -> > m = 0x6D = 01101101 -> > / = 0x2F = 00101111 -> > -------------------------------------------------------------------------- --- > My response: Hi, That is an EMS message, as you have correctly determined. GSM 7-bit packing is a little bit unusual when UDH is present. I would recommend that you also look at long SMS messages (concatenated messages when text is sent with more than 160 characters) as another example of how GSM 7-bit packing is a bit unusual when UDH is present. Basically, if the size of the UDH is not a multiple of 7 bytes ... then the 7-bit packing begins on a boundary that is relative to the size of the UDH. This is very difficult to explain in words, and I have not seen this adequately described in specifications (the SMS specifications suggest that filler characters should be used, but in practice, they are not). So, let's take your example: UDH=050A03000620 Data=92F4303B3D06A1E974B8EEF5BADFEF2E735D9DA6CFEBAEF1BBFD02 The UDH is 6 bytes in length. The first byte of the SMS message data, 92, completes that first set of 7 bytes. Then, comes the next 7 bytes, which can be unpacked to 8 characters: F4303B3D06A1E9 (I manually decoded the first two characters here, and got the expected "ta".) And another 7 bytes to be unpacked to 8 characters: 74B8EEF5BADFEF And another 7 bytes to be unpacked to 8 characters: 2E735D9DA6CFEB And the final section has only 5 bytes to be unpacked: AEF1BBFD02 Now the question is the unpacking of the first byte, "92". To decode 92, we treat this character as the last byte of a 7 byte block. The first character that can be fully encoded in this remainder of this block is character number 8. If we shift 92 one byte to the right, we get 49, which is the character encoding for "I". -bn | |||
| David Olsson Unregistered guest |
Thanks a lot! Now I got it working! David | |||
