Wholesale Long Code FAQ

Follow

Q) If I’m sending the same text message to a large number of phone numbers, it appears I have to do it as individual calls. Is this correct or can I send an array of numbers with the single message in a single call?

A) You would need to do individual calls. It's important to note that we don't allow marketing messages through our service.

 

Q) We had an issue where our DID got blocked as a spam number by upstream providers to our carrier. It took a while to clear this up, the result of which was we had to get a new number and change our messages to have a greater variety of text (10 versions of a message versus just the 1), and remove bit.ly links from the messages. Have you seen problems like this for customers? How did you resolve them?

A) With long codes, we use a pool of thousands of numbers in order to avoid triggering spam filters with the mobile operators. The actual throughput to handsets is limited by the specific carriers, which will allow a much lower throughput from a single number. As a rule of thumb, when working with a single number, we recommend keeping the message volume under 10 messages per minute, 200 messages per hour and 1000 messages a day. These are approximations, as every carrier has different policies, but we have found those numbers to work well. If a higher throughput is needed, we recommend using a pool of numbers big enough to maintain the traffic per number under the soft limits mentioned above; if using a pool of numbers is not an option, we suggest setting up a short code, which although more expensive, has better delivery rates and they are not subject to the limits mentioned above.

 

Q) Do you offer SMS forwarding?

A) No, we do not offer a SMS forwarding product.


Q) Why does our SMPP bind often reconnect?

A) Reconnects are normal in our setup. The bind should be configured to immediately reconnect on disconnect and messages should be queued in between.
Binds are restarted periodically to load or maintain configuration. None of the restarts exceed a couple of seconds and should not affect service if queuing and reconnect settings are configured properly.

 

Q) Why do handsets receive a "?" question mark between each character?

A) This happens when a message is encoded in UTF16 instead of UTF8. Messages must be encoded in UTF8, not 16.

 

Q) Why are we receiving "Fake DLR" when using SMPP?

A) Since we act as an SMSC aggregator, we don’t have visibility into the full message life-cycle, instead we provide DLR visibility to our gateway. Specifically, when setting the 'registered_delivery' flag of the 'submit_sm' SMPP PDU to 1, we will respond with bitmask 8 for smsc submit or bitmask 16 for smsc reject to acknowledge the receipt of the message by our gateway and either bitmask 1 for delivery success or bitmask 2 for delivery failure when the message has been delivered to our peering partner, not the handset.

In short, we only provide a response that the message has entered our gateway and passed along to our peering partner. We do not provide full life cycle DLR via long code and our 'SMS_ACK' is only an indication that we have received the message. This acknowledgment should in no way be interpreted as delivery to the handset.

In addition, a lack of delivery report does not in any way indicate a non delivery or a failed message. It simply means we have not received a delivery report from the relevant network.

 

Q)We are seeing delay in message delivery, why?

A) Delays in message delivery is normal for all SMS carriers. Once the message reaches the terminating carrier the carrier will attempt to deliver the message the receiving handset until they consider the message to be 'expired'. However, this is all carrier specific and will vary according to carrier policy. If the issue is persistent we recommend the handset owner contact their carrier to investigate the issue. 

Q) Why are we being billed for messages to invalid number or numbers to fixed(landline) numbers?

A) We don not validate the destination numbers as doing so is cost prohibiting and will result in a significantly higher rate on all your messages. If you want to avoid this, please validate the numbers on your side before submitting the messages to us.

 

Q) What is the max number of binds and throughput?

A) Long Code - Can have up to 50 messages per second, per bind, guaranteed.

 

Q) What are the supported Source Number (ANI) format?

A) We only support 11 digit DID for the Source Number. Alphanumeric and Source Numbers less than 11 digits are not supported, and may cause message failures.

 

Q) What types of character encoding is supported when sending messages?

A) We only support RAW Latin characters(xyz?!@) and UTF-8 in HEX format (CE BB CE AC CF 82). Any other character encoding may not appear as intended once received by the handset. Please refer to the SMSCv2 documentation for a PDU dump with example messages using our supported character sets.

Have more questions? Submit a request

Comments