Kannel doesn't seem to be buffering / concatenating inbound multipart messages.
So if I send a message from my cell phone that is longer than 160 chars (2 messages long) Kannel receives the first message and forwards it to my system, then receives the second part and forwards it to my system independently.
Is there are way to make sure multipart messages are concatenated properly in Kannel?
You can set in core group:
sms-combine-concatenated-mo = true
Related
I'm creating a load test where I try to sent three types of JSON messages through ActiveMQ topic to server. After sending first message I get 3 responses, sending second - get 2 responses according to business logic.
One iteration sequentially:
publish message1
consume 3 responses as a result of successful processing message1
publish message2
consume 2 responses as a result of successful processing message2
etcetera
I need to start 50 parallel iterations and not to confuse messages from different iterations. How can I do it?
I tried JMS selector but this one can filter messages by the headers only. I don't have any specific headers for each responses to get.
Can I filter messages, for example, by UUID? And how it can be implemented? I tried to find needed info on Internet but without results.
Will be very thankful for advices and help with it!
Yes, messages can be filtered by either header (fixed set of JMS header names) or by property (custom key-value pair).
JMSCorrelationID may be a good bet here. You can publish all messages for a given producer (or iteration) w/ the same JMSCorrelationID and then check the consumer counts that way.
ie.. for producer1 set: JMSCorrelationID = 'producer-1'
for producer2 set: JMSCorrelationID = 'producer-2'
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."
We have developed an SMPP server based on CloudHopper SMPP library. The system is in production processing a considerable volume of messages everyday.
Customers are allowed to maintain multiple TX binds for a higher throughput and redundancy. Recently we identified that a few of our customers send segmented messages (message parts) over multiple binds. So we receive parts of a single SMS over different binds from the same customer (same SystemId) and those are valid (in UDH, Having the same reference number, valid seq no etc).
We support concatenation on a bind level, but not across multiple binds.
Is it a standard/good practise to support concatenation for parts sent over multiple binds? Message reference number in the UDH header for concatenated messages should be unique for all binds created by an SMPP gateway? Any thoughts on this are welcome
UPDATE:
Regarding MessageRef no in UDH, we understood that there is no guarantee that it will be unique across multiple binds. (We see repeated MessageRef in concurrent binds from the same customer). Now we concatenate parts if they have the same MessageRef no and also the same destination number. We believe it is rare to receive two part sequences at the same time with equal MessageRef numbers, going towards the same mobile.
As long as a concatenated messages have valid UDH, I see not issue on this. SMSC further is usually transparent on this, altough it knows the multipart messages belong to single SMS message. From a practice side, customers usually have limitation on bind side just for 1 transmitter (on gigabit network should not be an issue), but this depends on number of messages/s they want to submit.
I usually have my own queue in between, so the submit response does not affect SMSC submit delay.
EMI/UCP is a protocol to communicate to SMS gateways.
I am confused how should I do in respect to network connection.
Do you open a socket for each logic bundle of data (and close it of course), or do you re-use the same socket?
How do you handle out-of-sequence responses in both cases?
My use case is send a couple of SMS with status request (submit short message), each will generate a traffic of 4 messages (a 51 operation and its ack and a 53 operation from the gateway plus the 53 ack).
If I open two sockets, may I be confident each dialog is performed on the some socket or is it a false assumption?
If I use a single socket, how I distinguish the messages from the two conversations? From the OaDC (originator address) only?
Answering the last question: you have to match the time stamp in the Ucp51 response message (ACK). It is the field: SCTS.
The correlation id is the couple SCTS and ADC (address caller: it is the recipient cell phone).
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.