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