How does Twilio segment long messages containing urls? - sms

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).

Related

SMS to Twilio Number with Extension

I'd like users to be able to text my Twilio number and have the text forwarded to various recipients based on the number's extension. i.e. texting to 555-555-5555,2 should route to a different receiver than 555-555-5555,3.
This Quora answer hints that this is possible, but I haven't found any further documentation: https://www.quora.com/Is-it-possible-to-send-a-text-message-from-my-Android-to-a-phone-number-with-an-extension-number
I tried using Twilio Studio to implement something like an IVR or message/response, but that only produced a text prompt which didn't seem to respond to the number entered after the comma.
This not possible by appending data to the destination number. You would need to place directives in the SMS message body and have your Twilio (Studio) logic parse the message body to determine how to deliver the SMS (which Phone number to deliver the SMS to).

Kannel routing based on prefix

I've got a trouble with Kannel. I am using it as an SMS aggregator like this ESME-Kannel-SMSC. I've got several SMSC and I need to implement routing based on phone number prefix. Is it possible? Anyone has done it before?
Take a look at the Kannel documentation for SMS center variables:
allowed-prefix: A list of phone number prefixes which are accepted to be sent through this SMSC. Multiple entries are separated with semicolon (';'). For example, "040;050" prevents sending of any SMS message with prefix of 040 or 050 through this SMSC. If denied-prefix is unset, only these numbers are allowed. If set, number are allowed if present in allowed or not in denied list.
denied-prefix: A list of phone number prefixes which are NOT accepted to be sent through this SMSC.
preferred-prefix: As denied-prefix, but SMS messages with receiver starting with any of these prefixes are preferably sent through this SMSC. In a case of multiple preferences, one is selected at random (also if there are preferences, SMSC is selected randomly)

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.

How to send SMS with more than 160 characters and enable the customer to receive as ONE SMS using GSMComm library

I'm developing SMS system using C# and using GSMCOMM free API(http://www.scampers.org/steve/sms/libraries.htm) to send SMS.
As the system can only send SMS less than 160 characters, I cut the LONG SMS into two messages and send them out.
The problem is that the customer will receive two SMS, which is quite irritating. Is there any way to enable customer to receive them as one SMS?
If using HTTP, you have to set the MLC to 2.
Message length control: determines system behavior when the message length exceeds limits set by the mobile operator.
0 – Reject the MT if message text > maximum allowed for the target operator.
1 – Truncate the MT if message text > maximum allowed for the target operator.
2 – Automatically create multiple MTs dividing the message text at the point(s) where message text length = maximum allowed for the target operator.

Error when sending long SMS message

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.

Resources