Sending SMS in Text format to an app with a specific port number

Sending SMS in Text format to an app with a specific port number SearchSearch
Author Message
Eli Kartey
New member
Username: Spiky

Post Number: 1
Registered: 11-2009
Posted on Tuesday, November 17, 2009 - 01:50 pm:   

These are two test that were carried out on NowSms ,the first message to the default port of '0' and the second message was sent to a specific port '6015'.The following are the results of the text

First Message
Text:"test 1 to default port"
Mobile: +233244343726
Message received: "test 1 to default port"
Delivered to mobile's inbox.

Second Message
Text :"test 2 to specified port"
Mobile:+233244343726
Message received: "06050417D9000074657374203220746F207370656369656420706F7274"
NowSms failed to send message.

I don't really understand why the second text was decoded or changed and hence caused the failure of nowsms being able to send the text message. i'm using an SMPP connection.
Please give me ideas on how to solve this problem}
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 1439
Registered: 08-2008
Posted on Tuesday, November 17, 2009 - 05:39 pm:   

Hi Eli,

Did the SMS service provider return an error on the second message? (Does the SMSOUT-yyyymmdd.LOG show an error?)

When you say "Message received: 06050417D9000074657374203220746F207370656369656420706F7274" ... does this mean that the handset received the message as a hex string of characters? (Or are you just referring to the way that NowSMS displays the message in its log file?)

When you send a message to a specific port, the port number needs to be encoded in the "User Data Header" of the message. That is what the "06050417D90000" part of the message is.

The rest of the message that you display looks like standard 8 bit encoding of the text.

Unfortunately, the SMPP standard is a bit vague on how text messages that include User Data Header should be encoded. So there are 3 different ways that you can configure NowSMS to encode the data.

All of these settings are accessible if you highlight the SMPP connection in the "SMSC" list of NowSMS, and press the "Properties" button. Then select "Advanced Settings".

Try a test with "Encode long messages with 7-bit packed encoding" CHECKED, and another test with this setting UNCHECKED. (Note: When changing this setting, to apply it, it is necessary to press "OK" twice, then "Apply" and allow the service to restart.)

If it still doesn't work, there is an additional setting to try. Try CHECKing "Use TLV parameters for port numbers and segmentation". (Note: Most providers don't support this technique, which is why I'm suggesting it last ... so don't be surprised if the message arrives as a standard text message with no port number addressing.)

Hopefully one of those three settings will work. Unfortunately, there is no way to know which technique your SMPP provider expects.

If none of these settings work, then try similar tests sending long text messages (where NowSMS has to break them into multiple segments). Can you find a setting in NowSMS where the long message is received as a single message?

If long messages have a similar problem, then you should ask your provider about how they support long messages (and if they support them). I suggest this because your provider is more likely to understand a question about long messages than port addressing.

It is very possible that your provider does not support long messages or port addressing. In that case, you may want to try with a GSM modem until you can sort an alternative provider.

--
Des
NowSMS Support
Eli Kartey
New member
Username: Spiky

Post Number: 2
Registered: 11-2009
Posted on Friday, November 20, 2009 - 09:22 pm:   

I sorry 4 the delay in reply,but we currently solving a problem with our providers, i'l give u a reply very soon.
Eli Kartey
New member
Username: Spiky

Post Number: 3
Registered: 11-2009
Posted on Monday, November 23, 2009 - 03:26 pm:   

7-bit packed encoding-CHECKED: NowSms was able to send this message in binary instead of plain text but then the network providers rejected this message.

This was the same result when the 7-bit packed encoding was UNCHECKED:

TLV parameters for port: like you said,the message was sent in plain text alright, but was received in the inbox instead of the application.
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 1451
Registered: 08-2008
Posted on Monday, November 23, 2009 - 10:44 pm:   

Hi Eli,

Unfortunately, if none of those three techniques works, then it sounds like your provider does not support port addressed messages.

It is probable that they cannot support any user data header (UDH), which is where port addressing is encoded.

I would suggest trying additional tests with these three settings, but this time send long messages (longer than 160 characters), and see if that works.

If that also fails, then ask your provider how they support long messages. I suggest this because the encoding for long messages is similar to port addressing, but your provider is more likely to understand long messages.

--
Des
NowSMS Support