Error when sending long SMS message - sms

I am doing a long SMS project but I have encountered some problems. I am able to send 2 SMS messages as one long message, but the text that appears doesn't seem to be right. I know there is an error at A0 indicating a 160 word so the SMS has a # word filling all the empty space. But what I mean is the actually SMS text is corrupted.
The 2 SMS I send:
AT+CMGS=28
0041000A9156186651270000A0050003000201E8F71D14969741F9771D
AT+CMGS=23
0041010A9156186651270000A0050003000202E8329BFD06

From what I can see the PDU is wrongly encoded. With concatenated SMS's you must include the UDH (so you also need to set in the SMS header octet the flag to say a UDH is included). And of course ensure that the message text starts on a septet boundary.
There are a few tutorials on the web:
http://www.dreamfabric.com/sms/
Which explain things in more detail and also in a very understandable way. I suggest you take at look a them and check the way you are encoding your messages.

Related

Can AT+CMGS be cancelled without ESC?

Is it possible to have AT+CMGS commands cancelled by some control code other than ESC?
I need it because ESC is intercepted by the attached equipment for its own use and never gets to the modem. And, I can't change that.
Unfortunately, CTRL-Z will send even an empty message, or else I could backspace enough to clear the message and do CTRL-Z to abort.
The relevant "AT command set" manual is no help.
According to TS 127 005 specification, it seems that there's no way to configure the character for SMS sending abortion.
Anyway I can suggest a workaround, based on three different commands:
+CMGW - Write Message To Memory
+CMGD - Delete Message
+CMSS - Send Message From Storage
So basically, instead of using +CMGS that sends the message in one step
Write the SMS to memory with +CMGW (same syntax of +CMGS). After the SMS contents closure with the CTRL-Z character, its answer is
+CMGW: <index>
where <index> is the message location index in the current memory storage
Actually send it with
AT+CMSS=index
Delete the SMS with
AT+CMGD=index
Since memory slots are limited, you will have to delete it anyway. If you realize that the message you are composing during +CMGW phase is wrong, store it anyway with CTRL-Z and skip the actual sending.
As you can see, the entire procedure is performed without using the ESC character (0x1B), can be easily automated and doesn't require much more time to be executed.

Sending message sequence to Twilio

Hello , I want to send a set of messages to Twilio API with some parameters that make sure that they are concatenated and sent a one sms .
I've heard of some SegmentNum to use but with no documentation on it.
No need, Twilio handles the concatenation for you.
Does Twilio support concatenated SMS messages or messages over 160 characters?
"When sending concatenated SMS, Twilio will auto-segment long messages with a special header, which mobile carriers can use to reassemble the segments on the destination handset. Thus, concatenated SMS can appear as one single message on the receiving device."

How does Twilio segment long messages containing urls?

Let's consider a string M which contains some words and a url that puts the final message length at 1000 characters (including the characters in the url).
I know Twilio auto-segments messages > 160 chars:
Ref. article.
Twilio will auto-segment long messages with a special header, which mobile carriers can use to reassemble the segments on the destination handset. Thus, concatenated SMS can appear as one single message on the receiving device.
My question is will it segment the message in a way that breaks the url into multiple parts or does Twilio account for urls in the message during the segmentation?
Example: The message gets segmented at a point such that the url in the message say https://www.example.com/some-url, gets broken across two segments say - https://www.exampl(in one segment) and e.com/some-url (in another segment).

Any way to determine which text message is being responded to?

I use Twilio with my team management system. A text message is automatically sent out for each game. The receiver can then reply with YES or NO. My issue is that when I send two text messages, I have no way to tell if the reply is for the first message I sent, or the second.
Does Twilio have any way to determine which text message it was a response to?
Twilio developer evangelist here.
If you are sending two messages from one Twilio number to the same user number there is nothing within the SMS specification that allows a user to reply to a specific message, so there is nothing you can do with Twilio to detect that.
If you are sending two messages to two different numbers and you get replies from those numbers, you can match against the from number and see what the last message sent from that number was and attach the reply to that.
Alternatively, if you want to get replies from one user to different messages, you could send them from different Twilio numbers. That way you can match the outgoing number to the message and the answer. This is mostly used for phone number masking to enable anonymous communications and there is a good tutorial available on this in the Twilio documentation.
Let me know if that helps at all.

Will concatenated sms be delivered always in the order sent out by a GSM handset?

As I know concatenated sms are split in GSM handset and delivered to network. Does GSM standard talk about order of these packets? Will it be always sent in order? That is first sequence packet first and next later?
My questions regarding this.
1. Does SMPP talk about order of long sms segments? Like is it possible for SP to get out of order messages?
2. Does GSM handset deliver long messages always in order or not?
"long sms" officially known as concatenated sms can and will turn up in any order. Therefore the receiving device / system must be able to cater for this. Concatenated sms come in the form of multiple sms. Encoded within is the part number and the total number of parts for the concatenated sms (you can search for information on the "UDH - User Data Header" to get more information).
So answering your questions:
1) There is no ordering in the sending / receiving of concatenated sms. Only information within each concatenated sms part which says which part it is and how big the complete concatenated sms is.
2) GSM handsets tend to send out in order. The order is lost usually during the store and forward process on the SMSC side. On a side note GSM handsets when receiving a concatenated sms build the sms once all parts are received.

Resources