GSM7 encoding problem? for SMPP connection.

GSM7 encoding problem? for SMPP connection. SearchSearch
Author Message
Dane Dwyer
New member
Username: Danedwyer

Post Number: 2
Registered: 06-2006
Posted on Tuesday, June 20, 2006 - 03:35 pm:   

Hi --

I have run into an issue with character encoding of SMS MO messages. I've configured NowSMS with a USB handset as the SMSC. I can send a plain text message (US English), which is received by NowSMS. When I look in the SMS-IN log file, I can see the text I entered (test message).

I've configured NowSMS to deliver SMS inbound messages to an SMS User (via SMPP 3.4). For some reason, when the SMPP 3.4 client receives the message, the text is getting corrupted.

After some analysis of the byte level SMS message, it appears that the SMPP header indicates that the text has been encoded in GSM7 format (7-bits per character), but when looking at the actual encoded text in the SMPP message, it appears that the characters are _not_ 7-bit encoded. This is causing the SMPP client to interpret the text as 7-bit encoded, expand them to 8-bit, thus corrupting the text.

Has anyone else seen this before? Is there a setting I can change to resolve this? It really does appear to be a problem with NowSMS, but I do not know for sure.

I've uploaded a zip file that contains information from the SMPPDEBUG.log file and SMS-IN and SMS-OUT log files. Hopefully this will help you to identify the problem.

application/zipMOSMS-SMPPLOGS.zip
MOSMS-SMPPLOGS.zip (1.5 k)
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 6091
Registered: 10-2002
Posted on Tuesday, June 20, 2006 - 04:06 pm:   

Hi Dane,

We do a lot of SMPP connections as an SMPP client, and I've only seen two SMPP servers that expect clients to submit SMS messages with text that is 7-bit packed.

Usually, those servers are based upon SMPP v3.3, where the specifications are more vague.

The generally accepted behaviour in SMPP is that text is not 7-bit packed.

That said, I don't understand why the data_coding value is 11 hex.

That may very well be what the problem is.

We are carrying over the DCS value from the received message that came in via the modem. And 0x11 is not a valid value for data_coding in the SMPP world.

In GSM, 0x11 means that the message is class 1. And this is the same meaning as the default value of 0.

But in SMPP, 0x11 is undefined.

When routing outbound messages to SMPP, we would catch this and convert it.

But we are not doing this on messages that come in from a modem ... as basically, we haven't seen this as an issue before. Normally a standard text message would come in to the phone with DCS of 0 (or 8 if Unicode).

We'll have to look at applying the same conversions that we apply for outbound SMPP data_coding to the inbound side as well.

There's a minor update planned for later this week, so I'll see if we can get a change for this included.

-bn



Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 6118
Registered: 10-2002
Posted on Friday, June 23, 2006 - 07:30 pm:   

Follow-up.

A patch has been posted at http://www.nowsms.com/download/patch2006.zip.

When receiving messages from a GSM modem, unusual DCS values are now properly translated for routing to an SMPP client.

-bn